2011-11-22 19 views
8

Sto verificando il mio sito web con w3af.Protezione del mio sito

Dice che ha trovato diversi problemi sul mio sito, ma dubito che sia davvero il caso.

Uno dei problemi è:

L'URL: http://localhost/en/login è vulnerabile a croce richiesta sito falso. Consente all'utente malintenzionato di scambiare il metodo da POST a GET quando invia dati al server.

Sono abbastanza sicuro che non sia vulnerabile a un attacco csrf da quando ho usato la protezione crsf nei miei moduli (campo con token che viene controllato).

Quindi mi chiedo che cosa questo messaggio riguarda:

Esso permette all'attaccante di scambiare il metodo da POST a GET durante l'invio dei dati al server.

Non mi importa se un utente malintenzionato potrebbe essere in grado di passare POST-GET o devo?

E se posso, puoi spiegare perché lo faccio? Come può essere sfruttato?

+0

Stai utilizzando $ _REQUEST in tale formato, invece di _POST? –

+0

@MarcB: Sì, lo sono. Ma non vedo come sarebbe sfruttabile (considerando il campo di prevenzione CSRF). – PeeHaa

+0

@Macmade: puoi spiegare perché me ne importa? – PeeHaa

risposta

3

Provenendo da un punto di vista di nessuna esperienza con w3af, presumo che ci siano delle regole piuttosto semplici scritte in esso e controlla quelle regole e riporta su di esse.

In questo caso sarà probabilmente verificare se si è utilizzato al posto di $_REQUEST$_POST o $_GET e poi segnalare un errore se lo trova, indipendentemente gli sforzi che avete fatto per garantire questo.

Ognuno codificherà in modo diverso, quindi ottenere il software per comprendere il contesto del proprio codice sarebbe un risultato straordinario e probabilmente va oltre l'intelligenza di questo. Questo non è inteso come un attacco al software, ma per essere onesti se mi viene in mente qualche programma che possa comprendere il contesto e l'intento del codice di qualcun altro, non lo darei a sourceforge: p

Importa? Forse dipende da quanto bene hai assicurato il sito (vedi il commento di Marc B (+1) sopra).

- EDIT -

Utilizzando $_REQUEST invece di specificare $_POST o $_GET hai lasciato te stesso aperto a una zona di attacco che può essere facilmente chiuso. Non solo questo ma $_REQUEST include anche $_COOKIE. Questo è stato coperto here anziché duplicare la risposta di qualcun altro.

+0

Dimmi perché il +1 da quando ho la protezione csrf in ... non capisco. Vedi anche il mio commento sul commento di Marc B. Come può mai essere sfruttato quando la protezione CSRF è a posto. O mi manca qualcosa di enorme qui (può anche essere il caso, succede a volte :)) – PeeHaa

+0

Ho aggiornato il mio post in risposta;) –

+0

Oh @PeeHaa a proposito +1 per w3af. Ho appena visto e sembra davvero fantastico. –

Problemi correlati