Czy ktos moze mial przyjemnosc integrowac SAML? Musze dodac CSFR token do SAML. I zastanawiam sie czy moge uzyc relayState, zeby przeslac ten token?
0
0
Może przyjemności nie było, ale CSRF to popularny mechanizm zabezpieczania, gdy masz cookies jako http only wtedy przeglądarka za ciebie je dołącza.
Czyli ktoś może zmusić cię do wysłania zapytania, a twoja przeglądarka za ciebie cię zautoryzuje.
Czyli zabezpieczenie działa tak, że wchodzisz na stronę, ona ci tego tokena CSRF (cross site request forgery) wyśle, ty go odbierasz na stronie i dodajesz do zapytania.
Wtedy serwer sprawdza czy token zgadza się z tym wygenerowanym przez serwer inaczej zapytanie jest odrzucane.
Teraz jak złodziej da ci fałszywy link i z niego wyślesz przez przypadek do twojej strony zapytanie to się nie uda, CORS pewnie odrzuci + CSRF zadziała.
Dalej bez cors to tylko CSRF cię chroni, bo złodziej by musiał wtedy ztriggerować cię, żebyś otworzyła stronę aplikacji, dostaniesz token, ukraść go, czy przekierować i dodać do zapytania.
Czyli jest tak, serwer dodaje csrf-token gdzieś, ty od strony clienta po prostu go musisz później z powrotem przekazać do serwera, żeby potwierdzić, że zapytanie dotyczy ostatniego zapytania do serwera, a nie jakiś randomowe bez potwierdzenia.
A co do tego SAML, to nie znam, ale to będzie działać jakoś podobnie, przekazujesz do frontentu CSRF token i potem do tej usługi musisz dołączyć przy fetch zapytaniu z javascript, czy jakimś form
0
Wlasnie ten SAML 2 taki prosty do oganiecia wcale nie jest. Nie mam jak tam dolaczyc ten CSFR token. I myslalem, czy mozna uzyc relayState w SP, zeby przeslac ten token?
0
Token różnie możesz dodać, jakieś cookies ustawić, przesłać z template strony, np. jakiś <input token="dafsafasdfds">, a patrzyłeś dobre praktyki i DOCS tego SAML2?
Albo GUIDE CSRF, i ty wpisujesz z błędem CSFR to literówka, bo to się nazywa Cross Site Request Forgery, to jest skrót abreviation z tego zdania.
0
poniatowski napisał(a):
Czy ktos moze mial przyjemnosc integrowac SAML? Musze dodac CSFR token do SAML. I zastanawiam sie czy moge uzyc
relayState, zeby przeslac ten token?
Napisz więcej:
- czy kontrolujesz klienta/serwer czy oba
- przed jakim dokładnie scenariuszem chcesz się zabezpieczyć (jeden z flow SAML, "identity provider initiated sso", legalny, wyklucza użycie relayState jako tokena csrf więc idąc w tę stronę wykluczasz z kolei ten scenariusz)
0
Wiktor Zychla napisał(a):
poniatowski napisał(a):
Czy ktos moze mial przyjemnosc integrowac SAML? Musze dodac CSFR token do SAML. I zastanawiam sie czy moge uzyc
relayState, zeby przeslac ten token?Napisz więcej:
- czy kontrolujesz klienta/serwer czy oba
- przed jakim dokładnie scenariuszem chcesz się zabezpieczyć (jeden z flow SAML, "identity provider initiated sso", legalny, wyklucza użycie relayState jako tokena csrf więc idąc w tę stronę wykluczasz z kolei ten scenariusz)
Chodzi mi o to jak uzytkownik dokonana juz autentyfikacja uzytkownika (IDP), a nastepnie jest wysylany request do aplikacji Server Provider. Chce dodac token to tego SAML response, ktory jest wysylay do SP. Ponoc odpowiedz z IDP moze zostac przechwycona i hacker moze miec dostep do aplikacji uzytkownika.
0
Czyli mam zaimplementowana meotde Server Provider SSO. W momencie, gdy uzytkownik zaloguje sie przez formularz wysylany jest request z SP do IdP. IdP weryfikuje/autoryzuje usear i wraca z SAML response do SP. I tutaj moze byc ten SAML response przechwycony. Dokladnie nie wiem jak :) Ale moze byc przechwycone response ID i uzyte przez konos innego, zeby dostac sie do danego SP.
0
poniatowski napisał(a):
Czyli mam zaimplementowana meotde Server Provider SSO. W momencie, gdy uzytkownik zaloguje sie przez formularz wysylany jest request z SP do IdP. IdP weryfikuje/autoryzuje usear i wraca z SAML response do SP. I tutaj moze byc ten SAML response przechwycony. Dokladnie nie wiem jak :) Ale moze byc przechwycone response ID i uzyte przez konos innego, zeby dostac sie do danego SP.
Takie zagrożenie w którym obawiasz się że ktoś przechwyci token i użyje go gdzie indziej eliminuje się nie przez token csrf w relayState.
Przykładowy scenariusz:
- twoja aplikacja generuje AuthnRequest z relayState
- IdP autentykuje użytkownika, tworzy AuthnResponse
- użytkownik przekierowuje AuthnResponse do innej aplikacji (ręcznie)
- inna aplikacja nie korzysta z mechanizmu weryfikacji relayState
W tym scenariuszu nie ochronisz się przed nadużyciem tokenu w innej aplikacji.
Oczywiście w drugą stronę:
- czyjaś aplikacja generuje AuthnRequest z relayState
- IdP autentykuje użytkownika, tworzy AuthnResponse
- użytkownik przekierowuje AuthnResponse do twojej aplikacji (ręcznie)
- twoja aplikacja odrzuci żądanie bo nie pasuje jej relayState
to jest to co chcesz.
Tyle że jak widać, ochrona działa tylko wtedy kiedy aplikacje klienckie używają tej ochrony konsekwentnie.
Dlatego sugeruję inne podejście, używanie po prostu szyfrowanych asercji zwracanych z dostawcy. SAML obsługuje taki feature. W tym scenariuszu:
- provisioning SP w IdP obejmuje nie tylko rejestrację adresu zwrotnego ale też klucza publicznego certyfikatu
- IdP szyfruje asercję kluczem publicznym SP
- SP jak odbiera AuthnResponse to nie tylko sprawdza podpis (kluczem publicznym IdP) ale też deszyfruje asercję (swoim kluczem prywatnym)
W takim scenariusz nie da się nadużyć tokena nigdzie, nikt kto go przechwyci w przeglądarce i przekieruje gdziekolwiek indziej nie będzie miał z tego pożytku (bo nikt poza backendem SP nie ma klucza prywatnego)
Mówiąc inaczej - w takim scenariuszu IdP ma klucz publiczny każdego SP i każdemu wystawia asercje zaszyfrowaną jego konkretnym certyfikatem.
0
@Wiktor Zychla: Widze, ze assertions moge byc podpisane singed. To jest jakos podpiete pod validacie assertions. Ta walidacja moze byc pominieta. I fakt, taki attack moze nastapic. Czy to jest to samo co piszesz o szyfrowaniu assertions?
W sumie to co dokladnie powinno znajdowac sie w relayState, ktore jest wysylane do IdP przez SP? I kto waliduje to co sie w nim znajduje?
Wydaje mi sie, ze chodzi te o taki atak, ze hacker moze stworzyc swoja strone z logowaniem do SP. Moze przechwycic usernam i password nastepnie sam wysle dane do logowania do SAML i przechwyci SAML response ID i relayState. Nastepnie juz wystarczy wyslac zwykly formualarz z hidden inpits SAMLResponse i relayState i mamy dostep do SP. Czy ma to sense?
@Wiktor Zychla: Moglbys troche rozjasnic temat, prosze?
0
poniatowski napisał(a):
Wydaje mi sie, ze chodzi te o taki atak, ze hacker moze stworzyc swoja strone z logowaniem do SP. Moze przechwycic usernam i password nastepnie sam wysle dane do logowania do SAML i przechwyci SAML response ID i relayState. Nastepnie juz wystarczy wyslac zwykly formualarz z hidden inpits
SAMLResponseirelayStatei mamy dostep do SP. Czy ma to sense?
Jak ktoś przechwyci username/password to nie musi żadnych sztuk robić, z formularzem, hidden itd, po prostu odpali SP, po przekierowaniu na idp wprowadzi username/password i ma dostęp.
0
Z tego co czytam, wyglada na to, ze SAML jest bardzo stara technologia. Niestety powoli jest ona porzucana przez firmy, ze wzgeldu na to, ze na markecie mozna znalezc juz lepsze produkty np OpenID. Ponoc duzo bibliotek SAML nie sa juz wspierane przez samych progamistow. Ciekawe ile w tym prawdy? Trzeba przyznac, ze strasznie ciezko znalezc material o SAML. Sama technologia widze, ze jest stosunkowo prosta do zrozumienia, ale znalezienie materialow to koszmar.
W takim razie czy w ogole CSRF token ma w SAML jakikolwiek sens? Tutaj podaje przyklad, jak developer podaje CSRF token w relayState. https://www.scottbrady91.com/saml/dangers-of-idp-initiated-sso#:~:text=IdP%20login%20page.-,Validation,-SP%2Dinitiated%20SSO
Z tego co rozumiem, to assertions zawieraja np dane o uzytkowniku tj email, imie, nazwisko itd. W sumie to XML szyfrowanie tylko utrudnia dostep do tych danych, ale nie utrudnia dostepu do SP. Jezeli same requesty IdP <->SP sa szyfrowane przez SSL/TLS to czy warto jeszcze raz uzywac XML szyfrowania? W sumie moze i tak... kurde...
Chyba juz wiem o jaki chodzi atak.
Osoba atakująca mogła zainicjować proces logowania i nakłonić użytkownika do jego ukończenia.
User loguje sie do SP przez IdP. Hacker przechwytuje otrzymuje SAML Response ID. Tym samym uniemozliwa wyslanie ACS request. Dzieki temu Respons ID dalej jest wazny.
Hacker tworzy swoj formularz HTML w ktorym osadza response ID:
<input type="hidden" name="SAMLResponse" value="SAML_response_ID" />
Hacker wysyla powyzszy formularz do ACS. I tak zostaje przekierowany do panela uzytkownika. Nie mam pojecia jak czesto cos takiego moze zostac wykorzystane i dokonane. Nie wiem tez jak hacker moze zainicjowac ten proces logowania? Podac fake login form?
0
poniatowski napisał(a):
Z tego co czytam, wyglada na to, ze SAML jest bardzo stara technologia. Niestety powoli jest ona porzucana przez firmy, ze wzgeldu na to, ze na markecie mozna znalezc juz lepsze produkty np OpenID. Ponoc duzo bibliotek SAML nie sa juz wspierane przez samych progamistow. Ciekawe ile w tym prawdy? Trzeba przyznac, ze strasznie ciezko znalezc material o SAML. Sama technologia widze, ze jest stosunkowo prosta do zrozumienia, ale znalezienie materialow to koszmar.
SAML nie jest "porzucany" bo dobrze przyjął się i jest częścią rozwiązań korporacyjnych. Na przykład dobrze obsługuje single sign-out, z czym protokoły oparte o OAuth (w tym OpenIdConnect) mają problemy. Na SAML oparte są m.in. logowanie do Węzła Krajowego (a wcześniej ePUAP).
poniatowski napisał(a):
Chyba juz wiem o jaki chodzi atak.
There are many ways to intercept the SAML response & assertion. For example, it could be some sort of Man-In-The-Middle (MITM) attack, an open redirect attack taking advantage of improper endpoint validation, via leaky logs and headers, or even via browser-based attacks.
Nie chcę umniejszać tego co tu napisano (to jest cytat z tego zalinkowanego tekstu), aczkolwiek moim zdaniem taki atak wcale nie tak łatwo wykonać:
- MITM jest trudny jeśli cały ruch chodzi po prawidłowym SSL
- open redirect świadczy o źle zaimplementowanym serwerze, który nie waliduje przychodzących żądań z whitelistą uprawnionych SP
- leaky logs/headers - te dane nie idą w logi ani headery
- browser based attacks - jak ktoś jest w stanie mi np. złośliwym extension w przeglądarce ukraść token SAML to dwa kroki wcześniej powinien był mi ukraść login/hasło
Podsumowując: ten zalinkowany artykuł ma rację. Można próbować podnosić bezpieczeństwo przez dodanie relayState, ale to SP musi ustawić relayState i sprawdzić czy prawidłowo wraca z IdP. Takie rozwiązanie wyklucza IdP-initiated SSO, aczkolwiek w praktyce można bez tego żyć.
0
@Wiktor Zychla: Ok, czyli ostatecznie jak uzyje tego CSRF tokena, ktory sam wygenerauje oraz sam sprawdze w ACS to to jest zle podejscie oraz nic nie daje? Problem jest tego typy, ze ja nie moge nic znalezc na temat ustawiania tego relayState przez PHPowa biblioteke, ktore zastala uzyta dla SAML. Zupelnie nic, w kodzie tez nie widze takiej opcji do ustawiania relayState token. Takze musze zrobic to sam. Wole dodac to, niz w ogole nic nie miec. Tak mi sie wydaje. Czy dalej zle mysle?
0
np w tym artykule jest napisane, ze relayState moze byc uzyty wylacznie jako parametr w URL. I chyba ma to byc zwrotny URL do ktorego jest zwrocony user po udanej autoryzacji. Takze ja nawet nie rozumiem, dlaczego so dwie opcje. Niby mozna uzyc tego tokena, pozniej ze nie mozna, bo to jest URL. Nie wiem dlaczego tak jest i kiedy co moge wpisac w ten relayState.
https://learn.microsoft.com/en-us/archive/blogs/askds/ad-fs-2-0-relaystate
edit
Wydaje mi sie ze to chodzi o IdP i SP initieted. W IdP initieted musi by relayState jako URL, zeby wiedziec gdzie odeslac usera. W SP wydaje mi sie, ze ten relayState jest juz mniej wazny. I moze ludzie wykorzystuja go do przeslania CSRF token.
Tylko teraz jak mam rozroznic czy user zalogowal sie przez SP czy przez np okta dashboard?