Perché questo attacco di divisione della risposta non funziona?

Naviga le tue risposte
5

Sto lavorando attraverso l'applicazione web vulnerabile di "WebGoat" (versione 5.4) di OWASP, ma mi sto bloccando su una delle prime lezioni che ha a che fare con la divisione della risposta HTTP.

Ho esaminato tutti i suggerimenti e la soluzione (e anche tutti i tutorial sparsi per l'interwebs), ma non riesco ancora a farlo funzionare.

Ho persino modificato completamente la risposta del mio server web a: 

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: http://localhost/WebGoat/attack?Screen=3&menu=100&fromRedirect=yes&language=en
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 19
<html>Graeme</html>
Content-Type: text/html;charset=ISO-8859-1
Content-length: 0
Date: Sun, 28 Jul 2013 20:26:13 GMT

Sono abbastanza fiducioso che questo dovrebbe far apparire il mio browser "Grezzo", ma invece sta seguendo la prima risposta piuttosto che la seconda risposta. Ho persino provato a prendere la prima riga "Content-Length: 0", ma non fa differenza.

Cosa sta succedendo qui? Mi sto perdendo qualcosa? Forse i moderni browser web seguono sempre la prima risposta in questi giorni?

    
posta Grezzo 28.07.2013 - 22:33
fonte

4 risposte

10

Il pezzo base di HTTP Response Splitting (HRS) che viene tralasciato più spesso, è il proxy.

HRS non è un attacco tra un server web e un browser, o anche un browser e un server web.
L'attacco è sulle idiosincrasie dei dispositivi HTTP semi-conformi, ovvero il server Web e il proxy Web.
Nello specifico, l'attacco sfrutta il fatto che il server web vede un set di risposte (una risposta) e il proxy vede un set diverso (due risposte) e il proxy divide una richiesta alla vittima e l'altro all'attaccante (o all'etere).

Quindi, per testare meglio questo attacco, devi impostare:

  1. server web
  2. proxy
  3. browser vittima
  4. client attacker (o browser)

Suppongo che tu abbia perso la parte proxy ...

    
risposta data 28.07.2013 - 23:47
fonte
0

Non sono un hacker man), ma penso che l'attacco sia dipendente dal server. Quindi il tuo attacco ha successo quando il server gestisce in modo errato la richiesta (o gestisce in modo errato la risposta).

Broswer gestisce sempre la prima risposta (i vecchi browser gestiscono anche la prima risposta).

Ma questo attacco funzionerà sempre quando il server metterà alcune variabili su una delle intestazioni (per esempio: Cookie) Semplice esempio per capire: Pagina di caricamento del client con Textarea e pulsante per inviare la richiesta. Quando il server gestisce la richiesta, mette variabile da Textarea a cookie (non farlo mai). Quindi il cliente può scrivere su textarea questa stringa: 

some data to cookies
Content-Type: text/html
Content-Length: 16

<H1>Hacked</H1>

Quindi, quando il server mette su cookie questa stringa, la risposta dal server sarebbe tale: 

Connection:keep-alive
Content-Type:this server content-type (for example: application/json)
Set-Cookie:qqq="some data to cookies
Content-Length:16  -  your length
Content-Type:text/html - your content type 

<H1>Hacked</H1>

Questo non è un bug del server, questo è un bug dei programmatori che scrivono il sito web.

    
risposta data 29.07.2013 - 20:45
fonte
0

assicurati di utilizzare il ritorno a capo. PHP Charset Encoder codifica solo in %0A , ma dovrebbe essere %0D%0A per ottenere una nuova riga nella risposta. Solo se questo è fatto, la risposta è interpretata come HTTP 200 OK (o qualunque cosa tu voglia).

    
risposta data 21.06.2014 - 12:38
fonte
-2

Anch'io sono rimasto bloccato qui per un po 'di tempo. Si scopre che il nostro WebGoat è la versione di Linux. Linux utilizza solo LF, quindi quando si codificano i parametri, utilizzare solo% 0a, anziché% 0d% 0a.

    
risposta data 05.11.2014 - 13:52
fonte

Leggi altre domande sui tag

Driver basati su WDF e WDM Soppressione del traffico di trasmissione nei registri honeyd?