Wie sicher ist Oracle‘s Webentwicklungstool? - Oracle Application Express auf dem Security-Prüfstand

Im Großen und Ganzen sicher, aber...

Oracle APEX ist von Hause aus sicher konfiguriert und entwickelt worden. Sofern man diese Konfigurationen beibehält und in manchen Punkten (wie beispielsweise Autorisierungsschemata) gegebenenfalls noch etwas nachjustiert, bringt Oracle APEX keine Bedrohungen für Ihre Daten mit sich.

Doch sobald Applikationen über den Standard hinausgehen und die Entwickler die vorgefertigten Wege von Oracle APEX verlassen, sind sie selbst gefragt, dieses Sicherheitsniveau beizubehalten. Arbeiten die Entwickler hier nicht gewissenhaft, kommt es schnell zu Schwachstellen, die ein großes Schadenspotenzial bieten und mittels einfachster Werkzeuge auszunutzen sind. Hierbei handelt es sich um zwei Schwachstellen, die in der Webentwicklung bereits lange bekannt sind. Dennoch treten sie durch nachlässige Entwicklung leider immer wieder auf. Die Rede ist von SQL-Injection und Cross-Site-Scripting. In diesem Artikel möchte ich diese Schwachstellen kurz vorstellen und exemplarisch zeigen, was für ein Schadenspotenzial sie mit sich bringen. Anschließend möchte ich erläutern, welche Fehler man bei der Entwicklung von APEX-Applikationen begehen kann, durch die diese Schwachstellen auftreten. Zudem wird erläutert, wie man sich vor diesen Schwachstellen schützen kann.

SQL-Injection

Bei der SQL-Injection kann von einem Nutzer Code an ein SQL-Statement oder eine Abfrage angehängt werden. Somit können nicht vorgesehene Kommandos ausgeführt werden oder es kann unautorisiert auf Daten zugegriffen werden. In Web-Applikationen treten SQL-Injection-Schwachstellen in verschiedenen Konstellationen auf. Alternative 1 ist, dass sie durch die Verwendung von Substitutionsvariablen in SQL-Statements eintreten. So kann beispielsweise bei dem folgenden Statement, das hinter der Suche für eine Sucheingabe steht

SELECT *
FROM ABTEILUNGEN
WHERE ABTEILUNGSNR='&Abteilungsnummer.' AND ABTEILUNGSNR!=
1
; 

durch die Eingabe von

' OR 1=1 –- 

das Statement so manipuliert werden, dass alle Datensätze der Tabelle Abteilungen – einschließlich der Datensätze mit der Abteilungsnummer 1 – angezeigt werden. Und das, obwohl nur die Datensätze einer Abteilung angezeigt und die Datensätze mit der Abteilungsnummer 1 niemals ausgegeben werden sollten.

Um dieses Verhalten beim Ausführen des Statements zu veranschaulichen, wird die Substitutionsvariable durch die Eingabe ersetzt.

SELECT *
FROM ABTEILUNGEN
WHERE ABTEILUNGSNR='' OR 1=1 -- ' AND ABTEILUNGSNR!=1
; 

Nun ist zu sehen, dass nach einer leeren Abteilungsnummer oder nach allen Zeilen (1 = 1) gesucht wird. Somit werden alle Zeilen selektiert. Zudem ist zu erkennen, dass die folgende Bedingung, dass nur Zeilen ausgegeben werden sollen, in denen die Abteilungsnummer nicht gleich 1 ist, auskommentiert wurde.

Um Variablen in SQL-Statements verwenden zu können, ohne die Gefahr von SQL-Injection eingehen zu müssen, sollten Bind-Variablen genutzt werden.

Der Inhalt einer Bind-Variable wird automatisch vom JDBC-Driver maskiert, sodass dieser automatisch als Nutzereingabe erkannt wird. Zudem wird der Inhalt von Bind-Variablen erst nach dem Parsen des SQL-Statements ausgelesen. Eine Bind-Variable definiert sich durch das Anführen mittels eines Doppelpunktes wie in dem folgenden SQL-Statement zu sehen:

SELECT *
FROM ABTEILUNGEN
WHERE ABTEILUNGSNR=:Abteilungsnummer AND ABTEILUNGSNR!=
1
; 

Bei Alternative 2 können SQL-Injection-Schwachstellen durch dynamische SQL-Statements entstehen, in denen aus verschiedenen Gründen keine Bind-Variablen genutzt werden.

In diesem Fall sollten alle Nutzereingaben mittels des PL/SQL-Paketes dbms_assert geprüft werden, um sich vor SQL-Injection-Angriffen zu schützen. In Oracle-APEX-Applikationen ist die Gefahr von SQLInjection-Schwachstellen sehr hoch, da diese, sobald sie über den normalen Standard hinausgehen, auf sehr viel SQL- und PL/SQL-Code zurückgreifen, der von den Entwicklern stammt.

Zudem ist es sehr schwer, Applikationen auf SQLInjection-Schwachstellen zu prüfen, da Oracle APEX an vielen verschiedenen Stellen die Möglichkeit bietet, SQL und PL/SQL-Code zu implementieren. Daher müssen die Entwickler hier sehr gewissenhaft arbeiten.

Cross-Site-Scripting

Cross-Site-Scripting ist eine Angriffsmethode, bei der ein Nutzer die Möglichkeit hat, eigenen Quelltext in eine Webseite zu injizieren, sodass er vom eigenen Browser und von den Browsern anderer Nutzer ausgeführt wird. Möglichkeiten, dieses zu tun, gibt es viele. So kann ein Nutzer beispielsweise ein Gästebuch oder die Kommentarfunktionen nutzen, um Quelltext dauerhaft in einer Webseite unterzubringen. Werden die Nutzereingaben nicht maskiert, so wird der vom Angreifer eingegebene Schad-Code vom Browser interpretiert und nicht als Text angezeigt.

Dieses Vorgehen wird häufig genutzt, um Nutzer von Webseiten anzugreifen. Dabei sind beispielsweise Session- oder Anmelde-Informationen das Ziel der Angreifer. Es bietet aber auch die Möglichkeit, Inhalte und Funktionen freizuschalten, die für den Angreifer und andere Nutzer nicht vorgesehen sind. Eine weitere Möglichkeit, einen solchen Angriff umzusetzen, ist beispielsweise das Manipulieren von URLs, sodass der injizierte Quelltext nur lokal bei dem Angreifer ausgeführt wird. So hat der Angreifer beispielsweise die Möglichkeit, sich Inhalte oder Funktionalitäten freizuschalten, die nicht für ihn vorgesehen sind.

Letztere Möglichkeit bietet sich in Oracle APEX allerdings nicht so einfach an, da die URLs von Oracle APEX-Applikationen standardmäßig mit einer Checksumme versehen sind (Session State Protection). Diese verhindert zudem URL-Tampering-Angriffe sowie Cross-Site-Request-Forgery-Angriffe.

In Oracle Application Express bietet sich der Angriffsvektor wie folgt: Ein Angreifer kann Schad-Code über Eingabemasken in der Datenbank speichern, der später von einer Oracle-APEX-Applikation ausgelesen wird und beispielsweise in Reports dargestellt wird.

Die Option Escape Special Characters in Oracle APEX schützt davor, dass ein solcher Code ausgeführt wird. Diese ist standardmäßig auf YES gesetzt (siehe Abbildung 1).

In der Praxis kommt es jedoch häufig vor, dass diese Funktion deaktiviert wird. Das passiert meist durch das berühmte „..nur einmal kurz etwas ausprobieren.." und anschließend wird die Funktion nicht mehr aktiviert.

Ein weiteres Beispiel für das Ausschalten der Funktion Escape Special Characters aus der Praxis ist das „Aufhübschen" der Datenausgabe im SQL durch die Verwendung von HTML. Das folgende Statement stammt in abgewandelter Form aus einem Oracle-APEX-Sicherheitscheck und soll dieses Beispiel veranschaulichen.

SELECT adresse || '
' || plz || '' || ort
FROM kunden
WHERE id=:kunden_nr
; 

Anfällig für solche Angriffe sind nicht nur Reports, sondern ALLE Elemente, die Daten der Datenbank in HTML anzeigen.

Da Oracle APEX eine breite Masse solcher Elemente anbietet, ist eine nachträgliche manuelle Kontrolle einer Applikation je nach Größe der Applikation sehr komplex und somit sehr fehleranfällig. Daher sollte darauf geachtet werden, dass diese Funktion niemals geändert wird, um eine solche Schwachstelle auszuschließen.

Die Einstellung der Funktion Escape Special Characters wird im Data-Dictionary zu den einzelnen Elementen, die in Oracle APEX genutzt werden können, gespeichert.

Dieses bietet die Möglichkeit, mittels eines SQL-Statements alle Elemente der Applikation auszugeben, bei denen die Einstellung dieser Funktion auf „NO" steht. Somit können alle Cross-Site-Scripting-Schwachstellen in einer Applikation gefunden werden.

Fazit

Um SQL-Injection-Schwachstellen zu vermeiden, muss der Entwickler bei der Entwicklung von SQL-Statements und PL/SQL-Funktionalitäten sehr gewissenhaft arbeiten.

Hier muss der Entwickler darauf achten, dass Nutzereingaben ausschließlich mit Bind-Variablen in SQL und PL/ SQL Code eingebaut werden. Sollte die Verwendung von Bind-Variablen nicht möglich sein, so müssen Nutzereingaben mittels des PL/SQL-Paketes „dbms_assert" geprüft werden.

Cross-Site-Scripting Schwachstellen sind durch die APEXStandardkonfiguration vorerst nicht möglich. Um eine solche Schwachstelle in einer APEX-Applikation zu verursachen, muss der Entwickler die Funktion Escape Special Characters auf „NO" setzen. Daher ist zu raten, dieses niemals zu tun.

Links

[1] Bundesamt für Sicherheit in der Informationstechnik: G 5.170 - Cross-Site Scripting (XSS)
https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/g/g05/g05170.html

[2] Bundesamt für Sicherheit in der Informationstechnik: G 5.131 - SQL-Injection
https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/g/g05/g05131.html