htmlentities and add/strip_slashes

[rockinaway]

Now, I'm trying to figure out some security factors of a website with a login etc.

 

Would I need to add and strip slashes if I'm using htmlentities on anything that the user enters?

[requinix]

- stripslashes() at the beginning but only if magic_quotes is enabled.

- mysql_real_escape_string() for string values just before you stick them into the query. Use typecasting or numeric functions (eg, intval() and is_numeric()) for non-string values. Or you can validate the input to ensure it couldn't possibly contain any SQL injection.

- htmlentities() or htmlspecialchars() right when you output stuff into HTML.

- json_encode() right when you output stuff into JavaScript (or as JSON).

 

Note how addslashes() did not make that list.

[batwimp]

And let's not forget hashing your passwords before entering them into the database.

[rockinaway]

Yeah I've got everything hashed and salted etc..

 

Thanks requinix, very helpful. Okay so say someone is submitting a message and they enter some HTML or PHP text into the textbox, and I want to make sure that is inserted as normal text and not run in any way, would stripslashes() and mysql_real_escape_string be sufficient?

 

And I don't need htmlentities when putting stuff into the database? Just when returning it out?

[requinix]

Thanks requinix, very helpful. Okay so say someone is submitting a message and they enter some HTML or PHP text into the textbox, and I want to make sure that is inserted as normal text and not run in any way, would stripslashes() and mysql_real_escape_string be sufficient?

stripslashes() is about making sure PHP's old magic_quotes setting (if present) does not screw up the submitted value. If you don't stripslashes() and magic_quotes is on then characters like apostrophes and quotation marks will have backslashes to "escape" them. But you do your own escaping so it ends up that the backslashes come in literally and you end up with people's names like "O\'Brien".

 

mysql_real_escape_string() makes a string safe for inclusion directly into a SQL query, so long as you put it in quotes. It does not affect what the data is - only how it is represented in the query.

 

Those two happen on the input side of things. When you're inserting data into your database. When the data comes out and you output it into something like HTML or XML, it might not be safe. For instance, it could contain s and at the worst means someone can  insert arbitrary HTML into your page. Just like how MySQL has mysql_real_escape_string() there is the htmlspecialchars() function for HTML (and XML). That escapes s and quotes so that the string couldn't possibly affect the markup of a page.

That's a good function but for HTML (only, not XML) there's a better function: htmlentities(). Besides doing everything the other function does, when used properly this one will make sure the output doesn't contain any "invalid" characters. For example: á. Your page might not use a character encoding that supports that character so htmlentities() will turn it into á - something that will always work because it represents the á character not as bytes but as "an 'a' with an acute".

 

And I don't need htmlentities when putting stuff into the database? Just when returning it out?

Correct, and do it just before you echo it into the HTML as a code safety measure. Databases should contain raw values in their original form. Using htmlentities() means you've corrupted the data and turned it into an HTML-safe string. For a lot of purposes that's okay because the data will only go back into HTML later on, but it's not okay because of the other things you might want to do to it. Common examples:

- Insert the data into an RSS feed (which is XML). XML doesn't support HTML entities like á and will barf if you try to use one*

- Measure the string length. If you were to impose a maximum string length of 10 characters, and someone enters "páginas" the length check will incorrectly fail because it measures "páginas" (14 characters) instead of "páginas" (7 characters)

- Use the value in AJAX. If the code treats the AJAX results as text strings (as opposed to HTML strings) then you might end up with "páginas" literally in the HTML.

 

* It's possible to include a definition of HTML entities, and that would allow you to use entities, but it's work that you don't really need to do. There's also a risk of XML parsers that aren't aware this kind of thing is possible.

[rockinaway]

Thanks a lot for that reply! I checked and I have magic_quotes turned off so I guess I won't need stripslashes() after all? So all I need is mysql_real_escape_string for sanitation of stuff for the database right? I have other checks like length of passwords, and hashing etc.

 

As for the htmlentities(), you've cleared that up for me very nicely thank you!

[requinix]

Thanks a lot for that reply! I checked and I have magic_quotes turned off so I guess I won't need stripslashes() after all? So all I need is mysql_real_escape_string for sanitation of stuff for the database right?

Yep.

[rockinaway]

Thank you very much! Saved me a lot of work!