Ist es in Ordnung, eine Validierungsschicht vor der Zugriffskontrollschicht zu haben?

24

Ich erstelle eine API-gestützte Webanwendung und in dieser Anwendung haben wir verschiedene Ebenen, die ihre eigene Arbeit erledigen.

Die erste Schicht ist die Validierungsschicht , die Benutzereingaben validiert. Wenn sie die Validierung bestehen, verschieben wir diese in die zweite Schicht (die Zugriffskontrollschicht ). Andernfalls wird die Fehlermeldung zurückgegeben

Die zweite Ebene ist die Zugriffssteuerung, die überprüft, ob der Benutzer die Berechtigung zum Ausführen der gewünschten Aufgabe hat. Wenn der Benutzer die Berechtigung hat, wird die Anforderung auf die nächste Ebene verschoben, andernfalls wird eine Fehlermeldung zurückgegeben

Die dritte Schicht ist die Controller- Schicht, auf der die Logik der Anwendung liegt

Meine Frage ist, dass ist das in Ordnung, Validierungsschicht vor der Zugriffskontrolle zu haben? Was passiert, wenn der Benutzer versucht, eine Aufgabe auszuführen, für die er keine Berechtigung hat, und wir eine Validierungsfehlermeldung zurücksenden? Der Benutzer sendet Anforderungen an einen Endpunkt und spricht mit der Validierungsschicht. Sobald die Validierung erfolgreich abgeschlossen wurde, wird die Nachricht angezeigtYou can't access this!

Es fühlt sich seltsam für mich an, ist es in Ordnung so oder was könnten meine anderen Optionen in der Infrastruktur sein?

validation web-api access-control

— Muhammad
quelle

10

Erwähnenswert ist auch, dass Validierungen häufig an die Datenbank gesendet werden müssen, um ihre Aufgabe zu erfüllen, oder an einen Dateispeicher. Wenn Sie dies tun, bevor Sie nach Zugriffsverletzungen suchen, gestatten Sie Angreifern im Wesentlichen, DDoS für Ihre Datenbank oder Ihr Dateisystem auszuführen, indem Sie massiven Datenverkehr auf diese bestimmte URL lenken.

— Greg Burghardt

In meinem Fall Middleware das gleiche gilt für Access Control, überprüft er eine Ressource und sehen , ob die Art der Ressource durch den Benutzer zugänglich ist, wenn es zugänglich ist erlaube ich Zugang sonst nicht

— Muhammad

Das ist richtig. Während eines DDoS wird diese Ebene weiterhin Ihren Datenspeicher treffen. Wenn Sie diesen Layer zuerst ausführen, werden Sie Ihren Datenspeicher nicht für Überprüfungen UND Zugriffssteuerung treffen - Sie werden ihn nur für Zugriffssteuerung treffen. Es verringert die Größe des Tsunamis, hindert ihn jedoch nicht daran, den Strand zu treffen. Dies gibt Ihnen oder Ihrem Serverteam die Möglichkeit, auf einen Angriff zu reagieren, bevor das gesamte System zum Stillstand kommt.

— Greg Burghardt

5

Aus praktischer Sicht sollte die Zugriffskontrolle ohnehin vor der Validierung stehen. Wie können Sie die Richtigkeit der Benutzeranforderung validieren, wenn sie überhaupt nicht auf die Anforderung zugreifen können?

— Zibbobz

Die @ Zibbobz-Validierung ist so einfach wie die Überprüfung, ob der Benutzer das richtige Schema sendet. Der Parameter, der eine Ganzzahl sein sollte, ist eine Ganzzahl oder etwas anderes

— Muhammad

57

Es hängt davon ab, ob die Gültigkeit einer Eingabe für eine Aufgabe, die Sie nicht ausführen dürfen, ein Sicherheitsleck ist. Wenn ja, sollten Sie es wirklich umgekehrt machen.

Die einzige sichere Antwort für einen nicht autorisierten Benutzer lautet "Zugriff verweigert". Wenn die Antwort manchmal "schlechte Anfrage" und ein anderes Mal "Zugriff verweigert" lautet, senden Sie Informationen an einen nicht autorisierten Benutzer.

Beispielsweise könnten Sie die Überprüfung der Aufgabe "Dokument löschen" veranlassen, dass das genannte Dokument vorhanden ist. Jemand ohne Berechtigungen kann erkennen, ob etwas vorhanden ist, indem er versucht, es zu löschen, und vergleicht, welchen Fehler er zurückerhält. Ein besonders entschlossener Angreifer könnte alle Dokumentnamen (unter einer bestimmten Länge) auflisten, um zu sehen, welche existieren.

— Caleth
quelle

7

+1, absolut. Wenn Ihre Daten in irgendeiner Weise persönlich identifizierbar oder auf andere Weise sensibel sind, sind die Auswirkungen auf die Sicherheit weitaus schwerwiegender als die Auswirkungen auf die Benutzerfreundlichkeit.

— Kilian Foth

4

@caleth Eigentlich würde es Sie nicht darüber informieren, ob sich ein bestimmtes Dokument im System befindet oder nicht. Diese Art von Informationen wird nur angezeigt, wenn Sie die Controller-Ebene erreichen. Bei der Validierung muss nur das Schema überprüft werden. Es greift nicht auf die Datenbank zu. Der Datenbankzugriff erfolgt nur über die Zugriffskontrolle und tiefere Ebenen. Außerdem zeigt die Zugriffskontrollebene nur dasselbe Material an, während eine Ressource vorhanden ist oder nicht. Der einzige Kompromiss ist das Schema, von dem ich denke, ob es in Ordnung ist oder nicht

— Muhammad

@Caleth Könnten Sie Ihren letzten Kommentar erläutern? Ich verstehe nicht, wie das der Fall ist, wenn man den Kommentar von OPs erhält. Es scheint in jedem Fall, dass die einzige Information, die zurückgesendet wird, nicht privilegierte Information ist, wenn das Schema öffentlich dokumentiert ist.

— Rotem

11

@Rotem Es ist im Grunde unmöglich, im Voraus zu bestimmen, welche Informationen ein Angreifer nutzen könnte. Nur weil Sie keinen Weg gefunden haben , etwas zu lernen, was Sie nicht sollten, heißt das nicht, dass es keinen solchen Weg gibt. Als extremes Beispiel könnte es keine Verwundbarkeit sein jetzt , aber in der Zukunft jemanden könnte einen Scheck an die Validierungsschicht hinzuzufügen , die tun Leck Informationen , weil sie es nicht wussten , war nicht geschützt.

— Kamil Drakari

4

@KamilDrakari das ist kein extremes Beispiel, das ist ein absolut vernünftiges Beispiel. Anders ausgedrückt: Wenn Sie die Validierung vor der Zugriffskontrolle durchführen, müssen Entwickler jedes Mal, wenn sie einen Validierungsschritt hinzufügen möchten, entscheiden, ob diese Validierung sensible Informationen enthält. Die Chance, dass jeder Entwickler diesen Anruf richtig macht, scheint gering.

— mfrankli

24

Nun, es gibt verschiedene Arten der Validierung:

Günstige grundlegende Überprüfung der Integrität, die sicherstellt, dass die Anforderung nicht offensichtlich fehlerhaft ist.

Dies ist in der Regel zumindest teilweise clientseitig dupliziert, um sinnlose Roundtrips zu vermeiden.

Auf jeden Fall sollte dies vor der Zugriffskontrolle erfolgen, um die Dinge einfacher und weniger fehleranfällig zu machen, da dadurch kein Informationsleck riskiert wird.
Teurere Validierung, die noch nicht von geschützten Anwendungsdaten abhängt.

Wenn es eine solche zusätzliche Validierung gibt, kann es sein, dass nach der Zugriffskontrolle keine Daten verloren gehen, sondern DOS-Angriffe verhindert werden.
Manchmal führt die einfache Ausführung der Anforderung einen Teil dieser Validierung implizit zu reduzierten oder kostenlosen Kosten aus, sodass sie hier möglicherweise weggelassen wird.

Wenn die gesamte Validierung des ersten Schritts dupliziert wurde, ist es möglicherweise sinnvoll, Teile dieser Clientseite ebenfalls zu duplizieren.
Zusätzliche Validierung abhängig von den geschützten Anwendungsdaten.

Wenn Sie dies vor der Zugriffskontrolle tun, besteht die Gefahr von Informationslecks. Führen Sie also zuerst die Zugriffskontrolle durch.

— Deduplizierer
quelle

3

Es ist ideal, die Zugriffskontrolle an einem Durchsetzungspunkt für Richtlinien in Ihrer Infrastruktur durchzuführen, noch bevor Sie Ihre API erreichen. Ein grundlegender statischer Validierungssatz (Beispiel: OpenAPI) wird zuerst erstellt, gefolgt von einer eingehenderen Geschäftsvalidierung. Sogar eine statische Überprüfung kann sich möglicherweise auf die Verfügbarkeit Ihrer App-ex- ReDOS- Angriffe auswirken .

— Felickz

@felickz: Ja, DOS-Angriffe sind ein gültiger Grund, die Validierung bis nach der Autorisierung aufzuschieben. Es ist ein Balanceakt. Wie auch immer, ich habe meinen ersten Punkt aufgeteilt, um das richtig zu berücksichtigen.

— Deduplikator

Wenn Sie vor der Zugriffskontrolle eine teure Validierung durchführen, können aufgrund von Timing-Angriffen auch Informationen verloren gehen. Wenn Ihr System je nach Ressource kürzer oder länger dauert, kann der Angreifer auf Aspekte der angeforderten Ressource schließen.

— Lie Ryan

@LieRyan: Aus diesem Grund hängt die gesamte Validierung, die möglicherweise vor der Zugriffskontrolle erfolgt, überhaupt nicht von geschützten Anwendungsdaten ab.

— Deduplizierer

13

Es muss einige Validierung vor Zutrittskontrolle. Angenommen, die SO-API hat einen Endpunkt "Antwort bearbeiten". Ob der Benutzer eine bestimmte Antwort bearbeiten kann, hängt von der Antwort ab (unter einem bestimmten Ruf kann ein Benutzer nur seine eigenen Antworten bearbeiten). Der wohlgeformte Parameter "Antwort-ID" muss daher überprüft werden, bevor die Zugriffskontrollebene ins Spiel kommt. möglicherweise auch, dass die antwort existiert.

OTOH ist, wie Caleth und Greg erwähnen, ein potenzielles Sicherheitsrisiko, wenn eine umfassendere Validierung vor der Zugriffskontrolle erfolgt.

Also sind die harten Regeln

Sie dürfen keine Informationen durch Validierung weitergeben, die der Benutzer sonst nicht herausfinden könnte.
Sie müssen Daten validieren, bevor die Zugriffskontrolle sie in dem Umfang verwenden kann, in dem die Zugriffskontrolle sie benötigt.

Das Befolgen dieser beiden Regeln kann bedeuten, dass Sie vor und nach der Zugriffskontrolle eine Validierung durchführen müssen.

— Sebastian Redl
quelle

3

Das ist die realistische Antwort. Wenn es sich um eine einfache, direkte Validierung der Eingabedatenstruktur handelt, darf es keine Bedenken geben, die es an die erste Stelle setzen. Es schützt sogar die Zugriffskontrollschicht vor speziell entwickelten Eingaben / Paketen. Die Validierung, die tatsächlich ein sicheres Informationsleck oder Raten zur Folge hat, muss nach der Zugriffskontrolle erfolgen.

— SD

Das setzt voraus, dass die Antworten öffentlich sind. Ich wage zu sagen, dass viele APIs nicht einmal die Daten ohne Authentifizierung anzeigen.

— TomTom

6

Zusätzlich zu der möglichen Frustration, einen "Zugriff verweigert" zu erhalten, nachdem die Eingabe validiert wurde; Beachten Sie auch, dass die Validierungsschicht , sofern sie nicht sehr einfach ist, immer Informationen vom Controller benötigen kann . Vor diesem Hintergrund ist es meiner Meinung nach sinnvoller, die Validierung hinter der Zugriffskontrolle näher am Controller zu positionieren .

— simurg
quelle

2

Das hängt davon ab, was Sie unter Validierungsebene verstehen. Wenn Sie damit nur die Syntax der Anforderung überprüfen möchten, ist dies sicher und muss auf jeden Fall erledigt werden. Wenn bei Ihrer Validierung Informationen verwendet werden , auf die ein nicht privilegierter Benutzer keinen Zugriff hat, ist dies nicht mehr sicher.

Sie sollten auf jeden Fall eine Sicherheitsüberprüfung haben, bevor Sie versuchen, den Zugriff zu kontrollieren, aber Sie sollten darauf achten, allen Betreuern (derzeit und in Zukunft) klar und deutlich mitzuteilen, dass dieser Teil keine privilegierten Informationen verwenden darf . Solche Überprüfungen sollten nach der Authentifizierung in einem separaten Validierungsschritt durchgeführt werden .

Als Sicherheitsüberprüfung für das Sicherheitsüberprüfungsprogramm sollte es keine Code-Abhängigkeiten zu einem Teil Ihres Codes weiter unten in der Pipeline aufweisen und in ein eigenes Paket zerlegbar sein, das problemlos öffentlich veröffentlicht werden kann (mit Ausnahme möglicher rechtlicher Probleme). . Wenn Sie das nicht können, tut Ihre "Validierungsschicht" zu viel (oder Ihre Codebasis ist ein Chaos).

— Kubisch
quelle

1

Nein, es ist nicht in Ordnung.

Wenn Sie einen Fehler in Ihrer Validierungsschicht haben, wird die Sicherheitsschicht möglicherweise umgangen.

Es ist ein häufiger Fehler, Sicherheit als Teil der Geschäftsanforderungen zu betrachten. "Nur Benutzer mit der Rolle Umsatz sollten in der Lage sein, die Quartalszahlen zu sehen", scheint eine Geschäftsregel zu sein.

Wenn Sie jedoch sicher sein möchten, müssen Sie die Regel "Nur Benutzer in der Vertriebsrolle sollten Code auf diesem Endpunkt ausführen können" lesen. Sie müssen sicherstellen, dass Ihr Server immer "Zugriff verweigert" zurückgibt, bevor er ausgeführt wird Jede Art von Code, den Sie geschrieben haben, oder Dateien auf dem Server.

— Ewan
quelle