41–50 of 55 posts
Don't read it, always start with using a good framework. It will do everything for you
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. 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?
Context here means the context of the output page. 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): ... Here, the input that you need to transition to JavaScript execution is a alert(1) . Therefore, to correctly sanitize this, you…
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. 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?
Context here means the context of the output page. 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): ... Here, the input that you need to transition to JavaScript execution is a alert(1) . Therefore, to correctly sanitize this, you…
Theres 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)
Go 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
Go does already have one of the strictest compilers (by default) out there. But it is pretty typical for a great many language frameworks to support optional additional strictness. Eg "use strict" in Perl or the gcc flags of which I cannot recall off hand. I see God's vet as akin to those. ie there when you need it but keeps out of your way when you just need to get some prototyping done.
Go 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.
Go 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
Earlier quoted context omitted.
To be fair to the person you're responding to, do you think people looking for copypasta are going to check the fine print? 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.
To be fair to the person you are responding to, I don't think copypasta developers are going to create secure applications anyway.
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…
Don't read it, always start with using a good framework. It will do everything for you
Hi homakov, given your experience with security, could you please expand on _why_ we should not this particular guide? I do understand why we should start with using a good framework, and I have so far felt that reading guides also help us understand things to be aware of.
For reference:
http://homakov.blogspot.fr/2012/03/how-to.html https://news.ycombinator.com/item?id=3663197