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
Auf dem Weg zu Gold: Steigende Standards für sicheren Code bei Paysafe
Sehen Sie, wie die Partnerschaft von Paysafe mit Secure Code Warrior die Produktivität der Entwickler um 45 % steigerte und die Zahl der Code-Schwachstellen erheblich reduzierte.
Die Macht der Marke in AppSec DevSec DevSecOps (Was ist in einem Acrynym!?)
Für eine dauerhafte Wirkung von AppSec-Programmen braucht es mehr als nur Technik - es braucht eine starke Marke. Eine starke Identität stellt sicher, dass Ihre Initiativen auf Resonanz stoßen und ein nachhaltiges Engagement innerhalb Ihrer Entwicklergemeinschaft fördern.
Vertrauensagent: AI von Secure Code Warrior
Dieser One-Pager stellt den SCW Trust Agent: AI vor, eine neue Reihe von Funktionen, die tiefgreifende Beobachtbarkeit und Kontrolle über KI-Codierwerkzeuge bieten. Erfahren Sie, wie unsere Lösung die Nutzung von KI-Tools mit den Fähigkeiten von Entwicklern korreliert, um Sie beim Risikomanagement zu unterstützen, Ihren SDLC zu optimieren und sicherzustellen, dass jede Zeile des von KI generierten Codes sicher ist.
Vibe Coding: Praktischer Leitfaden zur Aktualisierung Ihrer AppSec-Strategie für KI
In diesem On-Demand-Video erfahren Sie, wie AppSec-Manager durch einen praktischen Ansatz, bei dem die Schulung im Vordergrund steht, in die Lage versetzt werden, KI zu fördern, anstatt sie zu blockieren. Wir zeigen Ihnen, wie Sie Secure Code Warrior (SCW) nutzen können, um Ihre AppSec-Strategie strategisch für das Zeitalter der KI-Codierassistenten zu aktualisieren.
Ressourcen für den Einstieg
Sicheres Coding im Zeitalter der KI: Testen Sie unsere neuen interaktiven KI-Herausforderungen
KI-gestütztes Coding verändert die Entwicklung. Testen Sie unsere neuen KI-Herausforderungen im Copilot-Stil, um Code in realistischen Workflows sicher zu prüfen, zu analysieren und zu korrigieren.