Sobald ein Blog-Posting, Artikel oder Buch sich dem Thema "Sicherheit" in APEX-Anwendungen widmet, findet sich recht schnell der Hinwies auf die APEX Session State Protection und dass man diese unbedingt nutzen sollte. Dieser Community Tipp stellt die Session State Protection (SSP) vor und zeigt, wie man als Entwickler damit umgeht.

Was ist Session State Protection?

Ausgangspunkt sei eine einfache APEX-Anwendung, bestehend aus einem Bericht und einem Formular. Bei Klick auf einen Eintrag im Bericht wird auf das Formular verzweigt (Abbildungen 1 und 2).

Die Verknüpfung zwischen Bericht und Formular findet (wie immer bei APEX), mit einem Link statt - die EMPNO, dessen Daten ins Formular geladen werden sollen, wird per APEX-URL-Syntax übergeben. Nun kann ein Anwender die URL allerdings manuell, direkt in der Browser-Adressleiste, verändern und damit auch andere Zeilen ins Formular laden - ohne über den Bericht zu navigieren. Und so ist es denkbar, dass Daten geladen werden, die der Anwender gar nicht sehen darf. Eben diese Möglichkeit des manuellen Veränderns der URL (URL Tampering) wird durch SSP verhindert.

Session State Protection einrichten

Navigieren Sie dazu zu den Gemeinsamen Komponenten und dort zum Schutz für den Session Zustand oder Session State Protection (Abbildung 3).

Zunächst erfahren Sie, ob SSP überhaupt aktiv ist (Abbildung 4) - dort sollte Deaktiviert stehen.

Mit einem Klick auf Schutz festlegen können Sie SSP aktivieren und für die Anwendung einrichten (Abbildung 5).

Ein Klick auf Aktivieren oder Deaktivieren schaltet SSP für diese Anwendung nur grundsätzlich ein oder aus. Da der SSP-Schutz jedoch auf Ebene der Seiten und der einzelnen Elemente konfiguriert wird, reicht das allein noch nicht aus. Klicken Sie daher auf Konfigurieren - dort kann SSP nicht nur aktiviert, vielmehr wird auch der Schutz für alle Anwendungsseiten und -Elemente eingerichtet (Abbildung 6).

Konfigurationsmöglichkeiten

Die hier vorgenommenen Einstellungen werden als "Initialkonfiguration" auf alle Elemente und alle Seiten angewendet. Für den SSP-Schutz einer Seite können Sie zwischen folgenden Varianten wählen:

• Uneingeschränkter Zugriff bedeutet, dass SSP für diese Seite nicht aktiv sein soll. Für die Initiale Einrichtung wählen Sie diese Option, wenn Sie SSP nur für wenige Seiten nutzen wollen. Da die hier gemachten Einstellungen auf alle Anwendungsseiten angewendet werden, schalten Sie SSP hier zunächst für alle Seiten ab und anschließend in den Seitenattributen der jeweiligen Seite wieder ein.
• Argumente müssen Prüfsumme haben ist sicherlich die am häufigsten gewählte Option. In diesem Fall erlaubt APEX die Parameterübergabe per URL, allerdings wird der URL eine Prüfsumme hinzugefügt, die auf der Zielseite validiert wird. Wird ein Parameter manuell geändert, stimmt die Prüfsumme nicht mehr und APEX löst eine Fehlermeldung aus.
• Keine Argumente zulässig bedeutet, dass APEX die Parameterübergabe per URL für diese Seite überhaupt nicht mehr erlaubt.
• Kein URL Zugriff bewirkt, dass die Seite per URL-Aufruf überhaupt nicht mehr erreichbar ist. Der einzige Weg, auf eine solche Seite zu gelangen, ist dann eine APEX Verzweigung nach einem Page Submit.

Wie schon gesagt, wird hier die Initialkonfiguration für alle Seiten vorgenommen. Jede Seite kann anschließend in den Seitenattributen umkonfiguriert werden. So ist es durchaus möglich, dass manche Anwendungsseiten ohne SSP arbeiten, andere verwenden die Prüfsumme und wieder andere erlauben keine Parameter. In Produktion sollte jede Seite so restriktiv wie möglich ausgestattet werden - wenn die Parameterübergabe per URL für eine Seite nicht nötig ist (weil keine Links darauf verzweigen), so sollte dies auch wirklich per SSP verboten werden.

Die nächsten drei Einstellungen nehmen die Initialkonfiguration zur Prüfsummenberechnung vor - und zwar für alle Anwendungselemente, für alle "normalen" Seitenelemente und für alle schreibgeschützten (Read Only) Seitenelemente. Auch hier gilt, dass jedes Element anschließend individuell angepasst werden kann.

• Uneingeschränkt bedeutet, dass dieses Element, obgleich dessen Seite mit SSP geschützt ist, dennoch per URL, die auf eine andere Seite zielt,, gesetzt werden kann. Um ein Element komplett zu schützen, muss also sowohl dessen Seite also auch das Element selbst geschützt werden.
• Prüfsumme auf Session-Ebene bedeutet, dass eine Prüfsumme auf Session-Ebene berechnet wird. In einer anderen Session ist die Prüfsumme nicht mehr gültig. Das bedeutet faktisch, dass der Link nicht mehr als Lesezeichen verwendet und auch nicht an andere Nutzer weitergegeben werden kann.
• Prüfsumme auf Benutzerebene bedeutet, dass eine Prüfsumme für den Anwendungsuser berechnet wird. Die Prüfsumme ist auch in einer anderen Session gültig - ein Link mit einer solchen Prüfsumme kann also als Lesezeichen verwendet werden, solange der gleiche Anwendungsuser ihn nutzt. Wird der Link per Email weitergesendet und meldet sich der Empfänger mit einem anderen Usernamen an, ist die Prüfsumme nicht mehr gültig.
• Prüfsumme auf Anwendungsebene bedeutet, dass die Links sowohl in verschiedenen Sessions als auch von verschiedenen Anwendungsnutzern genutzt werden können. Wenn Sie es den Anwendern ermöglichen möchten, einen Link auf ein Formular mit URL-Parameter und SSP-Prüfsumme zu teilen und als Lesezeichen zu nutzen, wählen Sie diese Option.
• Eingeschränkt: Darf nicht vom Browser festgelegt werden schließlich verbietet das Setzen jenes Elements per URL-Parameter vollständig.

Klicken Sie dann auf Weiter. Sie erhalten eine Zusammenfassung (Abbildung 7).

Mit Klick auf Fertig stellen wenden Sie die Änderung schließlich an. Sie gelangen wieder auf die Einstiegsseite der SSP-Konfiguration.

Auswirkungen der SSP

Navigieren Sie nun wieder zu ihrem Bericht und klicken Sie auf eine der Zeilen, um zum Formular zu gelangen - die Verzweigung wird nach wie vor funktionieren, nun sieht die URL aber etwas anders aus (Abbildung 9).

Abbildung 10 zeigt das Ergebnis des Versuchs, die EMPNO in der URL von Hand zu ändern ...

Reine Endanwender erhalten eine etwas andere, weniger technische, Fehlermeldung (Abbildung 11).

Nachträgliche Änderung der SSP Konfiguration

Wenn Sie zu den Seitenattributen navigieren, können Sie SSP im Bereich Sicherheit für jede Seite individuell konfigurieren (Abbildung 12).

Das gleiche gilt natürlich für das einzelne Element - auch dort kann die Einstellung im Bereich Sicherheit individuell vorgenommen werden (Abbildung 13).

Wird ein Link zu einer geschützten APEX Seite deklarativ erstellt, also im Bereich Link eines Berichts oder in Navigationslisten, so berücksichtigt APEX den SSP-Status automatisch - die Prüfsummen werden also automatisch korrekt hinzugefügt, ohne dass man sich als Entwickler darum kümmern muss. Wie Abbildung 14 zeigt, kann die Prüfsumme für einen Link sogar noch "verschärft" werden: Wenn bspw. beim jeweiligen Element hinterlegt ist, dass die Prüfsumme auf Ebene der Anwendung generiert werden soll (Links können dann als Lesezeichen verwendet und an andere Nutzer weitergegeben werden), so kann festlegt werden, dass ein Link auf Ebene des Benutzers generiert werden soll - dieser Link kann dann zwar noch als Lesezeichen gespeichert, nicht jedoch an andere weitergegeben werden.

SSP und "manuell" (mit SQL und PL/SQL) generierte URLs

Aufpassen müssen Entwickler bei URLs, die mit SQL und PL/SQL generiert werden - so kommt es recht häufig vor, dass ein Link nicht in den Spaltenattributen deklarativ, sondern programmatisch in der Berichtsabfrage generiert wird. Hier kann APEX die Prüfsumme nicht automatisch hinzufügen, der Entwickler muss das selbst tun. Erzeugen Sie als Beispiel einen neuen Bericht (auf einer neuen Seite) mit folgendem Berichts-SQL.

select
  ename,
  sal,
  'f?p='||:APP_ID||':3:'||:APP_SESSION||'::::P3_EMPNO:'||empno as link_url
from emp

Die Ziel-URL wird so im Berichts-SQL "zusammengebaut". Mit Hilfe von Berichts-Templates oder der Spaltenformatierung kann nun im Bericht dafür gesorgt werden, dass ein klickbarer Link entsteht - der allerdings so keine Prüfsumme enthält. Da die Zielseite jedoch per SSP geschützt ist, werden diese Links nicht funktionieren. Die Lösung ist die Funktion APEX_UTIL.PREPARE_URL. Eine per SQL oder PL/SQL generierte URL, die auf eine mit SSP geschützte Seite verweist, muss immer mit APEX_URIL.PREPARE_URL "vorbereitet" werden.

select
  ename,
  sal,
  apex_util.prepare_url(
    p_url => 'f?p='||:APP_ID||':3:'||:APP_SESSION||'::::P3_EMPNO:'||empno 
  ) as link_url
from emp

Auch die PREPARE_URL kennt den Parameter P_CHECKSUM_TYPE, mit dem Sie den Prüfsummentyp (Ebene der Session, des Nutzers oder der Anwendung) explizit setzen können. 'SESSION' meint dabei auf Ebene der Session, 'PRIVATE_BOOKMARK' ist die Ebene des Nutzers und 'PUBLIC_BOOKMARK' ist die Anwendungsebene.

Fazit

SSP schützt eine APEX-Anwendung recht effektiv vor ungewollten Parametern, die durch Manipulation der URL übergeben werden - Man kann generell die Empfehlung geben, SSP in einer APEX-Anwendung einzusetzen. Allein durch die Nutzung von SSP "zwingt man sich" als Entwickler, genau darüber nachzudenken, wie Parameter durch URL übergeben werden können, was gewollt ist und was nicht.

Beachten Sie als Entwickler auch stets, dass URL-Parameter nicht der einzige Weg sind, Werte an eine APEX-Anwendung zu übergeben. SSP ist in keinster Weise aktiv, wenn ein Formular abgesendet wird (Page Submit). Es schützt also nicht vor der Manipulation einer Auswahlliste in einem Formular (was im Browser ohne weiteres machbar ist). Auch bei intensiver Nutzung von SSP muss man als Entwickler allen übergebenen Werten gegenüber "misstrauisch" sein; vor der weiteren Verwendung in SQL, PL/SQL oder APEX sollten Sie daher immer nochmals überpüft werden (APEX Validations, PL/SQL, PL/SQL-Paket DBMS_ASSERT). In einer wirklich sicheren APEX-Anwendung, in der keine Komponente einer anderen traut, ist SSP eine von mehreren Maßnahmen.

Zurück zur Community-Seite