I agree, and as I continue to read about this particular attack, it may be a true SQL statement injection. (Also, for some reason they linked this to ASP sites?)
My point, I guess, is that in order to affect thousands of sites, one need not try that hard these days. A lot of frameworks are providing automatic protection from SQL injection, but it's up to the developer to think about not displaying raw user input.... or blacklist "sanitized" input, which is easy to hack.
However, I don't literally sanitize on output for perf reasons... the filter would run on every render. I do maintain two separate DB columns for every user input field that is ever displayed in the browser. One is the input/edit field, the other is the sanitized output field. So, this really is sanitize-on-output, with cached output.
Also, my sites use a subset of Textile for markup, so all angle brackets are escaped.
This description of a SQL injection attack is completely correct. However the method that appears to have been used in this case is different, and unfortunately much simpler for the attacker.
Rather than manipulating the actual SQL statement syntax, they are merely adding a malicious script tag to a text field. The contents of the text field are not sanitized, and are saved to the database as is. Later, when the text is dynamically displayed in the browser, the script tag is included, and is executed by the client browser.
The reason you will not find the offending code by inspecting all your HTML (or whatever templating language you use) is because it is actually in your SQL database. Thus, this attack only works on sites that display dynamic content.
Any and all developers should be sanitizing any and all text that will later be displayed in a browser. Even sites that are well written against the kind of attack Emb3rz describes, seem to often overlook this simple vulnerability.
Slashdot Mirror
Right, I get it now. Thanks for the explanation.
I agree, and as I continue to read about this particular attack, it may be a true SQL statement injection. (Also, for some reason they linked this to ASP sites?)
My point, I guess, is that in order to affect thousands of sites, one need not try that hard these days. A lot of frameworks are providing automatic protection from SQL injection, but it's up to the developer to think about not displaying raw user input.... or blacklist "sanitized" input, which is easy to hack.
I agree whitelist is the way to go.
However, I don't literally sanitize on output for perf reasons... the filter would run on every render. I do maintain two separate DB columns for every user input field that is ever displayed in the browser. One is the input/edit field, the other is the sanitized output field. So, this really is sanitize-on-output, with cached output.
Also, my sites use a subset of Textile for markup, so all angle brackets are escaped.
This description of a SQL injection attack is completely correct. However the method that appears to have been used in this case is different, and unfortunately much simpler for the attacker.
Rather than manipulating the actual SQL statement syntax, they are merely adding a malicious script tag to a text field. The contents of the text field are not sanitized, and are saved to the database as is. Later, when the text is dynamically displayed in the browser, the script tag is included, and is executed by the client browser.
The reason you will not find the offending code by inspecting all your HTML (or whatever templating language you use) is because it is actually in your SQL database. Thus, this attack only works on sites that display dynamic content.
Any and all developers should be sanitizing any and all text that will later be displayed in a browser. Even sites that are well written against the kind of attack Emb3rz describes, seem to often overlook this simple vulnerability.