Meine Frustration ist allzeit hoch, weil es gerade wieder passiert ist. Wenn Sie meine vorherige Analyse mit dem Titel CVE-2022–29622: (In)vulnerability Analysis gelesen haben , ahnen Sie vielleicht, worauf ich mich beziehe. Gleiche Geschichte, anderes Opfer. Allerdings sind die Daten in diesem Fall wichtig. Meine bisherige Unverwundbarkeitsanalyse stammt aus dem Jahr 2022, heute werde ich ein weiteres Problem aus dem Jahr 2018 analysieren.

Sie fragen sich vielleicht: „Warum müssen Sie sich mit etwas aus dem Jahr 2018 befassen?“ Ausgezeichnete Frage! Weil ich erst kürzlich Dependency Track aktiviert habe, um Schwachstelleninformationen aus dem OSS-Index von Sonatype abzurufen.

Heute, als ich SCA durchgesehen habe, um zu sehen, ob wir anfällige Komponenten hatten, und wenn ja, priorisieren Sie die Korrekturarbeiten. Ich bin auf etwas sehr Überraschendes gestoßen. Koa.JS hat eine kritische Schwachstelle?! Nach meinem üblichen „#FFS, meine ganze Woche muss neu geordnet werden.“ dachte ich: „Atme tief durch und sieh dir an, worum es geht. Du erinnerst dich, was letztes Mal passiert ist …“

Und das tat ich. Zunächst einmal macht der Titel klar, dass das „Problem“ im Jahr 2018 gefunden wurde. Warum sollte ich nun eine Schwachstelle in einer Bibliothek haben, die noch gewartet wird, und ich aktualisiere immer wieder auf die neueste Version? An diesem Punkt setzte der investigative Teil meines Gehirns ein.

Was wissen/sehen wir an dieser Stelle?

1. Angeblich gab es 2018 in Koa eine Schwachstelle mit einem kritischen Schweregrad
2. Laut Sonatype OSS Index und Dependency Track betrifft mich das Problem im Jahr 2022, während ich die neueste Version von Koa verwende

• Welche Versionen der Koa.JS-Bibliothek waren von der „Schwachstelle“ betroffen?
• Wenn die „Schwachstelle“ in der neuesten Koa.JS

Problemanalyse

Mal sehen, was die „Schwachstelle“ ist/war. Lassen Sie mich hier schnell das verwandte Problem Nr. 1250 von GitHub verlinken . Ich werde einfach das Beispiel (PoC?) unten kopieren und einfügen, damit wir es analysieren können.

const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.redirect("javascript:alert(1);")
});

app.listen(3000);

„Als Entwickler einer Webanwendung oder eines Webdienstes kann ich Ihren Browser dorthin umleiten, wohin ich möchte, wenn Sie meine Website besuchen.“

Das bedeutet der obige Code. Im obigen PoC wird einem böswilligen Akteur kein Angriffsvektor präsentiert, um irgendetwas auszunutzen.

Wenn Sie einen richtigen „PoC“ für diese Nicht-Schwachstelle bereitstellen wollten (ja, ich habe es gerade gesagt), würde es so aussehen:

const Koa = require('koa');
const app = new Koa();
// Try: http://localhost:3000/?vector=javascript:alert(1);
app.use(async ctx => {
  ctx.redirect(ctx.request.query.vector);
});

app.listen(3000);

Apropos XSS-Schwachstelle: Wenn das, was ich als Wert des vectorParameters eingegeben habe, im HTML-Kontext unsicher angezeigt würde, wäre die von mir implementierte Anwendung anfällig für Cross Site Scripting. (Dazu später mehr)

Zoomen Sie hinein, wie Sonatype dies präsentiert hat, und analysieren Sie es ein wenig weiter:

„Open Redirect führt zu Cross-Site Scripting“? Zunächst einmal gab es keine offene Weiterleitung. Es ist nur geöffnet, wenn Sie es öffnen, und der Unterschied zwischen den beiden PoCs (dem Original und meinem) zeigt dies deutlich. In der ersten gab es keinen Angriffsvektor, daher gab es keine offene Weiterleitung. Mein PoC hatte einen Angriffsvektor, keine Filterung, daher gab es eine offene Weiterleitung. Aber wie Sie sehen können, hing von mir, dem Entwickler, ab, ob es eine offene Umleitung gab oder nicht, und nicht von Koa.JS. Noch besser, ob es eine Weiterleitung gab oder nicht, hing auch von mir ab. Ob ich vom Benutzer bereitgestellte Eingaben als/in die Umleitungs-URL auf unsichere Weise eingefügt habe, lag ebenfalls bei mir. Von welcher Schwachstelle in Koa.JS sprechen wir dann? Technisch gesehen gab es keine Schwachstelle und jemand hat ihr trotzdem den Schweregrad Kritisch zugewiesen. Nicht gerade professionell.

Wie auch immer, lassen Sie uns die besagte „Schwachstelle“ „ausnutzen“, die durch den richtigen PoC implementiert wird. Bitte beachten Sie, dass ich den Service-Port von 3000 auf 4444 ändern musste, da ich bereits etwas auf Port 3000 hatte.

Wir können sehen, dass der LocationAntwortheader den Wert hat javascript:alert(1). Dann leitet der Browser weiter zu…

Huh, ich bin sicher! Es wurde kein Warnfenster angezeigt. Ja, ich könnte https://google.comden Wert des vectorAbfrageparameters eingeben und zu Google umgeleitet werden, daher ist meine Anwendung (PoC) anfällig für eine offene Weiterleitung, aber nicht wegen Koa, sondern weil ich ungefilterte Benutzerdaten an weitergegeben habe ctx.redirect. Es ist nichts, worüber ich mir Sorgen mache, ich würde das niemals tun.

Eine wichtige Anmerkung zu den Issue-Kommentaren auf GitHub ist Folgendes:

Das Problem ergibt sich aus der Tatsache, dass Koa einen HTML-Hyperlink in den Hauptteil der Umleitungsantwort druckt, was einen Cross-Site-Scripting-Angriff auslösen kann.

Ah, das ergibt etwas mehr Sinn! Mal sehen, ob das immer noch so ist.

Nein, das ist nicht mehr der Fall. Es gibt keinen Antworttext. Ich denke, ich kann daraus schließen, dass diese „Schwachstelle“ mich nicht betrifft. Ich kann es einfach im Dependency Track als falsch positiv markieren.

Kontextanalyse

Ich schlage vor, dass eine „Kontextanalyse“ von allen Sicherheitsexperten angenommen und durchgeführt wird, bevor „Probleme“ gemeldet werden. Lassen Sie dies ein weiteres Beispiel sein und zeigen Sie Ihnen, wie es gemacht wird. (Ich empfehle Ihnen dennoch, CVE-2022–29622: (In)vulnerability Analysis zu lesen , da es die Bedeutung des Kontexts viel besser erklärt.)

1. Koa.JS leitet Sie standardmäßig nirgendwohin weiter. Daher gibt und gab es keinen „Open Redirect“, wie vom Sonatype OSS Index angegeben.
2. Basierend auf dem auf GitHub bereitgestellten „PoC“ gab es für einen Entwickler die Möglichkeit, etwas Dummes zu tun, das zu XSS führen könnte. Aber siehe Nr. 1 oben. Koa.JS hat selbst keine Umleitung durchgeführt. Siehe Nr. 2 unten.
3. Ein Entwickler muss seine Anwendung auf unsichere Weise implementiert haben, damit die gemeldete „Schwachstelle“ vorhanden ist. Das bedeutet so ziemlich, dass Koa.JS zwar besser hätte sein können, man es aber nicht als anfällig bezeichnen kann. Es ist kontextuell unangemessen. Die fragliche Schwachstelle könnte nur in einer unsicher implementierten Webanwendung vorhanden sein .

Lassen Sie mich Ihnen ein Beispiel geben, wie Situationen wie diese am besten gehandhabt werden. Schauen Sie sich dieses Problem an, das ich bei Swagger Parser eingereicht habe, und wie es kommuniziert wurde. Analysieren wir den Problembericht:

1. Der Titel lautet „Unsicheres Resolver-Verhalten“. Ich spreche im Titel nicht von LFI (Local File Inclusion). Dies liegt daran, dass es zwar ein Potenzial für die lokale Dateieinbindung gibt, WENN ICH DINGE VERMISSE, es aber wirklich an mir als Entwickler liegt, zu wissen, womit ich arbeite und wie ich damit arbeite. Das Standardverhalten war (vielleicht ist es immer noch) unsicher. Aber die Bibliothek allein, ohne meine Beteiligung, wird nichts bewirken.
2. Dann gebe ich klar an, von welcher Version der Bibliothek ich spreche. Ich mache den Kontext noch klarer, indem ich die Bedingungen aufzähle, unter denen sich das unsichere Standardverhalten der Bibliothek auf eine Anwendung auswirken würde. Dies macht ziemlich deutlich, dass die Bibliothek selbst nicht anfällig ist, aber ein unsicheres Verhalten aufweist, das verbessert werden kann, um Entwicklern zu helfen.
3. Nun, da der Kontext festgelegt ist, stelle ich einen funktionierenden PoC, ein anfälliges Code-Snippet (das ich als PoC geschrieben habe, es ist nicht Teil von Swagger Parser!) und das tatsächliche Ergebnis der Ausnutzung einer anfälligen App/eines anfälligen Dienstes bereit, das die Bibliothek unsicher.
4. Ich habe einige Nachforschungen angestellt und festgestellt, dass ich als Entwickler die Bibliothek tatsächlich so konfigurieren kann, dass das Problem gemildert wird. (bis zu einem gewissen Grad) Ich habe dies mit den Entwicklern geteilt. Wenn nichts anderes, können sie zumindest die Dokumentation aktualisieren, um das Bewusstsein zu schärfen.
5. Ich habe zusätzlichen Kontext, Analysen und ein Beispiel dafür bereitgestellt, wie die Dinge verbessert werden könnten.

Fazit

Zunächst einmal sollte Sonatype den OSS-Index verbessern und sicherstellen, dass für jede Schwachstelle in der Datenbank Versionsinformationen verfügbar sind. Das ist das absolute Minimum. (Bonuspunkte für das vollständige Entfernen dieses speziellen Eintrags aus der Datenbank.)

Ich vermute, dass Dependency Track unter FOMO leidet, daher ist es bereit, Probleme nur auf der Grundlage der Übereinstimmung von Komponentennamen zu melden, wenn die Versionsnummer nicht verfügbar ist. Ich verstehe bis zu einem gewissen Grad, dass sie nicht riskieren würden, eine kritische Schwachstelle zu übersehen. Das Problem bei diesem Verhalten (False Positives) besteht darin, dass es die Einführung von Software Composition Analysis nicht fördert. Es wird Entwickler abschrecken wie die Fehlalarme der statischen Codeanalyse. Kontraproduktiv.

Kontext! Der verdammte Kontext, Leute! Ich schlage vor:

1. „Kontextanalyse“, die von allen Sicherheitsexperten übernommen und durchgeführt werden muss, bevor „Probleme“ gemeldet werden
2. Unterscheidung zwischen „unsicherem Verhalten“ und „Verwundbarkeit“
3. Den Unterschied zwischen einer Softwarebibliothek und einer Anwendung/einem Dienst verstehen