C'è qualche pericolo da CSRF se un webservice non ha alcun impatto sui dati del server?

1

Ho letto su CSRF e come funziona, e, se ho capito bene, l'unica cosa che un utente malintenzionato può fare è costringere l'utente a compiere azioni che non intendeva.

Comprendo il pericolo se disponiamo di un servizio come / moneytransfer? da = user & to = attacker.

Tuttavia, se un servizio si limita ad aggiornare i valori del cookie dell'utente, allora CSRF non darebbe nulla all'attaccante, corretto? Esiste il pericolo che l'autore dell'attacco possa visualizzare cookie o contenuti di risposta senza XSS? In tal caso, sarebbe addirittura necessaria la protezione CSRF?


Modifica

Mi scuso, temo di non essere stato troppo chiaro ...

Diciamo che ho un cookie con un ID di sessione. Ogni volta che l'utente accede al servizio:

foo.com/getSession?user=jon&password=pass

... recupera un cookie con Auth-Cookie = # SessionId .

Per l'autenticazione, invece del cookie, il server si aspetta la sessione in un'intestazione HTTP, ad esempio:

HTTP-AUTH: #SessionId


In tal caso, una chiamata al servizio / getSession da parte di un utente malintenzionato darebbe semplicemente all'utente un nuovo cookie di sessione.


In uno scenario come questo, CSRF sarebbe mai un pericolo?


(Questo è tutto ipotetico, so che ci sono modi migliori per fare l'autenticazione. Sono un nuovo arrivato per la sicurezza, e sto solo cercando di capire i limiti della CSRF, e quali tipi di servizi avrebbero bisogno di protezione). / p>     

posta lv. 10.11.2015 - 14:30
fonte

3 risposte

1

CSRF intende principalmente sfruttare sessioni già autenticate. Quindi, se esiste un metodo utilizzabile senza l'utilizzo di token Random CSRF per la convalida con il server, può essere eseguito anche dall'attaccante. Puoi anche utilizzare l'intestazione Origin e Referer e la risposta alle sfide come suggerito in OWASP Cheat Sheet ( link )

    
risposta data 10.11.2015 - 17:03
fonte
1

L'attaccante è ancora in grado di fare richieste POST se può iniettare qualche javascript, quindi recuperando la risposta a / getSession . Si prega di dare un'occhiata a OWASP e questo Blog post per imparare come prevenire CSRF attacchi.

    
risposta data 10.11.2015 - 16:46
fonte
0

Il punto principale di CSRF è forzare il browser client a inviare richieste HTTP senza l'intenzione del cliente. In realtà, la frequenza di aggiornamento dei cookie non è un argomento importante per lo sfruttamento della CSRF. Se l'aggiornamento dei cookie sta avvenendo così velocemente o meno, il browser client utilizzerà l'ultimo. Perché il cliente mirato sarà l'unico! chi sarà costretto dall'attaccante a inviare richieste HTTP speciali all'applicazione.

Non c'è modo di vedere cookie o risposta della richiesta HTTP durante lo sfruttamento di vulnerabilità CSRF di base.

Immagina di essere una vittima e stai visitando un sito Web che è sotto il controllo degli hacker. Website.com invierà di seguito

<img src="https://bank.com/api/disableMyAccount"></img>

Il tuo browser invierà GET all'URL sopra per servire il contenuto dell'immagine. Se hai una sessione valida prima di visitare website.com. Il tuo account sarà disabilitato, che non è la tua intenzione. Come puoi vedere, non abbiamo visto alcun cookie o contenuto di risposta durante le visite a bankbank.com.

    
risposta data 10.11.2015 - 14:49
fonte

Leggi altre domande sui tag