Wie sich die Richtlinien für sichere Kodierung 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 Schwachstellen in Java Spring recherchiert, um unsere Richtlinien für sichere Kodierung auf den neuesten Stand zu bringen.
Anwendungssicherheitsforscher - F&E-Ingenieur - PhD-Kandidat

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenAnwendungssicherheitsforscher - F&E-Ingenieur - PhD-Kandidat


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 unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchenAnwendungssicherheitsforscher - F&E-Ingenieur - PhD-Kandidat
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
Inhaltsübersicht
Anwendungssicherheitsforscher - F&E-Ingenieur - PhD-Kandidat

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Professionelle Dienstleistungen - Beschleunigen Sie mit Fachwissen
Das PSS-Team (Program Strategy Services) von Secure Code Warriorunterstützt Sie beim Aufbau, der Verbesserung und der Optimierung Ihres Programms für sichere Codierung. Ganz gleich, ob Sie neu anfangen oder Ihren Ansatz verfeinern möchten, unsere Experten bieten Ihnen maßgeschneiderte Beratung.
Themen und Inhalte der Schulung zu sicherem Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sie an die sich ständig verändernde Softwareentwicklungslandschaft anzupassen und Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis XQuery Injection und werden für eine Vielzahl von Rollen angeboten, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Überblick über die Inhalte, die unser Katalog nach Thema und Rolle bietet.
Quests: Branchenführendes Lernen, damit die Entwickler immer einen Schritt voraus sind und Risiken minimiert werden.
Quests ist eine learning platform , die Entwicklern hilft, Software-Sicherheitsrisiken zu verringern, indem sie ihre Fähigkeiten zur sicheren Programmierung verbessern. Mit kuratierten Lernpfaden, praktischen Herausforderungen und interaktiven Aktivitäten befähigt sie Entwickler, Schwachstellen zu erkennen und zu vermeiden.
Ressourcen für den Einstieg
Das Jahrzehnt der Defenders: Secure Code Warrior Zehnte Runde
Secure Code WarriorDas Gründungsteam von SCW ist zusammengeblieben und hat das Schiff ein ganzes Jahrzehnt lang durch alle Lektionen, Triumphe und Rückschläge gesteuert. Wir vergrößern uns und sind bereit für unser nächstes Kapitel, SCW 2.0, als führendes Unternehmen im Risikomanagement für Entwickler.
10 wichtige Vorhersagen: Secure Code Warrior über den Einfluss von KI und Secure-by-Design im Jahr 2025
Unternehmen stehen vor schwierigen Entscheidungen über den Einsatz von KI, um die langfristige Produktivität, Nachhaltigkeit und den Sicherheits-ROI zu unterstützen. In den letzten Jahren ist uns klar geworden, dass KI die Rolle des Entwicklers niemals vollständig ersetzen wird. Von KI + Entwicklerpartnerschaften bis hin zum zunehmenden Druck (und der Verwirrung) rund um die Secure-by-Design-Erwartungen - lassen Sie uns einen genaueren Blick darauf werfen, was wir im nächsten Jahr erwarten können.