RELEASE-INFORMATION
io.netty:netty-codec-http
vor Version 4.1.77.Final enthält eine unzureichende Korrektur für CVE-2021-21290. Wenn die Multipart-Decoder von Netty verwendet werden, kann die Offenlegung lokaler Informationen über das temporäre Verzeichnis des lokalen Systems erfolgen, wenn die temporäre Speicherung von Uploads auf der Festplatte aktiviert ist. Dies wirkt sich nur auf Anwendungen aus, die unter Java Version 6 und niedriger laufen. Darüber hinaus wirkt sich diese Schwachstelle auf Code aus, der auf Unix-ähnlichen Systemen und sehr alten Versionen von Mac OSX und Windows ausgeführt wird, da sie alle das temporäre Systemverzeichnis für alle Benutzer freigeben. Version 4.1.77.Final enthält einen Patch für diese Sicherheitslücke. Als Workaround kann man sein eigenes java.io.tmpdir
beim Starten der JVM angeben oder DefaultHttpDataFactory.setBaseDir(...) verwenden, um das Verzeichnis auf etwas zu setzen, das nur für den aktuellen Benutzer lesbar ist..checkboxradio( "refresh" )
auf einem solchen Widget und das anfängliche HTML enthielt kodierte HTML-Entitäten, die fälschlicherweise dekodiert wurden. Dies kann dazu führen, dass möglicherweise JavaScript-Code ausgeführt wird. Der Fehler wurde in jQuery UI 1.13.2 behoben. Um das Problem zu beheben, kann jemand, der das ursprüngliche HTML ändern kann, alle Nicht-Eingabe-Inhalte des "Labels" in ein "span" einpacken.java.sql.ResultRow.refreshRow()
führt kein Escaping von Spaltennamen durch, so dass ein bösartiger Spaltenname, der einen Anweisungsterminator, z.B. ;
, enthält, zu einer SQL-Injection führen kann. Dies könnte dazu führen, dass zusätzliche SQL-Befehle als JDBC-Benutzer der Anwendung ausgeführt werden. Benutzeranwendungen, die die Methode ResultSet.refreshRow()
nicht aufrufen, sind davon nicht betroffen. Benutzeranwendungen, die diese Methode aufrufen, sind betroffen, wenn die zugrunde liegende Datenbank, die sie über ihre JDBC-Anwendung abfragen, unter der Kontrolle eines Angreifers stehen könnte. Für den Angriff muss der Angreifer den Benutzer dazu bringen, SQL gegen einen Tabellennamen auszuführen, dessen Spaltennamen das bösartige SQL enthalten, und anschließend die Methode refreshRow()
für das ResultSet aufzurufen. Beachten Sie, dass der JDBC-Benutzer der Anwendung und der Eigentümer des Schemas nicht identisch sein müssen. Eine JDBC-Anwendung, die als privilegierter Benutzer ausgeführt wird und Datenbankschemata abfragt, die potenziell böswilligen, weniger privilegierten Benutzern gehören, wäre anfällig. In einer solchen Situation könnte es dem böswilligen Benutzer möglich sein, ein Schema zu erstellen, das die Anwendung dazu veranlasst, Befehle als privilegierter Benutzer auszuführen. Die gepatchten Versionen werden als 42.2.26
und 42.4.1
veröffentlicht. Den Benutzern wird empfohlen, ein Upgrade durchzuführen. Es gibt keine bekannten Umgehungsmöglichkeiten für dieses Problem.javascript:
URL-Ausdrücke enthält, falsch bereinigen, was XSS-Angriffe ermöglichen könnte, wenn ein Leser anschließend auf diesen Link klickt. Wenn die nicht standardmäßige Option SafeList.preserveRelativeLinks
aktiviert ist, wird HTML, das javascript:
URLs enthält, die mit Steuerzeichen erstellt wurden, nicht bereinigt. Wenn die Website, auf der dieses HTML veröffentlicht wird, keine Content Security Policy einstellt, ist ein XSS-Angriff möglich. Dieses Problem wurde in jsoup 1.15.3 behoben. Benutzer sollten auf diese Version aktualisieren. Da die nicht sanitisierten Eingaben möglicherweise erhalten geblieben sind, sollten alte Inhalte mit der aktualisierten Version erneut bereinigt werden. Um dieses Problem zu beheben, ohne sofort zu aktualisieren: - deaktivieren Sie SafeList.preserveRelativeLinks
, wodurch Eingabe-URLs als absolute URLs umgeschrieben werden - Stellen Sie sicher, dass eine geeignete Content Security Policy definiert ist. (Dies sollte unabhängig von einem Upgrade als bewährtes Verfahren zur Tiefenverteidigung verwendet werden)