Oracle Application Express - Security - Grundlagen

Die Sicherheit von Systemen oder Anwendungen wird in der heutigen Zeit immer wichtiger. Jeden Monat gehen neue Sicherheitsvorfälle durch die Medien, welche immer einen Image-Schaden für die entsprechenden Firmen bedeuten. Die Sicherheitsvorfälle können entweder direkt bemerkt werden, teilweise zeigen sich die Auswirkungen aber auch erst nach einer gewissen Zeit, wenn Daten an die Öffentlichkeit gelangen. Dies zeigte sich erneut im Januar 2019 als 600 GByte Daten mit E-Mail-Adressen und Passwörtern im Internet unter den Namen Collection #1 bis #5 angeboten wurden.

Berühmte Sicherheitspannen im letzten Jahr traten beim BeA, dem besonderen elektronischen Anwaltspostfach, aber auch bei der Gesundheitsapp Vivy auf. Beim BeA wurden Root-Zertifikate mit der Software ausgeliefert und bei Vivy ließen sich Behandlungsdaten von anderen Patienten einsehen, die eigentlich nur für den Patienten und den Arzt bestimmt waren.

Authentifizierung

Um eine Authentifizierung in APEX einrichten zu können, ist man nicht an die APEX-Benutzerkontensteuerung gebunden, sondern kann bereits bestehende Systeme hierzu verwenden. Die weiteren Möglichkeiten sind u.a.:

• Oracle-Datenbank-Benutzer
• LDAP
• PL/SQL-Scripte mit eigener Logik
• Keine Authentifizierung bei allgemeinen Daten

Eine Methode muss dabei immer bewusst angegeben werden, auch wenn diese am Ende "Keine Authentifizierung" ist.

Bei allen anderen Verfahren sollten Standard-Accounts vermieden und gelöscht oder deaktiviert werden, da diese bekannte Angriffsvektoren darstellen.

Autorisierung

Nach einer Authentifizierung sollte immer eine Autorisierung folgen, bei der z.B. nach verschiedenen Hierarchieebenen im Unternehmen unterschieden werden kann. Die Granularität, die uns APEX hier anbietet, kann entweder die ganze Seite sein, Teile einer Seite oder auch nur einzelne Elemente auf einer Seite.

Die Basis für diese Einschränkungen ähneln den Möglichkeiten der Authentifizierung.

• Oracle-Datenbank-Benutzer
• LDAP
• PL/SQL-Scripte mit eigener Logik
• SQL-Abfragen

Die Praxistauglichkeit der verschiedenen Methoden richtet sich danach, wie viele Benutzer die Anwendung haben wird und wie sensibel die Daten sind. Wird mit vielen Benutzern gerechnet, so lohnt sich eine automatische Benutzerverwaltung über SQL-Befehle. Hieraus ergibt sich ein geringer Aufwand, eine leichte Erweiterbarkeit und eine mittlere Sicherheit, da neue Benutzer immer direkt angelegt werden und über SQL-Injections die Tabelle verändern könnten.

Das Gegenstück bildet eine Autorisierung über die APEX Benutzer. Dabei wird jeder Benutzer von Hand angelegt und einer Gruppe zugewiesen. Dies bedeutet einen hohen manuellen Aufwand, aber auch eine hohe Sicherheit, da jeder neue Benutzer aktiv angelegt werden muss. Das Verfahren lohnt sich aber nur bei wenigen Benutzern und sensiblen Daten.

Session Handling

Das Session Handling in APEX läuft so ab, dass der Zustand jeder Session in der Datenbank gespeichert wird. Die einzelnen Eigenschaften, die zu einer Session gehören, können dabei über Formulare "manipuliert" werden. Hierzu gehört auch die aktuell aufgerufene Seite. Dies sollte man immer im Hinterkopf haben, wenn sensible Informationen angezeigt werden sollen.

Die Art wie ein Benutzer mit Formularen in APEX umgehen kann, lässt sich für jedes Feld separat bestimmen. Die Schutzarten sind dabei die Page Data Entry Item Protection, bei der festgelegt wird, ob ein Nutzer überhaupt die Daten-Inputs ändern darf und Page Display Only Item Protection, bei der die Daten-Outputs verändert werden können.

Neben den Formularen können wir auch festlegen, wie APEX mit der URL der einzelnen Seiten verfahren soll. Grundlegend können Seitenaufrufe auf zwei Wegen geschehen: Entweder über einen Link in der Anwendung oder bei Kenntnis der URL direkt. Hierfür bietet APEX die Attribute Unrestricted für den direkten Aufruf und No url access für das Verbot von direkten Aufrufen.

Dies hindert uns aber nur bedingt daran, Seiten aufzurufen, indem wir die Parameter in der URL manipulieren. Den Schutz bietet hierbei die Session State Protection mit der Einstellung Arguments Must Have Checksum. Hierbei wird eine zusätzliche Checksumme gebildet, die vor Manipulation der Session Informationen schützt.

SQL Injections

Eine SQL Injection bezeichnet das Einschleusen von Code in SQL-Abfragen, wodurch ein Angreifer Informationen oder Rechte erlangen kann, die er im Normalfall nicht besitzt. So liefert ein Select * from Mitarbeiter where mitarbeiternr = ' Eingabe '; mit der Eingabe 3 geplant nur einen Mitarbeiter zurück. Wird als Eingabe aber ein ' or 1=1 – benutzt, wird aus dem Ursprünglichen Statement Select * from Mitarbeiter where mitarbeiternr = ' ' or 1=1 -- '; welches plötzlich alle Mitarbeiter zurückliefert.

Um SQL-Injections zu verhindern, sollten nie ungeprüfte, vom Benutzer eingegebene Werte verwendet und einfach in SQL-Statements eingesetzt werden. Stattdessen sollte auf prepared Statements gesetzt werden, bei denen geprüft wird, ob in dem Wert, bei dem eine Zahl erwartet wird, auch wirklich eine Zahl enthalten ist.

XSS – Cross-Site-Scripting

„Cross-Site-Scripting bezeichnet das Ausnutzen einer Computersicherheitslücke in Webanwendungen, indem Informationen aus einem Kontext, in dem sie nicht vertrauenswürdig sind, in einen anderen Kontext eingefügt werden, in dem sie als vertrauenswürdig eingestuft werden."

Ein solcher nicht vertrauenswürdiger Kontext kann ein Feld für eine Eingabe des Benutzers sein. In dieses könnte ein Angreifer Skripte eingeben, die dann bei anderen Benutzern Auswirkungen haben. Ein solches Skript kann im einfachen Fall ein <script>alert(„Dies ist ein XSS Angriff");<script> sein, was nur ein Popup mit dem Text "Dies ist ein XSS Angriff" erzeugt, kann aber auch dazu führen, dass Daten anderer Benutzer abgegriffen werden.

Damit dies nicht vorkommt, sollten Benutzereingaben nie ungeprüft übernommen oder angezeigt bzw. ausgeführt werden. Hat man alles richtig gemacht, so wird das Skript nicht ausgeführt, sondern einfach nur als Text angezeigt und hat so keine Wirkung.

Unsichere Teilkomponenten

Eine moderne Webanwendung besteht heutzutage aus einer Vielzahl von einzelnen Teilkomponenten. Dadurch haben wir nicht immer die volle Kontrolle über alle Teile der Anwendung, wodurch sich Sicherheitslücken auf verschiedenen Wegen einschleichen können.

So besteht eine moderne APEX-Anwendung aus dem APEX-Framework selber und der Datenbank, aber auch aus externen Komponenten wie z.B. jQuery. Zusätzlich können noch selbst entwickelte oder zugekaufte Bibliotheken dazukommen.

Durch die Menge der Teilkomponenten können wir nie sicher gehen, dass sich nirgendwo eine Lücke eingeschlichen hat, denn eine Kette ist immer nur so stark, wie ihr schwächstes Glied.

Fazit

Der Themenbereich Security ist ein großes Minenfeld, bei dem es viele Aspekte zu beachten gibt, die man nicht immer alle kontrollieren kann. So ist man auf Dinge anderer angewiesen und muss diesen vertrauen um ein Projekt zu starten. Man kann aber sein bestmöglichstes geben, um die Risiken zu minimieren und so klein wie möglich zu halten.

Für tiefergehende Informationen ist das "Open Web Application Security Project" zu empfehlen. Dabei handelt es sich um ein Team von Herstellern und Institutionen mit dem Ziel, die Sicherheit von Anwendungen und Diensten im Internet zu verbessern. Zu finden unter www.owasp.org.