JavaEE verfügt über einige tolle integrierte Sicherheitsmechanismen , aber sie sind weit davon entfernt Abdeckung Alle Bedrohungen, denen Ihre Anwendung ausgesetzt ist, wie Cross-Site Scripting (XSS), SQL-Injection, Cross-Site Request Forgery (CSRF) und XMLExternal Entities (XXE) werden nicht abgedeckt Es ist möglich, zu verhindern, dass Webanwendungen und Webdienste diesen Angriffen ausgesetzt werden, aber es erfordert einen gewissen Aufwand an Arbeit und Tests. Glücklicherweise hat das Open Web Application Security Project (OWASP) dies veröffentlicht Bericht „Die 10 kritischsten Risiken für Webanwendungen“.
Werfen wir einen Blick darauf, wie sich diese Hauptrisiken auf Java EE-Webanwendungen und Webdienste auswirken:
1. Injektion
Die Injektion erfolgt, wenn der Entwickler nicht vertrauenswürdige Informationen erhält, wie etwa request.getParameter(), request.getCookie() oder request.getHeader() , und in Verwenden Sie es jederzeit in einer Befehlsschnittstelle, zum Beispiel SQL-Injection, wenn Sie nicht vertrauenswürdige Daten mit einer regulären SQL-Abfrage verbinden, wie „SELECT * FROM users WHERE username='“ + request.getParameter("user") + „' AND passw Tritt auf, wenn ord='" + request.getParameter("pass") = "'". Entwickler sollten PreparedStatement verwenden, um zu verhindern, dass Angreifer die Bedeutung der Abfrage ändern und den Datenbankhost übernehmen. Es gibt Viele andere Arten von Injektionen wie Befehlsinjektion, LDAP-Injektion und Expression Language (EL)-Injektion sind alle äußerst gefährlich. Seien Sie daher äußerst vorsichtig, wenn Sie Daten an diese Interpreter senden
2. Defekte Authentifizierung und Sitzungsverwaltung
JavaEE unterstützt Authentifizierung und Sitzungsverwaltung, aber hier kann eine Menge Dinge schief gehen. Sie müssen sicherstellen, dass der gesamte authentifizierte Datenverkehr über SSL läuft, keine Ausnahmen Legen Sie JSESSIONID offen, dann kann es verwendet werden, um die Sitzung des Benutzers ohne Ihr Wissen zu kapern. Sie sollten die JSESSIONID rotieren, wenn sich der Benutzer authentifiziert, um Sitzungsfixierungsangriffe zu verhindern Es fügt der URL die JSESSIONID des Benutzers hinzu, wodurch sie anfälliger für Offenlegung oder Diebstahl wird.
3. Cross-Site-Scripting (XSS)
XSS tritt auf, wenn JavaEE-Entwickler nicht vertrauenswürdige Informationen aus HTTP-Anfragen erhalten und diese bei der Codierung ohne entsprechende Kontextausgabe in HTTP-Antworten einfügen. Angreifer können dieses Verhalten ausnutzen, um ihre Skripte in eine Website einzuschleusen, wo sie dann Sitzungen kapern und Daten stehlen können. Um diese Angriffe zu verhindern, müssen Entwickler eine sensible Kontextausgabecodierung durchführen. Wenn Sie Daten in HTML konvertieren, verwenden Sie das x;-Format. Achten Sie darauf, HTML-Attribute in Klammern zu setzen, da Attribute ohne Klammern beendet werden, wenn es viele verschiedene Zeichen gibt. Wenn Sie nicht vertrauenswürdige Daten in JavaScript, URL oder CSS einfügen, sollten Sie jeweils die entsprechende Escape-Methode verwenden. Und seien Sie sehr vorsichtig, wenn Sie mit verschachteltem Kontext arbeiten, beispielsweise einer in Javascript innerhalb eines HTML-Attributs geschriebenen URL. Möglicherweise möchten Sie bei der Codierung von Bibliotheken wie OWASP ESAPI helfen.
4. Unsichere direkte Objektverweise
Immer wenn eine Anwendung einen internen Bezeichner offenlegt, z. B. einen Datenbankschlüssel, einen Dateinamen oder eine Hash-Mapindex, kann ein Angreifer versuchen, diese Kennungen zu manipulieren, um auf nicht autorisierte Daten zuzugreifen. Wenn Sie beispielsweise nicht vertrauenswürdige Daten von einer HTTP-Anfrage an einen Java-Dateikonstruktor übergeben, kann ein Angreifer „../“- oder Null-Byte-Angriffe verwenden, um Ihre Validierung auszutricksen. Um diese Art von Angriffen zu verhindern, sollten Sie erwägen, indirekte Verweise auf Ihre Daten zu verwenden. Die ESAPI-Bibliothek unterstützt ReferenceMaps, die solche indirekten Referenzen ermöglichen.
5. Falsche Sicherheitskonfiguration
Moderne JavaEE-Anwendungen und Frameworks wie Struts und Spring verfügen über eine Vielzahl von Sicherheitseinstellungen. Gehen Sie unbedingt die Sicherheitseinstellungen durch und richten Sie sie nach Ihren Wünschen ein. Seien Sie beispielsweise vorsichtig mit dem Tag in nur für die aufgeführten Methoden gilt, sodass ein Angreifer andere HTTP-Methoden wie HEAD und PUT verwenden kann, um die gesamte Sicherheitseinschränkung zu umgehen. Vielleicht sollten Sie das -Tag in web.xml entfernen.
6. Offenlegung sensibler Daten
Java verfügt über eine große Anzahl von Verschlüsselungsbibliotheken, die jedoch nicht einfach richtig zu verwenden sind. Sie sollten eine auf JCE basierende Bibliothek finden, die nützliche Verschlüsselungsmethoden bequem und sicher bereitstellt. Solche Bibliotheken sind beispielsweise Jasypt und ESAPI. Sie sollten starke Algorithmen wie AES für die Verschlüsselung und SHA256 für Hashes verwenden. Seien Sie jedoch vorsichtig mit Passwort-Hashes, da diese mithilfe einer Rainbow Table entschlüsselt werden können. Verwenden Sie daher einen adaptiven Algorithmus wie bcrypt oder PBKDF2.
JavaEE unterstützt deklarative und prozedurale Zugriffskontrolle, aber viele Anwendungen entscheiden sich immer noch dafür, ihre eigenen Lösungen zu erstellen. Das Spring-Framework verfügt auch über Zugriffskontrollprimitive, die auf der -Annotation basieren. Das Wichtigste ist, sicherzustellen, dass jeder exponierte Port über angemessene Zugriffskontrollprüfungen verfügt, einschließlich Webdiensten. Gehen Sie nicht davon aus, dass der Client alles kontrollieren kann, da Angreifer direkten Zugriff auf Ihre Endpunkte haben.
8. Cross-Site Request Forgery (CSRF)
Jeder Endpunkt, der den Status ändert, muss überprüfen, ob die Anfrage gefälscht wurde. Entwickler sollten ein zufälliges Token in die Sitzung jedes Benutzers einfügen und es dann validieren, wenn die Anfrage eintrifft. Andernfalls könnte ein Angreifer über ein bösartiges IMG-, SCRIPT-, FRAME- oder FORM-Tag, das mit einer ungeschützten Anwendung verknüpft ist, eine „Angriffs“-Seite erstellen. Wenn ein Opfer eine solche Seite aufruft, generiert der Browser eine „falsche“ HTTP-Anfrage an die im Tag angegebene URL, die automatisch die Authentifizierungsinformationen des Opfers enthält.
9. Verwenden Sie Komponenten mit bekannten Schwachstellen
Moderne JavaEE-Anwendungen verfügen über Hunderte von Bibliotheken. Tools zur Abhängigkeitsauflösung wie Maven haben diese Zahl in den letzten fünf Jahren explodieren lassen. Viele weit verbreitete Java-Bibliotheken weisen bekannte Schwachstellen auf, die Webanwendungen vollständig untergraben können. Die Lösung besteht darin, die -Bibliothek rechtzeitig zu aktualisieren. Führen Sie nicht nur einen einzigen Scan durch, da jeden Tag neue Schwachstellen bekannt werden.
10. Nicht verifizierte Umleitung und Weiterleitung
Jedes Mal, wenn Ihre Anwendung nicht vertrauenswürdige Daten wie request.getParameter() oder request.getCookie() verwendet, kann ein Angreifer dies tun Zwingen Sie den Browser des Opfers, eine nicht vertrauenswürdige Website aufzurufen, um Malware zu zu installieren. Forward stellt ein ähnliches Problem dar, mit der Ausnahme, dass Angreifer sich selbst an nicht autorisierte Funktionen weiterleiten können, beispielsweise an Admin-Seiten. Überprüfen Sie unbedingt die Weiterleitungen und Weiterleitungsziele.
Sie sollten diesen Themen weiterhin Aufmerksamkeit schenken. Ständig werden neue Angriffe und Schwachstellen entdeckt. Im Idealfall können Sie Sicherheitsprüfungen in Ihre bestehenden Build-, Test- und Bereitstellungsprozesse integrieren.
Um diese Probleme in Ihrer Anwendung zu überprüfen, können Sie das kostenlose Contrast for Eclipse-Plugin ausprobieren. Dies ist kein einfaches statisches Analysetool. Stattdessen nutzt C4E Java-Instrumentierungs-APIs, um alles zu überwachen, was in der Anwendung sicherheitsrelevant ist. C4E kann sogar eine vollständige Datenflussanalyse in Echtzeit durchführen und so Daten von Anfragen über eine komplexe Anwendung verfolgen. Angenommen, Ihr Code nimmt einen Parameterwert, dekodiert ihn mit Base64, speichert ihn in einer Karte, fügt die Karte in eine Daten-Bean ein und speichert die Bean in einer Sitzungseigenschaft in JSP. Holen Sie sich die Beans Wert und fügen Sie diesen Wert mit EL in die Webseite ein. Contrast for Eclipse kann diese Daten verfolgen und XSS-Schwachstellen melden. Auch wenn Sie komplexe Frameworks und Bibliotheken verwenden. Kein anderes Werkzeug kann mit seiner Geschwindigkeit, Genauigkeit und Benutzerfreundlichkeit mithalten.
Contrast für Eclipse finden Sie im Eclipse Marketplace. Gehen Sie dann einfach auf die Server-Registerkarte „Start with Contrast“ – der Rest wird erledigt.
Das obige ist der detaillierte Inhalt vonDie 10 wichtigsten Sicherheitskontrollen, die in Java EE fehlen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
