Consegna del cookie per la correzione della sessione

3

Ho trovato una possibilità per la fissazione della sessione in un'applicazione che sto cercando. È una correzione di sessione attraverso un cookie ID di sessione. Ora ho letto sulla sessione di fissazione e il concetto è chiaro e si riduce a far sì che una vittima utilizzi il valore del cookie fornito da (attaccante).

Da quanto ho capito, non puoi impostare un valore di cookie per un dominio diverso da quello di provenienza. Quindi non puoi semplicemente mettere sul tuo sito malvagio (evil.com) set cookie: sessID=1234 from targetsite.com . Quindi la mia domanda è quali sono tutte le diverse vie che possono essere utilizzate per consegnare il cookie alla vittima? Ho già elencato quelli che ho trovato, quindi la domanda è, c'è di più? (Voglio usare queste informazioni principalmente per creare consapevolezza nella gestione che sia una cosa seria per la fissazione delle sessioni).

Quelli che già conosco:

  • XSS (memorizzato e riflettente, ma è necessaria una vulnerabilità nel sito stesso!)
  • Lascia il computer aperto con la pagina aperta e attendi che qualcuno effettui l'accesso
  • MitM (ma in questo caso potresti fare molto di più che fissare una sessione!)
  • Iniezione di meta tag
  • L'hacking del server DNS (che è un po 'troppo per una cosa del genere, ma si riduce a entrare nel dominio della destinazione attraverso il server DNS. Per quanto ho capito).
posta Wealot 21.03.2017 - 14:24
fonte

2 risposte

1

Ecco i due metodi che vorrei aggiungere con quelli che hai già fornito:

  • Inserimento dell'ID di sessione nell'URL:

    1. Prima tu (attaccante) devi collegarti al server web e ti verrà rilasciato un ID di sessione valido.
    2. Quindi devi creare un collegamento con l'id della sessione e inviarlo alla vittima. L'URL ha il seguente aspetto: link
    3. Quindi la vittima fa clic sull'URL e la richiesta viene inoltrata al server web con l'attacker fornito sessionid.
    4. Il server pensa che la vittima abbia già l'ID di sessione e inizi a utilizzare il sessionid senza fornire una nuova sessione.
    5. Ora la vittima accede all'applicazione e l'attaccante sarà in grado di dirottare la sua sessione.

Nota: questo metodo funziona solo se l'ID di sessione è lo stesso pre e post login.

  • Utilizzo della divisione risposta HTTP:

Se il sito è vulnerabile alla divisione della risposta HTTP, un utente malintenzionato può inserire un'intestazione del cookie Set in risposta al sessionid generato dall'utente malintenzionato.

    
risposta data 21.03.2017 - 14:46
fonte
1

Oltre al tuo elenco:

Sottodominio non controllato

Il tuo sito funziona su example.com sebbene l'autore dell'attacco controlli bob-usercontent.example.com . Questo potrebbe essere dovuto a una progettazione scadente o un amministratore del server ha creato un sottodominio per un utente che non è a conoscenza delle vulnerabilità che si aprono con i cookie.

L'attaccante imposta il proprio sito Web per l'output dell'intestazione:

Set-Cookie: sessID=1234; Domain=example.com

e quindi attira la vittima a visitare bob-usercontent.example.com . Potrebbe trattarsi di qualsiasi risorsa, inclusa un'immagine incorporata su un altro sito.

Quando l'utente passa a example.com e accede, il cookie eseguirà l'accesso nell'hacker.

Sottodominio non sicuro

Simile a quanto sopra, ma questa volta non c'è difetto di progettazione.

static.example.com contiene una vulnerabilità XSS basata su DOM (ad esempio).

L'attaccante attira l'utente a visitare

http://static.example.com/page.html?name=<script>document.cookie = "sessID=1234; Domain=example.com";</script>

(Ovviamente il parametro name sarebbe codificato in percentuale, ma lasciato come è qui per la leggibilità.)

Quando l'utente passa a example.com e accede, il cookie eseguirà l'accesso nell'hacker.

Mancanza della politica di sicurezza del trasporto rigoroso HTTP

L'utente visita siti Web arbitrari su HTTP.

L'attaccante Man-In-The-Middle intercetta una di queste richieste e la reindirizza a http://example.com . Anche l'attaccante intercetta questa richiesta e risponde con la propria pagina che imposta la seguente intestazione:

Set-Cookie: sessID=1234

Quando l'utente visita https://example.com , il cookie è già impostato e al momento dell'accesso l'utente malintenzionato ha effettuato l'accesso. Ulteriori informazioni su HSTS qui.

    
risposta data 21.03.2017 - 14:47
fonte

Leggi altre domande sui tag