Perché è necessario convalidare i dati in un servlet ottenuto chiamando HttpSession.getAttribute ()?

3

Sono nuovo nella programmazione WebApp e sto cercando di capire le implicazioni sulla sicurezza di non convalidare i dati ottenuti chiamando il metodo di interfaccia javax.servlet.http.HttpSession.getAttribute (). So come regola generale che si dovrebbe sempre convalidare i dati ottenuti da una fonte non attendibile, ma suppongo di non capire perché i contenuti della sessione non siano attendibili. Questo si basa su ipotesi (probabilmente ingiustificate) che l'unico modo in cui i dati potrebbero essere aggiunti alla sessione sarebbe chiamando HttpSession.setAttribute () e che solo il codice fidato che rientra nell'ambito della stessa applicazione dovrebbe essere in grado di farlo .

Credo che quello che sto chiedendo veramente è come un utente malintenzionato potrebbe sfruttare la mia incapacità di eseguire una corretta convalida dei dati ottenuti da HttpSession. È perché l'implementazione è sconosciuta e non è possibile garantire che i contenuti della sessione non siano costruiti in qualche modo dai dati nella richiesta HTTP (a parte un id di sessione) e quindi soggetti a manomissioni? Oppure perché fidarsi del contenuto della sessione significa fidarsi implicitamente dell'id della sessione, che potrebbe essere compromessa e puntare alla sessione sbagliata? (Anche se ciò accada, sembra che l'autore dell'attacco debba avere qualche possibilità di creare una sessione alternativa che contenga i dati compromessi).

Supponendo che il contenuto della sessione non sia costruito a partire dai dati della richiesta, è il caso che l'unico modo in cui questa vulnerabilità possa essere sfruttata sia se esiste un'altra vulnerabilità che consentirebbe a un utente malintenzionato di creare una cattiva sessione? Per esempio. caricare il codice eseguibile e ottenere il server per eseguirlo e restituire un ID di sessione che viene catturato e riprodotto?

    
posta user16047 16.11.2012 - 00:53
fonte

3 risposte

1

No, hai ragione, non c'è un modo per un aggressore esterno di iniettare contenuti in un attributo di sessione.

Non vedo alcun motivo per convalidare i dati dalla memoria di sessione. Se il codice dell'attaccante è in esecuzione nel tuo contenitore di servlet, ti trovi già in una situazione molto peggiore di qualsiasi cosa abbia a che fare con la convalida dell'input.

    
risposta data 16.11.2012 - 11:38
fonte
1

Hai due possibilità: (a) convalidare tutti i dati prima di memorizzarli nella sessione, o (b) convalidare i dati dopo averli letti fuori dalla sessione. Penso che la scelta (a) abbia molto più senso. Se questo è l'approccio che segui, allora no, non è necessario convalidare i dati estratti dalla sessione, poiché sarà già stato convalidato (prima che fosse archiviato nella sessione).

    
risposta data 16.11.2012 - 12:08
fonte
1

Nella maggior parte dei casi hai il diritto. La validazione corretta dei dati prima che entri nella sessione generalmente consente di fidarsi della sessione. Una cosa da considerare è che oggigiorno molte applicazioni utilizzano fonti di dati esterne per sincronizzare le sessioni utilizzando origini dati esterne (redis, mongo, ecc.) Per ridimensionare le app orizzontalmente. Se tale origine dati è compromessa, un utente malintenzionato potrebbe sfruttare la tua app tramite gli attributi di sessione

    
risposta data 17.11.2012 - 08:59
fonte

Leggi altre domande sui tag