Il server richiama le intestazioni HTTP sul client - eventuali problemi di sicurezza con questo?

1

Sto risolvendo problemi con un server che si comporta in modo un po 'strano. Se faccio una richiesta simile a questa:

GET / HTTP/1.1
Connection: close
Host: hostname
Someheader: somevalue
Location: Woot?
Set-Cookie: test=funtimes;

Avrò una risposta con tutte le intestazioni che ho inviato.

HTTP/1.1 200 OK
Host: hostname
Set-Cookie: test=funtimes
Content-Type: application/json
Someheader: somevalue
Location: Woot?

Come puoi vedere, le intestazioni vengono restituite al client. Non l'ho mai visto prima, e non penso che molte altre persone abbiano o.

Può tu vedere potenziali problemi di sicurezza con questo tipo di comportamento?

    
posta Dog eat cat world 02.06.2016 - 23:36
fonte

4 risposte

1

Esiste una vulnerabilità chiamata Splitting delle risposte HTTP che può essere sfruttabile, a seconda che i caratteri di nuova riga vengano filtrati .

    
risposta data 02.06.2016 - 23:42
fonte
1

Potrebbe essere possibile utilizzarlo per creare cookie dannosi per il sito Web o per inviare intestazioni di sicurezza non sicure al fine di disabilitare la protezione dei frame, aprire il criterio di cross domain o downgrade o disabilitare la protezione cross site scripting, che sarebbe molto utile quando esecuzione di clichon, csrf o attacchi di cross site scripting.

L'efficacia di ciò dipenderebbe comunque da quali intestazioni il server ha già impostato e da come il browser di destinazione tratta le intestazioni duplicate se il server ha intestazioni di sicurezza per queste cose per cominciare.

    
risposta data 03.06.2016 - 00:11
fonte
1

Potrebbe essere possibile visualizzare i valori del cookie HttpOnly durante un attacco XSS. Conosciuto anche come Traccia tra siti ( link ).

Scenario di attacco

Prerequisiti:

  1. Il sito è vulnerabile a XSS.
  2. I cookie di sessione hanno il flag HttpOnly impostato in modo che JavaScript (XSS) non possa leggere il cookie.
  3. XSS e pagina che echos richiesta HTTP sulla stessa origine.

Passi:

  1. L'hacker attira la vittima nell'esecuzione di JavaScript dannoso (tramite XSS, ad esempio).
  2. L'attaccante invia una richiesta HTTP (AJAX) per conto della vittima alla pagina che echa la richiesta HTTP.
  3. L'attaccante registra la risposta HTTP (che include i cookie HttpOnly dell'utente) e la invia a un server che controllano.
  4. L'attaccante usa i cookie per autenticarsi come vittima. (account compromesso)

Detto questo, il furto di sessione è solo un rischio con XSS, anche con questa pagina che fa eco alle richieste HTTP che un utente malintenzionato potrebbe semplicemente trovare più semplice agganciare il browser della vittima con BEeF, ad esempio. O esegui una moltitudine di altri possibili attacchi sfruttando XSS.

MODIFICA ---

Dopo aver riletto la tua domanda ho notato che non hai specificato dove o come il server fa eco alla richiesta HTTP (ho assunto tramite un corpo di risposta). Se ciò avviene tramite i metodi TRACK / TRACE (XST tradizionale tramite le intestazioni di risposta), sarà molto più difficile visualizzare i cookie HttpOnly in quanto i browser moderni non consentono più i metodi AJAX TRACE / TRACK.

    
risposta data 03.06.2016 - 16:02
fonte
0

Se c'è un Reverse Proxy Cache davanti a questo server, questo potrebbe facilmente portare a attacchi da avvelenamento della cache .

È possibile creare la query con alcune intestazioni di risposta memorizzate automaticamente nella risposta memorizzata nella cache come:

  • Intestazioni di sicurezza del contenuto -
  • Imposta le intestazioni dei cookie (ma in genere le cache rimuovono le intestazioni di tesi)
  • Transfer-encoding o Content-Length potrebbe aiutare a costruire più risposte in uno (@see Http Smuggling e HTTP response splitting)
  • qualsiasi altra intestazione relativa alla sicurezza che puoi trovare

Se disponi di iniezioni CR \ LF o Lf disponibili, o come hai detto nel commento della risposta di @ korockinout13 una pagina con intestazioni nel corpo, puoi anche utilizzarlo per consentire l'accesso javascript alle intestazioni che non dovrebbero essere leggibile . È lo stesso di Cross-Site-Tracing (che sfrutta il metodo TRACE). Ecco una buona spiegazione.

    
risposta data 28.06.2016 - 16:20
fonte

Leggi altre domande sui tag