Vor nicht allzu langer Zeit schrieb ich über eine Schwachstelle , die Koa.js im Jahr 2018 betraf. Ich war frustriert, dass ich mich mit einem Problem aus dem Jahr 2018 befassen musste, obwohl das Datum 2022 war und ich die neueste Version von Koa verwendete. 4 Jahre sind vergangen. Das ist eine lange Zeit. Das Problem ist doch nicht mehr da!? Und es war und war nicht gleichzeitig. Das heißt, ich lag falsch und richtig zugleich. Also, hier ist ein Update zum vorherigen Beitrag, um Ihnen zu sagen, wie:

• Ich habe Sonatype und Dependency Track zu Unrecht beschuldigt, in bestimmten Fällen nicht mit Versionsinformationen zu arbeiten
• Ich kann in Bezug auf eine Schwachstelle gleichzeitig Recht und Unrecht haben

Der OSS-Index enthält Versionsinformationen

Wenn Sie meinen vorherigen Beitrag gelesen haben, erinnern Sie sich wahrscheinlich, dass ich zu dem Schluss kam, dass das Problem mich nicht betrifft. Die gute Nachricht ist, dass ich Recht hatte. Die schlechte Nachricht ist, dass ich Sonatype fälschlicherweise vorgeworfen habe, die Versionsnummern in den von OSS Index für Dependency Track bereitgestellten Daten nicht zu haben, um damit zu arbeiten. Es stellt sich heraus, dass sie die Informationen haben. Es war einfach nicht sichtbar, wo ich es erwartet hatte. Siehe den folgenden Screenshot, der am 22.11.2022 aufgenommen wurde.

Es ist sehr wahrscheinlich, dass Dependency Track (DT) nicht genau mit dem funktioniert, was auf der obigen Seite angezeigt wird, aber ich wollte nicht überprüfen, wie die Daten aussahen, die DT aus dem OSS-Index abruft. DT hat gerade einen Link zum OSS-Index gezeigt, wo ich mehr erfahren könnte. Ich klickte und landete auf dieser Seite.
Ich wurde heute von Sonatype darauf aufmerksam gemacht, dass Versionsnummern verfügbar sind; Ich muss woanders suchen. Wenn Sie sich bei Ihrem Konto anmelden und entweder nach Koa suchen oder im obigen Screenshot auf die Schaltfläche „Details für Koa anzeigen“ klicken, können Sie es finden. Siehe Screenshot unten.

Also lag ich falsch. Sonatype hat die Informationen in der Datenbank. Das Problem liegt dann bei der Präsentationsschicht. Es wäre besser, wenn sie die betroffenen Versionen auf der Seite auflisten würden, auf der die Schwachstelle tatsächlich diskutiert wird, damit wir sie sehen und bei Bedarf überprüfen können.

Ich habe Sonatype OSS Index zu Unrecht beschuldigt, keine Versionsinformationen zu haben. Ich habe Dependency Track auch fälschlicherweise beschuldigt, bereit zu sein, nur auf der Grundlage des Abhängigkeitsnamens zu berichten, wenn Versionsinformationen nicht verfügbar sind. (Ich muss noch herausfinden, ob letzteres wahr oder falsch ist, ich habe es nicht überprüft.)

Gib noch nicht auf! Spannender zu diskutieren sind die eigentliche Schwachstelle und die (hoffentlich) bevorstehenden Änderungen am Schwachstellenbericht im OSS-Index. Beginnen wir mit der Schwachstelle.

Cross-Site-Scripting

Sonatype hat Koa basierend auf dem folgenden Gedankengang XSS zugeschrieben.

Koa ist die Entität, die die URL in die HTML-Antwort schreibt, nicht der Entwickler, der Koa verwendet

Es ist definitiv vernünftig zu erwarten, dass der Entwickler die angegebene URL validiert, wahrscheinlich anhand einer Zulassungsliste, um eine offene Weiterleitung zu verhindern, und nicht Koa, da Koa keine Ahnung hätte, welche URLs Sie zulassen möchten oder nicht. Als Entwickler denke ich jedoch nicht, dass ich mir Gedanken über die XSS-Bereinigung für eine URL machen muss, die ich an eine redirect()-Methode übergebe.

Koa scheint sich in diesem Zusammenhang um XSS zu kümmern, da sie dort bereits Code haben, um dies zu verhindern, HTML-Entitäten, die die URL codieren, wenn sie sie in HTML schreiben

Ich stimme bis zu einem gewissen Grad zu. Dem stimme ich beispielsweise nicht zu.

Ich denke nicht, dass ich mir Gedanken über die XSS-Bereinigung für eine URL machen muss, die ich an eine Umleitung () -Methode übergebe

Wenn Sie eine gültige, sichere URL an eine von Ihnen (dem Entwickler) bereitgestellte Umleitungsmethode übergeben, müssen Sie sich (offensichtlich) keine Gedanken über XSS machen. Wenn Sie vom Benutzer bereitgestellte Daten ganz oder teilweise weitergeben, müssen Sie sich immer Gedanken darüber machen, ob Sie ein Entwickler oder ein Sicherheitsexperte sind. Dennoch ist es nicht weit hergeholt zu erwarten, dass Koa dem Entwickler hilft.

Lassen Sie mich Ihnen ein ausgezeichnetes Beispiel geben, das hoffentlich hilft zu verstehen, woher ich komme. Im folgenden Beispiel gebe ich vom Benutzer bereitgestellte Daten im Antworttext an den Browser zurück. Ich mache das ohne Validierung, Bereinigung oder Codierung.

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

app.use(async ctx => {
  ctx.body = ctx.query.payload;
});

app.listen(4444);

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=<img%20src=x%20onerror=alert(1)> HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 28
< Date: Wed, 23 Nov 2022 10:59:17 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
<img src=x onerror=alert(1)>%

• Denken Sie darüber nach, was und wie ich im Antworttext an den Browser übergebe
• Berücksichtigen Sie den Wert des Content-Type-Headers für die Antwort (und steuern Sie ihn wahrscheinlich am besten explizit!).
• Beachten Sie, dass Koa standardmäßig den Wert des Content-Type-Headers basierend auf dem an übergebenen Wert automatisch anpasst ctx.body. (Versuchen Sie zum Beispiel aaa, vorbeizukommen, und sehen Sie, wie es sich ändert.)

In Anbetracht des obigen ctx.body„XSS“-Beispiels klingt es so, als ob wir Koa beschuldigen würden, bestimmte Maßnahmen ergriffen zu haben, um eine Katastrophe bei der Verwendung von zu verhindern ctx.redirect(). Nochmals Sonatype zitieren:

Koa scheint sich in diesem Zusammenhang um XSS zu kümmern, da sie dort bereits Code haben.

Bedeutet dies, wenn Koa sich in diesem Zusammenhang nicht um XSS gekümmert hätte, ähnlich wie sie sich nicht darum gekümmert haben (und sollten), wenn es um geht ctx.body, niemand hätte es als XSS-Schwachstelle gekennzeichnet? Das ist ziemlich lustig. Mir sind einige Ähnlichkeiten mit meiner früheren Analyse über Formidable aufgefallen, die hier und hier dokumentiert ist .

Nach allem, was ich bisher gesagt habe, ist zufällig ein XSS da ... und nicht gleichzeitig. Wie ist das möglich? Einfach! Es ist da, aber Sie können es nicht ausnutzen, es sei denn:

1. Das Opfer verwendet einen alten Webbrowser UND
2. Es gibt eine offene Umleitung, die vom Entwickler mit Koas ctx.redirect(), AND implementiert wurde
3. Der Entwickler vertraut allen vom Benutzer bereitgestellten Daten vollständig und gibt sie wörtlich weiterctx.redirect()

Auf der Sonatype-Berichtsseite stand, wie Sie dem heutigen Screenshot entnehmen können, „Öffne Weiterleitung, die zu Cross-Site Scripting führt“. In meinem vorherigen Beitrag wurde der Teil „Umleitung öffnen“ in Frage gestellt:

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.

Sonatype stimmt auch zu, dass Koa nicht dafür verantwortlich ist, offene Weiterleitungen zu verhindern. Ihre Sorge, meine Sorge und die Hauptsorge aller anderen galt dem XSS. Es war nur verwirrend, eine offene Weiterleitung einzubeziehen. Gleichzeitig war es technisch nicht unvernünftig, wie wir später sehen werden. (Dies wirkt sich auch auf die Bewertung der Schwachstellen aus.)

Wie bereits erwähnt, erfordert die erfolgreiche Ausnutzung des Verhaltens von Koa eine offene Weiterleitung. Aber:

• Koa ist nicht dafür verantwortlich, offene Weiterleitungen zu verhindern (wie bereits erwähnt).
• Koa wird nicht ctx.redirect()ohne Zustimmung des Entwicklers ausgeführt
• Koa zwingt Entwickler nicht, Umleitungen zu verwenden

Es gibt also eine weitere Schutzebene: die Anwendungsfälle. Wie wahrscheinlich möchte ein Entwickler keine Kontrolle darüber haben, wohin ein Browser umgeleitet wird? Sehr unwahrscheinlich. Dies bedeutet, dass Entwickler höchstwahrscheinlich benutzergesteuerte Daten ctx.redirect()an eine andere Zeichenfolge anhängen werden. Etwas Ähnliches wie in den unten gezeigten Beispielen ist also am wahrscheinlichsten:

ctx.redirect(`http://website.example.org/search?q=${userInput}`);
ctx.redirect(`/search?topic=${userInput}`);

Bewertung von Schwachstellen

Es müssen drei (3) Bedingungen erfüllt sein, damit der Fehler ausgenutzt werden kann, wie am Ende des vorherigen Abschnitts besprochen.

• Welche Version eines Browsers verwendet wird, ist Sache des Endbenutzers
• Die Verwendung der Redirect-Methode und wie sie verwendet wird, ist Sache des Entwicklers

Hervorzuheben ist auch, dass die Verwendung der Redirect-Methode auf unsichere Weise der Angriffsvektor ist. Für eine erfolgreiche Ausnutzung ist ein Angriffsvektor erforderlich. Koa liefert nicht den Angriffsvektor; der Entwickler tut es.

Lassen Sie uns dies mit der Definition von „Software Vulnerability“ von NIST in Beziehung setzen:

Der Teil, den ich hervorheben möchte, ist „könnte ausgenutzt werden“. Nehmen Sie Koa als Softwarebibliothek. Können Sie es ausnutzen, ohne zuerst den erforderlichen Angriffsvektor zu erstellen? Nein. Aus Sicht von Koa, einer Softwarebibliothek, wird also kein Angriffsvektor präsentiert; ohne das ist Ausbeutung unmöglich. Wenn wir die Definition streng interpretieren (was ich tue), könnten wir Koas Verhalten nicht als Schwachstelle bezeichnen.
Versuchen wir, einen CVSS-Score ohne Angriffsvektor zu berechnen:

Es gibt keine Punktzahl, wenn es keinen Angriffsvektor gibt. Ich würde sagen, dass dies mit der Definition von Software Vulnerability übereinstimmt, die von NIST bereitgestellt wird.
Lassen Sie uns experimentieren und ein imaginäres Szenario erstellen, in dem ein Angriffsvektor existiert.

Hier gibt es neben dem imaginären Angriffsvektor noch einige Probleme. Die Angriffskomplexität wurde auf Hoch gesetzt, da eine erfolgreiche Ausnutzung einen alten Browser erfordert. Ein Angreifer muss die Opfer davon überzeugen, einen alten Browser herunterzuladen und zu installieren.
In diesem Sinne ist Benutzerinteraktion erforderlich, auch wenn es bei den Basismetriken für Benutzerinteraktionen nicht wirklich darum geht. Ob das Ausnutzen des XSS in diesem Szenario eine Benutzerinteraktion erfordert, hängt davon ab, wie die verwendete Webanwendung umleitet, und nicht von Koa. Erwähnenswert ist auch, dass das injizierte JavaScript nicht von selbst ausgeführt werden würde, da es in erster Linie eine Benutzerinteraktion erforderte: das Klicken auf den Link in der HTML-Antwort.

Was können wir also tun, um eine Schwachstellenbewertung zu erzwingen? Wir müssen etwas auswählen. Wunschdenken, das Schlimmste annehmen, was auch immer Sie bevorzugen. Eines ist sicher, Sie machen eine Rechnung, die Sie gar nicht machen sollten, und das Ergebnis ist so weit von der Realität entfernt, dass ich nicht einmal die Worte dafür finden kann.

Das nächste große Ding sind die Impact Metrics. Sie müssen wissen, was die Webanwendung über die Auswirkung sagen wird. Aber wir berechnen keinen Vulnerability Score für eine Webanwendung … Angesichts des Kontexts hat dieses XSS keine Auswirkungen auf Koa. Koa handhabt oder verarbeitet vertrauliche Informationen nicht selbst. Der Fehler hat keine Auswirkungen auf die Verfügbarkeit oder Integrität. Damit bleibt uns das Endergebnis von 0,0, selbst nachdem wir einen Angriffsvektor in die Berechnung gezwungen haben.

Die Frage ist also, berichten wir über Fakten oder Fiktion?

Sonatype machte mich auf die offizielle Anleitung zum Scoring Vulnerabilities in Software Libraries aufmerksam , die 2019 mit CVSSv3.1 veröffentlicht wurde. Ich gebe zu, ich wusste nichts davon, was sowohl gut als auch schlecht ist. Gut, weil es zu einem Schimpfwort geführt hätte, schlecht, weil ich vielleicht all meine Hoffnung verloren hätte, wenn ich es früher gesehen hätte, bevor ich mich so sehr bemüht hätte, zu erklären, dass es nicht der richtige Weg ist. Also, was sagt die offizielle Anleitung?

Bei der Bewertung der Auswirkungen einer Schwachstelle in einer Bibliothek … sollte der Analyst für das angemessene Worst-Case-Implementierungsszenario punkten. Wenn möglich, sollten die CVSS-Informationen diese Annahmen detailliert beschreiben.

Die Antwort lautet also, dass das Vulnerability Scoring auf Fiktion basiert.

Was ist außerdem ein „ angemessenes Worst-Case-Implementierungsszenario“? Wenn wir viele Projekte analysiert haben, die Koa verwendet haben, und festgestellt haben, dass die meisten Entwickler offene Weiterleitungen mit der ctx.redirect()Methode von Koa implementiert haben, könnte es vernünftig sein, das Schlimmste anzunehmen. Ich habe eine schnelle Codesuche in JavaScript-Projekten für ctx.redirect(auf GitHub durchgeführt. Ich habe 16.827 Codeergebnisse erhalten. Bei der Suche nach context.redirect(erhielt ich 15.751 Code-Ergebnisse. Das wären 32.578 zu analysierende Codeergebnisse. Einige davon werden Koa verwenden, einige Express und einige können etwas anderes sein. (Natürlich könnte der Kontext mit einem beliebigen Namen aufgerufen werden, nicht nur mit ctxoder context, sodass noch mehr Code angezeigt werden könnte.)

Die Frage ist: Werden vom Benutzer bereitgestellte Daten so häufig hirnlos weitergeleitet, um sie umzuleiten? Ich habe einen halbautomatischen Analyseansatz gewählt, indem ich ein kleines Skript geschrieben habe, um alle Projekte zu überprüfen, die den Suchkriterien entsprachen. Leider kam ich nicht über die ersten 1.000 Treffer hinaus, da GitHub weitere Anfragen ablehnte:

{
    "message":"Only the first 1000 search results are available",
    "documentation_url":"https://docs.github.com/v3/search/"
}

Basierend auf dem, was ich gesehen habe, und in Anbetracht dessen, was im nächsten Abschnitt („Der alte Webbrowser“) besprochen wird, glaube ich nicht, dass es vernünftig wäre, eine Worst-Case-Implementierung anzunehmen. Nicht in diesem speziellen Fall.

Die offizielle Anleitung sagt auch, dass:

Bei der Bewertung einer Schwachstelle in einer bestimmten Implementierung mithilfe der betroffenen Bibliothek muss die Bewertung für diese spezifische Implementierung neu berechnet werden.

Das ist vernünftig und mildert den Science-Fiction-Aspekt der Situation ein Stück weit. So endete dieses Koa-Problem mit dem Vulnerability Score von 9,8 in unserem Fall bei 0,0.

Das Gute ist, dass Sonatype zugestimmt hat, dass der Schwachstellenwert von 9,8 unangemessen war, und dass sie bereit sind, ihn zu reduzieren. Ich weiß es zu schätzen, und wahrscheinlich werden viele andere es auch tun.

Darüber hinaus teilte mir Sonatype mit, dass sie beim Hinzufügen des Problems zu ihrem System der Meinung waren, dass es am besten wäre, wenn ihre Kunden über diese möglicherweise unerwartete Situation Bescheid wüssten. Sie sagten: „Es war besser, Alarm zu schlagen, als zu ignorieren, was wir gesehen haben, und möglicherweise ein negatives Ergebnis zu haben“. Und natürlich hatten sie Recht.

Ich habe nie hinterfragt, ob Sicherheitsprobleme kommuniziert werden sollten oder nicht. Ja, Sicherheitslücken müssen sichtbar gemacht werden. Was mich interessiert, ist, wie diese Probleme kommuniziert werden:

• Ist es angemessen, etwas als Schwachstelle oder eher als Sicherheitsschwäche oder unsicheres Standardverhalten usw. zu bezeichnen?
• Ist die zugewiesene Schwachstellenbewertung angemessen?
• Sind genügend Details und Kontext angegeben?

Lassen Sie uns nun ein wenig über die alten Webbrowser sprechen.

Der alte Webbrowser

Ohne die guten Leute von Sonatype hätte ich wahrscheinlich nie wieder an alte Webbrowser gedacht.

Auch in Zukunft werde ich auf alte Browser verzichten. Zunächst einmal gibt es zu viele Dinge zu beachten; Ich kann mir keine Sorgen um alte Webbrowser machen. Zweitens, wie alt ist ( klicken Sie nicht auf den Link, wenn Sie keinen Sinn für Humor haben! ) ein alter Webbrowser? Was heißt eigentlich „alt“? Wenn jemand nur einen etwa 1 Jahr alten Browser verwendet, ist es ziemlich wahrscheinlich, dass er bereits viel größere Probleme als XSS hat.

Trotzdem habe ich etwas gegoogelt und folgendes gefunden:

• Google Chrome 48.0.2564.109 (64-Bit) aus dem Jahr 2016 (!) zeigte nicht einmal den Antworttext an. Da das Koa-Problem im Jahr 2018 gefunden wurde, dachte ich, dass es ausreichen sollte, bis 2016 zurückzugehen, aber es stellte sich heraus, dass dies nicht der Fall war.
• Firefox 4.0 aus dem Jahr 2011 zeigte den Antworttext an, aber Benutzer mussten auf den Link klicken, damit die JavaScript-Nutzlast ausgeführt werden konnte. (Natürlich ist es ein Link!)
• Firefox 52.0 aus dem Jahr 2017, 1 Jahr bevor das Koa-XSS-Problem gemeldet wurde, zeigte bereits den Response-Body mit der JavaScript-Payload nicht an. Firefox hat gerade einen Fehler mit der Aufschrift „Corrupted Content Error“ aufgrund einer „Netzwerkprotokollverletzung“ ausgegeben.

Koa 0.0.1 wurde 2013 veröffentlicht, es gab also einige Jahre, in denen das Problem hätte ausgenutzt werden können. Ab diesem Zeitpunkt wäre es wahrscheinlich akzeptabel, dieses Problem (immer noch nicht mit einer Punktzahl von 9,8) bis Koa 2.5.0 im Jahr 2018 zu kennzeichnen. Danach rechtfertigt jedoch nichts mehr als 1,0.

Beim Stöbern bin ich auf Wikipedia auf etwas Interessantes gestoßen . Lassen Sie mich zitieren:

Firefox 15 wurde am 28. August 2012 veröffentlicht … Firefox 15 führte stille Updates ein, ein automatisches Update, das Firefox auf die neueste Version aktualisiert, ohne den Benutzer zu benachrichtigen, [65] eine Funktion, die die Webbrowser Google Chrome und Internet Explorer 8 und höher haben bereits umgesetzt

Alle wichtigen Webbrowser hatten also eine automatische Update-Funktion, bevor die erste Version von Koa veröffentlicht wurde, was bedeutet, dass die Wahrscheinlichkeit groß ist, dass die Mehrheit der Benutzer einen aktuellen Webbrowser verwendet hat. Sehen wir uns den Zustand zur Zeit des „Urknalls“ an: 2013.

• Firefox 15 : Es wurde ein Fehler mit der Aufschrift „Corrupted Content Error“ zurückgegeben, was bedeutet, dass der Antworttext dem Benutzer nicht angezeigt wurde.
• Chrome 24.0.1312 (WebKit 537.17) : Es wurde kein Antworttext angezeigt. Beim Betrachten des Netzwerk-Tabs der Entwicklertools war kaum etwas zu sehen, also musste ich Wireshark ausführen, um zu sehen, ob der Browser die Anfrage überhaupt ausgeführt hat. In Wireshark war sichtbar, dass Chrome meinen PoC-Dienst kontaktiert und die Antwort mit der JavaScript-Nutzlast erhalten hat. Der Antworttext wurde nicht gerendert. Besser noch, nichts ist passiert.
• Internet Explorer 11 (11.0.9600.19180) : Es hat die Antwort von meinem PoC-Dienst abgerufen, die ich mit Wireshark überprüft habe. Der Antworttext wurde dem Benutzer nicht angezeigt. Es kam mit der klassischen, eingebauten Fehlerseite zurück, die besagt: „Diese Seite kann nicht angezeigt werden“.

Nachdem wir die obigen Recherchen durchgeführt haben, kehren wir für eine Sekunde zu einem Zitat von Sonatype zurück:

Koa scheint sich in diesem Zusammenhang um XSS zu kümmern, da sie dort bereits Code haben, um dies zu verhindern, HTML-Entitäten, die die URL codieren, wenn sie sie in HTML schreiben

Diese Aussage ist zwar richtig, aber die Tatsache, dass zum Zeitpunkt der Veröffentlichung der ersten Version von Koa keiner der großen Browser die Ausbeutung erlaubte, deutet auf etwas Interessantes hin, auf etwas anderes als das, was der Satz suggerieren möchte. Bitte beachten Sie, dass ich Spekulationen schreibe, da ich nicht genau wissen kann, wie die Koa-Entwickler gedacht haben. Ich kann mir leicht vorstellen, dass die Entwickler das fragliche Verhalten mit einem aktuellen Webbrowser getestet haben. Sie haben möglicherweise festgestellt, dass die HTML-Codierung geeignet war, da es bereits unmöglich war, injizierten JavaScript-Code von der hrefEigenschaft des auszuführenaSchild. Dies wirft eine ernsthafte Frage auf. Nachdem ich die letzten fünf Jahre mehr auf der Seite der Softwareentwicklung verbracht habe, gilt auch für mich: Wenn ich als Entwickler eine neue Webtechnologie für die Backend-Seite erstellen möchte, sollte ich mich dann um alte Webbrowser kümmern? Und wenn ja, was ist die offizielle Empfehlung der Sicherheits-Community, wie weit in der Zeit ich alte Webbrowser berücksichtigen muss? Sollten wir nicht bedenken, dass die bewährte Sicherheitsmethode für Endbenutzer darin besteht, ihre Browser auf dem neuesten Stand zu halten, und die Funktion zur automatischen Aktualisierung hilft auch dabei? Auch wenn wir erwarten, dass Entwickler alte Browser im Hinterkopf behalten und mit ihnen testen, können wir nicht erwarten, dass Sicherheitsexperten dasselbe tun und alle Webbrowser und ihre Versionen benennen, die zu einem bestimmten Problem beitragen, anstatt nur auf „alte Browser“ zu verweisen “? Es wäre nur fair.

Eines ist sicher, seit Jahren gibt es nichts zu befürchten…

Der moderne Browser

In meiner Analyse habe ich mit meinem Webbrowser den Antworttext überprüft und festgestellt, dass er leer ist. Ich habe nicht überprüft, ob die über die Leitung gesendete Antwort einen Körper hatte. Es stellt sich heraus, dass nur Google Chrome den Antworttext vollständig ignoriert hat. daher wurde es nicht angezeigt. Das war gut genug für mich. Vernünftigerweise muss ich hinzufügen.

Seitdem habe ich mir die Antwort meines Test-Webdienstes mit der neuesten Version von Koa angesehen. Wir können unten sehen, dass es einen HTML-Antworttext mit dem eingefügten JavaScript-Code gab:

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=javascript:alert(1); HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: javascript:alert(1);
< Content-Type: text/html; charset=utf-8
< Content-Length: 71
< Date: Tue, 22 Nov 2022 17:55:12 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
Redirecting to <a href="javascript:alert(1);">javascript:alert(1);</a>.

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=%22><%2f HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: %22%3E%3C/
< Content-Type: text/html; charset=utf-8
< Content-Length: 61
< Date: Tue, 22 Nov 2022 22:18:49 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
Redirecting to <a href="&quot;&gt;&lt;/">&quot;&gt;&lt;/</a>.

Kommende Änderungen

Nachfolgend finden Sie eine Liste der Updates, die Sonatype bezüglich dieses Problems implementieren möchte:

• Aktualisierung der Zusammenfassung/Titelzeile zur Beseitigung von Missverständnissen (bereits geschehen)
• Reduzierung des Vulnerability Score auf 4,7 (bereits geschehen)
• Erwähnen Sie, dass die Schwachstelle nur ausgenutzt werden kann, wenn ein Benutzer einen älteren Browser verwendet

Zusätzliche Änderungen, die ich sehen möchte

Zusätzlich zu den im vorherigen Abschnitt erwähnten Änderungen könnten noch einige Dinge verbessert werden. Diese sind:

• Weitere Reduzierung des Schwachstellen-Scores, insbesondere für die nach 2018 veröffentlichten Koa-Versionen.
• Angabe der Versionsnummer mindestens der wichtigsten Webbrowser und ihrer Veröffentlichungsdaten, die im Bericht enthalten sind, wenn auf die „älteren Browser“ verwiesen wird. Dies würde jedem erheblich helfen, „eine Schwachstelle in einer bestimmten Implementierung mit der betroffenen Bibliothek zu bewerten“. Wenn ich zum Beispiel gesehen habe, dass ein Benutzer einen Browser aus dem Jahr 2011 verwenden musste, hätte ich das Problem in SCA innerhalb einer Sekunde als „nicht betroffen“ markiert. Es ist eine Menge Zeit gespart.
• Die betroffenen Koa-Versionen sollen auf der Seite der Schwachstelle aufgelistet werden .

Übrigens hat Sonatype auch erwähnt, dass sie einige coole Prüfungen in ihrem kommerziellen Angebot haben, die beispielsweise tatsächliche Prüfungen auf Codeebene durchführen, um festzustellen, ob eine Anwendung von den gemeldeten Schwachstellen betroffen ist. Das klingt ordentlich, und angesichts des Science-Fiction-Charakters, wie Schwachstellenwerte für Bibliotheken berechnet werden, sind solche Überprüfungen ein Muss, um die Belastung der Entwicklungsteams zu verringern, insbesondere wenn die Dinge so weitergehen.

Fazit

Das sind so ziemlich alle Updates, die ich habe. Ich bin froh, dass ich mich an Sonatype gewandt habe, denn sie sind sehr professionell und freundlich. Es war eine Freude, mit ihnen daran zu arbeiten.

Bezüglich XSS in Koa: Es ist etwas, worüber sich seit einigen Jahren keiner von uns Sorgen machen sollte.