Coding Critique is the place to post source code for peer review by other members of DevNetwork. Any kind of code can be posted. Code posted does not have to be limited to PHP. All members are invited to contribute constructive criticism with the goal of improving the code. Posted code should include some background information about it and what areas you specifically would like help with.
Popular code excerpts may be moved to "Code Snippets" by the moderators.
The simplest way to avoid XSS is to run htmlspecialchars() before echoing anything. I don't recommend putting anything in the database with htmlspecialchars already run. Wait until output. Some day you may want to send your database data via a web service or print a check. It looks pretty stupid if you print a check made out to "Mr. O'Reilly".
The exception would be rich text. If you are accepting rich text like a blog post, you should run it through a full HTML parser and cleaner such as HTMLPurifier before putting it in the database.
As far as SQL injection, before putting anything into the database always use PDO binding or mysql_real_escape_string(). And addslashes() is unnecessary. In fact, addslashes() is rarely useful.
If you are going to use the code, get rid of the magic quotes checks and apply filtering regardless of it; magic_quotes_gpc has been deprecated and shouldn't be relied upon at all.
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering
social_experiment wrote:If you are going to use the code, get rid of the magic quotes checks and apply filtering regardless of it; magic_quotes_gpc has been deprecated and shouldn't be relied upon at all.
Though at that point all you're left with is a mysql_real_escape_string wrapper function.
I should have probably worded that better I mean he can leave the checks for magic_quotes_gpc() out; since it's no longer useful but still keep the other filters in place. This strip_tags(htmlspecialchars($data)); is redundant as htmlspecialchars() will make sure strip_tags() find nothing to strip, i would change it like this:
@social_experiment, your function probably behaves different than you are thinking. If you pass the string "Jane's <3 is Joe", you will get out of the database "Jane\'s ". Note how strip_tags() cuts off strings with less than signs in the middle. But if you run mysql_real_escape_string() alone on the way in, and htmlspecialchars() before displaying to the browser, the string will look identical.
Thanks for pointing that out tr0gd0rr I personally don't use strip_tags() [and it shows doesn't it]; if you catch " or ' (which mysql_real_escape_string() does) and use htmlspecialchars() when displaying data then strip_tags() becomes redundant
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering
None of the other listed options so far will work correctly:
strip_tags() is of dubious value and will damage the original data,
mysql_real_escape_string() is about MySQL and SQL injection, not XSS
addslashes() is just silly
htmlspecialchars($data) is insufficient protection when used in attribute context.
If it's an attribute and you use the 'wrong' type of quotes, plain htmlspecialchars() will fail to protect against XSS, read the docs. It's amazing how stupid some of the PHP functions are - it's a security measure which is insecure by default!