Sicherheit ist auch für Application Express-Anwendungen ein wichtiges Thema. Viele Anwendungen arbeiten mit sensiblen Daten, insofern müssen sich Entwickler und Betreiber von Application Express-Anwendungen Gedanken zur Sicherheit der Anwendung machen. Anhand dieser Checkliste können Sie ermitteln, wo Sie mit Ihrer APEX Anwendung zum Thema IT-Sicherheit stehen. Sie können dann anschließend selbst bestimmen welche Maßnahmen Sie ergreifen möchten um die IT-Sicherheit zu erhöhen.

Grundsätzliches

• Datenbank-Version:
  Sicherheit fängt bei der Datenbank an. Als erstes sollten Sie für die Datenbank das jüngste Patchlevel und das letzte Critical Patch Update berücksichtigen. Da dies nicht für die Express Edition gegeben ist, sollte zumindest die Edition Standard Edition One der Datenbank für den produktiven Einsatz verwendet werden.
• APEX-Version:
  Das jüngste Release APEX 3.2.1 beinhaltet verschiedene Verbesserungen zum Thema IT-Sicherheit wie Einstellungen zum Session Time-Out, geschützte Passwortfelder oder verschlüsselte Werte im Session State. Daher ist ein Upgrade auf diese Version sehr zu empfehlen
• Server- und Netzwerk-Architektur:
  Niemals sollte im produktiven Betrieb einen direkten Zugriff von außerhalb auf die Datenbank möglich sein. Deshalb sollten Endanwender niemals direkt aus dem Internet auf den "Embedded PL/SQL Gateway" der Datenbank zugreifen. Die folgende Abbildung zeigt einen möglichen Setup:
  
  
  1. einen HTTP-Server in die sog. Demilitarisierte Zone (DMZ)
  2. einen weiteren HTTP-Server (nun der Oracle HTTP-Server) ins LAN (1)
  3. die Datenbank ebenfalls ins LAN (2). Die Datenbank kann auf einem anderen Server als laufen, muss aber nicht.
  
  Firewalls regeln nun den Netzwerkverkehr zwischen den Zonen. So ist zwischen den beiden HTTP-Servern nur HTTP(S) gestattet. Die SQL*Net-Kommunikation mit der Datenbank findet nur innerhalb des LAN statt.

Entwicklung sicherer Anwendungen

Bereits während der Anwendungsentwicklung entscheidet sich, wie sicher eine Anwendung im späteren Betrieb sein wird ...

• Generell gilt: Misstrauen Sie jeder Benutzereingabe. Prüfen Sie alles, was vom Browser kommt, sei es durch ein Formular, durch die URL oder durch ein Cookie.
• Sichern Sie Ihre Anwendung gegen SQL Injection-Angriffe. Nahezu jeder "bösartige" Angriff erlangt Zugriff auf die Datenbank durch eine SQL Injection-Lücke in einer Anwendung. Es obliegt allein dem Entwickler, seine Anwendung sicher zu entwickeln - der Administrator kann gegen eine bestehende SQL Injection-Lücke so gut wie nichts mehr tun (mehr ...)
• Alle Texte die an den Browser zurück gegeben werden sollten im Prinzip "escaped" werden, damit eventuell enthaltener JavaScript-Code nicht durch den Browser interpretiert wird. Das schützt vor den sog. Cross-Site-Scripting-Attacken (XSS). Dazu können Sie die Formularelemente vom Typ Nur Anzeigen durch den Typ Nur Anzeigen (Escape bei Sonderzeichen, hat keinen Speicherstatus) ändern. Wenn Sie außerdem eine PL/SQL-Prozedur schreiben, die mit htp.p einen Text an den Browser zurück gibt, dann tun Sie das am besten wie folgt:

  htp.p(htf.escape_sc(v('PX_USER_INPUT_ITEM'))); 
  

• Alle Elemente vom Typ Passwort sollten in der Anwendung nicht im Session State gehalten werden. Verwende dazu ein Passwortfeld vom Typ Kennwort (Zustand wird nicht gespeichert).
• Nutzen Sie die Virtual Private Database. Damit wird schon durch die "SQL-Engine" sichergestellt, dass ein Benutzer nur die Tabellenzeilen sehen kann, die er auch sehen darf. Implementieren Sie ganz generell alle Zugriffsregeln dort, wo die Daten sind, also in der Datenbank und möglichst nicht in der Applikation (mehr ...)
• Validations sollten die fachlichen Anforderungen der versendeten Daten überprüfen. Auch wenn's lästig ist: Wenn eine Feld nur positive Zahlenwerte aufnehmen soll, müssen Sie das durch eine Validation sicherstellen. Prüfen Sie auch scheinbar abstruse Benutzereingaben und stellen Sie sicher, dass nur gültige Werte verarbeitet werden. Nutzen Sie auch die Möglichkeiten der Datenbank zur Sicherstellung der Datenintegrität wie Check-Constraints, Foreign Keys, Trigger und andere ...
• Lagern Sie Ihren PL/SQL Code in eigene Packages aus und "wrappen" Sie diese ($ORACLE_HOME/bin/wrap). Damit ist der Code nicht mehr via USER_SOURCE oder ALL_SOURCE lesbar.
• Es ist eine gute Praxis, ein Proxy Schema zu verwenden. Das bedeutet, das die Tabellen, Views und Prozeduren nicht direkt im APEX Workspace liegen, sondern in einem anderen Schema. Das APEX Workspace-Schema bekommt zum Zugriff, welcher nicht direkt auf die Tabellen, sondern durch PL/SQL Packages und Views erfolgen sollte, entsprechende Privilegien (Achtung: im APEX-Umfeld keine Rollen verwenden).
• Alle Elementwerte können ab APEX-Version 3.2.1 verschlüsselt im Session State abgelegt werden. Dazu wird das Elementattribut Wert verschlüsselt in Sessionzustand speichern auf Ja gesetzt.
• Auf der Seite Anwendungsdefinition sollte das Attribut Exakte Ersetzungen auf Ja - Nur exakte Ersetzungen ausführen eingestellt werden. Damit werden dynamische Texte nur noch ersetzt wenn diese mit &MY_TEXT. referenziert sind. Eine Schreibweise ohne Punkt am Ende ist bei dieser Einstellung nicht erlaubt.
• Nutzen Sie den Schutz für den Sessionzustand (Session State Protection). Damit können Sie verhindern, dass Endanwender Parameter direkt in der URL ändern und somit u.U. die Anwendungslogik aushebeln können. Setzen Sie dabei pro Seite das Attribut Schutz für den Sessionzustand auf Argumente müssen Prüfsumme haben. Pro Element sollte dieses Attribut auf Prüfsumme erforderlich auf Sessionebene konfiguriert werden. Wenn Sie APEX-URLs generieren möchten, nutzen Sie die Funktion apex_util.prepare_url, um die nötige Prüfsumme zu erzeugen.

  apex_util.prepare_url(
    p_url => 'f?p=' || :APP_ID || ':15:' || :APP_SESSION || '::NO::P1_X:foo
  );
  

  Achtung: Session State Protection schützt nur die URL, nicht jedoch per Submit (HTTP POST) abgesetzte Formulardaten! Eine serverseitige Validierung, ob der Benutzer zur jeweiligen Aktion berechtigt ist, muss daher zusätzlich erfolgen.
• Verschlüsseln Sie Daten gegebenenfalls in der Datenbank. Wie man das macht, ist in einem Tipp der DBA Community beschrieben. Achten Sie jedoch auf ein sicheres Schlüsselmanagement. Die Schlüssel dürfen auf keinen Fall in Datenbanktabellen liegen - PL/SQL-Funktionen zum Ver- und Entschlüsseln dürfen auf keinen Fall sprechende Namen haben oder den Schlüssel in sich tragen.
• Nutzen Sie die Möglichkeiten von APEX zur Zugriffskontrolle. Wenden Sie diese jedoch durchgängig an: So reicht es nicht aus, die Reiterkarte (Tab) einer Seite per Autorisierungsschema auszublenden; das muss auch für die Seite selbst geschehen - schließlich kann man diese auch direkt aufrufen. Auch PL/SQL onSubmit-Prozesse können durch geschicktes Präparieren einer HTTP-Anfrage direkt angesprochen werden - setzen Sie daher auch dort ggfs. das Autorisierungsschema.
• Alle Elementwerte die nach der Verarbeitung durch einen Prozeß nicht mehr gebraucht werden, sollten wieder zurückgesetzt werden (zum Beispiel bei einer Verzweigung).
• Das mehrfache "Submitten" von Formulardaten nicht gestatten. Schalten Sie außerdem das automatische Vervollständigen von Formularen ab.
  
  Mehrfaches "Submit" von Formulardaten verhindern
  
  Automatisches Vervollständigen von Formularen verbieten
• Entfernen Sie alle Objekte, die Sie nicht mehr brauchen (Seiten, Templates, Prozesse, Datenbanktabellen oder PL/SQL-Code).
• Auditieren Sie Ihre Anwendung mit den Möglichkeiten der Datenbank. Die Besonderheiten, die beim Auditieren von APEX-Anwendungen zu beachten sind, sind in einem Community-Tipp beschrieben.
• Wenn die Entwicklung abgeschlossen ist: Nur die Ausführung der Anwendung erlauben (Anwendungseigenschaften). Stellen Sie außerdem das Debugging ab und nutzen Sie dieses nur bei konkretem Bedarf.
  
  Anwendung nur ausführen

Betrieb einer sicheren APEX-Umgebung

Für den Betrieb einer APEX-Umgebung gibt es zahlreiche Tipps und Anregungen; auch hier kann diese Liste keinen Anspruch auf Vollständigkeit erheben. Der Schwerpunkt liegt bei den APEX-spezifischen Dingen, wobei für eine APEX-Umgebung grundsätzlich das gleiche gilt wie für jede andere Datenbankumgebung. Sehr guter Lesestoff zum Thema findet sich im Dokument Project Lockdown: A phased approach to securing your database infrastructure im Oracle Technet. Einige der darin enthaltenen Tipps finden Sie auch hier wieder ...

• Allgemeine Sicherheitseinstellungen:
  Navigieren Sie als APEX Administrator (Workspace INTERNAL) zu Service verwalten, Umgebungseinstellungen verwalten und dort zur Sicherheit. Konfigurieren Sie die Einstellungen dort nach Ihren Bedürfnissen - im Sinne einer sicheren Umgebung sollten die Einstellungen so restriktiv wie möglich sein - achten Sie aber auch darauf, dass Sie Ihre Entwickler und Endanwender nicht überfordern (bspw. mit komplizierten Passwort-Policys).
• Deaktivieren Sie das Debugging von Anwendungen in der Produkivumgebung. Navigieren Sie dazu zu den Anwendungseigenschaften.
  
  Debugging deaktivieren
• Generell sollte man über die Umgebung so wenig Informationen wie möglich preisgeben. Wenn zum Beispiel ein HTTP Server verwendet wird, dann sollte man den sog. Database Access Descriptor (DAD) nicht unbedingt "apex" nennen. Auch das "pls" ist nicht unbedingt nötig. So ist es besser, wenn eine APEX-Umgebung mit "http://myserver/dev/mycompany" anstelle von "http://myserver/pls/apex" erreichbar ist.
• Netzwerkverschlüsselung mit SSL nutzen. Das ist sowohl mit dem Apache Webserver als auch mit dem PL/SQL Embedded Gateway möglich.
• Mit der Advanced Security Option der Datenbank kann eine verschlüsselte Verbindung zwischen Datenbank und Webserver eingerichtet werden. Außerdem ist es möglich, die Datenbankdateien (Transparent Data Encryption) oder Backups transparent zu verschlüsseln.
• Single Sign On (SSO) Mechanismen nutzen. Die Oracle Fusion Middleware bietet einen SSO-Server an. Ein solcher Server übernimmt die Anmeldung (Sign On) für mehrere Applikationen, so dass Endanwender sich nur einmal anmelden müssen. Und je weniger Passwörter sich ein Endanwender merken muss, desto sicherer werden diese, weil sie nicht "unter dem Schreibtisch" aufgeschrieben werden. Mehr dazu ...
• Nutzen Sie die Möglichkeiten des Ressourcenmanagements in der Oracle-Datenbank (mehr ...)
• Überwachen Sie Ihre Umgebung: Auf Anwendungsebene kann das Attribut Logging eingeschaltet werden. Alle Zugriffe auf Seiten werden dann protokolliert und können direkt in APEX ausgewertet werden. Siehe Activity unter Application Reports.
• Entfernen Sie auf dem Produktivsystem die APEX-Entwicklungsumgebung mit dem SQL-Skript apxdevrm.sql. Instanzweite Aufgaben (Workspace erstellen) können mit dem Paket APEX_INSTANCE_ADMIN erledigt werden. Alle Anwendungen werden dann mit SQL*Plus durch einen DBA installiert. Mit apxdvins.sql können Sie die Entwicklungsumgebung wieder installieren.
• "Härten" Sie den Apache Webserver, einige Beispiele hierfür sind ...
  • Schalten Sie alle nicht benötigten Apache-Module (PHP, Perl, ...) ab.
  • Löschen Sie alle nicht benötigten statischen Seiten
  • Entfernen Sie alle nicht benötigten Direktiven (Aliasnamen, Verzeichnisse) aus der httpd.conf
  Nehmen Sie die Hilfe eines erfahrenen Webserver-Administrators in Anspruch.
• Schränken Sie den direkten Aufruf von PL/SQL-Prozeduren per URL ggfs. ein. Bei Verwendung des Embedded Gateways mit einer Oracle11g-Datenbank findet dies bereits statt. Wenn Sie den Apache Webserver nutzen, können Sie bei Konfiguration des mod_plsql den Parameter PlsqlRequestValidationFunction nutzen. In der Dokumentation finden Sie hierzu nähere Erläuterungen.

Diese Liste erhebt (wie schon betont) keinen Anspruch auf Vollständigkeit, vielmehr gibt sie die Erfahrung des Autors aus verschiedensten Kundenprojekten wieder. Natürlich kann sie auch fortgesetzt werden; Anregungen dazu sind jederzeit willkommen.

Niels de Bruijn arbeitet seit 2003 als Senior Systemberater für die MT AG in Ratingen und hat langjährige Projekterfahrung in den Bereichen Oracle und Application Express. Die MT AG ist langjähriger IT-Beratungspartner von Großunternehmen und Mittelstand. Sie steht für Technologie-Know How und praxisnahe, effiziente IT-Dienstleistung: von Strategie und Beratung über Entwicklung und Integration bis hin zu Wartung und Administration von IT-Infrastrukturen.

Zurück zur Community-Seite