Czy można mieć warstwę sprawdzania poprawności przed warstwą kontroli dostępu

24

Tworzę aplikację sieciową opartą na interfejsie API. W tej aplikacji mamy różne warstwy, które wykonują swoją pracę.

Pierwsza warstwa to warstwa sprawdzania poprawności , która zatwierdza dane wprowadzone przez użytkownika, a jeśli przejdzie sprawdzanie poprawności, przenosimy ją do drugiej warstwy (która jest warstwą kontroli dostępu ), w przeciwnym razie zwracamy komunikat o błędzie

Druga warstwa to kontrola dostępu, która sprawdza, czy użytkownik ma uprawnienia do wykonania zadania, które chce wykonać. Jeśli użytkownik ma uprawnienia, przenosi żądanie do następnej warstwy, w przeciwnym razie zwraca komunikat o błędzie

Trzecia warstwa to warstwa kontrolera, w której mamy logikę aplikacji

Moje pytanie brzmi: czy można mieć warstwę sprawdzania poprawności przed kontrolą dostępu? Co się stanie, jeśli użytkownik spróbuje wykonać zadanie, do którego nie ma uprawnień, a my odeślemy komunikat o błędzie sprawdzania poprawności? Użytkownik wysyła żądania do punktu końcowego i rozmawia z warstwą sprawdzania poprawności, a gdy tylko przejdzie walidację, zobaczy komunikatYou can't access this!

Wydaje mi się to dziwne, więc czy tak jest dobrze, czy jakie mogą być moje inne opcje infrastruktury?

validation web-api access-control

— Mahomet
źródło

10

Warto również wspomnieć, że walidacje często muszą sięgać do bazy danych, aby wykonać swoją pracę lub do magazynu plików. Jeśli zrobisz to przed sprawdzeniem naruszeń kontroli dostępu, zasadniczo pozwalasz atakującym na DDoS bazy danych lub systemu plików, generując ogromne ilości ruchu pod tym konkretnym adresem URL.

— Greg Burghardt

W moim przypadku to samo dotyczy oprogramowania pośredniczącego kontroli dostępu, sprawdza zasób i sprawdza, czy typ zasobu jest dostępny dla użytkownika, jeśli jest dostępny, zezwalam na dostęp w przeciwnym razie

— Muhammad

To prawda. Podczas DDoS warstwa ta nadal trafi do Twojego magazynu danych. Najpierw uruchomisz tę warstwę, więc nie trafisz do magazynu danych w celu sprawdzenia poprawności ORAZ kontroli dostępu - po prostu uderzysz go w celu kontroli dostępu. Zmniejsza rozmiar tsunami, ale nie zapobiega uderzeniu go o plażę. Daje tobie lub twojemu zespołowi serwerowemu szansę walki na atak, zanim cały system się ugrzęźnie.

— Greg Burghardt

5

Z praktycznego punktu widzenia kontrola dostępu i tak powinna nastąpić przed sprawdzeniem poprawności - jak zamierzasz zweryfikować poprawność żądania użytkownika, jeśli nie może on uzyskać dostępu do żądania w pierwszej kolejności?

— Zibbobz

Sprawdzanie poprawności @Zibbobz jest proste, jak sprawdzenie, czy użytkownik wysyła poprawny schemat, np. Parametr, który powinien być liczbą całkowitą, jest liczbą całkowitą lub czymś innym

— Muhammad

57

Zależy to od tego, czy znajomość ważności niektórych danych wejściowych dla zadania, którego nie wolno wykonywać, jest przeciekiem bezpieczeństwa. Jeśli tak, naprawdę powinieneś to zrobić na odwrót.

Jedyną bezpieczną reakcją na nieautoryzowanego użytkownika jest „odmowa dostępu”. Jeśli czasami odpowiedzią jest „złe żądanie”, a innym razem „odmowa dostępu”, wysyłasz informacje do nieautoryzowanego użytkownika.

Na przykład możesz sprawdzić poprawność zadania „usuń dokument”, czy istnieje dokument nazwany. Ktoś bez uprawnień byłby w stanie rozpoznać, czy coś istnieje, próbując go usunąć i porównać otrzymany błąd. Szczególnie zdeterminowany napastnik może wymienić wszystkie nazwy dokumentów (poniżej określonej długości), aby zobaczyć, które istnieją.

— Caleth
źródło

7

+1, absolutnie. Jeśli Twoje dane są w jakikolwiek sposób identyfikowalne lub wrażliwe w jakikolwiek inny sposób, wpływ na bezpieczeństwo jest znacznie, znacznie poważniejszy niż wpływ na użyteczność.

— Kilian Foth

4

@caleth w rzeczywistości nie poinformuje cię, czy określony dokument znajduje się w systemie, czy nie, ten typ informacji będzie podawany tylko po osiągnięciu warstwy kontrolera. Sprawdzanie poprawności polega tylko na sprawdzeniu schematu, nie uzyskuje on dostępu do bazy danych - dostęp do bazy danych ma tylko kontrola dostępu i głębsze warstwy. Ponadto warstwa kontroli dostępu pokazuje tylko te same rzeczy, gdy zasób istnieje lub nie. Jedyną kompromitującą rzeczą jest schemat, który - jak sądzę - jest w porządku, czy nie

— Muhammad

@Caleth Czy mógłbyś rozwinąć swój ostatni komentarz? Nie rozumiem, jak to jest w przypadku komentarza OP. W każdym razie wydaje się, że jedyną odsyłaną informacją są informacje nieuprzywilejowane, jeśli schemat jest publicznie udokumentowany.

— Rotem

11

@Rotem Zasadniczo niemożliwe jest wcześniejsze ustalenie, jakie informacje może wykorzystać osoba atakująca. To, że nie znalazłeś sposobu na naukę czegoś, czego nie powinieneś, nie oznacza, że nie ma takiego sposobu. Jako przykład skrajny, nie może być żadnych luka teraz , ale w przyszłości ktoś może dodać czek do warstwy walidacji że dokłada informacje szczelności, ponieważ nie wiedział, że nie był chroniony.

— Kamil Drakari

4

@KamilDrakari nie jest to skrajny przykład, jest to całkowicie rozsądny przykład. Innymi słowy - jeśli sprawdzasz poprawność przed kontrolą dostępu, za każdym razem, gdy programista chce dodać krok sprawdzania poprawności, musi podjąć decyzję, czy weryfikacja ujawnia coś wrażliwego. Szansa, że każdy deweloper poprawnie wykona to połączenie, wydaje się niewielka.

— mfrankli

24

Istnieje wiele rodzajów sprawdzania poprawności:

Tania podstawowa kontrola poprawności poczytalności, która weryfikuje, czy żądanie nie jest oczywiście zniekształcone.

Zazwyczaj jest to co najmniej częściowo zduplikowane po stronie klienta, aby uniknąć daremnych powrotów.

W każdym razie należy to zrobić przed kontrolą dostępu, aby ułatwić i zmniejszyć podatność na błędy, ponieważ nie wiąże się to z ryzykiem wycieku informacji.
Droższa walidacja, która wciąż nie zależy od chronionych danych aplikacji.

Jeśli istnieje taka dodatkowa weryfikacja, może to być po kontroli dostępu, aby nie uniknąć wycieku danych, ale utrudnić ataki na DOS.
Czasami po prostu wykonanie żądania powoduje częściową weryfikację po obniżeniu kosztów lub bez kosztów, więc można je pominąć.

Jeśli cała walidacja pierwszego kroku jest zduplikowana, sensowne może być również zduplikowanie części tej strony klienta.
Dodatkowa walidacja w zależności od chronionych danych aplikacji.

Wykonanie tego przed kontrolą dostępu oczywiście wiąże się z ryzykiem wycieku informacji. Dlatego najpierw wykonaj kontrolę dostępu.

— Deduplikator
źródło

3

Idealnym rozwiązaniem byłoby przeprowadzenie kontroli dostępu w punkcie egzekwowania zasad w infrastrukturze nawet przed osiągnięciem interfejsu API. Podstawowy statyczny zestaw sprawdzania poprawności (np. OpenAPI) byłby pierwszy, a następnie głębsza weryfikacja biznesowa. Nawet niektóre sprawdzanie statyczne może potencjalnie wpłynąć na dostępność ataków ReDOS na Twoją aplikację .

— felickz

@ Felickz: Tak, ataki DOS są ważnym powodem odroczenia sprawdzania poprawności do czasu autoryzacji. To akt równowagi. W każdym razie podzieliłem swój pierwszy punkt, aby odpowiednio to uwzględnić.

— Deduplicator

Przeprowadzanie kosztownego sprawdzania poprawności przed kontrolą dostępu wiąże się również z ryzykiem wycieku informacji z powodu ataków na czas. Jeśli Twój system trwa krócej lub dłużej w zależności od zasobu, osoba atakująca może wywnioskować aspekty żądanego zasobu.

— Lie Ryan,

@LieRyan: To jest powód, dla którego cała walidacja, która jest potencjalnie przed kontrolą dostępu, wcale nie zależy od chronionych danych aplikacji.

— Deduplicator

13

Przed kontrolą dostępu musi być pewne sprawdzenie poprawności. Powiedzmy, że interfejs API SO ma punkt końcowy „edytuj odpowiedź”, a więc to, czy użytkownik może edytować konkretną odpowiedź, może zależeć od odpowiedzi (poniżej określonej reputacji użytkownik może edytować tylko własne odpowiedzi). Dlatego poprawnie sformułowany parametr „identyfikator odpowiedzi” musi zostać zweryfikowany przed uruchomieniem warstwy kontroli dostępu; być może także, że odpowiedź istnieje.

OTOH, jak wspominają Caleth i Greg, wprowadzenie szerszej weryfikacji przed kontrolą dostępu stanowi potencjalne ryzyko bezpieczeństwa.

Więc twarde zasady są

Nie wolno ujawniać żadnych informacji poprzez weryfikację, których użytkownik w inny sposób nie mógłby się dowiedzieć.
Musisz sprawdzić dane, zanim kontrola dostępu będzie mogła z nich korzystać w takim zakresie, w jakim kontrola dostępu tego potrzebuje.

Przestrzeganie obu tych zasad może oznaczać, że musisz mieć trochę sprawdzania poprawności przed kontrolą dostępu, a niektóre po niej.

— Sebastian Redl
źródło

3

To jest realistyczna odpowiedź. Jeśli jest to prosta, prosta walidacja struktury danych wejściowych, nie może być żadnych skrupułów stawiając ją na pierwszym miejscu. Chroni nawet warstwę kontroli dostępu przed specjalnie zaprojektowanymi wejściami / pakietami. Walidacja, która w rzeczywistości wiąże się z bezpiecznym wyciekiem lub zgadywaniem informacji, musi zostać umieszczona po kontroli dostępu.

— SD

Przy założeniu, że odpowiedzi są publiczne. Śmiem twierdzić, że wiele interfejsów API nawet nie pokazuje danych bez uwierzytelnienia.

— TomTom

6

Oprócz możliwej frustracji związanej z otrzymaniem „odmowy dostępu” po sprawdzeniu poprawności danych wejściowych; należy również pamiętać, że warstwa sprawdzania poprawności , o ile nie jest bardzo prosta, zawsze może potrzebować informacji od kontrolera . Mając to na uwadze, uważam, że umieszczenie sprawdzania poprawności za kontrolą dostępu , bliżej kontrolera, ma większy sens.

— simurg
źródło

2

To zależy od tego, co rozumiesz przez warstwę sprawdzania poprawności - jeśli przez to rozumiesz tylko sprawdzenie składni żądania, jest to bezpieczne i i tak musisz coś zrobić. Jeśli „sprawdzanie poprawności” wykorzystuje jakiekolwiek informacje, do których nieupoważniony użytkownik nie ma dostępu, nie jest już bezpieczne.

Przed przystąpieniem do kontroli dostępu zdecydowanie powinieneś mieć narzędzie do sprawdzania rozsądku, ale zadbaj o to, aby bardzo wyraźnie przekazać wszystkim opiekunom (obecnym i przyszłym), że ta część nie może wykorzystywać informacji uprzywilejowanych; Wszelkie takie kontrole powinny być wykonywane w osobnym etapie weryfikacji po uwierzytelnieniu.

Jako sprawdzanie poprawności dla sprawdzania poprawności, nie powinno ono faktycznie mieć żadnych zależności kodu od żadnej części kodu w dolnej części potoku i powinno być możliwe do rozdzielenia na własny pakiet, który powinien być publicznie publikowany bez żadnych problemów (innych niż możliwe problemy prawne) . Jeśli nie możesz tego zrobić, twoja „warstwa sprawdzania poprawności” robi zbyt wiele (lub twoja baza kodów to bałagan).

— Sześcienny
źródło

1

Nie. Nie jest ok.

Jeśli masz błąd w warstwie sprawdzania poprawności, może on ominąć warstwę bezpieczeństwa.

Częstym błędem jest uznawanie bezpieczeństwa za część wymagań biznesowych. „tylko użytkownicy z rolą sprzedaż, powinni widzieć dane kwartalne” wydaje się być regułą biznesową.

Ale jeśli chcesz być bezpieczny, musisz przeczytać taką zasadę, że „tylko użytkownicy pełniący rolę sprzedażową powinni mieć możliwość uruchomienia kodu w tym punkcie końcowym”. Upewnij się, że Twój serwer zawsze zwraca „odmowa dostępu”, zanim dojdzie do każdy rodzaj kodu, który napisałeś lub pliki na serwerze.

— Ewan
źródło