Seit Lektion 4.9.2 hat jede Anfrage ihr Büro, und der Mandantenfilter von EF Core arbeitet mit. Ob die Kladde damit dicht ist, weiß noch niemand. „Wir filtern überall nach dem Büro“ ist eine Behauptung, und ein einziger vergessener Filter genügt, damit ein Büro die Daten eines anderen sieht. In dieser Lektion beweisen Sie die Isolation, und zwar so, wie ein Angreifer vorgehen würde: Ein Büro greift jede Stelle der Kladde mit dem an, was einem anderen Büro gehört. Dabei finden Sie Fehler. Das ist der Zweck der Lektion.
Wie ein Leck zwischen Büros aussieht
Ein Leck ist nicht nur die fremde Kundenliste auf dem Bildschirm. Ein Büro erfährt etwas über ein anderes, sobald sich irgendeine Antwort der Kladde ändert, weil es das andere Büro gibt:
| Art | Beispiel | Wie es entsteht |
|---|---|---|
| fremder Datensatz über seine Id | GET /api/contacts/{id} mit der Id eines Kontakts aus Büro Nord liefert ihn aus |
die Abfrage sucht nur nach der Id |
| fremde Zeilen in einer Liste | der Papierkorb zeigt gelöschte Kontakte aller Büros | ein abgeschalteter Filter |
| fremde Zeilen ändern | PUT auf die Id eines fremden Angebots ändert es |
Laden ohne Büro, dann Speichern |
| eine Zahl | „Sie haben 214 Kontakte“, obwohl das Büro 12 hat | eine Zählung in SQL ohne Bedingung auf das Büro |
| ein Unterschied im Fehler | 403 für eine fremde Id, 404 für eine, die es nicht gibt | die Kladde verrät, dass es die fremde Id gibt |
Die letzte Zeile verdient einen Satz mehr. Antwortet die Kladde auf eine fremde Id mit „verboten“, auf eine unbekannte mit „nicht gefunden“, kann ein Büro ausprobieren, welche Ids es gibt. Die Regel lautet deshalb: Was einem anderen Büro gehört, gibt es nicht. Eine fremde Id bekommt dieselbe Antwort wie eine, die nie vergeben wurde.
In der Sicherheitswelt hat die erste Art einen eigenen Namen: Broken Object Level Authorization, ganz oben auf der Liste der häufigsten Schwachstellen von APIs (OWASP API Security Top 10). Sie steht seit 4.8.2 in Ihrem Bedrohungsmodell; jetzt bekommt sie ihren Nachweis.