21–30 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.
This guide still has some issues. It's missing common classes of web app vulns I've seen in Go code (e.g. CSRF, SSRF) and has some weird advice here and there (scan uploaded files with AV? Really?)
Earlier quoted context omitted.
This guide still has some issues. It's missing common classes of web app vulns I've seen in Go code (e.g. CSRF, SSRF) and has some weird advice here and there (scan uploaded files with AV? Really?)
Fail to scan with AV and you might be an unwitting malware distributor.
Under Validation and Storage > Storing password securely: the theory That code -- using sha256 to hash a password+salt, and store it in a db -- should not be there. Someone WILL copy paste it. Don't make it easy for people to do something stupid.
To be fair to the author, the paragraph immediately following that code snippet says: "However, this approach has several flaws and should not be used. It is given here only to illustrate the theory with a practical example. The next section explains how to correctly salt passwords in real life." and goes on to use bcrypt.
The code sample in question is in no way clearly labeled as being problematic, and a tiny statement buried in a large body of text does not change that fact.
is there an equivalent of this book for python?
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. 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?
Usually this means the HTML context. Different sanitization is needed depending on _where_ in the HTML document the input is used.
For instance, if the input is used in between HTML tags (let's say $foo is user input in this PHP example):
...
Therefore, to correctly sanitize this, you would call the PHP `htmlentities` function:
...
What if foo is used in a different context?
... '>...
The key problem is that `htmlentities` is not valid sanitization in the context of an HTML attribute value. In this example, you need to use `urlencode`
... '>...
I highly recommend the following research paper from 2011 that discusses the context-sensitivity of JavaScript in depth: http://www.comp.nus.edu.sg/~prateeks/papers/scriptgard-ccs11...
In my mind, the context-sensitivity of XSS is one of the key reasons why it is so prevalent.
Earlier quoted context omitted.
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…
You've said nothing that contradicts my post. As long as the data is sanitized before it can affect the storage/transport mechanism for its content type, you're good.
No, not really. Storing the user's data as is is almost always of paramount importance. The fact that it may be output as HTML/XML/MarkDown/whatever means that it really is at output-time that you must sanitize/escape/quote.
That's why the moral of the Bobby Tables story isn't: "Oh, just remove all semicolons". It's "use prepared queries".
Don't read it, always start with using a good framework. It will do everything for you
Earlier quoted context omitted.
You've said nothing that contradicts my post. As long as the data is sanitized before it can affect the storage/transport mechanism for its content type, you're good.
> As long as the data is sanitized before it can affect the storage/transport mechanism for its content type, you're good. No, not really. Storing the user's data as is is almost always of paramount importance. The fact that it may be output as HTML/XML/MarkDown/whatever means that it really is at output-time that you must sanitize/escape/quote. That's why the moral of the Bobby Tables story isn't: "Oh, just remove a…
Sometimes, data really does need to be sanitized at the point of submission. If you disagree, that's more of a point about application design than appsec.
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…
Honest and earnest question for you (as bluemonday's author): Where should gophers draw the line between Go's standard html/template library for rendering "safe" HTML, vs. needing to use bluemonday? The question assumes that any and all user inputs are checked/validated at the point of receipt. Is bluemonday just the "on steriods" version (e.g. provides more granular control, whitelist of specific tags, etc)? Perhaps…
If you accept any user input and this will be displayed or processed anywhere (be it in HTML fragments, input to SQL, etc)... then sanitize it and use bluemonday or any other sanitizer applicable to your content.
For user generated content, like comments on Hacker News, there is a pretty rich policy provided by bluemonday so you don't have to think about it and are going to be alright.
That looks like this:
p := bluemonday.UGCPolicy()
htmlOut := p.Sanitize(htmlIn)