Abbiamo bisogno della protezione CSRF per il profilo del richiedente passivo della Federazione WS?

Question

Abbiamo bisogno della protezione CSRF per il profilo del richiedente passivo della Federazione WS?

#1 da (1 voti)

2

Considera i passaggi coinvolti nel profilo del richiedente passivo della WS-Federation ¹:

Theabovefigureshowsasequencediagramofauser(requestor)accessingawebapplicationwithhisbrowser.Sincetheuserwasnotauthenticationduetoarecentsession,theapplicationredirectstheusertotheIDPforauserlogin(1).TheIDPcollectsthecredentialsfromtheuserandusesaSecurityTokenService(STS)tovalidatethecredentialsandalsotogetaSAMLtokenfromtheSTS(2).TheSTSitselfisconnectedtoaLDAPdatastoretovalidatetheusercredentialsandalsotoretrieveadditionalinformation(claims)abouttheuser,e.g.roles.Onsuccessfulauthentication(3)theIDPreturnstheSAMLtokenissuedbytheSTS(4)totheuserandadvices(auto-submittingform)theusertosendthisSAMLtokentotheoriginallyrequestedwebapplication(5).TheIDPtakescareofprovidingawebuserinterfaceandhandlingURLredirects,whereastheSTSisresponsibleforgeneratingSAMLTokenandvalidatingofusercredentials.ThewebapplicationvalidatestheSAMLtoken(6)andonsuccessreturnsthedesiredwebpage(7).

Nelpassaggio4,possiamorestituireunmoduloall'utentechesiautoinviaautomaticamente.QuestomodulorichiedeunaprotezioneCSRFsudiesso?

Stocercandoconferma,mapensochelarispostasia"no" . Anche se un sito Web dannoso potrebbe far sì che un utente esegua POST in questo modulo, dovrà anche creare un token di sicurezza.

_Fonti:

link

saml csrf federation

posta Frank Tan 13.02.2017 - 18:11

fonte

1 risposta

Leggi altre domande sui tag saml csrf federation

Devo eseguire KeePass come amministratore? Come gestire la registrazione OAuth2 dove l'indirizzo e-mail esiste già come account utente?

score 1 · Answer 1

CSRF richiede che il client abbia un token inviato passivamente, ad es. un biscotto. L'attacco, noto anche come "session riding", forgia una richiesta che sfrutta i token passivi inviati: la richiesta falsificata "cavalca" su una sessione legittima che è già stata stabilita.

Al punto 4, il browser non ha ancora abbastanza token SAML, quindi la mitigazione CSRF non è necessaria.

Il passaggio 6 potrebbe richiedere una mitigazione CSRF, ma solo se ha qualche effetto, ad es. cambiare una password, trasferire denaro, ecc. Se il suo unico scopo è quello di recuperare una pagina web per scopi di visualizzazione, la mitigazione CSRF non è necessaria. (L'obiettivo di un attacco CSRF è di emettere un comando, non di intercettazione.)

Presumibilmente ci possono essere passaggi 8, 9, 10, ecc. dove l'utente può effettivamente avere un effetto su qualcosa. Questi tipi di transazioni richiederebbero la mitigazione CSRF.

Nota a margine, il passaggio 0 richiede una mitigazione rispetto alla correzione della sessione .