81–90 of 107 posts
Really good write up. Some people are really smart, I wouldn't ever be able to do that kind of stuff even after being programming for years.
Earlier quoted context omitted.
Actually, the takeaway is not that "you should never use user input on unserialize." It is, that you should NEVER TRUST USER INPUT. This rule is as old as computing itself and trust of user input has always been the beginning of a security vulnerability. You need user input, you will use user input, but you must understand how it's used and filter, strip everything that is not needed away.
> you should NEVER TRUST USER INPUT That is not clear at all and pretty useless. What does it mean? I should not accept any user input at all? > strip everything that is not needed That does not always work. What if I have a comment form that should accept any characters?
Suppose you were handling snakes. Some snakes are not poisonous, and don't need to handled with the care you'd handle, say, a black mamba with. However, you are being advised to treat every snake you encounter as though it was the most poisonous snake known, and apply every care that you normally apply to snakes that you know are poisonous.
Will you handle the snakes? Yes, you're a snake handler, remember? But you handle all of them like they are deadly, even the ones you "know" to not be deadly.
> Dump the complete database of pornhub.com including all sensitive user information.
And of course leak the data to expose everyone that participates in this nasty business. It is such a sad thing that people are even proud to work at companies like this where humans are not worth more than a big dick or boobs.
And then you get around and say that child porn is so horrible. No, all porn is horrible and destroys our families and integrity. How can there be any dignity left if these things are held to be something good?
Earlier quoted context omitted.
Hash functions designed for hash tables are generally not hard to find collisions for, so there's not much that can be done. You could shoehorn in a secure hash function, but that would hurt performance.
I think that most major languages have fixed this for years. Python in 2012: http://bugs.python.org/issue13703
The takeway: You should never use user input on unserialize. Assuming that using an up-to-date PHP version is enough to protect unserialize in such scenarios is a bad idea. Avoid it or use less complex serialization methods like JSON.
Actually, the takeaway is not that "you should never use user input on unserialize." It is, that you should NEVER TRUST USER INPUT. This rule is as old as computing itself and trust of user input has always been the beginning of a security vulnerability. You need user input, you will use user input, but you must understand how it's used and filter, strip everything that is not needed away.
I think a lot of people are reading this and think that this advice is too wide, and include so much in so few words.
It's the same caliber as "don't trust strangers" and "be responsible of your actions". There is undeniable truth in it, you cannot go wrong following it and it's difficult to argument against. But I think that's what makes it counter productive and basically devoid of meaning.
Effectively if the rule is as old as computing, but it still has to be voiced, it means it's not a simple rule to begin with.
As you put it "you must understand how it's used and filter, strip everything that is not needed away". This basically means every time you have user input, ideally you'd have to audit all the libraries and frameworks accessing the data to check how they use it, and filter accordingly. Pass a construct to a json library ? first check what the json library does with it, sanitize your input for everything that could be harmful to the library. This solution is voiced in one sentence, but would mean hours/days of library auditing in a real world scenario.
TL;DR: you can't cover for everything, you have to choose your battles. Knowing which libraries have known vulnerabilities is valuable info.
Earlier quoted context omitted.
> you should NEVER TRUST USER INPUT That is not clear at all and pretty useless. What does it mean? I should not accept any user input at all? > strip everything that is not needed That does not always work. What if I have a comment form that should accept any characters?
You're confusing "trust" with "use," which appears to be the cause of your apparent bewilderment. I could be wrong, however. Suppose you were handling snakes. Some snakes are not poisonous, and don't need to handled with the care you'd handle, say, a black mamba with. However, you are being advised to treat every snake you encounter as though it was the most poisonous snake known, and apply every care that you normal…
User input ought to be treated with the same kind of respect, although in terms of user input the option of giving them a wide birth isn't always as practical.
Earlier quoted context omitted.
>What does it mean? I should not accept any user input at all? No, it means you should never assume that user data is safe, or even sane. Assume, rather, that everything every user is sending you is malicious, all the time, and write your code accordingly. >. What if I have a comment form that should accept any characters? First, you probably shouldn't, because your database and HTML should be using explicit characte…
> it means you should never assume that user data is safe, or even sane I'm curious if Haskell's purity helps developers focus on this issue and therefore makes it easier to mitigate. Given that all user input/state already has to be handled carefully (for ex: with monads). It will be obvious in the codebase which parts need to be zero'd in on for possible attack vectors.
No, haskell's type system does, not its purity.
>Given that all user input/state already has to be handled carefully (for ex: with monads)
What? Monads are not some mythical beast, there is nothing "handled carefully" about it. A monad is just a general interface.
The takeway: You should never use user input on unserialize. Assuming that using an up-to-date PHP version is enough to protect unserialize in such scenarios is a bad idea. Avoid it or use less complex serialization methods like JSON.
Actually, the takeaway is not that "you should never use user input on unserialize." It is, that you should NEVER TRUST USER INPUT. This rule is as old as computing itself and trust of user input has always been the beginning of a security vulnerability. You need user input, you will use user input, but you must understand how it's used and filter, strip everything that is not needed away.
Earlier quoted context omitted.
That's not actionable. You have to deal with user input at some point. What if my language can't deal with strings properly? Maybe strpos has a buffer overflow on a carefully crafted input. Would I be wrong for using it?
Never trust user input doesn't mean never use user input; you need to use it carefully -- often that means restricting to acceptable values and lengths, (appropriate!) escaping, and passing through that it's user input to other functions (ex: sql placeholders). When functions do arcane things, and don't let you pass through that it's user provided, that's a red flag. Note that a cookie that you set, and are now getti…
Earlier quoted context omitted.
> it means you should never assume that user data is safe, or even sane I'm curious if Haskell's purity helps developers focus on this issue and therefore makes it easier to mitigate. Given that all user input/state already has to be handled carefully (for ex: with monads). It will be obvious in the codebase which parts need to be zero'd in on for possible attack vectors.
>I'm curious if Haskell's purity helps developers focus on this issue and therefore makes it easier to mitigate No, haskell's type system does, not its purity. >Given that all user input/state already has to be handled carefully (for ex: with monads) What? Monads are not some mythical beast, there is nothing "handled carefully" about it. A monad is just a general interface.