Sicherheit

Gerade im Internet ist das Thema der Datensicherheit zu Recht ein besonders sensibles. Wann immer persönliche Nutzerdaten gespeichert werden, stellt sich automatisch die Frage nach dem Schutz vor Missbrauch. Und besonders wenn dabei Geschäfte getätigt werden, darf es keine zwei Meinungen geben. Nicht nur ist sie für den Kunden in höchstem Maße relevant bei seiner Einschätzung der Seriosität einer Seite, z. B. eines Shops; entsprechende Maßnahmen sollten auch für den Betreiber eines solchen von absolutem Interesse sein: Geraten die Daten tatsächlich in falsche Hände, geht das im besten Falle einher mit einem entsprechenden Imageschaden. Im schlimmsten Fall kann er sich mit empfindlichen Schadensersatzansprüchen konfrontiert sehen.

So wie es für die Entwickler von Anwendungen also Priorität hat, für die nötige Sicherheit zu sorgen, sollte es ebenso das Ziel eines jeden Projektverantwortlichen, IT-Leiters oder Geschäftsführers sein, eine Anwendung zu betreiben, die diesen Ansprüchen gerecht wird.

Auch für die Entwickler von OFBiz ist die Sicherheit ein stets aktuelles Thema. Mit einer Projektlaufzeit von mittlerweile fast zehn Jahren zeigt sich das OFBiz-Framework als sehr ausgereift und genügt damit auch den hohen Ansprüchen der Apache-Community.

OFBiz trennt die Oberfläche, die Applikationslogik und die Datenbanklogik in Schichten (Plattformunabhängigkeit). Die Schicht, die mit der Datenbank kommuniziert, wird als “EntityEngine” bezeichnet. Sie prüft die ankommenden Daten und versucht, sie in Werte zu konvertieren, die mit der jeweiligen Datenbank kompatibel sind. Sollte dies zum Beispiel aufgrund eines Manipulationsversuches (SQL Injection) nicht gelingen, beendet die EntityEngine die Verarbeitung mit einem Fehler und gibt die Daten gar nicht erst an die Datenbank weiter. Außerdem werden Felder, die als Passwort deklariert sind, automatisch lediglich als Hash-Wert in OFBiz hinterlegt, was ein Ausspähen quasi unmöglich macht. In der Datenbank selbst können besonders sensible Informationen auch verschlüsselt hinterlegt werden, z. B. Kreditkartendaten.

Zusätzlich kommen sogenannte “Map Processors” zum Einsatz, die direkt nach dem Absenden eines HTML-Formulars die jeweiligen Eingabefelder validieren. So wird beispielsweise geprüft, ob in Feldern, in denen numerische Werte (0-9) erwartet werden, diese auch tatsächlich stehen. Bei einer Datumsangabe kann darüber hinaus ausgelesen werden, ob die erwartete Syntax eingehalten wurde und die Angaben sich zu entsprechenden Date-Objekten konvertieren lassen. Diese Map Processors kommen im gesamten Backend stringent zum Einsatz sorgen so für einen flächendeckenden Schutz.

OFBiz ist sicher in Bezug auf alle zehn Punkte der Top Ten OWASP (http://www.owasp.org):

  • A1: Injection
  • A2: Cross-Site Scripting (XSS)
  • A3: Broken Authentication and Session Management
  • A4: Insecure Direct Object References
  • A5: Cross-Site Request Forgery (CSRF)
  • A6: Security Misconfiguration
  • A7: Insecure Cryptographic Storage
  • A8: Failure to Restrict URL Access
  • A9: Insufficient Transport Layer Protection
  • A10: Unvalidated Redirects and Forwards

Um die Sicherheit zu testen, greifen vor allem Kunden mit sehr publikumswirksamen Anwendungen – und entsprechenden Anforderungen an die Sicherheit – erfahrungsgemäß häufig auf die Hilfe von Sicherheitsdienstleistern (Hacker) zurück, die versuchen, etwaige Sicherheitslücken zu finden. Die Details solcher Untersuchungen von OFBiz-Projekten unterliegen selbstverständlicher der Vertraulichkeit. Man kann jedoch festhalten, dass sich mehr als einmal herausgestellt hat, dass OFBiz als sehr sicher einzustufen ist. Die von der OFBiz-Community bereitgestellten Funktionen bieten nur wenige Angriffsmöglichkeiten. Sofern die Best-Practices eingehalten werden, gilt dies ebenso für eigene Weiterentwicklungen.