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

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?

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ą.

Istnieje wiele rodzajów sprawdzania poprawności:

1. 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.

2. 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.

3. 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.

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ą

1. Nie wolno ujawniać żadnych informacji poprzez weryfikację, których użytkownik w inny sposób nie mógłby się dowiedzieć.
2. 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.

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.

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).

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.