API i żądania

Ataki wykorzystujące kształt żądania lub zaufanie, jakim przeglądarka darzy Twoją stronę. Łatwo je przeoczyć, bo normalny klient nigdy ich nie wysyła.

Lista kontrolna

• Chroń żądania zmieniające stan przed CSRF. Jeśli uwierzytelniasz się ciasteczkami, każdy punkt końcowy zmieniający stan potrzebuje tokenu CSRF lub ścisłej polityki ciasteczek SameSite. Jeśli uwierzytelniasz się tokenem typu bearer w nagłówku Authorization (a nie ciasteczkiem), klasyczny CSRF nie ma zastosowania, co jest jednym z powodów, by to preferować.
• Zamknij login-CSRF. Nawet przepływ logowania może zostać sfałszowany. Powiąż state OAuth z przeglądarką za pomocą ciasteczka ustawianego na początku i sprawdzanego przy callbacku. Zobacz uwierzytelnianie.
• Zablokuj CORS. Nigdy nie odbijaj dowolnego Origin i nigdy nie wysyłaj Access-Control-Allow-Origin: * z poświadczeniami. Używaj jawnej listy dozwolonych źródeł oraz tylko tych metod i nagłówków, których potrzebujesz. Domyślne "zezwól na wszystko" to częsty błąd szablonów projektowych.
• Zapobiegaj mass assignment. Nie przekazuj ciała żądania wprost do aktualizacji bazy danych. Akceptuj jawną listę pól, które można zapisać, aby użytkownik nie mógł wysłać {"role":"admin"} lub {"plan":"enterprise"} i podnieść uprawnień. Oznacz pola tylko do odczytu i ignoruj nieznane.
• Przyznawaj uprawnienia i stan płatności wyłącznie na podstawie zaufanego zdarzenia. Plan lub saldo kredytów powinny się zmieniać po zweryfikowanym webhooku płatności lub akcji administratora, nigdy na podstawie wartości z żądania użytkownika.
• Weryfikuj webhooki. Sprawdzaj podpis dostawcy nad surowym ciałem, potwierdzaj, że kwota i waluta zgadzają się z oczekiwanymi, i czyń każde zdarzenie idempotentnym, aby powtórka nie zastosowała go dwukrotnie.
• Waliduj typy treści i rozmiary. Odrzucaj nieoczekiwane typy treści i ogranicz rozmiar ciała przed parsowaniem.

Jak testować

• Dodaj role, is_admin, plan lub credits do żądania aktualizacji i potwierdź, że serwer je ignoruje.
• Wyślij żądanie cross-origin i potwierdź, że CORS nie odbija Twojego źródła.
• Odtwórz webhook dwukrotnie i potwierdź, że został zastosowany raz.

Powiązane

• Uwierzytelnianie i sesje
• Autoryzacja i kontrola dostępu
• Dostępność i nadużycia