Ein APEX-Link sieht oft harmlos aus: f?p=100:10:123456::NO::P10_ID:42. Trotzdem können Request-, Clear-Cache- oder Item-Argumente die Session State einer Anwendung beeinflussen. Werden Werte ungeprüft akzeptiert, kann ein Benutzer beispielsweise einen Datensatzkontext verändern oder interne Abläufe auslösen. Session State Protection (SSP) ist deshalb ein wichtiger Sicherheitsbaustein für jede Anwendung, die Parameter in URLs verwendet.
1. SSP auf Anwendungsebene aktivieren
Aktivieren Sie Session State Protection zunächst in den Shared Components der Anwendung. Danach konfigurieren Sie den Schutz pro Seite und pro Item. Die Seite bestimmt, ob URL-Argumente grundsätzlich erlaubt sind; das Item legt fest, welche Stärke für einen übergebenen Wert erforderlich ist.
2. Die richtige Schutzstufe wählen
Für Seiten mit Parametern ist „Arguments Must Have Checksum“ meist der sinnvolle Ausgangspunkt. Wenn eine Seite überhaupt keine URL-Argumente benötigt, ist „No Arguments Allowed“ strenger. „No URL Access“ eignet sich für Seiten, die nur über interne Branches oder Prozesse erreicht werden sollen.
Bei Items reichen die Stufen von „Unrestricted“ bis „Restricted: May not be set from browser“. Für fachlich oder sicherheitsrelevante Werte sollte der Browser den Session State nicht frei setzen dürfen. Beachten Sie auch die Kompatibilität: Enthält eine URL mehrere Items, muss die erzeugte Checksumme zur strengsten Schutzstufe aller übergebenen Items passen.
3. URLs mit APEX erzeugen
Hardcodierte f?p=-Strings sind fehleranfällig, sobald Seiten, Session State oder Checksum-Anforderungen hinzukommen. Verwenden Sie für neue PL/SQL-Links bevorzugt APEX_PAGE.GET_URL; die Funktion erzeugt eine navigierbare APEX-URL und berücksichtigt die notwendigen Sicherheitsinformationen. In älteren Anwendungen kann APEX_UTIL.PREPARE_URL weiterhin relevant sein, Oracle empfiehlt für bessere Lesbarkeit jedoch APEX_PAGE.GET_URL.
APEX_PAGE.GET_URL(
p_page => 10,
p_items => 'P10_ID',
p_values => l_ticket_id
)Prüfen Sie danach im Browser bewusst, was passiert, wenn ein Parameter entfernt, verändert oder ergänzt wird. Eine Fehlermeldung oder verweigerte Navigation ist in diesem Fall ein gewünschtes Ergebnis.
4. Sicherheit testen und im Team verankern
- Alle Seiten mit Request-, Clear-Cache- oder Name/Value-Argumenten identifizieren.
- Für jedes übergebene Item klären, ob es wirklich aus dem Browser gesetzt werden darf.
- Links aus Reports, Buttons und Branches auf generierte statt zusammengesetzte URLs umstellen.
- Mit einem Testbenutzer manipulierte Parameter prüfen und die Anwendung auf unerwartete Datenzugriffe beobachten.
Fazit
Session State Protection ist kein Ersatz für Authorization Schemes oder serverseitige Prüfungen. Es verhindert aber eine häufige Fehlerklasse: dass URL-Argumente ohne gültige Integritätsprüfung Session State verändern. Wer Seitenschutz, Item-Schutz und URL-Erzeugung gemeinsam betrachtet, bekommt eine deutlich robustere APEX-Navigation – und kann Sicherheitsentscheidungen im Team nachvollziehbar dokumentieren.
Weiterführend: Oracle APEX 24.2: Preventing URL Tampering und die Dokumentation zu APEX_PAGE.GET_URL.