Wątek przeniesiony 2017-04-09 14:46 z Nietuzinkowe tematy przez somekind.

Czemu ponowne wysłanie poprawnego zapytania POST wywołuje błąd CSRF?

0

Zadanie akademickie na formularze Django. Prowadzący zarządał ścisłej walidacji danych przychodzących w POST. No to ja chcę przetestować swoją walidację: Uruchamiam serwer deweloperski Django, wypełniam formularz w przeglądarce, otwieram zakładkę Network Narzędzi Deweloperskich Firefoxa, wybieram zapytanie POST związane z tym formularzem, i próbuję przesłać je ponownie, podmieniając kilka danych na nieprawidłowe (ale NIE TYKAM SIĘ csrfmiddlewaretoken ani ciasteczka csrftoken).

Serwer deweloperski Django odrzuca zapytanie, bo CSRF token missing or incorrect..

Próbuję przesłać poprawne zapytanie POST jeszcze raz, tym razem niczego nie zmieniając.

Znowu CSRF token missing or incorrect.

Jednocześnie wysłanie tego zapytania ponownie poprzez przeładowanie strony i przejście przez ostrzeżenie: To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier. działa bez zarzutu.

Nie rozumiem:

  1. Czemu wysłanie czystego zapytania POST wywołuje błędy CSRF pomimo, że zawiera ono prawidłową wartość csrfmiddlewaretoken (sprawdziłem porównując ze źródłem strony) i poprawną wartość ciasteczka csrftoken (sprawdziłem porównując z wartością ustawioną w ostatniej odpowiedzi serwera)? Jeśli dobrze rozumiem dokumentację: https://docs.djangoproject.com/en/1.8/ref/csrf/ to prawidłowe ustawienie tych dwóch wartości powinno bez problemu przejść to zabezpieczenie i nie wywalać błędów.

  2. Czym różni się przeładowanie strony od ręcznego wysłania tego samego zapytania, że przeładowanie strony działa bez problemu, podczas gdy ręczne wysłanie zapytania nie?

1

Generalnie nie rozumiesz chyba co to jest CSRF i na czym polega ten token. Cała idea jest taka że NIE MOŻNA wysłać dwa razy tego samego tokenu!
CSRF to atak polegający na tym, że klikasz na coś a pod spodem ta akcja jest przekazywana do zupełnie innej strony. Więc masz np. reklamę na całą stronę, klikasz żeby ją "zamknąć" a ktoś sprytnie podpiął do tego zamykania guzik który wykonuje akcje "usuń konto na pejsbuku".
Tokeny CSRF polegają na tym, że musisz najpierw wykonać GET na danej stronie, wygenerowany zostanie losowy token i tylko z tym tokenem możesz teraz wykonać tego POSTa.

0
  1. OK, ale czemu w takim razie przeładowanie strony działa?

  2. Za każdym razem ma być inny token? Cóż… Wchodzę przeglądarką na stronę z formularzem. Sprawdzam token, wynosi on hpmIWFXeUtsZ2NAo3o9r3WZo2ZNqViz1. Wypełniam formularz i wysyłam go przez przeglądarkę. Sprawdzam token, wynosi on… nadal hpmIWFXeUtsZ2NAo3o9r3WZo2ZNqViz1. Ponownie wypełniam formularz i wysyłam go przez przeglądarkę, nie wywala żadnych błędów. Ponownie wpisuję w przeglądarkę adres strony z formularzem. Sprawdzam token. Wynosi on… nadal hpmIWFXeUtsZ2NAo3o9r3WZo2ZNqViz1! Twierdzisz, że token musi być za każdym razem inny. Ale empirycznie widzę co innego, za każdym żądaniem serwer wysyła mi ten sam token. Może to jakiś ficzer serwera deweloperskiego Django, nie wiem.

  3. Być może jest tak, że serwer zlicza, ile razy wysłał token, i pilnuje bardzo, by ten sam token nie był użyty więcej razy, niż został wysłany. Ale chwila, przecież jeśli wypełniłem formularz przez przeglądarkę i wysłałem go przez przeglądarkę, to wtedy przeglądarka wysłała POSTa, w odpowiedzi na którego serwer dał przeglądarce stronę i token (taki sam, sprawdzałem). Twierdzisz, że token musi być otrzymany w wyniku GETa. Ale w zakładce Network Narzędzi Developerskich Firefoxa nie widzę, by przeglądarka oprócz tego POSTa wysłała jeszcze GETa na adres strony (a wyłącznie na pliki .css i .js) – a mimo to jestem w stanie natychmiast wypełnić ręcznie formularz w przeglądarce i wysłać go. Powinienem więc w tym momencie, jak rozumuję, być w stanie zamiast tego równie dobrze wysłać ręcznie POSTa z tym tokenem, którego przed chwilą otrzymałem (a nie jestem w stanie).

Jakoś dotąd nie widzę, gdzie wysyłam token, którego nie otrzymałem albo gdzie podwójnie wysyłam ten sam token. (Owszem, wysyłam podwójnie taki sam token, ale nie moja wina że za każdym razem otrzymuję taki sam – chyba że zrestartuję serwer, wtedy losuje się nowy).

Tak więc, wybacz, ale wciąż nie rozumiem…

1
  • Rzut okiem w dokumentacje django mówi że defaultowo dają rok ważności tokena csrf ...
  • Jak wysłałeś POSTa i dostałeś odpowiedź to nie musisz znów puszczać GETa bo przecież dostałeś zawartość strony już i tak

Otwórz Wiresharka i zobacz dokładnie co wysyła twoja przeglądarka a potem porównaj z tym co wysyła twój skrypt.

0

Jak pisałem o "ręcznym wysyłaniu zapytania ponownie", to nie miałem na myśli skryptu, tylko kliknięcie w Narzędziach Developerskich Firefoxa na "Edit and Resend".

W każdym razie tak, jest różnica.

Firefox przy ręcznym wysyłaniu zapytania ponownie jest łaskaw dodawać do nagłówków co następuje:

Content-Length: 489
Pragma: no-cache
Cache-Control: no-cache

Wydaje się, że to właśnie wywołuje ten nieszczęsny błąd CSRF… ale dlaczego??

1 użytkowników online, w tym zalogowanych: 0, gości: 1