Qualcuno potrebbe spiegare come il sito ASDA è vulnerabile?

3

Sono sicuro che molti di voi avranno visto l'exploit CSRF evidenziato da Paul Moore che ASDA conosce da circa due anni ( blog di Paul )

Sto cercando di trovare una spiegazione su PERCHÉ il sito web sia vulnerabile e su come garantire che i miei siti non lo siano. Comprendo CSRF fino a un certo punto: i miei siti convalidano un token anti-contraffazione presente nei moduli e tutte le pagine sono pubblicate su https.

Nell'exploit si reca in un altro sito con il carico utile malevolo in un'altra scheda e quando si torna alla pagina ASDA appare un modulo che richiede informazioni sulla carta di credito che il server vede quando viene inviato.

Che cosa sta facendo in modo errato ASDA per consentire questo exploit?

    
posta VictorySaber 21.01.2016 - 13:51
fonte

1 risposta

3

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.

    
risposta data 21.01.2016 - 15:48
fonte

Leggi altre domande sui tag