I have performed security testing on a web application. Following is the scenario:

  1. Logged into the application with valid credentials.
  2. There are two fields in a particular feature which are displayed only after login.
  3. I have provided XSS payloads which generates alert boxes with cookie information, domain information and saved that feature.
  4. Whenever a user visits that feature, those provided scripts are getting executed and alert boxes with cookie information are generated continuously.

But the dev team says that unless you are logged in, you cannot give the scripts as inputs and this is therefore an invalid scenario.

So now, how can I justify that it is the valid scenario and it is a potential risk to the application?

  • 2
    Privilege escalation? Can a normal user add this in and get the session info from an admin? – crovers Oct 27 '17 at 17:42
  • 2
    Alternatively, repudiation - if there is an action that could benefit a user, this could give them a way to do that action without it being tied to them - instead, it would look as if the victim did it – crovers Oct 27 '17 at 17:43
  • 1
    So, only an authenticated user can produce the stored XSS and only for themself? – Arminius Oct 27 '17 at 17:44
  • 1
    @SaiDuttMekala And the XSS payload is shared across different users as well? Or only for the one user which inserted it themselves? – tim Oct 27 '17 at 18:01
  • 1
    @Tim, they are getting executed for all the users who visit that page. – Sai Dutt Mekala Oct 27 '17 at 18:05

The Dev team is wrong. The impact here is horizontal and vertical privilege escalation.

Post-auth XSS is just as valid as pre-auth XSS. Generally, you want the victim to be logged in anyways, as you want to exploit their current authentication. The only mitigating factor is that the attacker requires an account. Depending on how easy that is to get, the impact rating of the issue would go down, but it is still a vulnerability[*]

An attacker can use XSS to perform arbitrary actions in the name of any user visiting the page containing the payload, and read any data that those users have access to.

[*] Note that for some users this may be an accepted risk. Some applications would for example let administrators post unfiltered HTML, as they already have unlimited access without XSS.

If the payload would only be displayed to the user inserting it themselves, then that would be a different issue. You could only exploit it by either getting the user to enter the data (eg via clickjacking or CSRF) or by tricking the user to log into the account that placed the payload (eg via session fixation or login CSRF).

| improve this answer | |
  • Is there any XSS payload that can read a user's CSRFtoken in the HTML page when the above-mentioned vulnerability exists.It can increase the severity of the bug. – Sai Dutt Mekala Oct 27 '17 at 20:10
  • @SaiDuttMekala Yes, when you have XSS, you always have CSRF (by reading the token in token-based CSRF protection). Because of that, you can perform arbitrary actions for the user. – tim Oct 27 '17 at 20:19

Create a script that hangs the apps, and let it run for all logged in users.

If you want to do more advanced attacks, insert a script that calls an API to change a user's profile info, or some other data (because your script will have access to cookies so it can make any calls on that domain that relies on cookies for authentication). It can also fetch user's profile info and display on screen (to demonstrate that the attacker can get access to all this data).

A yet further step would be to show a UI that requests user name and password (with some message like "your session has expired, please enter username and password to continue"), and does not allow user to continue to use the app until it has verified the password is correct (e.g. against some auth. endpoint). You don't have to store it anywhere, you're merely indicating that at this point, the script writer can send the password to their own server.

How much of this you will have to build depends on how much convincing you need to do. You can also let them know that you're being nice in telling them that you're doing this, a malicious user does not need to tell this.

If the app is open to any user (i.e. anyone can register) and carry out the attack, then just register a new user with a cryptic name and demo it.

If logged in users are internal employees only, then it comes down to trust between employees. Insider threat is a very legitimate concern.

| improve this answer | |

The only good defense is a defense in depth. At the moment, their authentication scheme may seem secure. But some day a vulnerability in it will be found, either by an attacker, or by you, or by a disgruntled insider that is already authenticated.

If they were executing proper defense-in-depth, then when that hostile agent gained access to the system, the damage they could do would be limited by further security mechanisms. However, with their attitude that a vulnerability only counts if it can be executed by an outside threat, they are completely throwing away any opportunity to create additional lines of defense.

So, for example, an attacker that was only able to gain limited user access could obtain admin credentials. Their authorization scheme is vulnerable. Or an underpaid employee could decide to run a JS-based cryptocurrency miner on the clients of all of your users to gain a little extra cash on the side. Or a user from outside of finance/management could access internal information for a little insider trading.

Saying XSS doesn't matter because you have to be logged in is functionally equivalent to saying that all logged in users should have permission to see and do everything that all other logged in users do. No users vs admins, no departmental privacy, no user non-repudiation. All users, functionally indistinguishable. If that's not true for their use-case, then XSS is an exploitable vulnerability they should be concerned about.

Edit: If they're convinced that none of the above could happen, I recommend you switch to social engineering attacks on the authentication scheme. The most secure authentication schemes still require human interaction and so are depressingly vulnerable.

| 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.