Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

So, in my brief research in PHP security, I have been guided toward two important functions to remove forbidden characters from forms. One being "htmlentities" and the other being "mysql_escape_string" - what I am wondering is if there is a common way for hackers to insert malicious forbidden characters in to the forms despite the functions. I am suspicious that this is possible, since this is such a commonly employed security technique. Is an extra layer of security needed?

NB: I understand that mysql_escape_string may become deprecated soon.

share|improve this question

1 Answer 1

While mysql_escape_string() is an alright method of preventing SQL injection, parameterized queries are a much better approach. mysql_escape_string() is still not perfect; for example the following is vulnerable to SQL injection:

$q="select * from user where uid=".mysql_real_escape_string($_GET[uid]);

The PoC is simple:

http://localhost/vuln.php?uid=sleep(30)

Use parameterized queries!

htmlentities(), or htmlspecialchars() will prevent some types of XSS. They won't prevent XSS in DOM events. This method won't prevent injecting events for example: value='junk' onclick=alert(/xss/). htmlspecialchars($var,ENT_QUOTES) is a little better, because it prevents DOM event injection, but you can still hijack an event (see the "it's a DOM event" blog post).

So these two functions will partially mitigate two vulnerabilities out of a couple thousand. To call out some of the big offenders that will not be mitigated by mysql_real_escape_string() or htmlentites() we have: Directory traversal (and LFI/RFI for PHP), LDAP injection, XPATH injection, HTTP Response Splitting, Log file injection... and the list goes on.

Escaping input has nothing to do with removing "forbidden characters". It's about converting escape characters (or sequences of characters) into their "character literal" such that attacker controlled data is still interpreted as data, and not executable code.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.