Jak najlepiej zapobiegać atakom CSRF w aplikacji GAE?

Question

Jaki jest najlepszy sposób, aby zapobiec atakowi XSRF dla aplikacji GAE? Wyobraź sobie następujące:

1. Każdy może zobaczyć obiekt publiczny użytkownika, a identyfikator db.Model jest używany w żądaniu do ustalenia, który obiekt ma być wyświetlany. Złośliwi użytkownicy mają teraz identyfikator.
2. Złośliwy użytkownik tworzy własny obiekt i sprawdza formularz usunięcia. Teraz wiedzą, jak usunąć obiekt o określonym identyfikatorze.
3. Złośliwy użytkownik dostaje niewinnego użytkownika, który przesyła żądanie usunięcia obiektu tego użytkownika.

Co mogę zrobić, aby zapobieC# 3? Zwróć uwagę, że kiedy mówię ID, używam rzeczywistej części ID klucza. Jedną z moich pomysłów było użycie pełnej wartości klucza w żądaniach usunięcia, ale czy to uniemożliwiłoby złośliwemu użytkownikowi zrozumienie tego? O ile mi wiadomo, klucz jest kombinacją typu klasy modelu, identyfikatora aplikacji i identyfikatora wystąpienia obiektu, aby mogli prawdopodobnie wyprowadzić klucz z identyfikatora, jeśli chcieli.

Jakieś inne pomysły? Jeff napisał a post about this i zasugerował kilka metod - ukrytą wartość formularza, która zmienia się przy każdym żądaniu, oraz wartość cookie zapisaną przez js do formularza. Nie chcę wykluczać użytkowników nieobsługujących javascriptu, więc rozwiązanie ciasteczek nie jest dobre - w przypadku ukrytej wartości formularza musiałbym pisać zapis datastore na każdym żądaniu wyświetlającym obiekt usunięcia - nie jest to idealna sytuacja dla skalowalnego aplikacja!

Jakieś inne pomysły?

Answer 1

Po wygenerowaniu strony, która umożliwia użytkownikowi usunięcie obiektu, wygeneruj losowy token i umieść go w ukrytym polu formularza. Ustaw także plik cookie typu "tylko HTTP" o tej wartości. Po otrzymaniu żądania usunięcia sprawdź, czy losowy token z formularza i wartość z pliku cookie są zgodne.

Twój losowy token nie powinien być zwykłą liczbą losową. Powinieneś zaszyfrować kombinację losowej liczby i tożsamości użytkownika, aby utrudnić napastnikowi tworzenie własnych tokenów. Powinieneś także używać różnych kluczy szyfrowania dla wartości przechowywanej w formularzu i wartości przechowywanej w pliku cookie, więc jeśli jeden z tokenów wycieknie, napastnikowi wciąż trudno jest sfałszować drugi token.

To podejście sprawdza, czy żądanie usunięcia pochodzi z formularza, przez obecność tokena zabezpieczającego w formularzu; i nie wymaga zapisu w magazynie danych.

Podejście to jest nadal podatne na ataki typu cross-site scripting, w których osoba atakująca może odzyskać ukrytą wartość z formularza lub przesłać formularz, więc dokładnie przetestuj swoją witrynę pod kątem luk w zabezpieczeniach między lokacjami. Podejście to jest również podatne na ataki typu "clickjacking".

Answer 2

Proste: Sprawdź odnośnik. Jest to (celowo) niemożliwe do ustawienia za pomocą Javascript, formularzy HTML itd. Jeśli jest puste (niektóre proxy i przeglądarki odrzucają paski) lub z własnej strony - lub dokładniej z oczekiwanego źródła - zezwól na to. W przeciwnym razie odmów i zapisz go.

Edytuj: Jeff napisał followup article kilkoma sposobami zapobiegania atakom CSRF.

Answer 3

W odpowiedzi serwera wyświetlając formularz utwórz magiczny skrót (na podstawie klienta ip + data/czas + losowa sól, cokolwiek). Umieść go w ciasteczku i przechowuj gdzieś na serwerze. Podczas przesyłania działań należy sprawdzić wartość skrótu pliku cookie względem pozycji w bazie danych.

Jeśli nie ma takiego hasha lub jest inny, odrzuć zgłoszenie.

Po pomyślnym wysłaniu możesz usunąć hash, zmienić jego stan na wysłany - cokolwiek ci pasuje.

Ta metoda powinna chronić Cię w wielu przypadkach, ale z pewnością wciąż nie jest w 100% bezpieczna.

Poszukaj artykułów na temat CSRF, może znajdziesz kilka dobrych odpowiedzi na temat tego Stack Overflow rzeczy. ;)

Nie wykonuj żadnych sprawdzeń referrer lub sprawdzania poprawności IP klienta - jest to zbyt podatne na błędy (informacje odsyłające mogą być usuwane przez program użytkownika, proxy lub preferencje użytkownika), a adres IP klienta może się zmieniać między formularzami tworzenie i składanie - nie karaj użytkownika za przydzielanie dynamicznego adresu IP.