I am trying to pentest a dummy website that has a form with a TEXTAREA input on one page.
When the form is submitted, the contents of the form are displayed on a second page.

However, the second page that receives the POST input, filters it to replace ", <, > and & with &quot, &lt;, &gt; and &amp;.

The second page also has a:

<meta http-equiv="content-type" content="text/html; charset=utf-8" />

I used Fiddler to intercept the POST from the first page and modified the request header from
Content-Type: application/x-www-form-urlencoded
Content-Type: application/x-www-form-urlencoded; charset=UTF-7

And changed the POSTed content to:

Hoping that it would decode to:

However, it didn't do anything and text showed up as it is. Also, the text-encoding of the second page was recognized as UTF-8. I guess that's because it has a meta tag in it's HTML with the charset set to UTF-8.

I want to know if there's a way this page can be exploited through XSS and if there is, what would be the input vector?

1 Answer 1


The OWASP XSS Experimental Minimal Encoding Rules suggest that all that needs to be encoded are <, & and >, as long as the charset is specified.

Assuming the second page outputs within an HTML context, then there doesn't seem to be an XSS attack vector in this case.

Setting charset and then encoding your POST will simply mean that the server will interpret it as such, converting any text into its own internal representation (assuming no flaws exist in the technology stack the site is using and everything is doing its job properly). So when it is output, the characters will be encoded again meaning your attack fails.

  • Thanks! I guess this one's a bust. I'll start looking into other areas of interest.
    – Vinayak
    Aug 8, 2014 at 8:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .