Script cross-site nel metodo HTTP?

2

Ultimamente, ho notato che molte configurazioni del server Web riflettono il metodo di una richiesta HTTP inviata con un metodo non implementato nel corpo della risposta del server.

Ad esempio, una richiesta inviata con il metodo GETTT riceverà un codice di risposta 501 "metodo non implementato", mentre il corpo della risposta annuncia che il metodo "GETTT" non è supportato. Da quanto ho capito, questo significa che se il metodo inviato al server web non è validato correttamente può essere vulnerabile a un attacco XSS riflesso.

La mia domanda è: in che modo un utente malintenzionato può sfruttare questo tipo di situazione per creare un collegamento che causerà l'emissione di una richiesta HTTP con un metodo arbitrario contenente il carico utile XSS? In teoria, le richieste di jquery $ ajax dovrebbero essere in grado di gestire questo tipo di problema, come indicato anche nella seguente discussione - link

Sono stato in grado di inviare questo tipo di richieste diversi mesi fa (in Internet Explorer), ma per qualche ragione, jquery $ ajax non fa più il trucco per me.

Sono sicuro che questo è un problema risolvibile e solo una questione di trovare il giusto carico utile, qualcuno ha qualche suggerimento?

    
posta user3074662 30.12.2013 - 08:27
fonte

1 risposta

1

Risposta semplice: Non utilizzabile

Sebbene sia possibile iniettare codice di script usando un verbo HTTP malformato, questo vettore di attacco manca del componente "cross-site" che rende la vulnerabilità utile a un utente malintenzionato. Quindi, perché un'iniezione come questa sarebbe inutile per un aggressore?

Prima di tutto, in che modo un utente malintenzionato invia una richiesta "cross-site"? Ci sono un paio di varianti, ma la più comune è la seguente.

<form id="CSRF" method="POST"  action="http://victim/search" >
<type=hidden name=search value="<script>alert(1)</script>">
</form>
<script>
document.getElementById("CSRF").submit()
</script>

L'HTML sopra invierà automaticamente una richiesta POST quando la vittima esegue il rendering dell'HTML. La pagina http://victim/search riflette la richiesta POST di ricerca sulla pagina, quindi esegue il payload XSS nel browser della vittima nel contesto di http://victim/search indipendentemente da dove ha origine la richiesta.

È possibile controllare alcune delle intestazioni HTTP usando il flash, quindi ho scritto un framework di exploit flash per sfruttare il CSRF insolito / XSS . Sfortunatamente il flash al momento consente solo i verbi GET e POST , PUT e DELETE dove consentito in una sola volta, ma non più.

    
risposta data 30.12.2013 - 17:16
fonte

Leggi altre domande sui tag