4 ms·

> 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

> 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.
- wongarsu 5y ago
  > does this even apply to non-networked apps? Are you protecting your user from? Some pages render data from GET parameters, which allows XSS by giving people a link. There's also scenarios where data from localstorage, cookies or manually copy-pasted data is an attack vector. Imagine I get you to paste my document into your text editor and that allows me to extract all your data.
- runarberg 5y ago
  XSS is a known vulnerability in social hacking as well as shared data. Imagine an app which allows you to paste an input which will later be rendered as HTML. An attacker can create a malicious script and persuade the victims to copy it and paste in their app. This script might include `fetch` calls to a server the attacker controls which the attacker can use to spy or install malware on the victims machine. The above example is a vulnerability in the app just the same, it just requires the attacker to consider different avenues of delivery (such as sharing the malicious script on a forum) then in traditional server connected apps.
tinus_hn 5y ago
What is your ‘app’ and how does it get untrusted input without any server being involved? There is also a spec for how html should work. And finally, 100% of the useful functionality of this ‘api’ could be implemented using a Javascript library or server side. Yes, browsers have slight disagreements over handling broken html. So the first step of server side sanitation is to remove the broken stuff. This also removes a lot of cross browser incompatibility. And then you select tags and only allow the tags you want. Basic xss sanitation like it’s 1999. Nobody needs any built in api for this. This proposal is about solving a solved problem.
- fabiospampinato 5y ago
  It's an Electron ‘app’ that can open arbitrary files. This isn't the sort of API that unlocks some previously impossible feature, but DOMPurify is incredibly slow and I would trust the browser's implementation more, obviously. Rewriting DOMPurify better has always been an option, but that's not an easy value proposition for most developers, hence the best we've got is still DOMPurify.
  - tinus_hn 5y ago
    - you don’t need to add apis to Firefox to use them in an Electron app - It isn’t hard to do what this api does in Javascript as fast as the browser can do it. There already is api to convert strings to DOM and it isn’t exactly rocket science to iterate over the result and drop tags that aren’t on a list. I’m sure there can be a library that does it slowly but it doesn’t have to.
    - fabiospampinato 5y ago
      > - you don’t need to add apis to Firefox to use them in an Electron app Right, so what? > - It isn’t hard to do what this api does in Javascript as fast as the browser can do it. There already is api to convert strings to DOM and it isn’t exactly rocket science to iterate over the result and drop tags that aren’t on a list. I’m sure there can be a library that does it slowly but it doesn’t have to. Of course it's DOMPurify's fault for being that slow, nobody is arguing that it must be rewritten in C++ to be fast. It's not as simple as you put it though, unless you have an extremely strict list of tags containing no tags in which case it's trivial, but it's also of very little use. Since your comment sounds overly arrogant to my ears I'd like to point out that by following the rules that you mentioned for making a sanitizer (DOMParser + drop non-whitelisted tags basically) you can only produce either a useless or a broken sanitizer, it's impossible to make a useful and working sanitizer that way. Proof-ish: either you drop <img> nodes, in which case you've made a pretty useless sanitizer in my book, or you leave it in, in which case you leave yourself open to XSS via stuff like the onerror attribute. It's not trivial to write a sanitizer that both works and it's useful, almost no developers should need to learn all the nuances necessary for writing one, hence the platform itself should provide it.

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.
wongarsu 5y ago
> does this even apply to non-networked apps? Are you protecting your user from? Some pages render data from GET parameters, which allows XSS by giving people a link. There's also scenarios where data from localstorage, cookies or manually copy-pasted data is an attack vector. Imagine I get you to paste my document into your text editor and that allows me to extract all your data.
runarberg 5y ago
XSS is a known vulnerability in social hacking as well as shared data. Imagine an app which allows you to paste an input which will later be rendered as HTML. An attacker can create a malicious script and persuade the victims to copy it and paste in their app. This script might include `fetch` calls to a server the attacker controls which the attacker can use to spy or install malware on the victims machine. The above example is a vulnerability in the app just the same, it just requires the attacker to consider different avenues of delivery (such as sharing the malicious script on a forum) then in traditional server connected apps.

tinus_hn 5y ago

What is your ‘app’ and how does it get untrusted input without any server being involved? There is also a spec for how html should work. And finally, 100% of the useful functionality of this ‘api’ could be implemented using a Javascript library or server side. Yes, browsers have slight disagreements over handling broken html. So the first step of server side sanitation is to remove the broken stuff. This also removes a lot of cross browser incompatibility. And then you select tags and only allow the tags you want. Basic xss sanitation like it’s 1999. Nobody needs any built in api for this. This proposal is about solving a solved problem.

fabiospampinato 5y ago
It's an Electron ‘app’ that can open arbitrary files. This isn't the sort of API that unlocks some previously impossible feature, but DOMPurify is incredibly slow and I would trust the browser's implementation more, obviously. Rewriting DOMPurify better has always been an option, but that's not an easy value proposition for most developers, hence the best we've got is still DOMPurify.
- tinus_hn 5y ago
  - you don’t need to add apis to Firefox to use them in an Electron app - It isn’t hard to do what this api does in Javascript as fast as the browser can do it. There already is api to convert strings to DOM and it isn’t exactly rocket science to iterate over the result and drop tags that aren’t on a list. I’m sure there can be a library that does it slowly but it doesn’t have to.
  - fabiospampinato 5y ago
    > - you don’t need to add apis to Firefox to use them in an Electron app Right, so what? > - It isn’t hard to do what this api does in Javascript as fast as the browser can do it. There already is api to convert strings to DOM and it isn’t exactly rocket science to iterate over the result and drop tags that aren’t on a list. I’m sure there can be a library that does it slowly but it doesn’t have to. Of course it's DOMPurify's fault for being that slow, nobody is arguing that it must be rewritten in C++ to be fast. It's not as simple as you put it though, unless you have an extremely strict list of tags containing no tags in which case it's trivial, but it's also of very little use. Since your comment sounds overly arrogant to my ears I'd like to point out that by following the rules that you mentioned for making a sanitizer (DOMParser + drop non-whitelisted tags basically) you can only produce either a useless or a broken sanitizer, it's impossible to make a useful and working sanitizer that way. Proof-ish: either you drop <img> nodes, in which case you've made a pretty useless sanitizer in my book, or you leave it in, in which case you leave yourself open to XSS via stuff like the onerror attribute. It's not trivial to write a sanitizer that both works and it's useful, almost no developers should need to learn all the nuances necessary for writing one, hence the platform itself should provide it.