Heute haben wir beschlossen, das Thema Informationssicherheit zu diskutieren. Wir veröffentlichen die Übersetzung des Kunal Pandey- Artikels , erkennen Schwachstellen und arbeiten der Kurve voraus!
Einführung
Der Diebstahl personenbezogener Daten (PII) des Nutzers ist für uns alltäglich geworden. Angreifer finden viele Möglichkeiten, um personenbezogene Daten abzurufen, z. B. mithilfe von XSS- und IDOR-Schwachstellen, Offenlegung von API-Endpunkten und mehr.
Das in diesem Artikel beschriebene Szenario kann getestet werden, indem einfach das Verhalten des API-Endpunkts beobachtet wird. Im folgenden Beispiel können durch Aufrufen der API die persönlichen Informationen eines Benutzers auf anderen API-Endpunkten gespeichert werden.
Erläuterung
In einem der privaten Programme auf der HackerOne Bug Bounty-Plattform , zu der ich eingeladen wurde, wurde vorgeschlagen, das Portal des Geschäfts zu testen, nämlich den Bereich für die Arbeit des Verkäufers. Hier können Filialmitarbeiter jedem Kunden eine Einladung zur Bestellung senden. Um die benötigten Informationen zu erhalten, sendet der Verkäufer diese Anfrage per E-Mail oder unter Verwendung eines QR-Codes an die Kunden.
Nach Erhalt eines Links mit einer Aufforderung zur Zahlung geht der Käufer zu: payment-na.examle.com/0811ebf4-d7d0-ba31-9ce68648a5a9 und gibt die erforderlichen Daten ein.
Beim Abfangen einer Anforderung erkennt Burp Suite einen POST-API-Endpunkt, der die eingegebenen Daten enthält.
Anfrage
POST /na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 HTTP/1.1
Host: payments-na.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json;charset=utf-8
X-Cdc-Client: 2.15.45
Content-Length: 125
Origin: https://payments-na.example.com
DNT: 1
Connection: close
Referer: https://payments-na.example.com
{"browser_prefilled":[],"customer_details":{"country":"US"..............},"skipped_fields":[],"user_submitted":true,"action":"continueAddressUnverified"}
Antworten
Nach dem Ausfüllen des Formulars ist der Vorgang abgeschlossen. Erledigt!
Während der POST-Methode an messages-na.example.com/na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 werden alle Informationen gespeichert und die Zahlung erfolgt.
Betriebsphase
Benutzer oder Angreifer finden möglicherweise einen anderen Bereich des Portals, in dem sie die Funktion " Bestellung aufgeben" wie in der oben beschriebenen Methode verwenden und den folgenden Zahlungslink erhalten können : zahlung-na.examle.com/fa5daba4-5d50-8f80 –9eb1-ebia3ea6d665 .
In diesem Fall füllen Sie einfach das Formular aus, fangen Sie die Anforderung in Burp Suite ab, erhalten Sie eine POST-Anforderung an payment-na.example.com/na/customer/client/v1/session/xxxx , laden Sie den generierten API-Endpunkt und verwerfen Sie andere Anforderungen an Wir haben sie nicht geschickt.
Empfangener API-Endpunkt: payment-na.example.com/na/customer/client/v1/session/96afd42f-4281-4529-9b8c-3ba70b0f000b .
Für weitere Tests kann dieser Endpunkt auch mit der GET-Methode im Browser verwendet werden. Unten sehen Sie einen Screenshot des resultierenden API-Endpunkts:
Wie wir sehen können, wurden noch keine Informationen hinzugefügt und keine Parameter angegeben.
Wir werden diesen API-Link jetzt abrufen und an andere Benutzer senden, die ihre Bestelldaten eingegeben haben. Sobald das Opfer auf diesen API-Link klickt, werden alle persönlichen Daten aus der vorherigen Übermittlung, die hier gespeichert wurden ( / na / customer / client / v1 / session / 002420e4-e031-47aa-8d94-6f7c40c248c7 ), auf den angegebenen Endpunkt kopiert API: / na / customer / client / v1 / session / 96afd42f-4281-4529-9b8c-3ba70b0f000b .
Nachdem das Opfer auf den API-Link geklickt hat, den wir Ihnen gesendet haben, werden alle persönlichen Daten des Benutzers auf diesen Endpunkt kopiert.
Von der Seite des Opfers: Es
reicht aus, wenn ein Angreifer diesen API-Endpunkt einfach im Inkognito-Modus besucht, und die Daten des Opfers (E-Mail, Adresse usw.) werden kopiert.
Persönliche Daten des Opfers: Auf
diese Weise können Angreifer die persönlichen Daten jedes Clients abrufen, indem sie einfach einen neuen Sitzungs-API-Endpunkt erstellen und an andere Benutzer senden.
An Fehlern arbeiten
Das Portalentwicklungsteam entfernte die GET-Methode, band sie an die POST-Methode und fügte der obigen POST-Methodenanforderung den Autorisierungstoken-Header hinzu, der sich jedes Mal vom Server authentifiziert.
Dadurch wurde die Möglichkeit ausgeschlossen, das oben beschriebene Szenario zu wiederholen - ein Angriff mit dem Kopieren der persönlichen Daten des Benutzers über die API.
Wichtige Punkte
1. Die Szenarien für solche Angriffe können unterschiedlich sein, mein Beispiel ist nur eines davon. Achten Sie auf solche Sicherheitslücken und versuchen Sie, tiefer zu graben, um ein ähnliches Szenario zu erstellen: Wie könnte ein Angreifer Sie sonst angreifen?
2. In dem beschriebenen Beispiel wurde die API des Angreifers beim API-Endpunkt des Opfers authentifiziert, da der Header des Autorisierungstokens nicht überprüft wurde. Dadurch konnte der Server die persönlichen Daten der Clients auf einen anderen API-Endpunkt kopieren.
Verlauf der Ereignisse:
22. Juli: Ich habe die Sicherheitslücke dem Portal-Team gemeldet.
23. Juli: Der Bericht wurde vom Team überprüft und der Schweregrad auf Mittel festgelegt.
23. Juli: Erhielt eine Belohnung von 500 US-Dollar.
27. Juli: Problem behoben, Bericht erstellt.