Czy formularze logowania wymagają tokenów przeciwko atakom CSRF?

161

Z tego, czego się do tej pory dowiedziałem, celem tokenów jest zapobieganie sfałszowaniu przesłania formularza przez atakującego.

Na przykład, jeśli witryna internetowa miała formularz, który wprowadzał dodawane pozycje do koszyka, a osoba atakująca mogłaby spamować Twój koszyk artykułami, których nie chcesz.

Ma to sens, ponieważ może istnieć wiele prawidłowych danych wejściowych do formularza koszyka, a osoba atakująca musiałaby tylko poznać przedmiot, który sprzedaje witryna.

Rozumiem, jak działają tokeny i dodam bezpieczeństwo w tym przypadku, ponieważ zapewniają, że użytkownik faktycznie wypełnił i nacisnął przycisk „Prześlij” w formularzu dla każdej pozycji dodanej do koszyka.

Jednak czy tokeny zwiększają bezpieczeństwo formularza logowania użytkownika, który wymaga nazwy użytkownika i hasła?

Ponieważ nazwa użytkownika i hasło są bardzo unikalne, atakujący musiałby znać oba, aby fałszowanie loginu działało (nawet jeśli nie masz skonfigurowanych tokenów), a jeśli atakujący już to wiedział, mógłby po prostu zalogować się na stronie internetowej samego siebie. Nie wspominając o ataku CSRF, który zmusza użytkownika do zalogowania się, i tak nie miałby żadnego praktycznego celu.

Czy moje rozumienie ataków i tokenów CSRF jest prawidłowe? I czy są bezużyteczne dla formularzy logowania użytkowników, jak podejrzewam?

php token csrf

— php_learner
źródło

Mogą przejąć twój router, ponieważ prawdopodobnie używasz do tego domyślnego hasła, które nie jest chronione przez CSRF do logowania.

— AbiusX,

Tak, więc inne witryny nie mogą naśladować formularza logowania. Co mogą dzięki temu osiągnąć? Po pierwsze, nie chcesz na to pozwolić. Po drugie: bardzo łatwe przypadki awarii, takie jak zablokowanie użytkownika z powodu nieprawidłowego hasła. N nie. często można tego uniknąć.

— mayankcpdixit

126

Tak. Ogólnie rzecz biorąc, musisz zabezpieczyć swoje formularze logowania przed atakami CSRF tak jak każdy inny.

W przeciwnym razie witryna jest narażona na rodzaj ataku polegającego na wyłudzaniu informacji o zaufanej domenie. Krótko mówiąc, strona logowania podatna na CSRF umożliwia atakującemu udostępnienie konta użytkownika ofierze.

Luka wygląda tak:

Osoba atakująca tworzy konto hosta w zaufanej domenie
Atakujący fałszuje żądanie logowania w przeglądarce ofiary przy użyciu danych uwierzytelniających tego konta hosta
Atakujący nakłania ofiarę do skorzystania z zaufanej witryny, na której może nie zauważyć, że jest zalogowana za pośrednictwem konta hosta
Atakujący ma teraz dostęp do wszelkich danych lub metadanych, które ofiara „utworzyła” (celowo lub nieumyślnie), gdy jego przeglądarka była zalogowana na koncie hosta

Jako dobry przykład rozważ YouTube . YouTube pozwolił użytkownikom zobaczyć zapis „własnej” historii oglądania, a ich formularz logowania był podatny na CSRF! W rezultacie osoba atakująca mogła założyć konto z hasłem, które zna, zalogować ofiarę do YouTube za pomocą tego konta - prześladując filmy, które oglądała ofiara.

W tym wątku komentarzy jest dyskusja, która sugeruje, że może on być używany „tylko” do takich naruszeń prywatności. Być może, ale cytując sekcję w artykule o CSRF Wikipedii :

Logowanie CSRF umożliwia różne nowe ataki; na przykład osoba atakująca może później zalogować się do witryny przy użyciu swoich legalnych danych uwierzytelniających i przeglądać prywatne informacje, takie jak historia aktywności, która została zapisana na koncie.

Nacisk na „nowe ataki”. Wyobraź sobie wpływ ataku phishingowego na Twoich użytkowników, a następnie wyobraź sobie, że atak phishingowy działa poprzez własną zaufaną zakładkę użytkownika prowadzącą do Twojej witryny! Artykuł, do którego prowadzi wspomniany wątek komentarzy, podaje kilka przykładów wykraczających poza zwykłe ataki na prywatność.

— natevw
źródło

6

Jak pomaga ochrona CSRF? Czy jest coś, co uniemożliwia atakującemu zażądanie własnego tokena CSRF i przesłanie go z tym? Ponieważ nie istnieje żadna uwierzytelniona sesja, nie ma powodu, aby serwer sieciowy preferował jeden token od drugiego.

— A. Wilson

2

„Czy jest coś, co uniemożliwia atakującemu zażądanie własnego tokena CSRF i przesłanie go z tym?” - Tak! To jest całe założenie logiki zapobiegania CSRF. Przeglądarki zezwalały / zezwalały na przesyłanie formularzy, aby kierować je na inne źródło, ale nigdy [celowo] nie zezwalały JS na odczytywanie danych z różnych witryn, z wyjątkiem teraz za pośrednictwem mechanizmu opt-in CORS. O ile CORS nie zostanie nieprawidłowo skonfigurowany, osoba atakująca może wywołać przesłanie formularza (co może zawierać istniejący token CSRF w plikach cookie ), ale nie ma możliwości poznania tokenu, aby wysłać wymaganą drugą kopię (np. W treści / nagłówkach). Więc kod CSRF odrzuci.

— natevw

7

Myślę, że twój ostatni komentarz jest błędny (źle zrozumiałeś, co mówił A. Wilson). Mówimy, że osoba atakująca może załadować http://good.com/login.htmlw jednym kliencie, przeanalizować zagnieżdżony token CSRF, a następnie opublikować, http://bad.com/login.htmlktóry zawiera zmodyfikowany formularz, który przesyła jego nazwę użytkownika, hasło i token, niezależnie od tego, co wpisuje ofiara. CORS nie ma zastosowania, ponieważ „ mam dwóch oddzielnych klientów: atakującego i ofiarę. A zatem, aby powtórzyć pytanie: czy ochrona CSRF naprawdę działa w przypadku formularzy logowania?

— Gili

8

Tak, CSRF będzie chronić formularz logowania przed fałszowaniem żądań między witrynami . Właściwy token CSRF jest kryptograficznie unikalny za każdym razem, gdy jest generowany. Oczywiście, atakujący może samodzielnie uzyskać token , ale nadal NIE DOPASUJE on [potencjalnie nieustawionego] pliku cookie ofiary w przeglądarce, a atakujący nie ma możliwości ustawienia tego pliku cookie bez narażania strony w dobrej domenie. (Twój przykład wydaje się być nieco zdezorientowany między CSRF a jakimś dziwnym atakiem phishingowym, więc nie jestem pewien, czy odpowiadam na twoje rzeczywiste pytanie…)

— natevw

3

Może się mylę, ale wydaje się, że istnieje poważne zagrożenie, jeśli użytkownik przypadkowo zrobi coś związanego z zakupem przedmiotów. Na przykład osoba atakująca nakłania użytkownika do zalogowania się na stronie internetowej, a użytkownik przechodzi do zakupu przedmiotów, nie zdając sobie sprawy, że znajdują się na innym koncie (pomyśl o Amazon lub podobnym). Teraz atakujący ma dostęp do zapisanych informacji o płatnościach, może przekierować zakupy itp.

— ty 786

14

Twoje rozumienie jest poprawne - celem CSRF jest to, że atakujący może z góry sfałszować wyglądające na zgodne z prawem żądanie. Nie można tego jednak zrobić za pomocą formularza logowania, chyba że napastnik zna nazwę użytkownika i hasło ofiary, w takim przypadku istnieją bardziej efektywne sposoby ataku (zaloguj się samodzielnie).

Ostatecznie jedyną rzeczą, którą może zrobić atakujący, jest niedogodność dla użytkowników poprzez spamowanie nieudanych logowań, kiedy system bezpieczeństwa może zablokować użytkownika na pewien czas.

— Jon
źródło

2

Wow Super szybka odpowiedź! Wielkie dzięki! Teraz mogę śmiało kontynuować tworzenie swojej witryny.

— php_learner

21

Login CSRF może być nadal używany do ataków na prywatność użytkownika seclab.stanford.edu/websec/csrf/csrf.pdf

— squiddle.

6

@squiddle: To całkiem ciekawa praca, dzięki za link. Zależy to jednak od zalogowania użytkownika za pomocą konta pod kontrolą atakującego i zakłada, że użytkownik nie zdaje sobie sprawy, że coś jest nie tak i zakłada, że użytkownik zamierza wytworzyć poufne informacje, które następnie zostaną zapisane na serwerze. Więc IMHO jest mniej poważny niż „klasyczny” CSRF.

— Jon

6

@Jon Tak, może to być mniej poważne, ale ostatecznie może być czymś więcej niż tylko uciążliwością, a mianowicie naruszeniem prywatności. Każda usługa musi samodzielnie zdefiniować swój model zagrożeń i odpowiednio się z nim obchodzić. Aby to zrobić, musisz przynajmniej być świadomy możliwych zagrożeń. Dlatego dodałem moje 2 centy.

— squiddle

1

Proszę, czy mógłbyś wyjaśnić, jak by to zrobili „Ostatecznie jedyną rzeczą, jaką może zrobić atakujący, jest niedogodność dla użytkowników poprzez spamowanie nieudanych logowań, kiedy system bezpieczeństwa może zablokować użytkownika na pewien czas”.

— samthebest

0

tak , więc inne witryny nie mogą naśladować Twojego formularza logowania! Tak proste jak to.

Co mogą dzięki temu osiągnąć?

Po pierwsze: nie chcesz na to pozwolić.
Po drugie: nawet bardzo proste przypadki awarii, takie jak:
- blokowanie użytkownika z powodu nieprawidłowego hasła n nr często można tego uniknąć.
- Można zapobiec ostrzeżeniom o włamaniach Flase. itd itd.

— mayankcpdixit
źródło

Większość z tych punktów jest błędna. Atakujący może utworzyć formularz logowania, uzyskać dane uwierzytelniające użytkownika, załadować formularz logowania (z tokenem csrf) i przesłać trzy informacje do celu. CSRF nie zapobiega temu.

— Snapey

Przeglądarki @Snapey generalnie nie pozwalają JS na odczyt danych CSRF. Używając JS, nie możesz naśladować prawdziwej prośby o przesłanie formularza.

— mayankcpdixit

Token csrf jest często przekazywany do klienta w celu użycia przez javascript. Nie mówię o corsach, które biorę o napastnika, który po prostu żąda formularza logowania i wypycha dane uwierzytelniające. @mayankcpdxit. Wydaje się, że sugerujesz, że csrf zapobiega upychaniu poświadczeń, czego nie robi.

— Snapey,

Teoretycznie tak, nie może temu zapobiec. Ale nie można zautomatyzować upychania danych uwierzytelniających po CSRF, jeśli przestaniesz ładować formularze CSRF w ramkach iframe i przestaniesz zezwalać na żądanie z różnych źródeł.

— mayankcpdixit

-1

Wstępne logowanie do weryfikacji CSRF nie ma większego sensu IMHO.

Dzięki @squiddle za link: seclab.stanford.edu/websec/csrf/csrf.pdf , możemy przeczytać na pierwszej stronie:

The most popular CSRF defense is to include a secret
token with each request and to validate that the received
token is correctly bound to the user’s session,
preventing CSRF by forcing the attacker to guess the
session’s token.

Próba wstępnego logowania do walidacji CSRF daje potencjalnemu napastnikowi możliwość zeskrobania prawidłowego kodu Twojej witryny internetowej! Będzie wtedy mógł ponownie umieścić żeton, pokonując cel.

Być może osoba atakująca może następnie spróbować odgadnąć nazwę użytkownika Twojej witryny. Co zrobiłem, jeśli adres IP próbuje odgadnąć 10 nazw użytkowników bez powodzenia, po prostu umieszczam go na czarnej liście.

— Patrice Gagnon
źródło