Sie sehen sich Hilfeinhalte der folgenden Version an:

Das Open Web Application Security Project (OWASP) führt eine Liste zu den ihrer Meinung nach 10 häufigsten Sicherheitsrisiken für Webanwendungen.

Diese sind unten aufgeführt – zusammen mit einer Erläuterung, wie CRX mit ihnen umgeht.

1. Injection

  • SQL – Vorbeugung durch konstruktive Maßnahmen: Das Standard-Repository umfasst und erfordert keine herkömmliche Datenbank, denn alle Daten werden im Inhalts-Repository gespeichert. Der Zugriff ist komplett auf authentifizierte Benutzer beschränkt und kann nur durch die JCR-API durchgeführt werden. SQL wird nur für Suchanfragen unterstützt (Auswählen). Darüber hinaus bietet SQL Unterstützung für Werte-Binding.
  • LDAP – Die LDAP-Injection ist nicht möglich, da das Authentifizierungsmodul die Eingaben filtert und den Benutzerimport mithilfe der bind-Methode durchführt.
  • BS – Aus der Anwendung heraus wird keine Shell-Ausführung durchgeführt.

2. Cross-Site Scripting (XSS)

Die allgemeine Praxis zur Schadensbegrenzung besteht in der Codierung aller Ausgaben benutzergenerierter Inhalte mithilfe einer serverseitigen XSS-Schutzbibliothek, die auf dem OWASP Encoder und AntiSamy basiert.

XSS hat sowohl bei den Tests als auch bei der Entwicklung eine hohe Priorität und alle festgestellten Probleme werden (in der Regel) umgehend behoben.

3. Fehler in Authentifizierung und Session Management

AEM nutzt fundierte, bewährte Authentifizierungstechniken und greift hierzu auf Apache Jackrabbit und Apache Sling zurück. In AEM werden keine Browser-/HTTP-Sitzungen verwendet.

4. Unsichere direkte Objektreferenzen

Jeglicher Zugriff auf Datenobjekte wird durch ein Repository vermittelt und daher durch die rollenbasierte Zugriffssteuerung beschränkt.

5. Cross-Site Request Forgery (CSRF)

Auf das Risiko der Cross-Site Request Forgery (CSRF) wird durch die automatische Injection eines kryptografischen Tokens in alle Formulare und AJAX-Anforderungen sowie durch die Verifizierung dieses Tokens auf dem Server bei jedem POST eingegangen.

Darüber hinaus ist AEM mit einem Referrer-Header-basierten Filter ausgestattet, der so konfiguriert werden kann, dass er nur POST-Anforderungen von bestimmten Whitelist-Hosts zulässt.

6. Sicherheitsrelevante Fehlkonfiguration

Es kann nicht garantiert werden, dass sämtliche Software immer korrekt konfiguriert ist. Allerdings versuchen wir, so viel Hilfe wie möglich bereitzustellen und die Konfiguration so einfach wie möglich zu gestalten. Darüber hinaus ist AEM mit integrierten Sicherheitsintegritätsprüfungen ausgestattet, die Ihnen bei der Überwachung der Sicherheitskonfiguration auf einen Blick helfen.

In der Sicherheitsprüfliste finden Sie weitere Informationen, die Ihnen Schritt für Schritt Härtungsanweisungen bereitstellen.

7. Unsicherer kryptografischer Speicher

Die Kennwörter werden als kryptografische Hashes im Benutzerknoten gespeichert. Solche Knoten können standardmäßig nur vom Administrator und vom Benutzer selbst gelesen werden.

Sensible Daten wie die Drittanbieteranmeldedaten sind in verschlüsselter Form mithilfe einer FIPS 140-2-zertifizierten kryptografischen Bibliothek gespeichert

8. Fehlgeschlagene Beschränkung des URL-Zugriffs

Das Repository ermöglicht die Einstellung von feinabgestimmten Rechten (wie durch JCR angegeben) für jeden Benutzer bzw. jede Gruppe unter jedem beliebigen Pfad über Zugriffssteuerungseinträge. Zugriffbeschränkungen werden durch das Repository durchgesetzt.

9. Unzureichende Transportschichtsicherheit

Dieses Risiko wird durch die Serverkonfiguration gemindert (z. B. nur HTTPS).

10. Ungeprüfte Um- und Weiterleitungen

Dieses Risiko wird durch die Beschränkung aller Umleitungen an benutzerseitig bereitgestellte Ziele auf interne Standorte gemindert.

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie