0

I am confused about the attack surface made possible by an XSS vulnerability. Suppose I have a simple web application that does not involve authentication (perhaps a "word of the day" kind of thing). If it is naively written and allows injection by crafting a malicious link, what kind of damage can the injection do?

To make things concrete, here's a PHP script (what else) that is wide open to attack, since it will send back any nonsense added to the request URL. 

<html><body>
<p>
  <?php echo 'Access denied:' . $_SERVER["PHP_SELF"] ; ?>
</p>
</body></html>

How bad would it be to have this problem on my server? What can happen exactly? My script does not collect or store any data, so there is no chance of a persistent injection on my server.

  • If the user clicking on the malicious link trusts my domain, they could be tricked into doing or accepting things that they wouldn't otherwise. But if my domain enjoys no special trust, is there still danger? The attacker has already had access to the user/victim to trick them into visiting me through the doctored link, so is my website really posing an additional danger?

  • Since the reflected code appears to originate on my domain, could the attacker gain access to my intranet? I suppose in this case no trickery is needed: the attacker can run the malicious requests directly on my server, right?

I must be missing something here, please help me understand what that is.

Improve this question
8
  • That script isn't actually exploitable; it only returns the current script name. You were probably looking for $_SERVER['QUERY_STRING'].
    – Polynomial
    Commented Nov 11, 2018 at 0:22
  • @Polynomial, actually you can inject javascript by e.g. appending /"><svg onload=... to the URL. But that's just a detail, I would welcome an answer that assumes $_SERVER['QUERY_STRING'] is used.
    – alexis
    Commented Nov 11, 2018 at 0:28
  • As far as I can tell that isn't correct. $_SERVER['PHP_SELF'] returns the path of the current executing script on the server-side, relative to the webroot. I just tested this myself and it entirely ignores query parameters and rewrite rules, instead just printing the script path. So if, for example, you have a 404.php page that gets invoked when a path isn't found, and you browse to /nonexistent/<script>alert(1);</script>/foo.php, the value of PHP_SELF is just /404.php.
    – Polynomial
    Commented Nov 11, 2018 at 0:37
  • Always fix vulnerabilities. Remember, this XSS vulnerability could be used against you if there’s an admin panel or something (even though it is unlikely) as mentioned in @Polynomial’s answer.
    – CoderPE
    Commented Nov 11, 2018 at 2:04
  • @CoderPE, I fixed my code as soon as I found out about this. My question is about the possible maximal impact-- this seems to be a very limited vulnerability, but I want to make sure.
    – alexis
    Commented Nov 11, 2018 at 10:34

2 Answers 2

Reset to default
1

If the user clicking on the malicious link trusts my domain, they could be tricked into doing or accepting things that they wouldn't otherwise. But if my domain enjoys no special trust, is there still danger? The attacker has already had access to the user/victim to trick them into visiting me through the doctored link, so is my website really posing an additional danger?

The attacker doesn't necessarily have access to the user. They may have just sent a spam email with a link, or made up a fake social media profile to send them that link. Since your site seems benign enough (they may even know of the site and trust it) they may be more likely to click the link.

You're right that there is a lesser impact by way of your domain not having any secrets on it and no authentication. This is certainly true for the general users, at least. But consider that if you had, for example, a CMS admin panel on your site for managing the content or a blog, the attacker could instead trick you into clicking a malicious link and trigger XSS to get access to that panel.

While unlikely, it may also be possible for an attacker to leverage your site as a trusted domain in order to deliver a browser exploit via the XSS. A common example of this is where an attacker writes a script that reveals identifying information about someone who is browsing via the Tor browser, and tricks the user into enabling scripts on what seems like a benign and trusted domain.

Since the reflected code appears to originate on my domain, could the attacker gain access to my intranet? I suppose in this case no trickery is needed: the attacker can run the malicious requests directly on my server, right?

If by "intranet" you mean other sites on your local LAN, not in general. Cross-origin requests are denied unless the target server allows them using a CORS header. Subdomains are also not reachable due to same origin policy unless you override this - http://foo.com cannot reach http://x.foo.com or http://y.foo.com, and http://x.foo.com can reach neither http://y.foo.com or http://foo.com without a permissive CORS policy applied by the target domain.

I'm unsure what you mean by "run the malicious requests directly on my server" - XSS results in client-side script execution, not server-side.

Improve this answer
0

If the vulnerable site doesn't share a domain with any security-sensitive operations, and isn't a "trusted" site that users have any special reason to believe is legitimate (for example, where users might believe that entering credentials for something would be expected), then the XSS is not a meaningful risk.

If the domain (including higher-level or sub-domains) is used for anything at all sensitive, then there is a risk, as an attacker could possibly access or manipulate cookies or hijack sessions even though that particular page is unauthenticated. If the domain is a trusted one (for example, a corporate internal web app), then people are likely to be less suspicious if it, for example, asks them to log in with their corporate credentials. Finally, some sites can still have sessions that need to be kept secure, even without authentication. Consider a ticket-booking site that doesn't require users to have an account before they buy a ticket, but where an XSS could still steal the user's payment info or similar.

Improve this answer

You must log in to answer this question.

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