Thema: authorization
-
Prüfzeitpunkte für Berechtigungen bei eingereihten Aufträgen nach Zugriffsentzug festlegen
Macht den Zeitpunkt der Autorisierung explizit, wenn eine Anfrage Arbeit einplant, die erst später ausgeführt wird. Die vorgeschlagene Übung trennt die Berechtigung, Arbeit einzureihen, von der Berechtigung, sie auszuführen und ihr Ergebnis abzurufen.
-
Prüfen, dass ein Notfall-Bypass endet, wenn seine Autorisierung endet
Prüft den Lebenszyklus eines ausdrücklich genehmigten Notfall-Bypass in einer kontrollierten Umgebung. Die vorgeschlagene Methode unterscheidet zwischen gewöhnlicher Autorisierung, befristeter Ausnahmebefugnis und der Rückkehr zur gewöhnlichen Strategie.
-
Autorisierung auch bei ausfallenden Abhängigkeiten durchsetzen
Prüft die Sicherheitsentscheidung, die getroffen wird, wenn eine benötigte Abhängigkeit nicht verfügbar ist. Dieser eigenständige Fehlerinjektions-Vorschlag macht Fail-open-Verhalten sichtbar, ohne anzunehmen, dass jeder Dienst dieselbe Fehler- oder Verfügbarkeitsantwort liefern sollte.
-
Prüfen, dass Profilaktualisierungen keine privilegierten Kontofelder zuweisen können
Erstellt eine eng gefasste Regression für Aktualisierungen, die gewöhnliche Profildaten zusammen mit Feldern entgegennehmen, die die aufrufende Partei nicht kontrollieren darf. Die Methode schlägt eine explizite Feldzuständigkeit statt einer allgemeinen Checkliste zur Eingabevalidierung vor.
-
Token-Passthrough und der Confused Deputy bei MCP-Servern, die andere APIs aufrufen
Ein MCP-Server, der das Token eines Clients an eine nachgelagerte API weiterleitet oder der im Auftrag beliebiger Anfragender seine eigenen weitreichenden Zugangsdaten verwendet, lässt Aufrufende mit einer Berechtigung handeln, die ihnen nie erteilt wurde. Die MCP-Sicherheitsanleitung verbietet Token-Passthrough und beschreibt den Confused-Deputy-Ablauf für Proxy-Server.
-
Fortsetzungs-Cursor prüfen, nachdem sich die anfragende Identität geändert hat
Prüft die Sichtbarkeitsstrategie der Anwendung, wenn ein Fortsetzungs-Cursor unter einem anderen Prinzipal wiederverwendet wird. Diese eigenständige Methode behandelt den Cursor als Teil eines Abfragekontexts, dessen sicherheitsrelevante Bedeutung festgelegt werden muss.
-
Berechtigung für Workflow-Übergänge statt für Bildschirmzugriff testen
Prüfen, ob eine aufrufende Partei einen bestimmten Zustandsübergang vornehmen darf, einschliesslich Übergängen, die von der aktuellen Oberfläche nicht angeboten werden. Diese vorgeschlagene Methodik zielt auf Freigabe-Workflows, deren Sicherheitsstrategie sowohl von der Identität als auch vom aktuellen Zustand abhängt.
-
Prüfen, wer ein gelöschtes Objekt und seine früheren Berechtigungen wiederherstellen darf
Die Wiederherstellung eines gelöschten Objekts als neue Berechtigungsentscheidung mit expliziter Berechtigungssemantik behandeln. Dieser vorgeschlagene Testfall zielt auf die Lücke zwischen Löschstrategie und Wiederherstellungsverhalten.
-
Konfigurationsänderungen testen, die die Befugnis einer anderen Person verändern
Konfigurationsschreibvorgänge identifizieren, die indirekt Berechtigungen gewähren, selbst wenn ihr Endpunkt wie eine gewöhnliche Einstellungsbearbeitung aussieht. Dieser Vorschlag folgt der resultierenden Befugnisänderung, statt das Risiko am Routennamen zu beurteilen.
-
Zugriff auf einen privaten Export von der Anfrage bis zur endgültigen Löschung testen
Einen privaten Export durch Erzeugung, Abruf, Ablauf und Aufräumen verfolgen. Die vorgeschlagene Methode prüft den gesamten Artefakt-Lebenszyklus, statt eine erfolgreiche Berechtigungsprüfung bei der Erzeugung des Exports als ausreichend zu behandeln.
-
Verweigerten Zugriff von einem defekten Negativtest-Testfall unterscheiden
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.
-
Autorisierung anhand von Ressourcenbeziehungen statt Rollennamen testen
Prüfen, ob eine aufrufende Partei über die vom Produkt tatsächlich zugesicherte Beziehung auf ein bestimmtes Objekt einwirken kann. Diese vorgeschlagene Labormethode behandelt Rollenbezeichnungen als Attribute der Testfixtur, nicht als Testorakel.
-
Den ausführenden Dienst von der vertretenen Person in Delegationstests trennen
Eine delegierte Aktion so testen, dass sowohl die Identität des ausführenden Dienstes als auch die vertretene Person im Testorakel sichtbar sind. Diese vorgeschlagene Methode vermeidet, eine erfolgreiche Dienst-Authentifizierung als ausreichenden Beleg für die Befugnis der vertretenen Person zu behandeln.
-
Prüfen, dass verschachtelte Ressourcenrouten Kind-Objekte an das angegebene Elternobjekt binden
Eine Beziehung validieren, die Coding-Agenten beim Aufbau verschachtelter Endpunkte auslassen können: das angeforderte Kind-Objekt muss gemäss dem Vertrag der Anwendung zum angeforderten Elternobjekt gehören. Dies ist ein ursprüngliches Fixtur-Design.
-
Das Autorisierungsorakel für gemischte Batch-Anfragen definieren
Mehrdeutige Zugriffsregeln bei Batch-Operationen aufdecken, bevor ein Agent Tests schreibt, die jede beliebige Antwort abnicken, die die Implementierung zufällig zurückgibt. Der Vorschlag konzentriert sich auf gemischten Besitz innerhalb einer Anfrage.
-
Prüfen der Einladungsannahme gegen die vorgesehene empfangende Person und den vorgesehenen Workspace
Die Bindung zwischen einer Einladung, ihrer vorgesehenen empfangenden Person und ihrem Ziel-Workspace testen. Die vorgeschlagene Regression richtet sich an von Agenten geschriebene Onboarding-Abläufe, die sonst nur die erfolgreiche Annahme testen.
Maschinenlesbar: JSON