search

OWASP / java-html-sanitizer

Takes third-party HTML and produces HTML that is safe to embed in your web application. Fast and easy to configure.
Other
854 stars 214 forks source link

Add a prepackaged policy for client-side templates. #106

Open joankaradimov opened 7 years ago

joankaradimov commented 7 years ago

It would make some sense to be able to easily control (disable completely) the sanitization of client-side templates. Maybe this can be a prepackaged policy. Even if there is a way to do this now, I found no easy way to do it.

jmanico commented 7 years ago

This seems like an dangerous request. Client side template code should still come from a trusted location. If you let attackers drive JS client template code they can XSS through things like angular expressions, javascript url's and all kinds of other vectors. Can you give us more info here?

Aloha,

Jim Manico @Manicode

On Feb 7, 2017, at 6:58 AM, Joan Karadimov notifications@github.com wrote:

It would make some sense to be able to easily control (disable completely) the sanitization of client-side templates. Maybe this can be a prepackaged policy. Even if there is a way to do this now, I found no easy way to do it.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

joankaradimov commented 7 years ago

Yes, I agree that client side templates can be dangerous.

However, with the policy builder a user of the library can allow potentially dangerous HTML. And that's completely fine, provided that this is done explicitly. It should not be inconsistent to have a similar mechanism for client-side templates.

I am not asking that this is the default behaviour. I am merely suggesting that there are use cases where this is needed.

Can you give us more info here?

I use Handlebars.java for email templates. I need users to be able to define their own templates. The client-side templates are actually used on the server. I control the helpers that are exposed and the context in which stuff is rendered in double mustaches.

jmanico commented 7 years ago

I need users to be able to define their own templates.

My take is, this is not what the tool is for. It's for HTML sanitization, not custom framework template code sanitization. But that's just my take. Please give Mike a chance to respond and thank you for your additional explanation.

Respectfully,

Jim Manico @Manicode

On Feb 7, 2017, at 8:45 AM, Joan Karadimov notifications@github.com wrote:

I need users to be able to define their own templates.

jmanico commented 7 years ago

And just one more note Joan. The point I'm trying to make is that a "legal and valid template snippet" can still cause XSS. Any template sanitizer would need very complex rules to understand those idiosyncrasies. That's what overwhelms me about this request. I think it's painfully tough to get right and a lot of custom code would be needed for each framework...

Aloha,

Jim Manico @Manicode

On Feb 7, 2017, at 8:45 AM, Joan Karadimov notifications@github.com wrote:

Yes, I agree that client side templates can be dangerous.

However, with the policy builder a user of the library can allow potentially dangerous HTML. And that's completely fine, provided that this is done explicitly. It should not be inconsistent to have a similar mechanism for client-side templates.

I am not asking that this is the default behaviour. I am merely suggesting that there are use cases where this is needed.

Can you give us more info here?

I use Handlebars.java for email templates. I need users to be able to define their own templates. The client-side templates are actually used on the server. I control the helpers that are exposed and the context in which stuff is rendered in double mustaches.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

amakhrov commented 3 years ago

In 2021 it's not that easy to execute custom code in a framework like React or Angular - even if the {{ }} are not escaped.

On the other hand, an application might have its own reasons to have {{ }} in html, while it doesn't even use potentially vulnerable templating libraries you had in mind originally. Being able to opt out of this special {{ processing sounds very valuable.

jmanico commented 3 years ago

In 2021 it's not that easy to execute custom code in a framework like React or Angular - even if the |{{ }}| are not escaped.

Actually it is. In react dangerouslySetInnerHTML will bypass escaping. In Angular the bypassSecurityTrustAs series of functions will bypass escaping. In Vue.js v-html bypasses escaping.

In Angular, you have the built-in ng-bind-html which is an integrated HTML sanitizer to protect you from XSS if you need to render HTML in Angular safely.

In React, I suggest you use DOMPurify whenever developers choose to disable React's escaping with dangerouslySetInnerHTML because they need to render HTML. https://github.com/cure53/DOMPurify

In Vue.js, I suggest you use the v-dompurify-html module to provide native HTML sanitization.

I do not believe that the OWASP Java HTML sanitizer should address {{}} any differently than standard HTML processors. Our job is to sanitize HTML and nothing more. We do not handle specialized template markup and will not likely add it, it's a misuse of the library. You should be taking the use template - then convert that to HTML - and then use our library server-side if you need server side HTML sanitization in your API's or similar.

I again suggest you also use your JS frameworks properly if you want to allow HTML to be rendered there as described above.

Respectfully,