Podczas pracy z witryną opartą na zasobach (taką jak aplikacja MVC lub usługa REST) mamy dwie główne opcje, gdy klient próbuje GET
uzyskać zasób, do którego nie ma dostępu:
- 403 , który mówi, że klient jest nieautoryzowany ; lub
- 404 , który mówi, że zasób nie istnieje (lub nie można go zlokalizować).
Powszechną mądrością i powszechną praktyką wydaje się być odpowiadanie na prawdę - to znaczy 403. Zastanawiam się jednak, czy tak naprawdę należy to zrobić.
Bezpieczne systemy logowania nigdy nie podają przyczyny niepowodzenia logowania. Oznacza to, że w przypadku klienta nie ma wykrywalnej różnicy między nieistniejącą nazwą użytkownika a niepoprawnym hasłem. Ma to na celu uniemożliwienie wykrycia identyfikatorów użytkowników - lub, co gorsza, adresów e-mail.
Z punktu widzenia prywatności znacznie bezpieczniej jest zwrócić 404. Przypomina mi się incydent, w którym ktoś podobno znalazł zwycięzców reality show (myślę, że Survivor), sprawdzając, które zasoby nie istniały na witryna vs. które. Niepokoi mnie fakt, że 403 potencjalnie ujawnia poufne informacje, takie jak numer seryjny lub numer konta.
Czy istnieją ważne powody, aby nie zwracać 404? Czy polityka 404 może mieć negatywne skutki uboczne w innym miejscu? Jeśli nie, to dlaczego praktyka nie jest bardziej powszechna?
źródło
Odpowiedzi:
Istnieje ogólne nieporozumienie (i niewłaściwe użycie)
403 Forbidden
: nie powinno ono zdradzać niczego, co serwer myśli o żądaniu. Jest specjalnie zaprojektowany, aby powiedzieć:Każdy UA lub klient powinien interpretować to w ten sposób, że żądanie nigdy nie zadziała i odpowiednio odpowiedzieć.
Ma to wpływ na klientów obsługujących żądania w imieniu użytkowników: jeśli użytkownik nie jest zalogowany lub się pomyli, klient obsługujący żądanie powinien odpowiedzieć: „Przepraszam, ale nic nie mogę zrobić” po raz pierwszy dostaje
403
i przestaje obsługiwać przyszłe żądania. Oczywiście, jeśli chcesz, aby użytkownik nadal mógł żądać dostępu do swoich danych osobowych po awarii, jest to zachowanie wrogie użytkownikowi.403
Jest to w przeciwieństwie do401 Authorization Required
, który ma oddać, że serwer będzie obsługiwać żądania dopóki przechodzą odpowiednie uprawnienia. O tym zwykle myślą ludzie, kiedy słyszą403
.Kontrastuje to również z
404 Page Not Found
tym, jak zauważyli inni, nie tylko po to, by powiedzieć „nie mogę znaleźć tej strony”, ale także po to, by zasugerować klientowi, że serwer nie wysyła żadnych roszczeń o sukces lub porażkę dla przyszłych żądań.Za pomocą
401
i404
, serwer nie mówi nic klientowi ani UA o tym, jak powinni postępować: mogą próbować w nadziei na inną odpowiedź.404
Jest to zatem odpowiedni sposób obsługi strony, której nie chcesz pokazywać wszystkim, ale nie chcesz zdradzać niczego, dlaczego nie chcesz jej pokazywać w określonych sytuacjach.Oczywiście zakłada to, że klient składający wniosek troszczy się o drobną awanturę w RFC. Wystarczająco złośliwy klient nie będzie dbał o zwrócony kod stanu, chyba że w sposób przypadkowy. Można wiedzieć, że jest to ukryta strona użytkownika (lub potencjalnie ukryta strona użytkownika), porównując ją z innymi znanymi stronami użytkowników.
Powiedzmy, że twój przewodnik jest
users/*
. Jeśli wiemusers/foo
,users/bar
iusers/baaz
praca, serwer przekazujących401
,403
lub404
nausers/quux
nie znaczy, że nie zamierzam spróbować, szczególnie jeśli mam powody, by sądzić, że jestquux
użytkownika. Standardowym przykładem jest Facebook: mój profil jest prywatny, ale moje komentarze do profili publicznych nie są. Złośliwy klient wie, że istnieję, nawet jeśli wrócisz404
na stronę mojego profilu.Dlatego kody statusu nie są przeznaczone dla przypadków złośliwego użycia, lecz dla klientów grających zgodnie z regułami. A dla tych klientów najbardziej odpowiednia jest prośba
401
lub404
żądanie.źródło
quux
istnieje. Ale nie zawsze będą istnieć zewnętrzne dowody, szczególnie na nie-społecznościowych stronach, gdzie dane klientów są naprawdę prywatne . Wścibski lub wrogie użytkownik może ostatecznie być w stanie wydedukować , że kłamiesz, ale niekoniecznie których zasoby leżysz temat . Myślę, że istotną kwestią jest tutaj, nie przejmuj się 404 zasobami, chyba że nie są dostępne inne metody odkrywania.Zgodnie z RFC2616
należy również pamiętać, że podczas uzyskiwania dostępu do zabronionych zasobów autoryzacja nie pomoże .
źródło
HttpUnauthorizedResult
tego, co jest przeznaczone do wykorzystania w uprzywilejowanych zasobach . Zdaję sobie również sprawę (oczywiście), że zamiast tego można użyć 404 ; moje pytanie brzmi, czy należy go użyć i co należy wziąć pod uwagę przy podejmowaniu tej decyzji.Powinieneś? Tak .
Sam to powiedziałeś, zdradzaj jak najmniej. Gdybym atakował system i zauważył, że serwer odpowiedział kodami 403, skupiłbym się na nich, zamiast iść dalej. Lepiej, aby drzwi głosiły, że nie istnieje, a następnie ogłosić, że zostaną zablokowane.
Wadą korzystania z 404 żądań jest to, że na zewnątrz będzie wyglądać, jakby strona nie istniała, i może to powodować konflikty w porównaniu ze stronami, które powinny istnieć, ale zamiast nich. Jeśli nie przejmujesz się robotami indeksującymi (systemy uwierzytelnione i tak powinny zostać całkowicie odrzucone), powinieneś absolutnie to zrobić. Każdy interfejs API, który mam, obsługuje nieautoryzowany dostęp dokładnie w ten sam sposób, podobnie jak StackOverflow . Nie widzisz tej strony? Zapewniam cię, że nie istnieje, mimo że nie twierdzi.
Państwo powinno uznać żądań, gdy zasób jest znany istnieć i odmowa dostępu. Nieudane logowanie nie powinno skutkować komunikatem 404. Nie należy potwierdzać żądań, gdy istnienie samego zasobu powinno być chronione. Dostęp do dziedziny istnieje publicznie, ale grupy zabezpieczeń lub role w niej nie istnieją.
Programiści powinni mieć dostęp do dzienników, co wskaże na próbę uzyskania dostępu do chronionego zasobu. Klienci / Użytkownicy / Testerzy będą generować informacje zwrotne, które ostatecznie trafią w programistę.
To nie jest bezpieczeństwo przez zaciemnienie. Oprócz odpowiednich środków bezpieczeństwa używasz niejasności .
Nie są prawidłowymi żądaniami, są nieautoryzowanymi żądaniami. Zmieniasz niewielką część (zwracasz 404 zamiast 403), aby zyskać znaczną przewagę wśród potencjalnych przyszłych atakujących.
źródło
To naprawdę zależy od informacji przekazywanych przez kod statusu 403. Jeśli masz punkt końcowy interfejsu API odpowiadający
GET /myresource/{id}
404, gdy zasób nie istnieje, kod stanu zwrócony przez punkt końcowy, gdy zasób istnieje, ale nie jest autoryzowany dla bieżącego użytkownika, powinien zależeć od przewidywalnościid
parametru i ilości zawartych w nim informacji.id
jest to pole prywatne, takie jak adres e-mail lub numer konta bankowego, prawdopodobnie powinno zawsze być ukryte za 404. W przypadku adresu e-mail może to uniemożliwić robotom spamującym zestawienie listy prawidłowych adresów e-mail zarejestrowanych w Twojej witrynie.id
jest to publiczna nazwa użytkownika, nie przejmuj się, istnieją inne sposoby uzyskania dostępu do tych informacji (np. Przeglądając stronę forum swojej witryny).id
jest nieprzejrzystym, ale przewidywalnym identyfikatorem (np. Liczbą całkowitą z auto-inkrementacją), nie przekazujesz atakującemu żadnych informacji, których nie mógłby uzyskać w inny sposób. Dlatego moim zdaniem bezpiecznie jest zwrócić kod stanu 403.id
jest nieprzejrzystym, nieprzewidywalnym identyfikatorem (jak losowy identyfikator GUID), pytanie jest bardziej subtelne. Osobiście uważam, że nie ma problemu ze zwrotem kodu stanu 403. Informacje te można wykorzystać tylko wtedy, gdy istnieje inny wadliwy punkt końcowy w interfejsie API używającym tego identyfikatora, ale prawdziwą wadą jest Twój drugi punkt końcowy.Możesz założyć, że lepiej jest w każdym razie być bezpiecznym niż żałować i ukryć informacje bez względu na kontekst, ale tak naprawdę nie możesz polegać na tego rodzaju zachowaniu, aby zapewnić jakąkolwiek formę bezpieczeństwa . Z drugiej strony może zapewniać poufność (lub prywatność, jak powiedzieli inni).
Mechanizm bezpieczeństwa nie powinien być dla atakującego jedynie ograniczeniem prędkości, w przeciwnym razie jest po prostu bezużyteczny. W takim przypadku może nawet uniemożliwić prawidłowe korzystanie z innych funkcji (przeszukiwacze, zapora aplikacji sieci Web szukają nieprawidłowych ilości kodów stanu 403 w celu zablokowania użytkowników ...).
źródło