È possibile utilizzare una sorta di CSRF usando il tag img / script per leggere le informazioni sensibili

3

Diciamo che ho un'API in https://mysite/api/getSensitiveData che:

  • Utilizza GET
  • Protetto con l'autenticazione cookie
  • Restituisce JSON con alcuni dati sensibili

Un cattivo ragazzo crea un sito sul suo server che ha un tag immagine:

<img src="https://mysite/api/getSensitiveData"><img>

Ora il browser eseguirà questa richiesta e invierà il cookie e i dati verranno caricati (per quanto ne so almeno) e, poiché non è un'immagine, non verrà mostrato nulla.

Ma la richiesta è stata eseguita su un sito in cui un cattivo ragazzo controlla javascript. C'è un modo in cui la risposta può essere letta dall'immagine, qualche intercettazione di richieste o qualche altro metodo?

P.S. Forse ci sono altre possibilità simili, non necessariamente tag img?

    
posta Ilya Chernomordik 26.04.2018 - 18:55
fonte

1 risposta

5

Con solo un tag immagine - no. Affinché l'hacker possa raccogliere dati dall'endpoint dell'API e restituirlo a se stesso, dovrebbe avere javascript nella pagina sotto il suo controllo. Con javascript / ajax, il browser continuerà a passare i cookie e quindi ad autenticare la sua richiesta, potenzialmente permettendogli di ricevere una risposta e quindi inviarla a un nuovo server.

Tuttavia, qualsiasi tentativo di farlo verrà eseguito in contrasto con lo stesso criterio di origine nel browser. Ciò indica che se uno script richiede un documento da un sito con un host, una porta o un protocollo diverso, la risposta verrà negata dallo script a meno che non sia esplicitamente approvata dal sito di destinazione.  Il modo più comune per approvare le richieste tra domini è tramite CORS. Di conseguenza, l'unico modo in cui un utente malintenzionato sarebbe in grado di leggere effettivamente la risposta dal proprio endpoint e recuperare i dati è se (il proprietario del dominio) ha comunicato esplicitamente al CORS di consentire le credenziali e di inserire il nome di dominio in bianco javascript è in esecuzione.

Per aggirare questa restrizione, l'utente malintenzionato dovrebbe ottenere il proprio javascript per l'esecuzione sul tuo dominio, ma in quel momento stiamo parlando di un attacco XSS, e tu sei praticamente protetto. Esistono modi per impedire che i dati tornino a un utente malintenzionato anche in caso di un attacco XSS con intestazione CSP ben configurata, ma le intestazioni CSP possono essere difficili da ottenere correttamente e non dispongono ancora di un ampio supporto browser (in particolare IE ).

L'analogia più vicina a ciò di cui stai parlando è il dirottamento XSSI / JSON. Queste sono tecniche diverse per aggirare le restrizioni della politica dell'origine stessa nel browser:

link

Tuttavia, le tecniche che consentono di aggirare queste restrizioni sono state ampiamente corrette nei browser moderni, rendendo la vulnerabilità molto meno rilevante:

link

È sempre possibile che ulteriori carenze di questo tipo possano essere trovate in futuro, nel qual caso ci sono alcune tecniche di protezione contro XSSI (h / t Xavier59):

link

    
risposta data 26.04.2018 - 21:04
fonte

Leggi altre domande sui tag