search

dway123 / clipboard-pickling

An explainer for the Pickling proposal for the Clipboard API
3 stars 0 forks source link

`{direct: ['text/html']}` safety expectations and XSS #4

Open arturjanc opened 3 years ago

arturjanc commented 3 years ago

One of the concerns with including both sanitized and unsanitized data of the same type in the clipboard is that developers may have expectations about the safety of the data (based on the current safe behavior) and unwittingly expose their applications to bugs such as XSS.

Specifically, MIME types that are currently sanitized and can be written to the DOM safely (e.g. text/html) will stop being safe when the developer uses them as a direct format. This can potentially be improved by the renaming mentioned in https://github.com/dway123/clipboard-pickling/issues/2, but I'm worried that this could still be a footgun.

Another possible approach to consider could be to disallow 'text/html' and 'text/plain' in the list of direct MIME types. This would require developers to use a custom MIME type for unsanitized data which would hopefully indicate that the pickled contents of the clipboard are a separate format that cannot be safely written to the DOM without additional processing.

snianu commented 3 years ago

Thank you @arturjanc for the feedback! Excluding standard formats from pickling and XSS: I think this shouldn’t be a concern because the standard formats such as text/html is written as a new custom format(“Web Text Html”) into the clipboard when web authors provide it in direct list explicitly. This is also true for reading text/html pickled format where authors have to opt-in to read unsanitized version of standard format. We could rename direct to unsanitized to inform the web authors that the content is not safe to use without proper sanitization if that helps in mitigating this concern?

arturjanc commented 3 years ago

Yes, I realize this is safe by default -- my concern is primarily about developers using pickled HTML without realizing it doesn't have the same protections as the current clipboard API has for HTML. In principle, think we could either address it by default (e.g. disallow text/html) or by making it easier for developers to understand that they may be reading arbitrary HTML.

The latter, which you suggested above, is probably fine, as long as we expect it will make the risk clear to the users of the API.