src/href blacklisting? about dompurify

[cure53]

That part indeed might need optimization. It was created based on the need to allow Data URIs for images and images only. Pull requests and tests are very much welcome!

[devd]

ok. Before I send in a PR, are there any attribtutes other than src/href that we want to support URIs in?

[fhemberger]

What about poster (video), xlink:href (svg)? (The first ones which come to my mind)

[devd]

I was thinking I will continue with the current behavior, but add a more explicit check for src and href attributes, saying that those must be http/https and data: if tag is img.

so, I don't think I am affecting any of the other cases you mentioned. wdyt?

[cure53]

One thing that is hard to check is the values attribute in SVG. It can contain comma-separated animation steps even for xlink:href. Then there is from and to, also residing in the SVG namespace.

Those attributes were the reason for the code we have right now. And not to forget formaction and friends :) I would really like to validate by API, it's open so many interesting possibilities too. But HTML/SVG are not there yet imho.

[fhemberger]

@devd I'm not sure that filtering by URL schemes is a good idea for general purpose tools like DOMPurify, as there are a lot of other valid schemes (tel, skype, magnet, etc.)

[devd]

isn't that actually a good argument to why we should be filtering: else untrusted content can show a link to some custom scheme on android that can do very bad things, including launching applications, from a click on a link on a (supposedly) safe and purified page?

[cure53]

Yes, I believe it is. But what we don't need is a discussion about the necessity of URL filtering where we bounce from yes to no and all the way back again. What we need is essentially two things:

• A list of use cases. How would URL/protocol filtering be useful to have for developers? What would a developer expect from an API like ours to make it easy? What should we use for a secure default, how should we offer relaxation from the strict default?
• A detailed exploration and documentation of possible and certain problems. SVG is one, based on set and animate and the attributes from, to and values with potential for more. HTML5 formaction is another one, DataURIs pointing to SVGs containing URIs is the next. At least on MSIE because of a bug.

I fear that this is not a simple three-line change and requires us to do a lot of busy-work before we can produce something reasonable. What about resources requested via CSS for example? Technically, we'd even need a threat model for this, I think it's a very complex issue - yet implementing it would give DOMPurify an amazing new feature. And get us a step closer to i.e. being able to block all external requests. Which would be major!

@devd So, to start with the easiest task first: What use cases do we have, how should the API look like to make this kind of filtering be useful?

[devd]

Sorry, didn't meant to make the discussion into this oscillation. But, I think this discussion is actually really important! The email from Frederic about URI schemes missed my inbox and I only saw it because I started thinking again about implementing a patch.

The basic use case I am interested in is showing user comments, user-provided data (like their names, email ids, and so on safely). I believe the default for this should be to disallow everything other than http(s) and possibly mailto: URIs.

My use cases isn't really interested in SVG and I am fine with blanket blocking all of SVG and also not interested in allowing <form> tag through DOMPurify.

I think the API should default to the above and then we can get into more complicated scenarios: developers can provide a set of whitelisted URI schemes or provide a set of whitelisted URI schemes per tag (or even tag+attribute pair)

[fhemberger]

As @cure53 already outlined, this is quite a complex matter. Also people might have various different use cases for URL filtering, so it's important to find a broad level of abstraction for the library, rather than tying it to a few special cases.

I'd strongly suggest to add this feature as some kind of plugin/extension, to keep the DOMPurify core compact. This would allow us to have more flexible rulesets for filtering (based on individual needs).

[cure53]

@devd @fhemberger +1 on the plugin idea.

Once we have that, we can make the URL filter, jPurify and many other things become plugins. Should we switch thread and discuss how we can do that?

My initial thought would be we add hooks at certain points in DOMPurify's code where plugins can act and influence a limited amount of objects.

[devd]

plugin works for me, but I do want to ask you to reconsider the defaults. I would prefer to recommend DOMPurify "just use it and don't think about it" :) Historically, default is what everyone uses.

[cure53]

Yes, then let's first collect what we need for a safe default. That needs to be clear first, then we can start designing and implementing.

To me it's not clear yet what safe default will really mean. And protect against.

[devd]

My vote for safe default is no URI schemes other than http(s). Although, I believe that would be a fascinating question for web security experts and (more importantly) developers. wdyt?

[cure53]

Fair enough. Now we need a map of elements that can send HTTP requests. This would include CSS and SVG. We also need a module that detects if one of those elements was added to white-list manually.

The more I keep thinking about this, the more I believe we need a plugin architecture first, a CSS parser nest - and then we can take care of URIs.

[devd]

that's fine. I am ok with a plugin architecture too.

[cure53]

I'll close this for now.