4 ms·

How to people do proper XSS protection and more importantly validate against it? It's effectively a manual process of calling appropriate escaping (html, css,

by tmd83 6y ago

How to people do proper XSS protection and more importantly validate against it? It's effectively a manual process of calling appropriate escaping (html, css, js) at every dynamic output site. Ensuring you are doing it 100% in thousands if not millions of calls is daunting. I have seen security tools crawling your app and using payload to test for vulnerability which sounds nice in theory but in a really complex application where you need to understand the business rules to even crawl the whole application (not get caught up on validation/error) how do people ensure that?

nom 6y ago
Not sure about validation, but Content-Security-Policy is the best tool we have at our disposal right now to prevent XSS - define what content the browser is allowed to load and execute. I have a feeling it will remain a very manual and diligent process. Be always on top of new techniques and solutions, have a good understanding how everything works in detail and reduce your attack surface by keeping things simple.
- yoloClin 6y ago
  I agree with CSP, but as I've commented on another thread I recommend CSP _with_ other mitigation factors due to DOM/HTML injection, and browser support.
continuational 6y ago
You simply never use string concatenation to produce HTML, CSS, JS, SQL, etc. Instead, use e.g. an HTML library that automatically escapes strings. Then you don't even have to think about it.
bawolff 6y ago
You use libraries with safe apis that make it easy to do the right thing and hard to do the wrong thing. Often this means you generate some sort of data structure which gets serialized into html by a library as a last step (e.g. React, but there are lots of other examples). If you're always using safe apis, its really easy to verify that you dont do the wrong thing (e.g. via static analysis, or even grep. Browsers are even now suporting trusted types to dynamically verify this at runtime)
- bjoli 6y ago
  I remember back in the days when SQL injections were a big thing. I was a newb and had no idea what I was doing, but I was using a scheme library that created the queries by something akin to format strings (or was it something like quasiquoted s-expressions? It is almost 20 years ago). Anyway, it did the right thing: it escaped everything. The result? The website of my little diablo 2 clan was the only one in my group of friends that did not get hacked. Due to me using an obscure library that did the right thing in a language nobody liked. It wasn't any victory of mine. Had I used PHP I would have been just as pwned as my friends.
  - simion314 6y ago
    >Had I used PHP I would have been just as pwned as my friends. This is a myth, the issue is if you learn by Google instead of using something like a book. All languages and libraries (that I used) allow you to run raw sql if you need and all books/good learning materials when introducing SQL will explain how to do the correct thing with escaping parameters or even nicer using bound paramters.
    - bjoli 6y ago
      That was the thing I was trying to convey: what was offered for me was a safe API. The things all the PHP tutorials of 2001 taught was "glue strings together and it will do what you want". That was the knowledge offered for us 13 years olds wanting to write a discussion board for our game groups. I think it is a lovely example of "the simple thing should be the safe thing, and if you need more there should be ample warning". That was not the case of PHP 4.0. Anecdote: the Swedish PHP book (I recall there being only one) that most of us got taught the string building approach without any escaping. The oldest things I can find Googling now are from 2007 and are almost all safe, either through PDO or a safe mysqli interface.
      - simion314 6y ago
        But this is not a language issue but some educational problem, it depends on luck if you land on some bad book or tutorial. If the language offers performance it must give me access to unsafe stuff like run raw SQL.
vbezhenar 6y ago
AFAIK Go template library parses HTML and applies appropriate escaping depending on context. I think that most sane HTML template libraries will do at least HTML escaping by default. Dynamic CSS and JS usually rare so you can pay extra attention.
pimterry 6y ago
In general: never mix user input indistinguishably from control content. In HTML generation, that means you never dynamically parse HTML generated directly from raw data. E.g. in React, you define your content entirely in terms of components that are explicitly defined in your code (no HTML parsing - they're objects in your code, explicitly built by your code) and content for those components (still no HTML parsing, they directly become text either for attribute params, or for text nodes that sit within your HTML tags). It's the same as protecting against SQL injection. Don't interpolate user input directly into a SQL string and then parse it. Define/generate the query in your code separately, with explicit parameter placeholders for where dynamic input will go, and then provide variables that can be safely used for those parameters, but which are never parsed as part of the query itself. For HTML, the only time this becomes challenging is when you accept user input that is itself HTML already. In that case, you have to parse it, and you have a big problem. Don't do that, wherever possible. Accept structured data, accept plaintext text, accept markdown (without HTML tags either disabled or _extremely_ carefully limited), but wherever possible, don't accept and output HTML given to you by a user. For similar reasons, don't accept SQL queries uploaded by a user. Dompurify exists for the case where you can't do this, but in general it's better, and not that hard, to avoid needing it at all.

by tmd83 6y ago

nom 6y ago

Not sure about validation, but Content-Security-Policy is the best tool we have at our disposal right now to prevent XSS - define what content the browser is allowed to load and execute. I have a feeling it will remain a very manual and diligent process. Be always on top of new techniques and solutions, have a good understanding how everything works in detail and reduce your attack surface by keeping things simple.

yoloClin 6y ago
I agree with CSP, but as I've commented on another thread I recommend CSP _with_ other mitigation factors due to DOM/HTML injection, and browser support.

continuational 6y ago

You simply never use string concatenation to produce HTML, CSS, JS, SQL, etc. Instead, use e.g. an HTML library that automatically escapes strings. Then you don't even have to think about it.

bawolff 6y ago

You use libraries with safe apis that make it easy to do the right thing and hard to do the wrong thing. Often this means you generate some sort of data structure which gets serialized into html by a library as a last step (e.g. React, but there are lots of other examples). If you're always using safe apis, its really easy to verify that you dont do the wrong thing (e.g. via static analysis, or even grep. Browsers are even now suporting trusted types to dynamically verify this at runtime)

bjoli 6y ago
I remember back in the days when SQL injections were a big thing. I was a newb and had no idea what I was doing, but I was using a scheme library that created the queries by something akin to format strings (or was it something like quasiquoted s-expressions? It is almost 20 years ago). Anyway, it did the right thing: it escaped everything. The result? The website of my little diablo 2 clan was the only one in my group of friends that did not get hacked. Due to me using an obscure library that did the right thing in a language nobody liked. It wasn't any victory of mine. Had I used PHP I would have been just as pwned as my friends.
- simion314 6y ago
  >Had I used PHP I would have been just as pwned as my friends. This is a myth, the issue is if you learn by Google instead of using something like a book. All languages and libraries (that I used) allow you to run raw sql if you need and all books/good learning materials when introducing SQL will explain how to do the correct thing with escaping parameters or even nicer using bound paramters.
  - bjoli 6y ago
    That was the thing I was trying to convey: what was offered for me was a safe API. The things all the PHP tutorials of 2001 taught was "glue strings together and it will do what you want". That was the knowledge offered for us 13 years olds wanting to write a discussion board for our game groups. I think it is a lovely example of "the simple thing should be the safe thing, and if you need more there should be ample warning". That was not the case of PHP 4.0. Anecdote: the Swedish PHP book (I recall there being only one) that most of us got taught the string building approach without any escaping. The oldest things I can find Googling now are from 2007 and are almost all safe, either through PDO or a safe mysqli interface.
    - simion314 6y ago
      But this is not a language issue but some educational problem, it depends on luck if you land on some bad book or tutorial. If the language offers performance it must give me access to unsafe stuff like run raw SQL.

vbezhenar 6y ago

AFAIK Go template library parses HTML and applies appropriate escaping depending on context. I think that most sane HTML template libraries will do at least HTML escaping by default. Dynamic CSS and JS usually rare so you can pay extra attention.

pimterry 6y ago

In general: never mix user input indistinguishably from control content. In HTML generation, that means you never dynamically parse HTML generated directly from raw data. E.g. in React, you define your content entirely in terms of components that are explicitly defined in your code (no HTML parsing - they're objects in your code, explicitly built by your code) and content for those components (still no HTML parsing, they directly become text either for attribute params, or for text nodes that sit within your HTML tags). It's the same as protecting against SQL injection. Don't interpolate user input directly into a SQL string and then parse it. Define/generate the query in your code separately, with explicit parameter placeholders for where dynamic input will go, and then provide variables that can be safely used for those parameters, but which are never parsed as part of the query itself. For HTML, the only time this becomes challenging is when you accept user input that is itself HTML already. In that case, you have to parse it, and you have a big problem. Don't do that, wherever possible. Accept structured data, accept plaintext text, accept markdown (without HTML tags either disabled or _extremely_ carefully limited), but wherever possible, don't accept and output HTML given to you by a user. For similar reasons, don't accept SQL queries uploaded by a user. Dompurify exists for the case where you can't do this, but in general it's better, and not that hard, to avoid needing it at all.