C'è un ulteriore rischio nel passare il token di sessione nel corpo del messaggio?

Question

C'è un ulteriore rischio nel passare il token di sessione nel corpo del messaggio?

#1 da (1 voti)
#2 da (1 voti)

1

Lavoriamo su un'app mobile e utilizziamo i token di sessione per l'autenticazione con un server back-end. È un rischio per la sicurezza passare il token di sessione dal client al server nel corpo? Questo non è per l'autenticazione, ma più semplicemente per qualcosa che stiamo cercando di realizzare nell'applicazione. Le pedine sono già passate nelle intestazioni, quindi se qualcuno stava annusando il nostro traffico, quindi averlo nel corpo non sembra un rischio in più - o mi sto perdendo qualcosa?

mobile session-management

posta Myelin 21.10.2016 - 23:59

fonte

2 risposte

Leggi altre domande sui tag mobile session-management

Generazione della password del router: perché i fornitori utilizzano SSID / Router ID? tentativi di accesso falliti, forza bruta

score 1 · Answer 1

Hai ragione nel presumere che non ci saranno ulteriori rischi nell'invio del token nel corpo quando lo stai già mandando nelle intestazioni. Mi chiedo perché è necessario inviare il token in due punti, ma per quanto riguarda il traffico sniffare non sarà più semplice per un utente malintenzionato leggere il traffico del corpo rispetto al traffico dell'intestazione. Se invii il traffico su HTTP anziché su HTTPS, sei vulnerabile a un uomo nell'attacco intermedio in ogni caso.

score 1 · Answer 2

La mia ipotesi è che la tua app mobile sia html / javascript ... Il fatto che il tuo client possa inviare il token come parte del corpo POST implica che uno script (1) nella pagina legga il token dall'intestazione e quindi costruisce il POST o (2) il token è già presente da qualche parte sulla pagina (ad es. campo modulo nascosto) ed è quindi POSTATO. In entrambi i casi se hai una vulnerabilità XSS sulla pagina, un utente malintenzionato potrebbe rubare il token.

Il consiglio OWASP sui token di sessione consiste nell'utilizzare i cookie con l'attributo HttpOnly per impedire (1). Tieni presente che ciò significherà che il tuo codice lato client legittimo non sarà in grado di accedere al cookie per eseguire il POST. Prevenire (2) non sarebbe possibile nel caso in cui si abbia una vulnerabilità XSS che consente allo script di accedere all'elemento dom che rappresenta il token di sessione.