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