I'm writing a PHP tutorial and I would like to display some forms where the users could enter values that are displayed in the same webpage, just as a demonstration.

The forms do nothing special, they only use print instructions to display the input.

I would like to know if these apparently innofensive forms could be a real danger for my server because of script injection.

The code that processes the form is:

      if (array_key_exists('user', $_POST)) { 
            print "Hello, " . $_POST['user'];
      } else { 
            print "Waiting for your input...";
  • \$\begingroup\$ I think it would be helpful to include the relevant code in your question. \$\endgroup\$
    – unor
    Jan 23 '14 at 16:48
  • 1
    \$\begingroup\$ <?php if (array_key_exists('user', $_POST)) { print "Hello, " . $_POST['user']; } else { print "Waiting for your input..."; } ?> \$\endgroup\$
    – Sakhal Turkaystan
    Jan 23 '14 at 16:51

The Short answer is yes you are vulnerable to injection. XSS to be precise which you can read more about here https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet


All user input should be sanatized for example:

if you input <script>alert("This will alert");</script> into your form you will notice an alert message will appear on your page

however if you sanatize the code i.e.

print "Hello, " . htmlentities($_POST['user']);

you will no longer see the alert message

using htmlentities() will help protect you from the script injection.

You would also be better validating the data that will be expected from the user

Other points which you can see here https://stackoverflow.com/questions/11554432/php-post-dynamic-variable-names-security-concerns which are based more on dynamically creating variables

  • 4
    \$\begingroup\$ Also, apart from the security aspect, if you don't convert special HTML characters (in the user input) to HTML entities when you output in the HTML page then the user might not even see what they have just entered and to the user your script might not appear to be working correctly - unless that is also part of the tutorial? \$\endgroup\$
    – MrWhite
    Jan 23 '14 at 22:40
  • \$\begingroup\$ @w3d good point I will add that later. \$\endgroup\$
    – Liam Sorsby
    Jan 23 '14 at 22:54
  • \$\begingroup\$ Yes, I understand. I have already applied htmlentities() to the input. Allowing the user to insert code is not a part of the tutorial, albeit it would be interesting that it were, but I'm too afraid to let people to put scripts in there. It would be too much risk to withstand. \$\endgroup\$
    – Sakhal Turkaystan
    Jan 24 '14 at 8:15
  • 1
    \$\begingroup\$ Consider updating your answer with the specific name of the vulnerability, cross site scripting. And, provide a link for more information about xss \$\endgroup\$ Jan 25 '14 at 19:56
  • \$\begingroup\$ @RobApodaca I've updated my answer \$\endgroup\$ Jan 26 '14 at 20:15

It's not a security risk for your server, but it may be for your users.

Beside the fact that if the input contains < the output might not be what you expected, the real dangers you face are XSS and CSRF.

For example, a malicious attacker could make the user click on a link which opens your example form, and executes some malicious javascript. The big problem is not executing (on the client) attacker-controlled code, but the fact that the browser sees it as coming from your website, so it has access to cookies, etc...

  • \$\begingroup\$ This is interesting, but I don't fully understand it... Would it be necessary that the malicious script were stored in my server before being sent to the victim? Or the attacker would create a fake webpage that would ressemble one from my server? \$\endgroup\$
    – user35533
    Jan 24 '14 at 19:45
  • \$\begingroup\$ A fake webpage with a form pointing to your website is enough. Also, the user may not even see this happening (e.g. Clickjacking) \$\endgroup\$
    – miniBill
    Jan 24 '14 at 19:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy