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 buchen
Anwendungssicherheitsforscher - 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 buchen
Anwendungssicherheitsforscher - 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
Sicher durch Design: Definition von Best Practices, Befähigung von Entwicklern und Benchmarking von präventiven Sicherheitsergebnissen
In diesem Forschungspapier werden die Mitbegründer von Secure Code Warrior , Pieter Danhieux und Dr. Matias Madou, Ph.D., zusammen mit den Experten Chris Inglis, ehemaliger US National Cyber Director (jetzt strategischer Berater der Paladin Capital Group), und Devin Lynch, Senior Director, Paladin Global Institute, die wichtigsten Erkenntnisse aus mehr als zwanzig ausführlichen Interviews mit Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, ein VP of Application Security und Software-Sicherheitsexperten, offenlegen.
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Aussagekräftige Daten über den Erfolg von Secure-by-Design-Initiativen zu finden, ist bekanntermaßen schwierig. CISOs stehen oft vor der Herausforderung, den Return on Investment (ROI) und den Geschäftswert von Sicherheitsprogrammen sowohl auf Mitarbeiter- als auch auf Unternehmensebene nachzuweisen. Ganz zu schweigen davon, dass es für Unternehmen besonders schwierig ist, Erkenntnisse darüber zu gewinnen, wie ihre Organisation im Vergleich zu aktuellen Branchenstandards abschneidet. Die Nationale Cybersicherheitsstrategie des Präsidenten forderte die Beteiligten auf, "Sicherheit und Widerstandsfähigkeit durch Design" zu erreichen. Der Schlüssel zum Erfolg von Secure-by-Design-Initiativen liegt nicht nur darin, Entwicklern die nötigen Fähigkeiten zu vermitteln, um sicheren Code zu gewährleisten, sondern auch darin, den Aufsichtsbehörden zu versichern, dass diese Fähigkeiten vorhanden sind. In dieser Präsentation stellen wir eine Vielzahl von qualitativen und quantitativen Daten vor, die aus verschiedenen Primärquellen stammen, darunter interne Daten von über 250.000 Entwicklern, datengestützte Kundeneinblicke und öffentliche Studien. Auf der Grundlage dieser gesammelten Daten wollen wir eine Vision des aktuellen Stands von Secure-by-Design-Initiativen in verschiedenen Branchen vermitteln. Der Bericht zeigt auf, warum dieser Bereich derzeit nicht ausreichend genutzt wird, welche erheblichen Auswirkungen ein erfolgreiches Schulungsprogramm auf die Minderung von Cybersecurity-Risiken haben kann und welches Potenzial zur Beseitigung von Schwachstellen in einer Codebasis besteht.
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.
Ressourcen für den Einstieg
Aufgedeckt: Wie die Cyber-Industrie "Secure by Design" definiert
In unserem neuesten Whitepaper haben sich unsere Mitbegründer Pieter Danhieux und Dr. Matias Madou, Ph.D., mit über zwanzig Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, AppSec-Leiter und Sicherheitsexperten, zusammengesetzt, um die wichtigsten Teile dieses Puzzles herauszufinden und die Realität hinter der Secure by Design-Bewegung aufzudecken. Die Sicherheitsteams haben ein gemeinsames Ziel, aber kein gemeinsames Regelwerk.
Wird Vibe Coding Ihre Codebasis in eine Verbindungsparty verwandeln?
Vibe Coding ist wie eine College-Verbindungsparty, und AI ist das Herzstück aller Festivitäten, das Fass. Es macht eine Menge Spaß, sich auszutoben, kreativ zu werden und zu sehen, wohin die eigene Fantasie einen führen kann, aber nach ein paar Bierfässern ist das Trinken (oder die Verwendung von KI) in Maßen zweifellos die sicherere langfristige Lösung.
Entwicklergesteuerte Kodierung.
Sicher ist sicher.
Setzen Sie sich noch heute mit uns in Verbindung und machen Sie Softwaresicherheit zu einem festen Bestandteil Ihres Entwicklungsprozesses.
