Authenticated XSS – problem or not?

Obviously, cross-site scripting (XSS) is a big problem on the public Web. But there’s another angle to XSS that no one seems to be talking about – at least I’m not seeing anything on it. It’s the issue of XSS on Web pages that are only accessible when the user is logged in. I see XSS in this context all the time which begs the question: is XSS indeed a “problem” if the user has to login to be on the receiving end of the exploit? Many developers I’ve worked with don’t seem to think so, but as of late, I’m forming a different opinion on the issue.

For starters, XSS on any page – whether or not authentication is required – clearly indicates an input validation issue. But that doesn’t automatically make it a security problem. So maybe it’s just a lower priority ‘best practice’ that’s being overlooked? But we can’t stop there. If you dig in further and think about some real-world scenarios I truly believe this is something that can be a big problem if we don’t address it.

Looking at certain authenticated XSS scenarios there’s no doubt that it can be exploited if all the right things fall into place at the right time. For instance, a user who’s logged into an application with a XSS flaw somewhere behind the login prompt. Assuming the user’s session hasn’t timed out, he could click a malicious link elsewhere that points back to the XSS hole and could end up falling victim to the exploit.

Another example would be in a business environment that uses single sign-on (SSO) across multiple applications. A user logs into one application and his authenticated session is passed along behind the scenes to subsequent applications he connects to. In this situation, the user is not prompted to login again, and thus, automated XSS could be carried out. In reality, this would likely be something that’s perpetrated by a malicious insider working for a large corporation or government entity. However, this attack could also be carried out in situations where SSO is implemented among multiple sites where, say, only key business partners and customers are granted access.
So, what are your thoughts? Is this a problem or should we only worry about public-facing XSS exploits that don’t involve user authentication?

If it is indeed a problem, what do we do about it? Depend on SSO systems to detect and block XSS? Re-prompt users for their login credentials when they’re crossing over to another domain? Use a WAF?

I know these are hypothetical cases where the likelihood is minimal. But an elevated impact does still exist so we can’t ignore the issue altogether.

Share this post
  • I have seen real world scenarios where the visitor logging system has an XSS vulnerability. This particular scenario is just or even more of a security concern than non-authenticated XSS.

    For example: A malicious user crafts a HTTP packet and changes the ‘referer’ header value to an XSS payload. When the authenticated admin goes to look at the logs the payload is then executed. Game over.

  • Authenticated XSS is a critical security flaw.
    For one thing, many of the most nasty features of XSS require the user to be authenticated anyway.

    For one more thing, many popular administration systems have authenticated XSS issues, cPanel for example. When anyone can see the back end of these applications, an attacker can almost launch a blind XSS campaign.

    In fact, my most recent published exploit on Digg involved authenticated XSS,

  • Authenticated XSS is critical indeed…I just think it’s interesting that no one’s really talking about it.

  • Let me ask the question the other way: Why is unauthenticated XSS an issue? What do I gain from a XSS-attack carried out against someone browsing a web-site beeing not logged in? I can browse the web-site on my own and see the same content as s/he does.
    But when s/he is logged in I could gather the credentials for any further (bad) purposes. Do I miss something here?

  • So someone does think the way I do — IMHO, yes, there should be no difference between authenticated-XSS and non-auth-XSS — both are at the same severity level. The primary reason is the attack vector — it is as easy to exploit an authenticated-XSS via social engineering, as it is to exploit a non-auth-XSS.

    I think this is also a primary problem why XSS (and its siblings) are poorly understood, and hence, are prevalent. 🙂

  • Leave a Reply

    Your email address will not be published.