CSRF su app GWT: ignorando la politica Same-Origin

0

Al lavoro sospettiamo un'app GWT (che non è ancora in produzione) che possediamo come vulnerabili a CSRF. Dobbiamo esaminarlo dal punto di vista della scatola nera prima di eseguire un controllo di sicurezza di terze parti.

Dato che tutte le chiamate nell'app vengono effettuate tramite AJAX (con metodo POST), la semplice replica di una chiamata Ajax in modo malevolo non è ottenibile grazie alla politica Same-Origin. In effetti sappiamo che non esiste una protezione CSRF, ma dal momento che solo i corpi delle richieste ("payload" nella scheda di rete di Chrome) vengono letti dal server, a prima vista sembra che la vulnerabilità non possa essere sfruttata.

C'è un modo per creare una richiesta simile attraverso un browser con un modulo classico? Il mio problema è che non riesco a replicare il corpo della chiamata Ajax attraverso un modulo: l'app legge il corpo delle richieste - l'invio di un modulo di classificazione richiede input con coppie chiave / valore che non verrebbero prese in considerazione dal server.

In altre parole, è possibile, con un modulo html, inviare una richiesta che contiene solo testo in un corpo, invece di coppie chiave-valore nel corpo? O c'è un altro angolo di attacco per questi casi?

Modifica (informazioni aggiuntive):

I clic sui pulsanti dell'applicazione generano richieste che utilizzano text/x-gwt-rpc; charset=UTF-8 come content-type che, suppongo, è ciò che si aspettano i gestori di chiamata GWT RPC e non possono essere "falsificati" con un browser normale (ovviamente una richiesta del genere potrebbe essere falsificato senza un browser, ma va bene, visto che sto solo cercando di sfruttare un potenziale CSRF).

Ciò che mi dà fastidio è il fatto che so che non ci sono token CSRF nelle richieste e che potrebbe esistere un modo complicato per falsificare le richieste maligne - ma non vedo come.

    
posta niilzon 27.03.2015 - 12:03
fonte

1 risposta

2

La tua applicazione utilizza post AJAX con content type impostato su text/x-gwt-rpc .

In other words, is it possible, with an html form, to submit a request that just contains text in a body, instead of key-value pairs in the body ?

In base alla specifica HTML , è possibile solo impostare seguenti tipi di contenuto per un modulo HTML:

  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

Pertanto non è possibile impostarlo come text/x-gwt-rpc e farlo capire dal browser.

Questo indica il "Protocollo GWT-RPC" . Con alcuni tipi di contenuto, potrebbe essere possibile "ingannare" il browser nell'inviare un altro tipo di payload usando text/plain . Ad esempio, ecco come potrebbe essere fatto con un payload JSON, sebbene venga inviato senza l'intestazione content-type corretta.

<form enctype="text/plain" method="post">

<input type="hidden" name="{&quot;foo&quot;: &quot;bar&quot; }//" value="" />

<input type="submit" />

</form>

sarebbe inviato come

{"foo": "bar" }//=

Non perfetto, ma ti viene l'idea.

Or is there another attack angle for such cases ?

Se l'applicazione non sta controllando il content type del lato del modulo del modulo inviato, potrebbe essere possibile per un utente malintenzionato costruire una richiesta AJAX e POST tale dominio incrociato sul server. Ad esempio, possono impostare content type come text/plain , che è permesso cross domain senza una richiesta OPTIONS .

I tipi di contenuto tra domini consentiti per la richiesta AJAX corrispondono esattamente ai tipi di contenuto consentiti tramite un modulo HTML.

Un'opzione potrebbe essere per aggiungere un'intestazione alle tue richieste come X-Requested-With e quindi verificare questo server lato. Poiché questa intestazione non può essere inclusa in una richiesta di dominio incrociato senza che il server opti per tramite CORS, ciò proteggerà la tua applicazione dagli attacchi CSRF.

    
risposta data 27.03.2015 - 13:29
fonte

Leggi altre domande sui tag