4 ms·

This is solving an issue in the browser that should be solved server side. Where is this data they are sanitizing coming from? Why would you want every browser

This is solving an issue in the browser that should be solved server side. Where is this data they are sanitizing coming from? Why would you want every browser treating this differently?

dobin 5y ago
It doesnt matter where the data is coming from, it matters what it is able to do. As always with security, if the server attempts to protect the client app by emulating its behaviour, it will go wrong (as the server is never able to emulate the client perfectly). This is a problem in most of the magic black security boxes (WAF, IPS, DLP etc.). The browser knows if a certain piece of data will perform execution or not, as it is the software implementing the functionality. It is the correct app to ask, as it is the one being exploited.
masa331 5y ago
This is for sanitizing content generated client-side which might not touch server at all. You can create HTML and put it into the DOM on the client
- silon42 5y ago
  If you are generating, you should have a whitelist of safe html/css.. Apart from performance this smells of not using a whitelist mechanism (I hope this is not the case).
  - masa331 5y ago
    What? Whitelisting is one technique which you can use in sanitizing content generated from unknown sources. If you need to generated such content then it's a probably a special feature of your software and no smell
  - kapep 5y ago
    > this smells of not using a whitelist mechanism What makes you think that? I just skimmed the draft and it seems to use a sensible whitelist as default. Developers can allow or deny additional elements/attributes as they like.
_vvhw 5y ago
In fact, this is actually an issue that can only be properly solved in the browser, hence the need for security projects like DOMPurify in the past. The reason being that all browsers parse potential XSS (and mXSS) content slightly differently so that a server side sanitizer by definition will never parse content in exactly the same way as a specific version of a given browser, since it's not sharing exactly the same runtime. This semantic gap between browser rendering quirks and server side approximations can be exploited by an attacker to slip content past the server side sanitizer. And that's why the browser vendors are actively working with Cure53, the author of DOMPurify, in order to ship Sanitizer API. I'm just surprised this has taken so long.
- cxr 5y ago
  A reminder: people, please don't take your cues on language theoretic security (or anything security-related) from internet comments containing unverified claims, even if those comments aren't nameless/faceless and are moderately-to-highly upvoted. The parent comment is an example, appearing to have the approval of the community, but there are several subtle things wrong (or just odd) with it. It's short of misleading people into doing anything harmful, though, so stopping the world to hash them out here isn't critical, and would be tedious besides. Aside from that, a subset of people using DOMPurify—maybe even a plurality—seem to treat it as a talisman and can't explain how or if they've configured it correctly to provide the kind of protections they need for their use case. Security is not a separable concern.
  - _vvhw 5y ago
    It would be better for your comment to provide reasonable objections as to why DOMPurify should not be considered state of the art, without spreading fear, uncertainty or doubt.
  - mcherm 5y ago
    > The parent comment is an example, appearing to have the approval of the community, but there are several subtle things wrong (or just odd) with it. It's short of misleading people into doing anything harmful, though, so stopping the world to hash them out here isn't critical, and would be tedious besides. It is not clear to me what subtle things are wrong with the parent comment. But I'm pretty sure I can see the flaw in claiming that something is wrong without saying how. It's an impossible-to-disprove accusation which therefore does not advance the conversation.
fabiospampinato 5y ago
> This is solving an issue in the browser that should be solved server side. This doesn't make much sense to me, my app doesn't even rely on any servers, what do you suggest I do then? > Where is this data they are sanitizing coming from? It's untrusted, what does it matter where exactly it comes from? > Why would you want every browser treating this differently? Why do you say that each browser would tread this differently? There's a spec for how this should work: https://wicg.github.io/sanitizer-api/ https://wicg.github.io/sanitizer-api/
- resonious 5y ago
  > my app doesn't even rely on any servers, what do you suggest I do then? Although I agree that there is nothing wrong with client-side sanitization, does this even apply to non-networked apps? Are you protecting your user from? Or perhaps by "doesn't rely on any servers" you mean "serverless", which doesn't literally mean no servers. If your app's client hits a database-as-a-service somewhere then that is a server and it very well can sanitize for you.
  - pjerem 5y ago
    I think it's "doesn't rely on any servers that you own". You can have no back-end code but still can call external APIs hosted on servers you don't control or which can be compromised by malicious user generated content.
  - esrauch 5y ago
    Besides the other comments there are legitimate security reasons to be worried about sanitizing in general even in zero-rpc-app cases; malicious files are an attack vector. Eg if you were making Calibre you do still want to be hardened against malicious local files from hijacking the app.
  - fabiospampinato 5y ago
    > Although I agree that there is nothing wrong with client-side sanitization, does this even apply to non-networked apps? Are you protecting your user from? Kind of from themselves, the app can open arbitrary files, you can't have people nuke themselves by opening a random file they got from the internet, or by pasting in something they don't understand. Also a plugin may sort of escape from the boundaries put on it by XSS-ing its user by outputting some malicious stuff. > Or perhaps by "doesn't rely on any servers" you mean "serverless", which doesn't literally mean no servers. If your app's client hits a database-as-a-service somewhere then that is a server and it very well can sanitize for you. No I actually meant no servers at all, it's a 100% local Electron app.
bugmen0t 5y ago
If you sanitize on the server, you are sanitizing for a theoretical browser and how _you_ might think it parse HTML. Any kind of parsing ambiguity will lead to XSS. That's why you should be using an API that relies on the browser's parser.
zerkten 5y ago
The right answer here is probably that there are some apps which have a no backend, or a limited one, where the possibility of handling dangerous input exists and this provides a standard solution. Further, it's not a panacea. Defense-in-depth still applies, so server-side and other mitigations will still be appropriate. Build and use threat models to understand what is appropriate.

This is solving an issue in the browser that should be solved server side. Where is this data they are sanitizing coming from? Why would you want every browser treating this differently?

dobin 5y ago

It doesnt matter where the data is coming from, it matters what it is able to do. As always with security, if the server attempts to protect the client app by emulating its behaviour, it will go wrong (as the server is never able to emulate the client perfectly). This is a problem in most of the magic black security boxes (WAF, IPS, DLP etc.). The browser knows if a certain piece of data will perform execution or not, as it is the software implementing the functionality. It is the correct app to ask, as it is the one being exploited.

masa331 5y ago

This is for sanitizing content generated client-side which might not touch server at all. You can create HTML and put it into the DOM on the client

silon42 5y ago
If you are generating, you should have a whitelist of safe html/css.. Apart from performance this smells of not using a whitelist mechanism (I hope this is not the case).
- masa331 5y ago
  What? Whitelisting is one technique which you can use in sanitizing content generated from unknown sources. If you need to generated such content then it's a probably a special feature of your software and no smell
- kapep 5y ago
  > this smells of not using a whitelist mechanism What makes you think that? I just skimmed the draft and it seems to use a sensible whitelist as default. Developers can allow or deny additional elements/attributes as they like.

_vvhw 5y ago

In fact, this is actually an issue that can only be properly solved in the browser, hence the need for security projects like DOMPurify in the past. The reason being that all browsers parse potential XSS (and mXSS) content slightly differently so that a server side sanitizer by definition will never parse content in exactly the same way as a specific version of a given browser, since it's not sharing exactly the same runtime. This semantic gap between browser rendering quirks and server side approximations can be exploited by an attacker to slip content past the server side sanitizer. And that's why the browser vendors are actively working with Cure53, the author of DOMPurify, in order to ship Sanitizer API. I'm just surprised this has taken so long.

cxr 5y ago
A reminder: people, please don't take your cues on language theoretic security (or anything security-related) from internet comments containing unverified claims, even if those comments aren't nameless/faceless and are moderately-to-highly upvoted. The parent comment is an example, appearing to have the approval of the community, but there are several subtle things wrong (or just odd) with it. It's short of misleading people into doing anything harmful, though, so stopping the world to hash them out here isn't critical, and would be tedious besides. Aside from that, a subset of people using DOMPurify—maybe even a plurality—seem to treat it as a talisman and can't explain how or if they've configured it correctly to provide the kind of protections they need for their use case. Security is not a separable concern.
- _vvhw 5y ago
  It would be better for your comment to provide reasonable objections as to why DOMPurify should not be considered state of the art, without spreading fear, uncertainty or doubt.
- mcherm 5y ago
  > The parent comment is an example, appearing to have the approval of the community, but there are several subtle things wrong (or just odd) with it. It's short of misleading people into doing anything harmful, though, so stopping the world to hash them out here isn't critical, and would be tedious besides. It is not clear to me what subtle things are wrong with the parent comment. But I'm pretty sure I can see the flaw in claiming that something is wrong without saying how. It's an impossible-to-disprove accusation which therefore does not advance the conversation.

fabiospampinato 5y ago

> This is solving an issue in the browser that should be solved server side. This doesn't make much sense to me, my app doesn't even rely on any servers, what do you suggest I do then? > Where is this data they are sanitizing coming from? It's untrusted, what does it matter where exactly it comes from? > Why would you want every browser treating this differently? Why do you say that each browser would tread this differently? There's a spec for how this should work: https://wicg.github.io/sanitizer-api/ https://wicg.github.io/sanitizer-api/

resonious 5y ago
> my app doesn't even rely on any servers, what do you suggest I do then? Although I agree that there is nothing wrong with client-side sanitization, does this even apply to non-networked apps? Are you protecting your user from? Or perhaps by "doesn't rely on any servers" you mean "serverless", which doesn't literally mean no servers. If your app's client hits a database-as-a-service somewhere then that is a server and it very well can sanitize for you.
- pjerem 5y ago
  I think it's "doesn't rely on any servers that you own". You can have no back-end code but still can call external APIs hosted on servers you don't control or which can be compromised by malicious user generated content.
- esrauch 5y ago
  Besides the other comments there are legitimate security reasons to be worried about sanitizing in general even in zero-rpc-app cases; malicious files are an attack vector. Eg if you were making Calibre you do still want to be hardened against malicious local files from hijacking the app.
- fabiospampinato 5y ago
  > Although I agree that there is nothing wrong with client-side sanitization, does this even apply to non-networked apps? Are you protecting your user from? Kind of from themselves, the app can open arbitrary files, you can't have people nuke themselves by opening a random file they got from the internet, or by pasting in something they don't understand. Also a plugin may sort of escape from the boundaries put on it by XSS-ing its user by outputting some malicious stuff. > Or perhaps by "doesn't rely on any servers" you mean "serverless", which doesn't literally mean no servers. If your app's client hits a database-as-a-service somewhere then that is a server and it very well can sanitize for you. No I actually meant no servers at all, it's a 100% local Electron app.

bugmen0t 5y ago

If you sanitize on the server, you are sanitizing for a theoretical browser and how _you_ might think it parse HTML. Any kind of parsing ambiguity will lead to XSS. That's why you should be using an API that relies on the browser's parser.

zerkten 5y ago

The right answer here is probably that there are some apps which have a no backend, or a limited one, where the possibility of handling dangerous input exists and this provides a standard solution. Further, it's not a panacea. Defense-in-depth still applies, so server-side and other mitigations will still be appropriate. Build and use threat models to understand what is appropriate.