Ich rate zu einer geschichteten Sicherheitsarchitektur zu verwenden. Ich meine, es ist möglich, eine sichere Anwendung per Hand zu erstellen, aber es ist extrem schwierig zu implementieren. Einige Sicherheitsfunktionen wie als Authentifizierung und grundlegende Zugriffskontrolle (URL-Ebene oder GUI-Komponentenebene) sind relativ einfach zu implementieren, aber Anforderungen wie Sicherheit auf Instanzebene (speziell mit älteren Datenbanken arbeiten), Sql Injection und XSS sind schwieriger.
Ich empfehle Spring Security zu verwenden und so viel wie möglich benutzerdefinierte Validierungen zu implementieren. Zusätzlich dazu empfehle ich, HDIV zu verwenden, um eine zusätzliche Sicherheitsschicht hinzuzufügen, die helfen könnte, die Ausnutzung von Risiken zu vermeiden, die nicht durch benutzerdefinierte Validierungen abgedeckt sind. Insbesondere die von HDIV angebotenen Funktionen sind:
A1- Injection: über HTTP Parameter Werte und Urls HDIV das Risiko dieser Sicherheitsanfälligkeit zu verringern, um nur die Daten, die aus Textfelder in Formularen kommen, Integrität Validierungen Anwendung (stellt sicher, dass der empfangene Wert mit dem auf der Serverseite generierten Wert übereinstimmt) für den Rest der Daten, die von der Client-Seite kommen. Für Textfelder, die in Formularen enthalten sind, bietet HDIV generische Validierungen (Whitelist und Blacklist), um Injektionsattacken zu vermeiden.
A2-Defekt Authentifizierung und Session Management: HDIV bietet keine Funktionen für dieses Web-Risiko.
A3-XSS: das gleiche wie A1, aber in diesem Fall XSS-Risiken zu vermeiden.
A4-Unsichere direkte Objektreferenzen: HDIV steuert alle Daten auf Server-Seite erzeugt, um die Integrität der Daten zu gewährleisten und diese Sicherheitsanfälligkeit zu vermeiden.
A5-Sicherheit Misconfiguration: HDIV keine besonderen Funktionalitäten für das schließt aber nicht den Zugang zu Ressourcen ermöglichen bisher nicht durch den Server gesendet, die Ausbeutung von unerwartetem Verhalten oder den Zugriff auf private Ressourcen zu vermeiden.
A6-Sensitive Daten Exposure: HDIV bietet Vertraulichkeit Funktion verstecken die Werte der HTTP-Parameter.
A7-Fehlende Funktionslevel Access Control: dank der Integrität Validierungen von HDIV implementiert, die Ausnutzung dieser Sicherheitsanfälligkeit vermeidet und den Benutzer begrenzen rechtliche Schritte auszuführen und den ursprünglichen Vertrag (GUI oder API) beibehalten wird angeboten durch die
Anwendung.
A8-Cross-Site Request Forgery (CSRF): HDIV fügt aleatorischen Token vermeiden diese Sicherheitsanfälligkeit
A9-Komponenten verwenden mit bekannten Schwachstellen: HDIV nicht spezifische Funktionalitäten enthält dafür aber dank der Interaktion Begrenzungen für den Benutzer in vielen Fällen ist nicht möglich, die Sicherheitslücke auszunutzen.
A10-Nicht validiert Umleitungen und vorwärts: Diese Schwachstelle ist hauptsächlich auf die Manipulation von nicht editierbare Daten oder Daten erzeugen zuvor auf Server-Seite. HDIV steuert alle vom Server gesendeten Daten und ermöglicht keine Umleitung auf schädliche Websites .
Neben diesen Funktionalitäten von OWASP Top Ten Web-Risiken zu schützen, Protokolle erzeugt HDIV auch auf die bösartigen Aktivitäten oder Angriffe auf Ihrer Website mit allen Informationen über den Angriff und die Benutzername innerhalb authentifizierten-Websites im Zusammenhang .
Grüße,
Roberto Velasco (HDIV Team)
Spring Security behandelt nur die Sicherung URLs und gibt Ihnen einen Login-Rahmen, wenn die zugrunde liegenden Authentifizierungsmechanismus nach wie vor schwach ist, werden Sie noch eine mögliche Sicherheitsverletzung haben . Spring Security bietet zwar einen Mechanismus zum Erzwingen von SSL für URLs, aber Sie benötigen dann immer noch ein SSL-Zertifikat.Kurz gesagt, Spring Security ist nicht genug, um die OWASP Top 10 zu befriedigen. –