Triggering Javascript dalla stringa user-agent. CSRF o XSS?

0

Ho letto diversi libri sulla sicurezza di PHP, ma dopo averne letto uno mi sono confuso sulla definizione di CSRF (Cross-Site Request Forgery). Wikipedia lo spiega così:

Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.

Normalmente questo exploit riguarda l'invio di due richieste, una per ottenere un token e l'altra per ottenere un token da ripristinare, ad esempio un account amministratore. Ad esempio, sfruttando la vulnerabilità in cui un sito Web genera token di entropia deboli utilizzando per esempio mt_srand() . Giusto?

E se un sito web registra quale browser stai utilizzando raccogliendo la stringa user_agent? Per esempio: AdminPanel.php:

<?php
    $browser = $_SERVER['HTTP_USER_AGENT'];
    addToLog($browser);

    $logs = getAllLogs();
    echo $logs;
?>

Normalmente questo ritorno: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0

Ma potrei modificare la mia stringa user-agent in Firefox:

+----------------------------+----------+--------+-----------------------------------------------------------------------------------------------------+
| general.useragent.override | user set | string | <script>window.location.replace('http://myHackerServer.com/fakeAdminPageForPhishing.php');</script> |
+----------------------------+----------+--------+-----------------------------------------------------------------------------------------------------+

In questo modo il codice Javascript verrebbe eseguito sul pannello di amministrazione. In questo modo, puoi sfruttare l'XSS quando l'amministratore registra le stringhe utente degli utenti e poi controlla in seguito.

Ma questo XSS o CSRF? Voglio dire, il sito web si fida del browser dell'utente per contenere valori validi. Come dice Wikipedia. Non è necessario fidarsi di "input dell'utente" come in XSS. Sono confuso da ciò che CSRF è, ho visto un sacco di definizioni diverse.

Grazie.

    
posta O'Niel 30.07.2016 - 15:57
fonte

2 risposte

2

Il tuo esempio è XSS. La definizione completa di CSRF da Wikipedia:

Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user’s web browser to perform an unwanted action on a trusted site for which the user is currently authenticated.

Esempio di un attacco CSRF: supponiamo che tu possieda un sito web example.com e che tu abbia un negozio in cui gli utenti possono acquistare articoli utilizzando le richieste GET. Un link di esempio potrebbe essere: example.com/shop/purchase?itemId=123456 e non esegue alcuna autenticazione, ma assicurandosi che l'utente sia online. Atterri sulla pagina - Boom, $ 30 vengono prelevati dal tuo conto bancario.

Ora, un utente malintenzionato potrebbe prendere quel link e mascherarlo all'interno di un'email o incorporarlo in un'immagine cliccabile su un forum attivo, rendendolo quindi sicuro (fai clic qui per ulteriori informazioni, ecc.). Quando un utente fa clic su quel link (chi non vuole comprare quell'oggetto), ha automaticamente addebitato i $ 30 che non voleva nemmeno spendere!

La protezione contro questo è abbastanza semplice: si genera un token CSRF univoco per ogni utente quando viene creata la sua sessione e si costringe a passare il token come parametro. Quindi ora il tuo link è example.com/shop/purchase?itemId=123456&token=abcdefg . Ora, un utente malintenzionato non può inviarmi link "dannosi" perché non conosce il mio token!

Come puoi vedere, questo attacco non ha niente a che fare con Javascript. Il tuo esempio era XSS persistente (un argomento interessante di per sé, anche se non correlato alla tua domanda, quindi non mi tufferò qui dentro)

    
risposta data 30.07.2016 - 16:09
fonte
-1

La spiegazione di Tom è buona, ma vorrei aggiungere quanto segue. In genere, quando si effettua l'autenticazione su un sito Web a cui viene assegnato un token che di solito viene memorizzato in un cookie di sessione del browser e per ogni richiesta successiva, il cookie identifica l'utente.

Ora per ogni richiesta allo stesso dominio il tuo browser emetterà il cookie.

Se un avversario crea un'immagine nascosta in una pagina ed esegue una richiesta GET al dominio, il lato server non ha idea se questo sia legittimo o meno.

È qui che entra in gioco un token CSRF. Se il lato server ha un altro identificatore indipendente dal cookie, può validarlo contro di esso.

È importante che il token CSRF sia associato al cookie di sessione degli utenti.

    
risposta data 30.07.2016 - 20:09
fonte

Leggi altre domande sui tag