Wie sich die Richtlinien für sichere Codierung entwickeln
Letzte Woche habe ich Schwachstellen in Java Spring recherchiert, um unsere Richtlinien für sichere Kodierung auf den neuesten Stand zu bringen. Ich ging die bestehenden Herausforderungen auf unserer Plattform durch und bemerkte einige zu XSS durch die Anzeige von url-Parametern in JSP-Seiten. Das fehlerhafte Code-Beispiel würde in etwa so aussehen wie das folgende:
<input type="text" name="username" value="${param.username}">
Die korrekte Lösung war, den URL-Parameter ganz zu entfernen, und in der Beschreibung wird erwähnt, dass das Escape des URL-Parameters auf die richtige Weise ebenfalls sicher ist.
Nun ist es meine Aufgabe, die Richtlinie für sichere Kodierung so zu formulieren, dass sie für Entwickler klar ist und sie so wenig wie möglich einschränkt, während sie trotzdem sicheren Code schreiben. In diesem Fall würde ich es vorziehen, die Entwickler ihre beabsichtigte Funktionalität beibehalten zu lassen und ihnen zu empfehlen, dies sicher zu tun, indem sie den URL-Parameter escapen. Auf diese Weise enthält der Code keine XSS-Schwachstelle mehr. Das obige Beispiel kann wie folgt abgesichert werden:
<input type="text" name="username" value="${fn:escapeXml(param.username)}">
Und das war für ein paar Tage unsere sichere Kodierungsrichtlinie, bis ich über eine OWASP-Seite über Expression Language Injection gestolpert bin. Diese Seite beschreibt, wie die Spring Expression Language (SpEL) für Injektionen mit einigen schwerwiegenden Auswirkungen, einschließlich Remotecodeausführung, missbraucht werden kann. Es lag an mir herauszufinden, ob es Fälle geben könnte, in denen Code, der sich an unsere Richtlinie zur sicheren Kodierung hält, trotzdem von dieser Schwachstelle betroffen sein kann. Also schrieb ich eine schnelle Testanwendung, um SpEL-Ausdrücke auszuwerten, und testete Eingaben mit und ohne Xml-Escaping, um zu sehen, ob ich einige Szenarien finden könnte, die nicht abgefangen würden. Und das habe ich, es gibt bösartige Ausdrücke, die keine Zeichen enthalten, die von XmlEscape abgefangen werden. Ich habe die funktionierende Demo auf unserem Github veröffentlicht, die Sie hier finden können.
Und natürlich habe ich unsere Secure Coding Guideline aktualisiert, die nun lautet: "URL-Parameter nicht mit der Spring Expression Language (SpEL) anzeigen oder auswerten."
Die Gesamtauswirkung dieses Problems ist aus den folgenden Gründen hoch: - Ein Angreifer könnte Funktionen auf dem Anwendungsserver ändern und aufrufen. - Unbefugter Zugriff auf Daten und Funktionen sowie Account-Hijacking und Remotecodeausführung. - Bedenken hinsichtlich Vertraulichkeit und Integrität bei einem erfolgreichen Angriff.
https://www.owasp.org/index.php/Expression_Language_Injection
Letzte Woche habe ich nach Sicherheitslücken in Java Spring gesucht, um unsere Richtlinien für sicheres Codieren auf den neuesten Stand zu bringen.
Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchen
Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand
Letzte Woche habe ich Schwachstellen in Java Spring recherchiert, um unsere Richtlinien für sichere Kodierung auf den neuesten Stand zu bringen. Ich ging die bestehenden Herausforderungen auf unserer Plattform durch und bemerkte einige zu XSS durch die Anzeige von url-Parametern in JSP-Seiten. Das fehlerhafte Code-Beispiel würde in etwa so aussehen wie das folgende:
<input type="text" name="username" value="${param.username}">
Die korrekte Lösung war, den URL-Parameter ganz zu entfernen, und in der Beschreibung wird erwähnt, dass das Escape des URL-Parameters auf die richtige Weise ebenfalls sicher ist.
Nun ist es meine Aufgabe, die Richtlinie für sichere Kodierung so zu formulieren, dass sie für Entwickler klar ist und sie so wenig wie möglich einschränkt, während sie trotzdem sicheren Code schreiben. In diesem Fall würde ich es vorziehen, die Entwickler ihre beabsichtigte Funktionalität beibehalten zu lassen und ihnen zu empfehlen, dies sicher zu tun, indem sie den URL-Parameter escapen. Auf diese Weise enthält der Code keine XSS-Schwachstelle mehr. Das obige Beispiel kann wie folgt abgesichert werden:
<input type="text" name="username" value="${fn:escapeXml(param.username)}">
Und das war für ein paar Tage unsere sichere Kodierungsrichtlinie, bis ich über eine OWASP-Seite über Expression Language Injection gestolpert bin. Diese Seite beschreibt, wie die Spring Expression Language (SpEL) für Injektionen mit einigen schwerwiegenden Auswirkungen, einschließlich Remotecodeausführung, missbraucht werden kann. Es lag an mir herauszufinden, ob es Fälle geben könnte, in denen Code, der sich an unsere Richtlinie zur sicheren Kodierung hält, trotzdem von dieser Schwachstelle betroffen sein kann. Also schrieb ich eine schnelle Testanwendung, um SpEL-Ausdrücke auszuwerten, und testete Eingaben mit und ohne Xml-Escaping, um zu sehen, ob ich einige Szenarien finden könnte, die nicht abgefangen würden. Und das habe ich, es gibt bösartige Ausdrücke, die keine Zeichen enthalten, die von XmlEscape abgefangen werden. Ich habe die funktionierende Demo auf unserem Github veröffentlicht, die Sie hier finden können.
Und natürlich habe ich unsere Secure Coding Guideline aktualisiert, die nun lautet: "URL-Parameter nicht mit der Spring Expression Language (SpEL) anzeigen oder auswerten."
Die Gesamtauswirkung dieses Problems ist aus den folgenden Gründen hoch: - Ein Angreifer könnte Funktionen auf dem Anwendungsserver ändern und aufrufen. - Unbefugter Zugriff auf Daten und Funktionen sowie Account-Hijacking und Remotecodeausführung. - Bedenken hinsichtlich Vertraulichkeit und Integrität bei einem erfolgreichen Angriff.
https://www.owasp.org/index.php/Expression_Language_Injection
Letzte Woche habe ich Schwachstellen in Java Spring recherchiert, um unsere Richtlinien für sichere Kodierung auf den neuesten Stand zu bringen. Ich ging die bestehenden Herausforderungen auf unserer Plattform durch und bemerkte einige zu XSS durch die Anzeige von url-Parametern in JSP-Seiten. Das fehlerhafte Code-Beispiel würde in etwa so aussehen wie das folgende:
<input type="text" name="username" value="${param.username}">
Die korrekte Lösung war, den URL-Parameter ganz zu entfernen, und in der Beschreibung wird erwähnt, dass das Escape des URL-Parameters auf die richtige Weise ebenfalls sicher ist.
Nun ist es meine Aufgabe, die Richtlinie für sichere Kodierung so zu formulieren, dass sie für Entwickler klar ist und sie so wenig wie möglich einschränkt, während sie trotzdem sicheren Code schreiben. In diesem Fall würde ich es vorziehen, die Entwickler ihre beabsichtigte Funktionalität beibehalten zu lassen und ihnen zu empfehlen, dies sicher zu tun, indem sie den URL-Parameter escapen. Auf diese Weise enthält der Code keine XSS-Schwachstelle mehr. Das obige Beispiel kann wie folgt abgesichert werden:
<input type="text" name="username" value="${fn:escapeXml(param.username)}">
Und das war für ein paar Tage unsere sichere Kodierungsrichtlinie, bis ich über eine OWASP-Seite über Expression Language Injection gestolpert bin. Diese Seite beschreibt, wie die Spring Expression Language (SpEL) für Injektionen mit einigen schwerwiegenden Auswirkungen, einschließlich Remotecodeausführung, missbraucht werden kann. Es lag an mir herauszufinden, ob es Fälle geben könnte, in denen Code, der sich an unsere Richtlinie zur sicheren Kodierung hält, trotzdem von dieser Schwachstelle betroffen sein kann. Also schrieb ich eine schnelle Testanwendung, um SpEL-Ausdrücke auszuwerten, und testete Eingaben mit und ohne Xml-Escaping, um zu sehen, ob ich einige Szenarien finden könnte, die nicht abgefangen würden. Und das habe ich, es gibt bösartige Ausdrücke, die keine Zeichen enthalten, die von XmlEscape abgefangen werden. Ich habe die funktionierende Demo auf unserem Github veröffentlicht, die Sie hier finden können.
Und natürlich habe ich unsere Secure Coding Guideline aktualisiert, die nun lautet: "URL-Parameter nicht mit der Spring Expression Language (SpEL) anzeigen oder auswerten."
Die Gesamtauswirkung dieses Problems ist aus den folgenden Gründen hoch: - Ein Angreifer könnte Funktionen auf dem Anwendungsserver ändern und aufrufen. - Unbefugter Zugriff auf Daten und Funktionen sowie Account-Hijacking und Remotecodeausführung. - Bedenken hinsichtlich Vertraulichkeit und Integrität bei einem erfolgreichen Angriff.
https://www.owasp.org/index.php/Expression_Language_Injection
Klicken Sie auf den untenstehenden Link und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenEine Demo buchen
Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand
Letzte Woche habe ich Schwachstellen in Java Spring recherchiert, um unsere Richtlinien für sichere Kodierung auf den neuesten Stand zu bringen. Ich ging die bestehenden Herausforderungen auf unserer Plattform durch und bemerkte einige zu XSS durch die Anzeige von url-Parametern in JSP-Seiten. Das fehlerhafte Code-Beispiel würde in etwa so aussehen wie das folgende:
<input type="text" name="username" value="${param.username}">
Die korrekte Lösung war, den URL-Parameter ganz zu entfernen, und in der Beschreibung wird erwähnt, dass das Escape des URL-Parameters auf die richtige Weise ebenfalls sicher ist.
Nun ist es meine Aufgabe, die Richtlinie für sichere Kodierung so zu formulieren, dass sie für Entwickler klar ist und sie so wenig wie möglich einschränkt, während sie trotzdem sicheren Code schreiben. In diesem Fall würde ich es vorziehen, die Entwickler ihre beabsichtigte Funktionalität beibehalten zu lassen und ihnen zu empfehlen, dies sicher zu tun, indem sie den URL-Parameter escapen. Auf diese Weise enthält der Code keine XSS-Schwachstelle mehr. Das obige Beispiel kann wie folgt abgesichert werden:
<input type="text" name="username" value="${fn:escapeXml(param.username)}">
Und das war für ein paar Tage unsere sichere Kodierungsrichtlinie, bis ich über eine OWASP-Seite über Expression Language Injection gestolpert bin. Diese Seite beschreibt, wie die Spring Expression Language (SpEL) für Injektionen mit einigen schwerwiegenden Auswirkungen, einschließlich Remotecodeausführung, missbraucht werden kann. Es lag an mir herauszufinden, ob es Fälle geben könnte, in denen Code, der sich an unsere Richtlinie zur sicheren Kodierung hält, trotzdem von dieser Schwachstelle betroffen sein kann. Also schrieb ich eine schnelle Testanwendung, um SpEL-Ausdrücke auszuwerten, und testete Eingaben mit und ohne Xml-Escaping, um zu sehen, ob ich einige Szenarien finden könnte, die nicht abgefangen würden. Und das habe ich, es gibt bösartige Ausdrücke, die keine Zeichen enthalten, die von XmlEscape abgefangen werden. Ich habe die funktionierende Demo auf unserem Github veröffentlicht, die Sie hier finden können.
Und natürlich habe ich unsere Secure Coding Guideline aktualisiert, die nun lautet: "URL-Parameter nicht mit der Spring Expression Language (SpEL) anzeigen oder auswerten."
Die Gesamtauswirkung dieses Problems ist aus den folgenden Gründen hoch: - Ein Angreifer könnte Funktionen auf dem Anwendungsserver ändern und aufrufen. - Unbefugter Zugriff auf Daten und Funktionen sowie Account-Hijacking und Remotecodeausführung. - Bedenken hinsichtlich Vertraulichkeit und Integrität bei einem erfolgreichen Angriff.
https://www.owasp.org/index.php/Expression_Language_Injection
Inhaltsverzeichnis
Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchenHerunterladenRessourcen für den Einstieg
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
Die Leistungsfähigkeit von OpenText Application Security + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
.png)
