3 ms·
The argument makes sense in the SQL injection example (don't escape, use prepared statements!) but falls apart when you get to the XSS example. Now we're just t
by kijin 13y ago
The argument makes sense in the SQL injection example (don't escape, use prepared statements!) but falls apart when you get to the XSS example. Now we're just trying to redefine words.
"HTML injection" does sound cool though. Since XSS nowadays is not necessarily about sending cookies to another site, perhaps we could adopt "HTML injection" as a more generic term.
Now of course, the problem we're trying to fix is someone who does:
$content = htmlspecialchars(mysql_real_escape_string(addslashes($content)));
before $content ever hits the database, without any understanding of what those functions really do. It's a surprisingly common cargo cult among newbie web devs. Just throw all the security-related functions together and you'll be safe!
- vezzy-fnord 13y agoHTML injection already is a term: https://www.owasp.org/index.php/HTML_Injection https://www.owasp.org/index.php/HTML_Injection Same principle, but different method of exploitation. If we supply plain HTML tags in a vulnerable parameter, it's HTML injection. If we use JavaScript (via a script tag or whatnot), it's XSS.
- mikeash 13y agoTo me, "sanitize" implies a blacklist approach, which is inherently insecure. For the HTML example, it means you're going through and blocking <script> and such, while allowing the rest through. What you should be doing is keeping a small whitelist of allowed tags and blocking everything else, if you must support user-provided HTML in the first place. That to me isn't sanitizing but rather defining an HTML subset and then translating from it to full HTML.