Il post sul blog di Paul Moore trattiene un bel po 'di informazioni, probabilmente apposta, visto che Asda non ha risolto il problema quando ha pubblicato il post.
Ecco un articolo un po 'più esplicito sulle vulnerabilità di Asda .
Vulnerabilità della CSRF
Per prima cosa, non sembravano avere alcuna protezione CSRF:
There is no XSRF protection throughout the site. It's possible to remotely hijack any active account without knowing the username/password
L'impatto di questo dipende da ciò che un utente può effettivamente fare sul sito web (perché è ciò che un utente malintenzionato può fare anche con CSRF, tranne se un utente deve inserire una password per l'azione). Dalla descrizione, non sembra che sia troppo però:
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.
Questo è ovviamente ancora brutto però.
CSRF in 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.
Non sono riuscito a trovare alcuna informazione al riguardo, ma una scommessa di salvataggio è che si tratta di un problema di XSS persistente tramite CSRF (o forse riflesso POST XSS tramite CSRF).
Che cosa sta succedendo probabilmente: alcuni campi modulo sul sito Web sono vulnerabili a XSS tramite POST, riflessi o persistenti, e questo può essere sfruttato perché non esiste una protezione CSRF.
Normalmente, i problemi POST XSS in un'area utente non sarebbero un grosso problema (anche se non dovresti ancora averli), dato che la protezione CSRF (e forse ClickJacking) impedisce alle persone di sfruttarla (se il login è anche CSRF protected).
Ma poiché non esiste una protezione CSRF, la vulnerabilità XSS nell'area utente è ora sfruttabile. Dato che XSS è un po 'più potente di CSRF, questo è un problema.
Il codice di attacco potrebbe essere simile a questo (è stato creato per illustrare il punto):
<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>
Se un utente visita un sito Web contenente questo codice mentre è connesso a asda, il suo profilo verrebbe aggiornato e il codice inserito sarebbe eseguito nel contesto del sito asda.
Come puoi vedere, il carico utile XSS nell'esempio è presentato dalla vittima, il che significa che il filtro del browser probabilmente proteggerà alcuni utenti. Tuttavia, è probabile che un utente malintenzionato possa creare un nuovo account, iniettare direttamente il carico utile in tale account e quindi forzare l'accesso a una vittima tramite CSRF, ignorando il filtro del browser. Se una vittima non si accorge di aver effettuato l'accesso a un altro account, può comunque fornire informazioni riservate.