Sfruttare una potenziale vulnerabilità di Session Fixation dell'app Web ASP.NET

Naviga le tue risposte
2

Sto testando con la penna un'applicazione ASP.NET che presenta il comportamento Correzione della sessione . L'applicazione utilizza sessioni basate su cookie . In sostanza:

  1. Quando atterri sulla pagina non viene creato alcun cookie di sessione
  2. Dopo il login ASP.NET_SessionId cookie viene creato
  3. Durante il logout e il login ripetuto il valore del cookie rimane lo stesso (non esiste la rigenerazione del valore del cookie)

Sono stato in grado di eseguire un attacco di Session Fixation manualmente :

  1. Sono arrivato alla pagina
  2. Ho creato manualmente un cookie ASP.NET_SessionId con qualche valore (per l'autore dell'attacco)
  3. Ho aperto una nuova sessione del browser e ho impostato lo stesso identico cookie (per la vittima)
  4. Ho effettuato l'accesso come vittima in questa nuova sessione del browser
  5. Nella sessione del browser dell'utente malintenzionato ero ora in grado di esplorare il sito Web come vittima

Ora sto avendo problemi a sfruttare questa vulnerabilità di Session Fixation in condizioni reali. Devo creare o modificare il cookie ASP.NET_SessionId in qualche modo. Da quello che sono in grado di dire, non c'è alcuna vulnerabilità XSS sul sito web che potrei usare.

Ho giocato con due varianti di attacco degne di nota, ma senza fortuna (un caso in cui una vittima avrebbe cliccato su un link che avrebbe impostato un cookie sulla pagina web):

  • JavaScript

https://www.example.com/<script>document.cookie='ASP.NET_SessionId=THISISAFIXATEDCOOKIE; expires=Thu, 18 Dec 2015 12:00:00 UTC; path=/; domain=example.com; path=/'</script>

  • Iniezione HTML

https://www.example.com/<meta http-equiv=Set-Cookie content="ASP.NET_SessionId=THISISAFIXATEDCOOKIE; expires=Thu, 18 Dec 2015 12:00:00 UTC; path=/; domain=example.com; path=/">

Qualunque cosa abbia provato, ho colpito una pagina di errore predefinita o la pagina di destinazione senza cookie creati / modificati.

Mi manca qualcosa con questi due vettori di attacco?

C'è qualche altro metodo che potrei provare a creare o modificare il cookie ASP.NET_SessionId della vittima oltre a usare man-in-the-middle o man-in-the-browser attacchi (basati su malware)?

    
posta fing 26.02.2015 - 10:13
fonte

2 risposte

2

Sembra che tu abbia copiato gli attacchi di esempio direttamente dalla pagina OWASP sulla risoluzione della sessione .

Per chiarire - questi sono intesi come esempi specifici di un sistema che ha un'altra vulnerabilità oltre alla risoluzione di sessione (XSS, HTML Injection, ecc.) - questi non sono attacchi che potrebbero funzionare in qualsiasi situazione del mondo reale.

Se volessi eseguire questo attacco ci sarebbero due passaggi:

  1. Trova una vulnerabilità che ti consenta di impostare l'autenticazione cookie per un altro utente. Il tuo miglior risultato sarebbe probabilmente XSS o Iniezione HTML. Per trovare questo tipo di vulnerabilità si vorrebbe Probabilmente vorresti fare una valutazione della sicurezza del sito in cui ti trovi catalogare tutte le richieste HTTP che possono essere fatte. Lo faresti allora fuzz tutti gli input a livello HTTP in modo automatico e cercare indicazioni che esista una vulnerabilità. Per il possibile vulnerabilità che avresti dovuto entrare e testare manualmente per vedere se qualcosa è davvero lì.

  2. Se trovi qualche vulnerabilità nella fase precedente, potresti quindi tentare un attacco di Session Fixation.

Spero che questo aiuti.

    
risposta data 11.03.2015 - 17:35
fonte
0

Giusto, un prerequisito per un attacco di fissazione della sessione è che l'attaccante possa posizionare un identificatore di sessione (cookie) sul computer della vittima. Poiché i cookie sono legati al dominio da cui sono emessi, questo non può accadere nel normale corso delle cose; cioè, l'aggressore ha bisogno di un modo per iniettare un cookie che sembra provenire dal sito di destinazione.

In pratica, ciò significa sfruttare un'altra vulnerabilità nell'applicazione di destinazione, come XSS. Questo è ciò che gli URL di esempio stanno cercando di fare, ma se la pagina di destinazione non è vulnerabile a quell'attacco, allora non funzionerà. La fissazione della sessione è una sorta di vulnerabilità secondaria in quanto richiede qualche altra vulnerabilità sfruttabile per poter effettuare un attacco. In pratica, è più semplice apportare le modifiche necessarie per prevenire attacchi di fissazione delle sessioni piuttosto che dimostrare che non esistono vulnerabilità XSS.

OWASP è sempre un buon riferimento.

    
risposta data 11.03.2015 - 16:54
fonte

Leggi altre domande sui tag

TPM - numero di AIK e chiave di firma [chiuso] Protocollo Smart Lock