4 ms·
XSS prevention cheat sheet: 1) Never send untrusted data to the client. How you do that isn't terribly important. It just matters that you do. Which is what t
by Xk 16y ago
XSS prevention cheat sheet:
1) Never send untrusted data to the client.
How you do that isn't terribly important. It just matters that you do. Which is what that page is talking about: what you can do in order to never send untrusted data to the client.
Web developers would love it if there was a paragraph explanation that could explain how to prevent all XSS vulnerabilities in every site in detail, but there isn't.
- Semiapies 16y agoAbsolutely right. It might be nice to call this useful document something else, though. "XSS prevention summary" or whatever.
- Xurinos 16y agoThat's excellent! We can pair that with the other prevention cheat sheet: 1) Never trust what the client sends you. AKA "How to prevent SQL injection and other such nasties"
- tptacek 16y agoThese are the two least-useful pieces of advice in software security. Everyone has heard them, nobody is secure. Great counter-indication of software security: "We have no SQL injection. No way. You'd get fired." What that tells me? You're not looking out for SQL injection; you think it can't happen.
- khafra 16y agoSomeone here--it may have been you--highlighted this problem once as the difference between a diet that works and public policy on diet that works. If you actually follow the (security guidelines|diet), you'll be good; but naively telling people has very little effect.
- Xurinos 16y agoYou can lead a horse to water, but you can't make it drink.
- pornel 16y agoActually, that's not entirely correct. It should be: 1) escape data to prevent it from being interpreted as code Because this security problem is just subset of markup correctness problem. If you escape data perfectly, then both trusted and untrusted data won't be misinterpreted, e.g. I can echo any evil input if my character encoding is enforced and HTML special chars are escaped as entities. I can send any untrusted nastiness to database via prepared SQL statement.
- Xurinos 16y ago> escape data to prevent it from being interpreted as code What about too much data? Overflow is a concern, too. Escaping is just one solution, so I shot for the more general rule.
- pornel 16y ago> What about too much data? Overflow is a concern Buffers are not supposed to overflow with trusted data either, so again, security is subset of correctness. "Not trusting" data only prevents exploit from reaching vulnerable code, it doesn't fix the vulnerability. Don't write web applications C? ;)
- Swannie 16y ago"e.g. I can echo any evil input if my character encoding is enforced and HTML special chars are escaped as entities." FAIL :-P AFAIK You need to JS escape anything that goes into a JS context too.
- Xurinos 16y agoAnd if you send that data from JS to the server, you cannot rely on the theory that JS massaged that data first.
- pornel 16y agoYou're right - escaping is very dependent on context, and sometimes you need to escape data multiple times in nested contexts. In inline script you need to get JS string escaping right and avoid </ sequence that ends HTML CDATA.