von Karsten Möckel, Competence Center Oracle, IT-P GmbH

Das Thema IT-Security ist derzeit ein hochaktuelles Thema. Kaum vergeht ein Tag, an dem nicht eine Pressemitteilung bezüglich gefundener und ausgenutzter Sicherheitslücken in IT-Systemen erscheint. In diesem Zusammenhang wollen wir den Bereich Sicherheit von Webanwendungen etwas genauer betrachten.

Vorab muss allerdings eines klargestellt werden: 100%ige Sicherheit gibt es nicht! Das soll jedoch nicht bedeuten, dass man das Thema nun gänzlich außer Acht lässt. Man sollte immer darauf bedacht sein, seine Anwendung so sicher wie möglich zu machen und den Bereich Security am besten von Beginn an in den gesamten Entwicklungsprozess zu integrieren.

Folgende Fragestellung dient nun als Grundlage für die weitere Betrachtung: Welche Dinge sind bei der Entwicklung zu beachten, damit eine Webanwendung möglichst gut gegen potentielle Angriffe abgesichert ist?

Als Beispiel soll uns eine auf Basis von Oracle Application Express entwickelte Webanwendung dienen. Wir verwenden hier die Version 5.0 Early Adopter 1, die bereits als Preview verfügbar ist. Die nachfolgenden Hinweise sind prinzipiell aber auf jede Art von Webanwendung übertragbar - unabhängig davon, mit welcher Technologie sie entwickelt wurde. Lediglich bestimmte Lösungsvorschläge werden an den Features von Application Express und Oracle PL/SQL orientiert sein.

OWASP Top 10

Um den Rahmen dieses Artikels nicht zu überschreiten, werden wir uns auf wesentliche Aspekte im Web Security-Umfeld beschränken. Dafür verwenden wir die Top 10 Liste der "häufigsten Sicherheitsrisiken für Webanwendungen" des Open Web Application Security Project (OWASP) in der Version 2013. Es gibt noch weitere solcher Listen im Internet, an denen man sich ebenfalls orientieren kann, jedoch sind die OWASP Top 10 speziell für Webanwendungen besonders interessant.

In dieser Liste werden einige der kritischsten Risiken für ein breites Spektrum an Organisationen aufgezeigt. Dadurch soll man für das Thema Anwendungssicherheit sensibilisiert werden. Jedoch ist bei 10 noch lange nicht Schluss! Da es das OWASP genauso sieht, stellt es auf seiner Website weitere Informationen bereit.

Was sind Sicherheitsrisiken für Webanwendungen?

Innerhalb einer Webanwendung gibt es potentiell verschiedene Wege, die ein möglicher Angreifer nutzen kann, um z.B. einen wirtschaftlichen oder anderweitigen Schaden für ein Unternehmen zu verursachen. Diese Wege können bezüglich Einfachheit der Ausnutzbarkeit bzw. Schwere eines möglichen Schadens durchaus variieren. Jedoch stellt jeder dieser Wege ein Sicherheitsrisiko dar, dem unter Umständen besondere Aufmerksamkeit geschenkt werden sollte.

Die Bewertung der Risiken und die Ableitung möglicher Handlungsweisen haben individuell zu erfolgen und sind von Anwendung zu Anwendung sowie von Unternehmen zu Unternehmen unterschiedlich.

Werden wir nun konkret und schauen uns die Top 10 Risiken im Detail an.

A1 - Injection

"Injection-Schwachstellen, wie beispielsweise SQL-, OS- oder LDAP-Injection treten auf, wenn nicht vertrauenswürdige Daten als Teil eines Kommandos oder einer Abfrage von einem Interpreter verarbeitet werden. Ein Angreifer kann Eingabedaten dann so manipulieren, dass er nicht vorgesehene Kommandos ausführen oder unautorisiert auf Daten zugreifen kann." (OWASP)

Eine Injection-Schwachstelle beinhaltet demnach zwei Komponenten:

1. Zum einen wird z.B. eine SQL-Abfrage oder ein Betriebssystem-Kommando dynamisch aufgebaut, um später vom entsprechenden Interpreter ausgeführt zu werden.
2. Zum anderen sind Daten erforderlich, die in die dynamisch erzeugte Abfrage (oder den Befehl) integriert werden sollen, um einen bestimmten Zweck zu erfüllen.

Betrachten wir beispielhaft die SQL-Abfrage

select * from EMP where deptno = '&P1_DEPTNO.'

Die Tabelle EMP beinhaltet Angestellte, die bestimmten Abteilungen zugeordnet sind (über DEPTNO). P1_DEPTNO stellt ein Seitenelement in Application Express dar und entspricht einem Eingabefeld innerhalb eines Formulars. Hier finden sich die beiden Komponenten der Injection-Schwachstelle wieder:

1. Die SQL-Abfrage, die dynamisch aufgebaut wird, um auf alle Angestellten einer bestimmten Abteilung einzuschränken.
2. Die Daten, die in diesem Beispiel von der Benutzereingabe ungeprüft in die Abfrage integriert werden.

Über eine Eingabe wie

' or 1=1 --

kann sich ein potentieller Angreifer nun ganz einfach alle Angestellten anzeigen lassen. Auch die, für die er unter Umständen keine Berechtigung besitzt. Über Erweiterungen der Eingabe können vielleicht sogar Datenbankbenutzer und ähnlich sensible Daten angezeigt werden. Sind auch bei Verwendung anderer DML-Befehle Schwachstellen vorhanden, so können z.B. auch gezielt Daten manipuliert werden.

Eine wichtige Empfehlung lautet daher:

Prüfen Sie immer alle Eingaben, die von außen in die Anwendung kommen (wie z.B. Benutzereingaben), bevor Sie diese im weiteren Programmverlauf verwenden.

Die zweite Empfehlung im Zusammenhang mit SQL-Abfragen lautet:

Verwenden Sie BIND-Variablen bei dynamischen Daten.

select * from EMP where deptno = :P1_DEPTNO

Dadurch kann die Struktur des Befehls nicht mehr verändert werden. Die Datenbank analysiert die Struktur der Abfrage und führt erst danach die Ersetzung der Variablen durch deren Inhalt aus.

Weitere Details zum Thema SQL Injection finden Sie im Community-Artikel Schutz vor "SQL Injection": So bleibt Ihre APEX-Anwendung sicher!

A2 - Broken Authentication and Session Management

"Anwendungsfunktionen, die die Authentifizierung und das Session Management umsetzen, werden oft nicht korrekt implementiert. Dies erlaubt es Angreifern, Passwörter oder Sessiontoken zu kompromittieren oder die Schwachstellen so auszunutzen, dass sie die Identität anderer Benutzer annehmen können." (OWASP)

Korrekte Benutzerauthentifizierung und Session Management sind durchaus komplexe Themen, d.h. es gibt viele Punkte zu beachten, um Schwachstellen in der Implementierung zu vermeiden:

• Übertragung von Login-Daten
• Validierung von Benutzerdaten wie Accountnamen, Passwörtern, Tokens, usw.
• Verwendung von Cookies, Session-IDs, um einen angemeldeten Benutzer über mehrere Seitenaufrufe hinweg zu identifizieren (denn HTTP ist ein zustandsloses Protokoll und die Session-ID müsste bei jedem Aufruf mitgesendet werden)
• Implementierung von Sessionverwaltung und Timeouts
• ...

Dies sind jedoch gängige Problemstellungen, die in der Praxis bereits lange bekannt sind. Es gibt also bereits Lösungen für verschiedenste Technologien, die sich im produktiven Einsatz als praxistauglich erwiesen haben. Man muss und sollte hier das Rad nicht neu erfinden.

Die Empfehlung lautet hier: Sofern die eingesetzte Technologie Standard-Mechanismen für Authentifizierung und Sessionverwaltung zur Verfügung stellt, sind diese einer individuellen Implementierung vorzuziehen. Machen bestimmte Ziele dennoch eine Eigenentwicklung erforderlich, so sollte man sich an bestehenden Frameworks orientieren.

Nach Möglichkeit sollte für Webanwendungen SSL/TLS eingesetzt werden, um die Kommunikation zwischen Client und Server zu verschlüsseln und damit die Übertragung von Login- und Session-Daten abzusichern.

Appplication Express unterstützt von Haus aus verschiedene Wege zur Benutzerverwaltung und bietet bereits Funktionalitäten für das Session Handling:

• Unterschiedliche Authentication Schemes für Benutzerverwaltung und Authentifizierung über Application Express selbst, über Datenbankbenutzer, LDAP, SSO, ...
  
  Abbildung 1: Authentication Schemes in Application Express
• Plug-in Mechanismus für individuelle Authentifizierungsmethoden: Man muss nur die Prüfung der Benutzerdaten implementieren. Alles andere wird weiterhin von Application Express übernommen.
• Anwendungsspezifische Konfiguration von Session Timeouts.
  
  Abbildung 2: Konfiguration von Session Timeouts
• After Login Application Process: Man kann Aktionen direkt nach erfolgreicher Anmeldung ausführen lassen, ohne in den Authentifizierungsprozess selbst eingreifen zu müssen.

A3 - Cross-Site Scripting (XSS)

"XSS-Schwachstellen treten auf, wenn eine Anwendung nicht vertrauenswürdige Daten entgegennimmt und ohne entsprechende Validierung und Kodierung an einen Webbrowser sendet. XSS erlaubt es einem Angreifer Scriptcode im Browser eines Opfers auszuführen und somit Benutzersitzungen zu übernehmen, Seiteninhalte zu verändern oder den Benutzer auf bösartige Seiten umzuleiten." (OWASP)

Das folgende Szenario soll eine konkrete XSS-Attacke verdeutlichen:

Ein potentieller Angreifer gibt über ein Eingabeformular der Anwendung JavaScript-Code ein. Diese Eingabe wird ohne weitere Validierung in einer Datenbank gespeichert.

Ein anderer Benutzer ruft diesen Datensatz ab, welcher - ebenfalls ohne zusätzliche Prüfung - im Browser des Benutzers angezeigt wird. Dabei werden nicht nur die Daten angezeigt, sondern auch der JavaScript-Code ausgeführt und so gelangt der Angreifer z.B. an Cookie und Session-ID des Benutzers.

Folgendes Vorgehen ist zu empfehlen:

• Prüfen Sie alle Benutzereingaben durch Positivlisten (Whitelists), so dass nur erlaubte Informationen von der Anwendung gespeichert werden.
• Maskieren Sie nicht vertrauenswürdige Zeichen/Texte für den jeweiligen Ausgabekontext (Escaping). So vermeiden Sie die Ausführung von JavaScript-Code, da dieser vom Client-Browser nur noch als Text erkannt wird.

Application Express führt standardmäßig eine Maskierung von Sonderzeichen durch, wenn für die betroffenen Komponenten eine entsprechende Konfiguration eingestellt ist. Folgende Punkte sind dabei zu beachten:

• Reports, die über die Assistenten angelegt werden, sind durch den Spaltentypen Plain Text per Default abgesichert. Hier wird vor der Darstellung ein Escaping durchgeführt.
  
  Abbildung 5: Spaltentypen Plain Text
• Seitenelemente, die der reinen Textanzeige dienen, sollten als Elementtyp Display Only Item definiert werden, damit ebenfalls eine automatische Sonderzeichen-Maskierung erfolgt.
  
  Abbildung 6: Elementtyp Display Only
• Generell sollte in den Security-Eigenschaften immer das Maskieren von Sonderzeichen aktiviert sein.
  
  Abbildung 7: Escaping von Sonderzeichen
• Im Fall von selbst angelegten PL/SQL Regionen, in denen eine Ausgabe erzeugt wird, muss der Entwickler selbst ein entsprechendes Escaping durchführen. Die Oracle Datenbank bietet hier u.A. die PL/SQL Funktion SYS.HTF.ESCAPE_SC an.

A4 - Insecure Direct Object References

"Unsichere direkte Objektreferenzen treten auf, wenn Entwickler Referenzen zu internen Implementierungsobjekten, wie Dateien, Ordner oder Datenbankschlüssel von außen zugänglich machen. Ohne Zugriffskontrolle oder anderen Schutz können Angreifer diese Referenzen manipulieren, um unautorisiert Zugriff auf Daten zu erlangen." (OWASP)

Master-Detail-Ansichten sind ein gutes Beispiel für die Verwendung direkter Objektreferenzen. In der Masteransicht hat man eine Übersicht aller Datensätze und kann darin einen auswählen, um zur Detailansicht zu gelangen. Der ausgewählte Datensatz muss dabei eindeutig identifiziert werden können. In Application Express ist dieser Fall häufig als Kombination aus Bericht und Formular implementiert. Die Referenzierung der Detail-Datensätze erfolgt meist über Primary Key-Spalten.

Werden diese IDs per URL übergeben, so könnte ein potentieller Angreifer auf die Idee kommen, die ID direkt in der URL zu ändern. Sofern keine weiteren Schutzmechanismen implementiert sind, bekommt der Angreifer möglicherweise auch Detail-Datensätze angezeigt, für die er keine Berechtigung besitzt.

• Es ist zu empfehlen, direkte Objektreferenzen zu entfernen und stattdessen Mappings zu verwenden. Die Primary Keys könnten z.B. auf zufällig generierte Werte abgebildet werden.
• Zusätzlich ist die Zugriffsberechtigung auf das angeforderte Objekt auch auf Serverseite zu prüfen.
• Die Manipulation von URL-Parametern kann durch den Einsatz von Prüfsummen (Checksums) verhindert werden.

Application Express bietet in diesem Bereich folgende Möglichkeiten:

• Zur Identifizierung von Detail-Datensätzen kann statt des meist numerisch hochgezählten Primärschlüssels eine UUID (SYS_GUID) verwendet werden. Es handelt sich dabei zwar immer noch um eine direkte Referenz, die jedoch nicht einfach zu erraten ist.
• Zur Prüfung der Zugriffsberechtigungen sind sogenannte Autorisierungsschemata vorgesehen. Damit können tatsächliche Berechtigungsprüfungen implementiert werden, anstatt Seitenelemente einfach nur auszublenden.
• Um URL-Manipulationen zu vermeiden, bietet sich die Funktionalität Session State Protection an. Aus der URL inkl. Parametern wird ein Hashwert berechnet und an die URL angehängt. Serverseitig wird dieser Wert geprüft und bei Manipulation eine Fehlermeldung ausgegeben, statt die geänderten Werte einfach zu übernehmen.

Weitere Informationen zur Session State Protection finden Sie in folgendem Community-Artikel: So nutzt man die "APEX Session State Protection"

A5 - Security Misconfiguration

"Sicherheit erfordert die Festlegung und Umsetzung einer sicheren Konfiguration für Anwendungen, Frameworks, Applikations-, Web- und Datenbankserver sowie deren Plattformen. Alle entsprechenden Einstellungen müssen definiert, umgesetzt und gewartet werden, da sie meist nicht mit sicheren Grundeinstellungen ausgeliefert werden. Dies umfasst auch die regelmäßige Aktualisierung aller Software, inklusive verwendeten Bibliotheken und Komponenten." (OWASP)

Neben der Webanwendung selbst ist auch die Infrastruktur, auf der sie betrieben wird, kritisch unter dem Aspekt IT-Sicherheit zu prüfen. Die nach besten Sicherheitsstandards entwickelte Anwendung ist machtlos, wenn der ausliefernde Application Server nur so vor Sicherheitslücken strotzt.

Für verschiedenste Betriebssysteme und Application Server Plattformen gibt es eine große Anzahl an Hardening Guides im Internet sowie in gedruckter Form. Diese sollten bei der Implementierung der Infrastruktur Berücksichtigung finden.

Ein paar Details sollen dennoch aufgezählt werden:

• Die Datenbankbenutzer, die von der Webanwendung verwendet werden, sollten nur die notwendigsten Berechtigungen erhalten.
• Default-Benutzerkonten sollten deaktiviert werden.
• Application Server sollten in Fehlerseiten keine Details wie die Anwendungsversionen oder gar Stack Traces anzeigen.
• Anwendungen sollten sinnvolle Session Timeouts vorsehen.
• Die eingesetzte Software sollte mittels Patches aktuell gehalten werden.

Application Express bietet die Möglichkeit, Session Timeouts sowie bestimmte Sicherheitseinstellungen auf Applikationsebene zu konfigurieren.

In Produktionsumgebungen macht es außerdem Sinn, keine komplette Application Express Entwicklungsumgebung zu installieren, sondern stattdessen nur die Laufzeitumgebung. So können einfache Änderungen an der produktiven Anwendung vermieden werden. Weitere Manipulationen sowie die Preisgabe interner Anwendungsinformation lassen sich durch die folgenden Export-Einstellungen ebenfalls erschweren:

• Build Status Override: Run Application Only
• Debugging: No

A6 - Sensitive Data Exposure

"Viele Anwendungen schützen sensible Daten, wie Kreditkartendaten oder Zugangsinformationen nicht ausreichend durch Verschlüsselung oder Hashing. Angreifer können solche nicht angemessen geschützten Daten auslesen oder modifizieren und mit ihnen weitere Straftaten, wie beispielsweise Kreditkartenbetrug, begehen. Viele Anwendungen stellen die Vertraulichkeit und Integrität von sensiblem Netzwerkverkehr nicht durch entsprechende Verschlüsselung und Authentisierung sicher. Wird Verschlüsselung eingesetzt, werden oft schwache Algorithmen, abgelaufene oder ungültige Zertifikate verwendet oder falsch eingesetzt." (OWASP)

Folgende Empfehlungen sind zum Umgang mit sensiblen Daten zu nennen:

Wie bereits im Abschnitt zu Benutzerauthentifizierung und Sessionverwaltung beschrieben, sollte für Webanwendungen generell SSL/TLS als Transportverschlüsselung eingesetzt werden. Damit wird das Auslesen von Login-Daten während des Anmeldeprozesses verhindert.

Schützenswerte Informationen sind ausschließlich verschlüsselt zu speichern und zu übertragen. Zuerst ist es wichtig, alle Stellen zu ermitteln, an denen diese Informationen ausgetauscht oder abgelegt werden. Zur Realisierung der Anforderung können anschließend entsprechende Bibliotheken und Frameworks eingesetzt werden, die für verschiedene Technologien zur Verfügung stehen. Hier sollte ebenfalls gelten, bestehende Standards individuellen Lösungen vorzuziehen, da die Implementierung von Krypto-Algorithmen durchaus fehleranfällig sein kann. Zu berücksichtigen ist jedoch, dass man auch ein sinnvolles Schlüsselmanagement einrichten muss. Es nützt wenig, den zur Ver-/Entschlüsselung verwendeten Schlüssel gleich neben den gesicherten Daten abzulegen.

Sofern man eine eigene Login-Verwaltung mit Passworten realisiert, ist auf die richtige Speicherung der Informationen zu achten. Passworte sollten nie im Klartext persistiert werden, sondern immer nur über einen Passwort-Hash. Ebenso sollte in diesem Zusammenhang der Einsatz eines ausreichend zufälligen Salt verpflichtend sein.

In Application Express bietet sich die Möglichkeit, die Informationen im Session Kontext zu verschlüsseln. So können diese nicht mehr einfach im Klartext ausgelesen werden.

Die Oracle Datenbank bietet darüber hinaus entsprechende Hash- und Krypto-Implementierungen in Form von PL/SQL Funktionen an. Weitere Informationen dazu können Sie dem Community-Artikel Arbeiten mit DBMS_CRYPTO entnehmen.

A7 - Missing Function Level Access Control

"Viele Anwendungen realisieren Zugriffsberechtigungen nur durch das Anzeigen oder Ausblenden von Links oder Buttons. Allerdings muss auch beim direkten Zugriff auf eine geschützte URL eine Prüfung der Zugriffsberechtigung stattfinden, ansonsten können Angreifer durch gezieltes Manipulieren von URLs trotzdem auf diese zugreifen." (OWASP)

Ist einem potentiellen Angreifer also eine bestimmte URL in der Anwendung bekannt, mit der z.B. ein Funktionsaufruf auf dem Server ausgeführt wird, so kann er diese URL bei fehlender Berechtigungsprüfung direkt im Browser aufrufen.

Application Express bietet deshalb die Möglichkeit, Seiten- und Applikationselemente mit Autorisierungsschemata zu versehen. Hier können Prüfungen anhand verschiedenster Kriterien definiert werden. Diese Richtlinien sollten rollenbasiert sein, um die Menge überschaubar zu halten. Autorisierungsschemata können innerhalb der Shared Components zentral verwaltet werden.

Im Gegensatz zum reinen Ausblenden von Items und Schaltflächen bei der Anzeige können auch Server-Prozesse mit einem Autorisierungsschema versehen werden. Dadurch ist gewährleistet, dass die Berechtigung einer Funktionalität sowohl bei deren Anzeige im User Interface als auch bei der Ausführung auf Serverseite zunächst geprüft wird. Damit kann ein unautorisierter Zugriff auf URLs und Funktionen vermieden werden.

A8 - Cross-Site Request Forgery (CSRF)

"Ein CSRF-Angriff bringt den Browser eines angemeldeten Benutzers dazu, einen manipulierten HTTP- Request an die verwundbare Anwendung zu senden. Session Cookies und andere Authentifizierungsinformationen werden dabei automatisch vom Browser mitgesendet. Dies erlaubt es dem Angreifer, Aktionen innerhalb der betroffen Anwendungen im Namen und Kontext des angegriffen Benutzers auszuführen." (OWASP)

Ein möglicher Angreifer kann so z.B. einen Request erzeugen, der einen Geldtransfer vom Konto des Opfers auf das des Täters auslöst. Dieser Request wird in eine beliebige Webseite eingebettet - als Image-Tag, IFrame oder ähnliches. Besucht das Opfer nun diese manipulierte Webseite, während es zeitgleich an der verwundbaren Anwendung angemeldet ist, so wird der untergeschobene Request automatisch vom Browser und vermutlich unbemerkt vom Benutzer an die Anwendung gesendet - inkl. der Sessioninformationen. Damit ist der Request aber autorisiert und wird von der Anwendung verarbeitet.

Um CSRF zu verhindern, muss ein zufälliges, unvorhersagbares Token in die HTTP-Request-Response-Kommunikation integriert werden. Dieser Token wird bei Web-Anwendungen üblicherweise in die ausgelieferte Seite eingebettet und muss bei jeder Anfrage an die Anwendung wieder zurückgesendet sowie auf Serverseite geprüft werden. Ein Token sollte nach Möglichkeit für jeden Request einzigartig sein, zumindest aber für die aktive Session.

Zur Vermeidung von CSRF-Schwachstellen in Application Express ist die - bereits unter A4 erwähnte - integrierte Session State Protection zu aktivieren und für alle relevanten Anwendungsseiten zu konfigurieren.

Mit der Konfigurationseinstellung Prüfsumme auf Session-Ebene wird für jede neue Session ein zufälliger Token generiert. Dieser Token wird bei der Berechnung der URL-Prüfsummen mit einbezogen und sichert Requests dadurch gegen CSRF-Angriffe ab.

Bei der Verarbeitung muss der im Request mitgelieferte Token schließlich gegen den in der Datenbank vorgehaltenen Token validiert werden. Nur bei erfolgreicher Prüfung darf der Zugriff auf die eigentliche Funktionalität gewährt werden. Angreifer, die den Token nicht kennen, können mit ihrem manipulierten Request dann keine Anwendungsaktion mehr auslösen.

A9 - Using Components with Known Vulnerabilities

"Eingesetzte Anwendungskomponenten wie Programmbibliotheken, Frameworks und andere Softwaremodule werden meist mit umfassenden Berechtigungen ausgeführt. Wird eine anfällige Komponente verwendet und deren Schwachstelle ausgenutzt, so kann dies z.B. zu Datenverlust oder sogar der Übernahme des Application Servers führen. Werden Softwarekomponenten mit bekannten Schwachstellen innerhalb einer Anwendung eingesetzt, so kann dies zu einer ganzen Reihe möglicher Angriffe mit unterschiedlichsten Auswirkungen führen." (OWASP)

Die beste Empfehlung, sich vor diesem Risiko zu schützen, ist, alle eingesetzten Softwarekomponenten stets auf aktuellem Stand zu halten.

Zusätzlich sollten alle Abhängigkeiten einer Anwendung zu eingesetzten Frameworks und Komponenten bekannt sein. Im Falle von Application Express betrifft dies z.B.

• die eingesetzte Application Express Version selbst
• mitgelieferte (also intern verwendete) JavaScript-Bibliotheken (z.B. jQuery)
• vom Entwickler selbst eingebundene Bibliotheken
• möglicherweise benutzte Application Express Plug-Ins

Es empfiehlt sich, die eingesetzten Komponenten anhand öffentlicher Datenbanken oder der Projekt-Mailing Listen bzgl. Sicherheitsrisiken und neuer Versionen zu überwachen und geeignete Richtlinien zum Umgang mit Schwachstellen und möglichen Updates festzulegen.

A10 - Unvalidated Redirects and Forwards

"Viele Anwendungen leiten Benutzer auf andere Seiten oder Anwendungen um oder weiter. Dabei werden für die Bestimmung des Ziels oft nicht vertrauenswürdige Daten verwendet. Ohne eine entsprechende Prüfung können Angreifer ihre Opfer auf Phishing-Seiten oder Seiten mit Schadcode um- oder weiterleiten." (OWASP)

Ein Beispiel für Umleitungen wäre z.B. die Weiterleitung eines Benutzers auf verschiedene Seiten innerhalb der Web-Anwendung anhand einer vorher getroffenen Auswahl. Kann ein potentieller Angreifer diese Auswahl manipulieren, so kann er möglicherweise ohne vorherige Prüfung auf bestimmte Anwendungsteile zugreifen, für die eigentlich keine Berechtigung vorliegt.

In Application Express gibt es verschiedene Möglichkeiten, um Weiterleitungen/Umleitungen anzulegen. Branches (Verzweigungen) können verwendet werden, um z.B. nach der Verarbeitung auf andere Anwendungsseiten umzuleiten. Schaltflächen können ebenfalls direkte Umleitungen ausführen. Hier besteht immer auch die Option, statt einer Anwendungsseite eine URL anzugeben. Wird diese URL nun anhand von Seitenelementen - die der Benutzer mit Daten füllt - dynamisch konstruiert, so könnte hier die beschriebene Schwachstelle vorhanden sein.

Häufig wird auch eine "Zurück zur letzten Seite"-Funktionalität in Web-Anwendungen implementiert. Die vorangegangene Seite muss dann innerhalb des Session-Kontext gespeichert werden. Gelingt es, den hier abgelegten Wert zu verändern, so ist unter Umständen ein Zugriff auf nicht autorisierte Anwendungsteile möglich.

Fazit

Oracle Application Express bietet von Haus aus viele Möglichkeiten, um Web-Anwendungen möglichst sicher zu entwickeln. Einige Funktionen sind bereits standardmäßig aktiv, bei anderen muss der Entwickler darauf achten, dass er die zur Verfügung stehenden Optionen auch verwendet.

Dieser Artikel kann natürlich nur einen groben Überblick über die bestehenden Risiken und die nötigen Schutzmaßnahmen geben. Nachdem Sie aber hier den Einstieg in das Thema Security gefunden haben, findet sich eine Fülle an weiterführenden Informationen im Internet. Zu einzelnen Aspekten gibt es bereits Artikel in diesem Forum und weitere werden folgen. Die Website des OWASP ist ebenfalls als Anlaufpunkt zu empfehlen. Entsprechende Links finden Sie im Folgenden.

Quellen und Links

Oracle Application Express 5.0 Early Adopter 1
Open Web Application Security Project (OWASP)
OWASP Top 10
CWE/SANS TOP 25 Most Dangerous Software Errors

Community-Artikel:
Sichere Application Express-Anwendungen: Einige Tipps
Schutz vor "SQL Injection": So bleibt Ihre APEX-Anwendung sicher!
So nutzt man die "APEX Session State Protection"
Arbeiten mit DBMS_CRYPTO

Zurück zur Community-Seite