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)

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)

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, 2017 at 17:49
  • Yes, that's what they provided in the report. Seems odd... Jan 7, 2017 at 19:11

1 Answer 1



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

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 


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. Jan 7, 2017 at 19:03

You must log in to answer this question.

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