Wie sich Richtlinien für sicheres Programmieren entwickeln
Letzte Woche habe ich Schwachstellen in Java Spring recherchiert, um unsere Richtlinien für sicheres Programmieren auf den neuesten Stand zu bringen. Ich bin die bestehenden Herausforderungen auf unserer Plattform durchgegangen und bin auf einige zum Thema XSS durch die Anzeige von URL-Parametern in JSP-Seiten gestoßen. Das fehlerhafte Codebeispiel sähe in etwa so aus:
<input type="text" name="username" value="${param.username}">
Die korrekte Lösung bestand darin, den URL-Parameter vollständig zu entfernen. Die Beschreibung erwähnt zudem, dass die korrekte Maskierung des URL-Parameters ebenfalls sicher ist.
Meine Aufgabe ist es nun, die Richtlinie für sicheres Programmieren so zu formulieren, dass sie für Entwickler klar verständlich ist und sie so wenig wie möglich einschränkt, während gleichzeitig sicherer Code geschrieben wird. In diesem Fall würde ich es den Entwicklern lieber ermöglichen, die beabsichtigte Funktionalität beizubehalten, und ihnen empfehlen, dies sicher durch die Maskierung des URL-Parameters zu tun. 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 unsere Richtlinie für sicheres Programmieren für ein paar Tage, bis ich auf eine OWASP-Seite über Expression Language Injection stieß. Diese Seite beschreibt, wie die Spring Expression Language (SpEL) für Injection-Angriffe mit schwerwiegenden Folgen, einschließlich Remote Code Execution, missbraucht werden kann. Es lag an mir herauszufinden, ob es Fälle geben könnte, in denen Code, der unsere Richtlinie für sicheres Programmieren einhält, dennoch von dieser Schwachstelle betroffen sein kann. Also habe ich eine schnelle Testanwendung geschrieben, um SpEL-Ausdrücke auszuwerten, und Eingaben mit und ohne XML-Maskierung getestet, um zu sehen, ob ich Szenarien finden kann, die nicht erfasst werden. Und das habe ich: Es gibt bösartige Ausdrücke, die keine Zeichen enthalten, die von XmlEscape erfasst werden. Ich habe die funktionierende Demo auf unserem GitHub veröffentlicht, die Sie hier finden können.
Natürlich habe ich unsere Richtlinie für sicheres Programmieren aktualisiert, die nun lautet: „URL-Parameter dürfen nicht mithilfe der Spring Expression Language (SpEL) angezeigt oder ausgewertet werden.“
Die Gesamtauswirkung dieses Problems ist hoch, und zwar aus folgenden Gründen: - Ein Angreifer könnte Funktionen auf dem Anwendungsserver ändern und aufrufen. - Unbefugter Zugriff auf Daten und Funktionen sowie Kontoübernahme und Remote Code Execution. - Bedenken hinsichtlich Vertraulichkeit und Integrität bei einem erfolgreichen Angriff.
https://www.owasp.org/index.php/Expression_Language_Injection
Kontrollieren Sie KI-gestützte Entwicklung, bevor sie in Produktion geht
Bewerten Sie KI-gestützte Risiken, setzen Sie Richtlinien für sicheren Code direkt beim Commit durch und beschleunigen Sie die sichere Bereitstellung über Ihren gesamten SDLC hinweg.
Weitere Blogs entdecken
Erhalten Sie Zugang zu Experteninhalten über sichere Programmierung, KI-Governance und Software-Risikomanagement.
%252520%252520(3).avif)
Supercharged Security Awareness: How Tournaments are Inspiring Developers at Erste Group
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Security as culture: How Blue Prism cultivates world-class secure developers
Learn how Blue Prism, the global leader in intelligent automation for the enterprise, used Secure Code Warrior's agile learning platform to create a security-first culture with their developers, achieve their business goals, and ship secure code at speed
Eine Sicherheitskultur: Wie Sage sein Champions-Programm aufgebaut hat
Erfahren Sie, wie Sage die Sicherheit durch einen flexiblen, beziehungsorientierten Ansatz gestärkt, über 200 Security Champions ausgebildet und eine messbare Risikoreduzierung erzielt hat.
Cybersecurity Awareness Month 2026: Das Verständnis von KI-Sicherheit ist entscheidend für die Unternehmensverteidigung
Wir haben einen Punkt erreicht, an dem die meisten führenden KI-Unternehmen öffentlich eine weltweite Verlangsamung der KI-Entwicklung gefordert haben, damit die Sicherheitsvorkehrungen Schritt halten können. Doch die Wahrheit ist: Ernsthafte Sicherheitsprobleme sind bereits Realität geworden. Dies bringt unzählige Sicherheitsverantwortliche und Führungsteams in eine dringliche Lage, da die finanziellen Kosten und Risiken durch die Implementierung von KI stetig steigen.
Enabler 8: Branding für Ihr Programm
Ein Programm für sicheres Programmieren braucht mehr als nur großartige Inhalte, um erfolgreich zu sein. Enabler 8 zeigt, wie Branding die Teilnahme zu einem begehrten, statusorientierten Erlebnis macht.
.avif)
Jeder Mitarbeiter steht jetzt an vorderster Front der KI-Cybersicherheit
Die Unternehmenslandschaft wandelt sich mit einer Geschwindigkeit, die kaum jemand vorhergesehen hat, bis es zu spät war. Wir haben offiziell die Schwelle von handgeschriebenem Code und einfacher Copilot-Unterstützung hin zur Ära des Agentic Development Lifecycle (ADLC) überschritten. Während autonome KI-Agenten eine beispiellose Effizienz in vielen Bereichen versprechen, bringen sie auch eine völlig neue Klasse von Sicherheits- und Regulierungsrisiken mit sich.
Sichere KI-gestützte Entwicklung vor dem Release
Erkennen Sie Entwicklerrisiken, setzen Sie Richtlinien durch und verhindern Sie Schwachstellen über den gesamten Softwareentwicklungszyklus hinweg.
