4 ms·

Sure, that's fine. But what if someone passes you an email address that's really 500 comma-separated email addresses? What if someone passes 'admin=true' to y

Sure, that's fine. But what if someone passes you an email address that's really 500 comma-separated email addresses? What if someone passes 'admin=true' to your user update URL? Your output sanitization doesn't do much for those.

by 17y ago
You are quite right, you do need to white-list the valid inputs for reasons other than SQL injection. I did not explain very clearly. What I was trying to say was that output normalisation will prevent SQL injection attacks. I am considering the components of the SQL statement, such as the string O'Beirne, to be things that have to be normalised before being output to the database in the SQL statement. This output normalisation, as the other replies to my post have correctly said, is best done for you by a library. It cannot be done properly by restricting the inputs, as my O'Beirne example shows, only by output normalisation of the SQL.
- tptacek 17y ago
  But output normalization will not prevent SQL Injection attacks, so I'm pretty unclear on what you're trying to say. I think you're trying to say that content neutralization (turning ' into ", for instance) stops SQLI. It might or it might not, depending on the vector (tablespace injection doesn't care about metacharacters, for instance). It's at least more accurate than saying "if you make sure that the web app doesn't spit out [!@#$%^&*(){}:"<>?] you're safe".
  - by 17y ago
    Maybe the words 'output normalisation' are the point of confusion. I am using them as in this thread http://www.reddit.com/r/programming/comments/86kgp/xss_cross_site_scripting_prevention_cheat_sheet/c08e4tm http://www.reddit.com/r/programming/comments/86kgp/xss_cross... which is the context of my quote of larholm above and is a discussion about this page http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Pr... Perhaps this is not common usage, but within this context I believe I am correct in saying output normalization is what prevents SQL injection. larholm goes on to say: "The lack of output normalization IS the security vulnerability." "You can either normalize your output for each specific location as you encounter it, or normalize your input once in advance for all current and future output locations." "The former beats the latter, as it is impossible for you to know how the data will be output in the future." which also seems correct. What is "tablespace injection"? I just googled it and there are no references to it anywhere. http://www.google.com/search?q=%22tablespace+injection%22&hl=en&filter=0 http://www.google.com/search?q=%22tablespace+injection%22&#3...
InclinedPlane 17y ago
"But what if someone passes you an email address that's really 500 comma-separated email addresses?" If I understand the idea of output-normalization correctly you'd keep an email address that's really 500 comma-seperated addresses in the database in exactly that form, but when it came time to send an email you would normalize the value, and at that stage you would check for such a case and handle it as appropriate (i.e. remove all commas, send to only the first, etc.) The point is that you don't try to create a stored value that can be used safely everywhere, rather you make the value safe at each instance where it's used. P.S. This appears to be the relevant conversation, interesting reading: http://www.reddit.com/r/programming/comments/86kgp/xss_cross_site_scripting_prevention_cheat_sheet/c08e64v http://www.reddit.com/r/programming/comments/86kgp/xss_cross...

by 17y ago

You are quite right, you do need to white-list the valid inputs for reasons other than SQL injection. I did not explain very clearly. What I was trying to say was that output normalisation will prevent SQL injection attacks. I am considering the components of the SQL statement, such as the string O'Beirne, to be things that have to be normalised before being output to the database in the SQL statement. This output normalisation, as the other replies to my post have correctly said, is best done for you by a library. It cannot be done properly by restricting the inputs, as my O'Beirne example shows, only by output normalisation of the SQL.

tptacek 17y ago
But output normalization will not prevent SQL Injection attacks, so I'm pretty unclear on what you're trying to say. I think you're trying to say that content neutralization (turning ' into ", for instance) stops SQLI. It might or it might not, depending on the vector (tablespace injection doesn't care about metacharacters, for instance). It's at least more accurate than saying "if you make sure that the web app doesn't spit out [!@#$%^&*(){}:"<>?] you're safe".
- by 17y ago
  Maybe the words 'output normalisation' are the point of confusion. I am using them as in this thread http://www.reddit.com/r/programming/comments/86kgp/xss_cross_site_scripting_prevention_cheat_sheet/c08e4tm http://www.reddit.com/r/programming/comments/86kgp/xss_cross... which is the context of my quote of larholm above and is a discussion about this page http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Pr... Perhaps this is not common usage, but within this context I believe I am correct in saying output normalization is what prevents SQL injection. larholm goes on to say: "The lack of output normalization IS the security vulnerability." "You can either normalize your output for each specific location as you encounter it, or normalize your input once in advance for all current and future output locations." "The former beats the latter, as it is impossible for you to know how the data will be output in the future." which also seems correct. What is "tablespace injection"? I just googled it and there are no references to it anywhere. http://www.google.com/search?q=%22tablespace+injection%22&hl=en&filter=0 http://www.google.com/search?q=%22tablespace+injection%22&#3...

InclinedPlane 17y ago

"But what if someone passes you an email address that's really 500 comma-separated email addresses?" If I understand the idea of output-normalization correctly you'd keep an email address that's really 500 comma-seperated addresses in the database in exactly that form, but when it came time to send an email you would normalize the value, and at that stage you would check for such a case and handle it as appropriate (i.e. remove all commas, send to only the first, etc.) The point is that you don't try to create a stored value that can be used safely everywhere, rather you make the value safe at each instance where it's used. P.S. This appears to be the relevant conversation, interesting reading: http://www.reddit.com/r/programming/comments/86kgp/xss_cross_site_scripting_prevention_cheat_sheet/c08e64v http://www.reddit.com/r/programming/comments/86kgp/xss_cross...