11–20 of 55 posts
Last time this was discussed: https://news.ycombinator.com/item?id=14192383 Still not convinced about the usefulness of the source, given the criticisms raised here and there.
When I see anything that touches web coding practices for Go I always look up an area that I know best: sanitization. I wrote https://github.com/microcosm-cc/bluemonday which is a pure Go HTML sanitizer inspired by https://github.com/owasp/java-html-sanitizer . The key things to understand about HTML sanitizers: * They must be whitelist based * They must be aware of context * You must sanitize ALL user input even if…
Not really.
When I see anything that touches web coding practices for Go I always look up an area that I know best: sanitization. I wrote https://github.com/microcosm-cc/bluemonday which is a pure Go HTML sanitizer inspired by https://github.com/owasp/java-html-sanitizer . The key things to understand about HTML sanitizers: * They must be whitelist based * They must be aware of context * You must sanitize ALL user input even if…
I'm not able to make sense of this. Sanitize it for what context? SQL? JSON? HTML? Inclusion as a command-line argument? All of these, and hope that sanitizing it for one context doesn't un-sanitize it for others?
When I see anything that touches web coding practices for Go I always look up an area that I know best: sanitization. I wrote https://github.com/microcosm-cc/bluemonday which is a pure Go HTML sanitizer inspired by https://github.com/owasp/java-html-sanitizer . The key things to understand about HTML sanitizers: * They must be whitelist based * They must be aware of context * You must sanitize ALL user input even if…
> You must sanitize ALL user input even if you don't think you're going to render it on a web page Not really.
Earlier quoted context omitted.
> You must sanitize ALL user input even if you don't think you're going to render it on a web page Not really.
Yes, really. Otherwise, you must take extra care not to reflect any input data back in any response to the user, whether it's in the HTML body or not. See: HTTP response splitting.
In fact, you have it totally backwards: you're not supposed to sanitize all user input before storing it. Instead you're supposed to sanitize any user input before you output it back to your webpage.
Even more so: it's the output that dictates what sanitization you should perform, not the input. You don't do input sanitization for HTML (for XSS etc) when you store your data in your DB. Instead you should sanitize the input for SQL Injection issues. And similarly for whatever other output -- if you take user input and run a shell command, you should sanitize for shell safety, not run html sanitization.
Earlier quoted context omitted.
Yes, really. Otherwise, you must take extra care not to reflect any input data back in any response to the user, whether it's in the HTML body or not. See: HTTP response splitting.
No, not really. In fact, you have it totally backwards: you're not supposed to sanitize all user input before storing it. Instead you're supposed to sanitize any user input before you output it back to your webpage. Even more so: it's the output that dictates what sanitization you should perform, not the input. You don't do input sanitization for HTML (for XSS etc) when you store your data in your DB. Instead you sho…
As long as the data is sanitized before it can affect the storage/transport mechanism for its content type, you're good.
When I see anything that touches web coding practices for Go I always look up an area that I know best: sanitization. I wrote https://github.com/microcosm-cc/bluemonday which is a pure Go HTML sanitizer inspired by https://github.com/owasp/java-html-sanitizer . The key things to understand about HTML sanitizers: * They must be whitelist based * They must be aware of context * You must sanitize ALL user input even if…
Perhaps it is more of a use-case question - I haven't worked on comment or wiki systems but that seems like it would be much harder to validate user inputs, and thus maybe that is where the line should be drawn? When user inputs are expressly expected to have markup?
Earlier quoted context omitted.
Yes, really. Otherwise, you must take extra care not to reflect any input data back in any response to the user, whether it's in the HTML body or not. See: HTTP response splitting.
No, not really. In fact, you have it totally backwards: you're not supposed to sanitize all user input before storing it. Instead you're supposed to sanitize any user input before you output it back to your webpage. Even more so: it's the output that dictates what sanitization you should perform, not the input. You don't do input sanitization for HTML (for XSS etc) when you store your data in your DB. Instead you sho…