2
votes

At https://www.owasp.org/index.php/PHP_Top_5#How_to_Determine_if_you_are_Vulnerable_2 link, under title P2: Cross-site scripting > How to Protect Against It; in item 4 and 5 it's written that:

  1. item 4: Free text input can only be safely re-displayed to the user after using HTML entities
  2. item 5: Variables sent back to the user via URLs must be URL encoded using urlencode(), although the use of GET requests is deprecated for anything besides navigation purposes

My Questions

Q1

For item 4 it's explicitly said that can only but I remember I read that htmlspecialchars() is enough & more efficient vs htmlentities(). (An example source link about superiority of htmlspecialchars. Please read the comment of Pornel_: What are the best practices for avoiding xss attacks in a PHP site) So I am confused after this input of OWASP. Should I replace my htmlspecialchars() with htmlentities() that I use while I print the MySQL user inputted data to the screen as html.

Q2

For my forms (add article, add comment, e-mail to admin) I utilize Post - Redirect - Session Variables flow. (My explanation may be stupid for you but I mean I don't use GET at the 3rd step of my flow. Instead of GET, I utilize Session variables.) So still do I need to use urlencode() somewhere on Session variables? (Note: Even if you yes, I don't know HOW, that's another topic for me to study, for the time being I only want to learn yes or no and why cause I couldn't find the answer of this question in my research. of course if you define HOW part also, it will be really appreciated)

thanks in advance
Best regards

1
@MikeB I read it. Thank you. For my question 1, I concluded that I don't need a replacement; htmlspecialchars is okey.Andre Chenier

1 Answers

2
votes

Focus on why you have to do these two point not how. The how should allways just be a tip on how you "could possibly" fullfill the requirements. But if you just use what other tell you, you are at risk of not fully understanding the reasons and therefore unknowingly reintroduce a security risk.

4) This recommendation tries to avoid users "breaking out" of your input/textarea fields. Check for yourself, how this can be done in your form and act against that. Typically, a text input can be broken out of with the correct quote:

$value = '\'/>alert("hello");'; echo '

So in this case filtering the double quote would be enough (correct me if Im wrong). But filtering EVERYTHING you wont need is allways better. Prefer whitelisting against blacklisting filters.

5) This tries to avoid your URL from getting malformed. Can't give you a nice attack sample for now, but even a just malformed urls will probably make your app unusable.

BTW, typical PHP session IDs are plaintext only and URL safe. It would be even better to store them in a cookie with "http only" setting. You should not need naything besides that session id for normal session handling.

So, yes. Use these tips you mentioned, but understand the attack it aims to prevent and not just use them because polep tell you too.