it-swarm.com.de

Ist OWASP ESAPI immer noch die empfohlene Methode zum Sichern von JSP-Seiten?

Ich habe festgestellt, dass OWASP ESAPI seit einiger Zeit nicht mehr aktualisiert wurde ( geringfügiges Update 2016 und vor 201 ). Gibt es bessere Alternativen zur Verwendung, d. H. Die Verwendung der Dienstprogramme eines besser gewarteten Frameworks, um beispielsweise Benutzereingaben als XSS-Verhinderung zu entkommen und zu validieren. Überlegen <cout .../> oder Struts 2 oder ein beliebiges Framework, das Code ausgibt und maskiert. Oder wird es aus Sicherheitsgründen bevorzugt, immer OWASP dafür zu verwenden? Gedanken?

6

Das OWASP ESAPI gilt nicht mehr als Flaggschiff oder gar aktives Projekt. Kevin Wall, der Projektbesitzer für die Java Implementierung, er selbst gab 2014 zu) dass das Projekt im Sterben liegt und sagte:

Ich bin es nicht, weil ich es nicht kann. Zum einen kann ich die Schrift an der Wand sehen. (Wortspiel beabsichtigt.) Alle Vorwürfe, die gegen ESAPI erhoben werden, sind zutreffend:

· Seit Juli 2011 wurde nur ein kleiner Punkt veröffentlicht.

· 164 offene Ausgaben, darunter 4 als kritisch und 11 als hoch.

· Viel zu viele Abhängigkeiten, etwas, das trotz der seit fast drei Jahren versprochenen Zusage nie angesprochen wurde.

· Wiki-Seite noch im alten OWASP-Format.

· Minimale Lebenszeichen von für ESAPI 3.0 in GitHub und ESAPI 2.x für Java in Google Code. Keine Lebenszeichen für Implementierungen in anderen Programmiersprachen. [Hinweis: Discounting der SalesForce als Ich habe es nicht im Auge behalten.]

· Für ESAPI für Java eine überfüllte Architektur, bei der alles ein Singleton ist, was einige Dinge wie Mock-Tests so gut wie unmöglich macht. Teilweise weniger als 80% Testcode-Abdeckung.

· Fehlen einer signifikanten Benutzerdokumentation außerhalb der Javadoc- und der ESAPI-Kryptodokumentation.

· Enttäuschende Teilnahme am ESAPI Hackathon.

4
Mark Burnett

Ein weiterer Klappentext von Kevin Wall auf Soll ich ESAPI verwenden?

Wenn Sie mit einem neuen Projekt beginnen oder zum ersten Mal versuchen, ein vorhandenes Projekt zu sichern, sollten Sie , bevor Sie ESAPI in Betracht ziehen, dies für möglich halten Alternativen:

  • Ausgabecodierung: OWASP Java Encoder Project
  • Allgemeine HTML-Bereinigung: OWASP Java HTML-Bereinigung
  • Validierung: JSR-303/JSR-349 Bean-Validierung
  • Starke Kryptographie: Keyczar
  • Authentifizierung/Autorisierung: Apache Shiro
  • CSRF-Schutz: OWASP CSRFGuard Project oder OWASP CSRFProtector Project

Beachten Sie, dass dies nicht darauf hindeutet, dass ESAPI tot ist, sondern vielmehr darauf, dass es nicht so gut gewartet wird, wie es die meisten F500-Unternehmen für ihre Unternehmenssoftware wünschen.

IMO, wenn Sie die Option haben, sollten Sie Frameworks wie Spring verwenden, das über Funktionen verfügt, mit denen viele Sicherheitsbedenken behandelt werden können (z. B. Spring Security zur Authentifizierung, CSRF). Für die Ausgabe kümmern sich wiederum viele moderne Frameworks/Bibliotheken um die Codierung. Z.B. Verwenden Sie dann mit JSP JSTL - es verfügt über eine Tag-Bibliothek für die HTML-Codierung. Wenn Sie Rich Clients entwickeln, werden Frameworks wie React standardmäßig HTML codieren).

Ein Szenario, in dem ESAPI weiterhin nützlich ist, ist die Nachrüstung einer Legacy-Anwendung, deren Sicherheit fehlt. Selbst dann hat ESAPI genügend offene Probleme/Schwachstellen, die Ihnen eine Pause geben sollten. Es ist ein trauriger Zustand und Kevin Wall wirkt ein wenig bitter:

Die erste Frage lautet: Verwenden Sie ESAPI bereits in Ihrem Projekt, und wenn ja, haben Sie viel damit zu tun? Wenn ja, dann die Antwort auf "Soll ich ESAPI verwenden?" wahrscheinlich ist "ja". Die zweite Frage, die Sie stellen sollten, wenn ich sie verwende, warum trage ich nicht in irgendeiner Weise dazu bei? Aber wir werden nicht dorthin gehen.

1
HTLee