8
\$\begingroup\$

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:

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

2 Answers 2

Reset to default
11
\$\begingroup\$

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

Explaination:

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

\$\endgroup\$
5
  • 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\$ Commented Jan 23, 2014 at 22:40
  • \$\begingroup\$ @w3d good point I will add that later. \$\endgroup\$ Commented Jan 23, 2014 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\$ Commented Jan 24, 2014 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\$ Commented Jan 25, 2014 at 19:56
  • \$\begingroup\$ @RobApodaca I've updated my answer \$\endgroup\$ Commented Jan 26, 2014 at 20:15
6
\$\begingroup\$

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...

\$\endgroup\$
2
  • \$\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\$ Commented Jan 24, 2014 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\$ Commented Jan 24, 2014 at 19:47

You must log in to answer this question.