BYPASSING SAML AUTHENTICATION FOR BEGINNERS!

[Nytro]

 

I'm a bug bounty hunter who's learning everyday and sharing useful resources as I move along. Subscribe to my channel because I'll be sharing my knowledge in new videos regularly.

[Dragos]

SAML necesita mult prea multe verificari si tine foarte mult de SP sa nu greseasca sau sa activeze vreun flag (sau sa uite sa-l dezactiveze) in SDK-ul de SAML care sa deschida o portita, gen verificarea semnaturii doar daca exista, cum prezinta in video.

 

Recomand cu toata increderea implementarea OpenID Connect. Din 100-200 de linii de cod se poate face schimbul de authorization code (daca e authorization code flow/pkce flow), decodarea JWT-ului, verificarea semnaturii si a timestamp-urilor si preluarea username-ului si a rolurilor, din token sau de pe endpoint-ul /introspect.

 

[Nytro]

Da, oricum e destul de RAR SAML. Si pentru JWT sunt niste reguli:

- De preferat criptarea asimetrica sau un secret "puternic" pe ciptarea simetrica

- De generat JWT dupa ce userul s-a logat doar, nu de exemplu la signup

- De verificat intotdeauna semnatura si nu permis mizeriile cu algorithm 'none'

- De nu pus date sensitive prin JWT

- De ne reutilizarea se secretului pentru a genera JWT-uri diferite, pentru aplicatii diferite, ca apoi cineva sa le poata interschimba

- De implementat corect flow-urile

- De evitat open redirect, mai ales in redirect_url

- De implementat protectiile anti-CSRF

 

Desi lista pare lunga, mi se pare mult mai simplu, practic si eficient decat SAML. 

[andr82]

9 hours ago, Nytro said:

Da, oricum e destul de RAR SAML. Si pentru JWT sunt niste reguli:

- De preferat criptarea asimetrica sau un secret "puternic" pe ciptarea simetrica

- De generat JWT dupa ce userul s-a logat doar, nu de exemplu la signup

- De verificat intotdeauna semnatura si nu permis mizeriile cu algorithm 'none'

- De nu pus date sensitive prin JWT

- De ne reutilizarea se secretului pentru a genera JWT-uri diferite, pentru aplicatii diferite, ca apoi cineva sa le poata interschimba

- De implementat corect flow-urile

- De evitat open redirect, mai ales in redirect_url

- De implementat protectiile anti-CSRF

 

Desi lista pare lunga, mi se pare mult mai simplu, practic si eficient decat SAML. 

Ce alte tipuri de autentificare mai exista in afara de Basic Auth, SAML, Keys, OAuth, JWT, Tokens ?

[n3Oh]

Authorization bypass?

 

[Nytro]

@andr82 - Cea clasica: session cookies. Cam astea ar fi, nu am alte idei. Dar pana la urma depinde de cum vrea fiecare developer. In trecut erau aplicatii care setau drept cookie user si parola si aceea era autentificarea...

[ardu2222]

26 minutes ago, n3Oh said:

Authorization bypass?

 

Mai degraba SAML parameter manipulation ?

[Dragos]

2 hours ago, andr82 said:

Ce alte tipuri de autentificare mai exista in afara de Basic Auth, SAML, Keys, OAuth, JWT, Tokens ?

Mai sunt WS-Fed (in principiu am vazut O365 sa-l foloseasca, desi mai nou cam toata lumea foloseste Graph API care are OIDC la baza), Kerberos ticket (pentru sisteme legate prin Active Directory) si derivate de la cele de baza, precum JPaseto.

Edited July 31, 2020 by Dragos

[n3Oh]

On 7/31/2020 at 9:11 PM, ardu2222 said:

Mai degraba SAML parameter manipulation ?

A intrebat cineva mai sus... ce alte tipuri de autentificare mai exista... Era un raspuns pentru el.