Go Language – Web Application Secure Coding Practices
checkmarx.gitbooks.io
Go Language – Web Application Secure Coding Practices
1–10 of 55 posts
Re: Go Language – Web Application Secure Coding Practices
#2Go has also an amazing static-analysis tool, vet, that is not mentioned in the article: https://golang.org/cmd/vet/
It can find printf-format errors, invalid shifts, unreachable code, etc.
Even though go vet is very helpful, it is sometimes scary that the compiler allows to build such incorrect code. For instance: https://play.golang.org/p/2AVHUt5Wcf
Re: Go Language – Web Application Secure Coding Practices
#3When 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 don't think you're going to render it on a web page.
The book linked to in the article does not seem to understand any of the above.
The section on sanitization has the equivalent of "string replace" as the primary recommendation. Elsewhere in the XSS section a focus is on escaping content before it is rendered.
Sanitization needs to know not to run on
blocks, and to escape HTML entities automatically, and to understand what links are safe and which are not.XSS can be really interesting and quite targeted. It can be that a user-agent contains the XSS, because the target may not be the person reading the page but the admin looking at a web page of their web server logs through an analytics program on the same domain.
The bluemonday package I wrote can deal with all of these things but that isn't the point, the point is that this is an area I know and the book falls way short of a decent standard for creating a secure and safe web application. And if it falls short in this area (the first 2 chapters) then I would assume that it falls short in all areas.
Re: Go Language – Web Application Secure Coding Practices
#4Under 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.
Re: Go Language – Web Application Secure Coding Practices
#5Theres a whole section on stored procedures - it was my understanding that the database/sql package in the sodlib didn't support stored procedures (something to do with multiple rows or output var support)
Re: Go Language – Web Application Secure Coding Practices
#6Under 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.
Re: Go Language – Web Application Secure Coding Practices
#7Under 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 fear is that people won't read that or just use the SHA256 example because it's before the bcrypt one, or maybe because they find it runs faster.
IMHO, I think examples of dangerous code should implement one of the following mindless-script-kiddie-consultant defenses (in order of most sane to least sane):
1. use screenshots of the snippet
2. use pseudo-code
3. put in deliberate syntax mistakes
4. have a javascript alert on right-click or ctrl/cmd+c with the warning about it being unsafe (a.k.a. going full 90s)
Re: Go Language – Web Application Secure Coding Practices
#8Last 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.
Re: Go Language – Web Application Secure Coding Practices
#9Earlier quoted context omitted.
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 fear is that people won't read that or just use the SHA256 example because it's before the bcrypt one, or maybe because they find it runs faster. IMHO, I think examples of dangerous code should implement one of the following mindless-script-kiddie-consultant defenses (in order of most sane to least sane): 1. use screenshots of the snippet 2. use pseudo-code 3. put in deliberate syntax mistakes 4. have a javascrip…
Yes the problem with "unsafe" examples is that people will use them -- perhaps thinking, "this is a POC, we'll come back later and do this properly" -- only it gets forgotten and ends up in production.
Re: Go Language – Web Application Secure Coding Practices
#10Go has also an amazing static-analysis tool, vet, that is not mentioned in the article: https://golang.org/cmd/vet/ It can find printf-format errors, invalid shifts, unreachable code, etc. Even though go vet is very helpful, it is sometimes scary that the compiler allows to build such incorrect code. For instance: https://play.golang.org/p/2AVHUt5Wcf
I'm not sure how `fmt.Printf("%s\n", i) // invalid type` is really that "scary". Expecting the compiler to introspect that Printf's `...interface{}` argument's first value is incorrect, even though `i` does fulfill the stated parameter's type, is a FAR more scary thought.