-2

I need to find a XSS and propose a solution in the following code:

<form action="#" method="post">
<input type="hidden" name="id" value="<?=$id?>"><br>
<textarea name="body"><?=$text?></textarea><br>
<input type="submit" value="Send"><br>
</form><br>

This is part of a message board. The submit will store the message in a database and then there is another function which reads this DB and copy the content of the register without sanitize it, so whatever I put in $text will be executed, hence vulnerable to XSS. I have added prior to that this line $text = htmlspecialchars($text);, but it's not escaping the string, so then again the script it's getting executed.

Also, the $id is vulnerable as well, isn't it? How could I exploit it? Because I've been trying but no luck.

  • 1
    Without the serverside code, it's impossible to know about the XSS vulnerabilities. The way you explained it doesn't help either, do you have code? – David Houde May 23 '14 at 13:07
  • @DavidHoude I have the code of the full application, but the scope of the question is just that portion of code. – eez0 May 23 '14 at 13:48
1

As @David_Houde said, without the server-side code you can't find out how to exploit the XSS vulnerability. But in case you don't have any idea about the filter used on the server-side (black-box testing) you can try to guess it. You can use the XSS Filter Evasion Cheat Sheet provided by OWASP.

0

I turned out to be that the only XSS the trainer was expecting was the $id, easily solved using htmlspecialchars($id)

-1

Usually this problem is solved by removing all scripting and HTML altogether, in PHP (I see you use a PHP function) this is done via the strip_tags function. This may strip also desirable formatting tags, so if you need some measure of text formatting, you need to either have them re-introduced with some kind of markup (as the StackExchange boards use: bold, italic and so on), or by using more specialized tag stripping functions.

Be aware that some such implementations are flawed, and may be in turn abused by sending, say, nested tags (e.g. <<script>script>) or crafted UTF8 sequences. You might want to test the chosen implementation against a corpus of known attacks.

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.