2

I'm sure many of you will have seen the CSRF exploit highlighted by Paul Moore that ASDA have known about for two years (Paul's blog)

I am trying to find an explanation as to WHY the website is vulnerable and how to ensure my sites are not. I understand CSRF to a point - my sites validate an anti-forgery token present in the forms and all pages are served over https.

In the exploit he goes to another site with the malicious payload in another tab, and upon switching back to the ASDA page a form appears asking for credit card info which his server sees when submitted.

What is ASDA doing incorrectly to allow this exploit?

3

The blog post from Paul Moore holds back quite a lot of information, probably on purpose, seeing that asda hadn't fixed the issue when he published the post.

Here is an article that is a bit more explicit about the vulnerabilities of Asda.

CSRF Vulnerability

First of, they did not seem to have any CSRF protection:

There is no XSRF protection throughout the site. It's possible to remotely hijack any active account without knowing the username/password

The impact of this depends on what a user can actually do on the website (because that is what an attacker can also do with CSRF, except if a user has to enter a password for the action). From the description, it doesn't sound like it's too much though:

It's also possible to add/remove items to the basket from a remote site and ship to an alternative address, increasing the risk of fraud/identity theft.

This is obviously still bad though.

CSRF to XSS

In the exploit he goes to another site with the malicious payload in another tab, and upon switching back to the ASDA page a form appears asking for credit card info which his server sees when submitted.

I couldn't find any information on this, but a save bet is that this is an issue of persistent XSS via CSRF (or maybe reflected POST XSS via CSRF).

What is probably happening: Some form field on the website is vulnerable to XSS via POST, either reflected or persistent, and this can be exploited because there is no CSRF protection.

Normally, POST XSS issues in a user area wouldn't be that big of an issue (although you still shouldn't have them), as CSRF (and possibly ClickJacking) protection prevents people from exploiting it (if the login is also CSRF protected).

But as there is no CSRF protection, the XSS vulnerability in the user area is now exploitable. As XSS is quite a bit more powerful than CSRF, this is a problem.

The attack code might look something like this (it's made up to illustrate the point):

<form action="https://example.com/profile.php" method="POST" id="myform">
  <input type="hidden" name="name" value="<script>alert(1)</script>" />
  <input type="submit" value="Submit request" />
</form>
<script>document.myform.submit();</script>

If a user visits a website containing this code while logged into asda, their profile would be updated, and the injected code would be executed in the context of the asda site.

As you can see, the XSS payload in the example is submitted by the victim, meaning that browser filtering will likely protect some users. However, it is likely that an attacker could create a new account, inject the payload in that account themselves, and then force-login a victim via CSRF, bypassing browser filtering. If a victim does not notice that they are logged into a different account, they may still provide sensitive information.

  • In your example, does the ASDA site's form also have the id of "myform"? I want to understand how the ASDA tab's form is submitted. Also you say "some form field... is vulnerable to XSS via POST". How? – VictorySaber Jan 21 '16 at 15:34
  • @VictorySaber no, the id is only in the payload, which will trigger XSS in the asda site. With the injected js code there, an attacker can submit any form they want, and they can read out any information that is displayed in the user area (if you are unsure how, I would read up on what JavaScript can do). And how XSS? Well, I would guess that it's just standard XSS. So either something like <input type="text" name="name" value="$_POST["name"]"> for reflected XSS via POST, or something like <div>$databaseResultRow["name"]</div> for persistent XSS. – tim Jan 21 '16 at 16:04

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.