Verweigerten Zugriff von einem defekten Negativtest-Testfall unterscheiden

Ziel

Verhindern, dass ein Agent jeden Fehler als Beweis dafür behandelt, dass ein Zugriffskontrolltest bestanden wurde. Die vorgeschlagene Methode nutzt abgestimmte Kontrollen, um festzustellen, ob die Anwendung die beabsichtigte Berechtigungsentscheidung tatsächlich erreicht hat.

Voraussetzungen

Synthetische Konten und einen geschützten Vorgang in einer entbehrlichen Umgebung verwenden. Ein Ablehnungsorakel definieren, das Invarianten des geschützten Zustands einschliesst, nicht bloss eine breite Kategorie von Antwortcodes.

Schritte

1. Den geschützten Vorgang mit einem berechtigten Konto und gültiger Eingabe ausführen. Dessen beabsichtigte Wirkung prüfen und nur den für den nächsten Fall nötigen Testfallzustand zurücksetzen.

2. Die aufrufende Partei zum nicht berechtigten Konto ändern, dabei Route, Eingabegültigkeit und Zielobjekt beibehalten. Festhalten, ob die Anfrage über zulässige Testinstrumentierung die beabsichtigte Berechtigungsgrenze erreicht.

3. Den geschützten Zustand nach der Anfrage unabhängig prüfen. Eine wie eine Ablehnung aussehende Antwort reicht nicht aus, wenn die verbotene Änderung vor dem Fehler eintrat oder ein späterer Worker sie ausführt.

4. Eine separat benannte Kontrolle für fehlerhafte Eingaben erstellen. Deren Erwartung von unberechtigtem Zugriff getrennt halten, damit Validierungsfehler nicht versehentlich die Sicherheitsbehauptung erfüllen.

5. Nach einer Änderung die zulässigen, abgelehnten und fehlerhaften Eingabefälle gemeinsam ausführen. Schlagen alle auf dieselbe Weise fehl, die Gesundheit des Testfalls untersuchen, bevor die Berechtigungsgrenze für repariert erklärt wird.

Erwartetes Ergebnis

Ein zuverlässiger Negativtest sollte fehlschlagen, wenn der geschützte Vorgang unberechtigt verfügbar wird, und ebenso fehlschlagen, wenn seine eigentlich gültige Anfrage die relevante Entscheidung nicht mehr erreicht.

Grenzen und Prüfbasis

Nur für Tests bestimmte Instrumentierung kann helfen, das Routing zu erklären, darf aber beobachtbare Sicherheitsbehauptungen nicht ersetzen. Dieser Vorschlag macht keine Aussage über die Statuscodes oder die Middleware-Reihenfolge eines bestimmten Frameworks. Dies ist eine originäre vorgeschlagene Methode; es wird keine Ausführung und kein empirisches Ergebnis behauptet.