1

My client's bank performed a PCI compliance can on their Apache/PHP server and reported some XSS vulnerabilities that to my (admittedly non expert) eyes seem to be false positives.

Example: they provide the following as evidence

GET {IP ADDRESS}/"><script>alert(document.domain)</script>.html

This generates an error 404 the response is the standard CPanel 404 message, including this:

<div class="info-heading">
{IP ADDRESS}/&quot;&gt;&lt;script&gt;alert(document.domain)&lt;/script&gt;.html (port 80)
</div>

This seems safe to me according to OWASP rule #1 - HTML Escape Before Inserting Untrusted Data into HTML Element Content.

Edit: as noted in the comments this is already using html entities which does seem weird, but that's what they provided. The unescaped version also seems safe:

{IP ADDRESS}/"><script>;alert(document.domain)</script>.htm

Which produces this output:

<div class="info-heading">
{IP ADDRESS}/%22%3E%3Cscript%3E;alert(document.domain)%3C/script%3E.htm (port 80)
</div>

Another one that is a bit murkier is this example:

https://{IP ADDRESS}/category/%27%3bfunc(document.cookie)%3b%27

The application does place components of the url into javascript variables, but always as quoted values.

This is in the output, and cited as evidence of XSS:

var gCategoryID="';func(document.cookie);'"

According to OWASP XSS prevention rule #3: The only safe place to put untrusted data into this code is inside a quoted "data value.", which I think is what we're doing.

So, are these actual vulnerabilities that I need to fix? Or does it appear that they are simply calling them vulnerabilities becasue the characters appear in the output?

I'm not clear on how these could be used to allow for an actual XSS attack.

  • 1
    Is the first provided GET-request actually html-escaped instead of url-escaped? One, that seems weird but may be on purpose. Two, the response should be escaping those ampersands. – ontrack Jan 7 '17 at 17:49
  • Yes, that's what they provided in the report. Seems odd... – Craig Jacobs Jan 7 '17 at 19:11
1

1.

<div class="info-heading">
{IP ADDRESS}/&quot;&gt;&lt;script&gt;alert(document.domain)&lt;/script&gt;.html (port 80)
</div>

With this particular payload it's a false positive. However, your query already contains HTML entites as input which was probably not intentional:

 GET {IP ADDRESS}/&quot;&gt;&lt;script&gt;alert(document.domain)&lt;/script&gt;.html 

Can you confirm the output is still encoded correctly when you try unescaped input instead? Like this:

GET {IP ADDRESS}/"><script>alert(document.domain)</script>.html 

2.

var gCategoryID="';func(document.cookie);'"

With the given payload, this also looks like a false positive, because single quotes don't interfere with the boundaries of a double-quoted string. However, if an attacker could insert double quotes or close the surrounding script tag instead, you'd be vulnerable.

So you need to ensure something like this is also escaped correctly:

https://{IP ADDRESS}/category/";alert(document.cookie);"

If it's not, you can use json_encode() in PHP to prepare a string for safe output as a JS string, e.g.:

var gCategoryID = <?php echo json_encode($category_id, JSON_HEX_QUOT|JSON_HEX_TAG|JSON_HEX_AMP|JSON_HEX_APOS); ?>
  • The example they provided had the HTML entities in the GET, which I also thought was weird. Updated question to include the unescaped GET which also seems safe. – Craig Jacobs Jan 7 '17 at 19:03

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.