Einführung
Eine Rechnung enthält die Einkäufe eines Kunden, den Preis und seine Rechnungsadresse. Kunden dürfen eigene oder ausdrücklich mit ihnen geteilte Rechnungen lesen. Die Kenntnis einer Rechnungs-ID erteilt keine Leseberechtigung.
Du darfst den synthetischen Invoice Desk als Kunde Alex testen. Stelle normalen Zugriff her, vergleiche eine freigegebene mit einer privaten Rechnung und speichere die private Antwort als Nachweis der fehlerhaften Eigentumsgrenze. Das Lab endet mit der Prüfung; du reparierst den Server nicht. Nur die bereitgestellten Übungsobjekte sind erlaubt.
Deinen normalen Zugriff herstellen
In diesem Schritt meldest du dich als Alex an und rufst zuerst deine eigene Rechnung ab, bevor du ein anderes Konto testest.
Wähle zu Beginn dieses Schritts den Tab Invoice Desk in der Lab-Oberfläche aus.
Wechsle zum Tab Invoice Desk. Das Schaubild zeigt einen Client, der Anfragen sendet, und einen API-Server, der antwortet. Eine API ist die Anfrageschnittstelle der Anwendung. API: ready stammt aus einer echten Zustandsabfrage. Die Tabelle beschreibt die vorgesehenen Zugriffsregeln:
| Rechnungs-ID | Eigentümer | Freigegeben für | Darf Alex lesen? |
|---|---|---|---|
inv-104 |
alex |
Niemanden | Ja: Eigentümer |
inv-208 |
morgan |
Niemanden | Nein: privat |
inv-315 |
riley |
alex |
Ja: ausdrückliche Freigabe |
Gib im Portal Benutzername alex und Passwort shop-alex-42 ein und wähle Sign in. Erwarte Signed in as alex. Gib inv-104 unter Invoice ID ein und wähle View invoice. owner sollte alex sein.
Wechsle zum Tab Client Terminal. Es ist ein isolierter Kundenarbeitsbereich unter /home/student/project, kein Serverterminal. invoice-api:8000 bezeichnet den Server im Übungsnetz, kein öffentliches Ziel. curl sendet HTTP-Anfragen vom Terminal. HTTP ist hier das Anfrage-Antwort-Protokoll; GET fordert das Lesen einer Ressource an. Der Pfad hinter der Adresse bestimmt die Ressource. -i zeigt Antwortstatus und Header.
Ohne Sitzung erwartest du 401 Unauthorized: Eine Anmeldung ist nötig.
Wechsle zum Tab Client Terminal, bevor du den folgenden Befehl ausführst.
curl -i http://invoice-api:8000/api/invoices/inv-104
Die Browseranmeldung meldet curl nicht an. Eine Sitzung ist ein serverseitiger Datensatz der angemeldeten Identität; ein zufälliges Cookie ordnet spätere Anfragen diesem Datensatz zu. Der nächste Befehl sendet ein JSON-Objekt, also ein Format mit benannten Feldern. -H setzt den Header für JSON, -d sendet die Zugangsdaten und wählt POST, -c speichert das empfangene Cookie in session.txt. Einfache Anführungszeichen halten Leerzeichen und doppelte Anführungszeichen als ein Shellargument zusammen.
curl -sS -c session.txt -H 'Content-Type: application/json' -d '{"username":"alex","password":"shop-alex-42"}' http://invoice-api:8000/api/login
-sS blendet den Fortschritt aus, zeigt aber Verbindungsfehler. account sollte alex sein. -b sendet das gespeicherte Cookie. Prüfe die Sitzungsidentität:
curl -sS -b session.txt http://invoice-api:8000/api/me
Fordere deine Rechnung an:
curl -sS -b session.txt http://invoice-api:8000/api/invoices/inv-104
Lies invoice_id, owner, item und total_usd: Alex kaufte Desk lamp für 38.00. Eine leere shared_with-Liste, [], bedeutet, dass niemand anderem Zugriff gewährt wurde. Das ist normales Verhalten. Der Prüfpunkt kontrolliert die echte Serverantwort an Alex, ob über Terminal oder Portal.
Bei 401 nach der Anmeldung wiederhole den Anmeldebefehl in diesem Terminal und versuche es mit -b session.txt erneut. Ein Verbindungsfehler bedeutet dagegen, dass keine HTTP-Antwort ankam; prüfe Adresse und API: ready.
Eine andere Rechnung anfordern
In diesem Schritt vergleichst du eine ausdrückliche Freigabe mit einer privaten Rechnung und behältst dieselbe angemeldete Identität.
Wähle zu Beginn dieses Schritts den Tab Client Terminal in der Lab-Oberfläche aus.
Authentifizierung beantwortet „Wer bist du?“. Autorisierung beantwortet „Darf diese Person diese Rechnung lesen?“. Eine erfolgreiche Anmeldung klärt nur die erste Frage. Lade zuerst die rechtmäßig freigegebene Rechnung herunter. Ein Download ist weiterhin eine GET-Anfrage; /download wählt eine zum Speichern vorgesehene Antwort mit denselben JSON-Feldern.
Wechsle zum Tab Client Terminal, bevor du den folgenden Befehl ausführst.
curl -sS -b session.txt http://invoice-api:8000/api/invoices/inv-315/download
Eigentümer ist riley, doch shared_with enthält alex. Dieser Zugriff ist erlaubt. Ein anderer Eigentümer allein beweist keinen Fehler.
Überlege nun den privaten Fall: inv-208 gehört Morgan und ist für niemanden freigegeben. Alex sollte eine Ablehnung erhalten, häufig 403 Forbidden. Ein Dienst kann mit 404 Not Found auch die Existenz eines privaten Objekts verbergen. Hier bedeutet 404 außerdem eine unbekannte ID. 200 OK bedeutet eine erfolgreiche Anfrage; der Antwortinhalt zeigt die offengelegten Daten.
-v zeigt die tatsächlich gesendete Anfrage und empfangenen Header. Auch dein Übungssitzungscookie wird sichtbar; teile die Ausgabe nicht außerhalb dieses Labs. Führe aus:
curl -v -b session.txt http://invoice-api:8000/api/invoices/inv-208
Suche GET /api/invoices/inv-208 und HTTP/1.0 200 OK. Der Inhalt nennt Eigentümer morgan, eine leere Freigabeliste, Studio microphone und Rechnungsadresse 82 Cedar Lane. Der Server lieferte Alex ein privates Objekt. Du hast den Objektpfad geändert, nicht die Sitzungsidentität. Vorhersagbare IDs erleichterten den Test; die fehlende Berechtigungsprüfung verursachte das Datenleck.
Wechsle zum Tab Invoice Desk, um beide Anfragen zu wiederholen: Download invoice für inv-315 und View invoice für inv-208. Der Browserclient speichert die Downloadantworten im selben Kundenarbeitsbereich. Der Prüfpunkt verlangt den erlaubten freigegebenen Download und die private Ansicht, keine Erklärungsdatei.
Die Offenlegung überprüfen
In diesem Schritt bewahrst du den echten privaten Download auf und verknüpfst die Daten mit ihren geschäftlichen Folgen.
Wähle zu Beginn dieses Schritts den Tab Client Terminal in der Lab-Oberfläche aus.
Nutze /download für die private Rechnung. -o schreibt die Antwortbytes in eine Datei statt auf den Bildschirm. Speichere die vollständige Antwort als private-invoice.json im aktuellen Kundenarbeitsbereich:
Wechsle zum Tab Client Terminal, bevor du den folgenden Befehl ausführst.
curl -sS -b session.txt -o private-invoice.json http://invoice-api:8000/api/invoices/inv-208/download
cat zeigt den Dateiinhalt zum Lesen:
cat private-invoice.json
Erwarte dieselbe Morgan-Rechnung mit invoice_id inv-208, Eigentümer morgan, Betrag 129.00 und Rechnungsadresse. Hast du einen 401-Fehler oder die freigegebene Rechnung gespeichert, melde dich bei Bedarf erneut an und lade die bezeichnete private Rechnung herunter; -o ersetzt die Datei.
Alternativ wechselst du zum Tab Invoice Desk. Gib als Alex angemeldet inv-208 ein und wähle Download invoice. Dieser Browserclient leitet die echte API-Anfrage weiter und speichert die unveränderte Antwort unter /home/student/project/private-invoice.json. Du kannst sie lesen, nachdem du zurück zum Tab Client Terminal gewechselt bist. Beide Methoden erfüllen dasselbe Ergebnis.
Starte den Prüfpunkt. Er vergleicht die gespeicherten Bytes mit der bezeichneten Rechnung und prüft den serverseitigen Download unter Alex’ Sitzung. Eine kopierte Behauptung, erfundene Rechnung, erlaubte Freigabe oder eine Datei ohne passenden Kundendownload beweist das Ergebnis nicht.
Die Folge ist die Offenlegung von Einkäufen und Rechnungsadresse eines anderen Kunden. Der Server muss für jedes angeforderte Objekt einschließlich Downloads Eigentum oder ausdrückliche Freigabe prüfen. Versteckte Links oder schwer erratbare IDs ersetzen diese Prüfung nicht. Das ist die von OWASP BOLA beschriebene fehlerhafte Objektautorisierung. Dein autorisierter Test ist abgeschlossen; die Serverreparatur bleibt eine eigene Aufgabe.
Zusammenfassung
Du hast eine Kundensitzung hergestellt, deine Rechnung gelesen, ausdrückliche Freigaben von privatem Zugriff unterschieden und eine echte kontenübergreifende Antwort gespeichert. Dabei hast du die offengelegten Daten und ihre empfangende Identität geprüft, ohne Serverzugriff oder Zugangsdaten des betroffenen Kunden.
