PHP: best security practices for displayed information?

Question

In PHP, I know that using parameterized queries is the best way to prevent SQL injection.

But what about sanitizing user input that will be used for other purposes, such as:

• Displaying back to a user (potential cross-site scripting vector)
• Addressing an email or filling in the message body

Is htmlentities() the best way to sanitize for non-database usage? What is considered to be best practice here?

Answer 1

In php the best xss filter is:

htmlspecialchars($_POST['param'],ENT_QUOTES);

The reason why you also have to encode quotes is becuase you don't need <> to exploit some xss. for instance this is vulnerable to xss:

print('<A HREF="http://www.xssed.com/'.htmlspecialchars($_REQUEST[xss]).'"&gt;link&lt;/a&gt;');

You don't need <> to execute javascript in this case because you can use onmouseover, here is an example attack:

$_REQUEST[xss]='" onMouseOver="alert(/xss/)"';

the ENT_QUOTES takes care of the double quotes.

E-mail is a bit different, javascript shouldn't be executed by the mail client, and if it is then your site isn't affected due to the Same Origin Policy. But to be on the safe side I would still use htmlspecialchars($var,ENT_QUOTES);. HOWEVER, PHP's mail() function can succumb to a different type of vulnerability, its called CRLF injection. Here is an example vulnerability against PHP-Nuke. If you have a function call like this: mail($fmail, $subject, $message, $header); Then you must make sure that a user cannot inject \r\n into $header.

Vulnerable code:

$header="From: \"$_GET[name]\" <$ymail>\nX-Mailer: PHP";

patched:

$_GET[name]=str_replace(array("\r","\n"),$_GET[name]);
$header="From: \"$_GET[name]\" <$ymail>\nX-Mailer: PHP";

Answer 2

Well you can first create rules for certain fields, like email the only thing it should consist of is letters, numbers, @ (at-symbol? what is it really called), and a period, so you cannot form an XSS out of that so no need to waste resources using htmlentities() or htmlspeicalchars().

Answer 3

You may also want to checkout HTML Purifier which will strip any dangerous HTML and leave on safe input. You can also create your own rules on what HTML to allow/disallow.

http://htmlpurifier.org/

Answer 4

No,

1) prepared statements are not a solution to SQL injection. In most cases prepared statements implies variable binding and therefore transparent escaping which is an effective way to prevent SQL injection.

2) you DO NOT sanitize input - you sanitize output. By all means validate input (e.g. make sure start date comes before end date), but the repsentation of data should only be changed at the point where it leaves your PHP code. The method for sanitizing data written directly into HTML is different from how you would sanitize data written into a URL is different from how you sanitize data to write it into a javascript string variable is different from how you sanitize data for insertion into an SQL statement is different from how you sanitize data before you send it to modem is...

...what are you going to do? create every possible representation of the data? Create a universal represenation of the data?

http://xkcd.com/327/

C.