W jaki sposób korzysta się ze wzoru tokenu synchronizatora, aby uniemożliwić korzystanie z CSRF?

Question

Czytałem o używaniu wzorca tokena synchronizatora, aby zapobiec CSRF (CSRF, co oznacza fałszowanie żądań między witrynami). Nie rozumiem, jak to naprawdę jest bezpieczne.

Powiedzmy mam fałszywą witrynę banku fakebank.com z dwoma adresami:

• fakebank.com/withdrawForm.html - żądanie GET który wyświetla formularz wycofać pieniądze
• fakebank.com/doWithdraw - Prześlij do tego adresu URL, aby zrobić to wycofać

Moje rozumienie bezpieczeństwa wada jest to, że można sfałszować maliciousSite.com żądania POST do fakebank.com/doWithdraw, a jeśli jesteś aktualnie zalogowany do fakebank Poczta będzie udany.

Załóżmy, że implementujemy wzór tokenu synchronizatora, który utworzy poufny kod na fakebank.com/withdrawForm.html. Czy nie można sparafrazować żądania GET dla tego formularza, przeanalizować wynik html, pobrać token, a następnie utworzyć żądanie POST z tym tokenem?

Zakłada, że ​​fakebank.com nie sprawdza HTTP Odsyłający lub Origin lub maliciousSite.com z powodzeniem podszywa się, że Polecający/Początek jest fakebank.com.

Answer 1

Powodem jest to bezpieczne i maliciousSite.com nie można po prostu zrobić GET, kradzieży tokena, a następnie zrobić POST jest, że żądanie jest wykonywane przez przeglądarkę użytkownika, a nie przez serwer w maliciousSite.com. Wszystkie dane zwrócone od fakebank.com są zwracane do przeglądarki użytkownika, a nie do serwera pod adresem maliciousSite.com. Jeśli maliciousSite.com wykona GET, aby pobrać token, będzie to inny token niż ten, który został mu wydany. maliciousSite.com nie może ustawić tego pliku cookie w przeglądarce użytkownika, aby można go było przesłać do fakebank.com z powodu ograniczeń domeny.

Atak CSRF POST działa poprzez oszukiwanie przeglądarki użytkownika w żądaniu fakebank.com/withdrawForm.html bezpośrednio przy użyciu odpowiednio utworzonego żądania POST. Serwer pod numerem fakebank.com z przyjemnością wykonuje żądaną POST, przekazując w ten sposób środki przy użyciu parametrów dostarczonych w treści POST (które obejmują konto docelowe należące do atakującego, które zostało tam umieszczone przez maliciousSite.com). Serwer pod numerem maliciousSite.com nie musi widzieć zwróconych danych, ponieważ akcja została podjęta (chyba że fakebank.com używa tych tokenów CSRF, których maliciousSite.com nie może wiedzieć, chyba że zostały w jakiś sposób wyjawione. dla tego). Jeśli fakebank.com używa tokenów CSRF, wówczas maliciousSite.com prześle żądanie o numerze POST, wskazując na potencjalny atak CSRF w toku.

Niepewności tej metody obejmują używanie tokenu CSRF, który nie jest wystarczająco tajny i jest w jakiś sposób ujawniany. Ponadto, jeśli token CSRF nie jest wystarczająco losowy, wtedy maliciousSite.com może go odgadnąć. Ponadto, jeśli istnieje słabość w egzekwowaniu przez przeglądarkę tych samych zasad domeny, można to wykorzystać. Ogólnie rzecz biorąc, nowoczesne przeglądarki nie są podatne na to.

Proszę dać mi znać, jeśli jest to niewystarczające wyjaśnienie, a ja postaram się lepiej go wyartykułować.

Ostatnie pytanie

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.

 Powiązane problemy

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.