OWASP und APEX Eine Einführung Sebastian Wittig Systementwickler merlin.zwo InfoDesign GmbH & Co. KG 76228 Karlsruhe
Spitzenleistung heißt, sich auf seine Stärken zu konzentrieren. merlin.zwo Wir machen Oracle - nur Oracle. Aus gutem Grund. www.merlin-zwo.de
Übersicht Motivation OWASP, was ist das denn? Wie entwickeln sich Risiken? Top 10 Ausprägungen und Gegenmaßnahmen Fazit & Tipps
Motivation
Motivation Die meisten APEX-Instanzen sehen wie folgt aus: Browser Webserver Appserver Abweichungen im Middle Tier sind möglich APEX- DB
Motivation Dieser Ansatz eröffnet viele Möglichkeiten: HTML-Frontend bietet Zugriff auf viele Webtechnologien (CSS, JavaScript, jquery, [ ]) DB-Backend ermöglicht die Nutzung von SQL und PL/SQL Das Middle Tier bietet weitere anbieterabhängige Verwundbarkeiten Durch alle Bereiche entstehen Angriffsoptionen
OWASP, was ist das denn?
Was ist OWASP? OWASP: Open Web Application Security Project Offenes Gremium aus Informatikern weltweit Vertreten starke, offene Kernwerte und prinzipien Diskutieren intern über Code Richtlinien, Best Practices, [ ] Stellen Anleitungen zur Verfügung Veröffentlichen in regelmäßigen Abständen eine Liste der größten Bedrohungen für Webapplikationen
Warum ist diese Offenheit etwas Gutes? Es ist überheblich anzunehmen, dass man selbst jeden möglichen Angriffspunkt zu jedem Zeitpunkt im Blick hat. 100% Sicherheit gibt es nicht. Mitunter schaffen Sicherheitsprodukte ihrerseits Sicherheitslücken. Security through obscurity ist leider Blödsinn.
Warum sollte man sich damit befassen?
Warum geht mich das an? APEX wird häufig für inhäusige Anwendungen genutzt, die nicht im Netz stehen, aber: Technisch versierte Nutzer können Verwundbarkeiten ausnutzen um unberechtigten Datenzugriff zu erhalten BYOD Geräte können infiziert sein und diese Infektion weitertragen Zugriffe auf das Firmennetz mit Privatgeräten können kompromittiert sein Manche APEX-Anwendungen sind öffentlich zugänglich
Wie entwickeln sich diese Risiken?
OWASP Top 10 2007 vs 2010
OWASP Top 10 2010 vs 2013
OWASP Top 10 2013 vs 2017
Was könnten wir lernen? Betrachten wir die Listen im Vergleich, dann könnten wir mutmaßen: Sind Entwickler lernresistent? Sind Herausforderungen zur Absicherung nicht handhabbar? Bieten Frameworks zu wenig Unterstützung? Besser: Risiken verhalten sich relativ zeitstabil. => Folglich lohnt sich jede Investition in Sicherheit und Knowhow
Top 10 Ausprägungen und Gegenmaßnahmen
#1 Injections https://imgs.xkcd.com/comics/exploits_of_a_mom.png Injections können offensichtlich sein. Manche sind dagegen schwieriger zu erkennen, wie folgende Folie beweist:
http://tkyte.blogspot.de/2012/02/all-about-security-sql-injection.html
#1 Injections Wann tritt eine Injection auf? Dynamischer Befehl (SQL, OS, LDAP) Ungeprüftes Konkatenieren von Parametervariablen Wie schütze ich mich? Verwenden Sie Bindevariablen, wann immer es möglich ist Meiden Sie Variablen in der Ampersand-Notation. Diese werden ungeprüft weitergegeben Überprüfen Sie dynamische Parameter mittels DBMS_ASSERT
#2 Broken Authentication and Session Management Wann bin ich verwundbar? Unverschlüsselte/schwache Passwörter Einfache Verfahren das Passwort zu überschreiben Session ID innerhalb der URL sichtbar Session ID kann mittels Session Fixation Angriffen attackiert werden Versand der Daten über unverschlüsselte Verbindungen
#2 Broken Authentication and Session Management Wie schütze ich mich? Nutzen Sie erprobte Standardverfahren APEX bietet eine breite Auswahl guter Standardimplementierungen Session Handling ist APEX-seitig (trotz sichtbarer Session ID) bereits umgesetzt, z.b. auch Timeouts Versenden Sie Daten über eine SSL-Verschlüsselung Session Hijacking ist durch XSS-Attacken besonders leicht.
#3 Cross Site Scripting (XSS) Wie werde ich verwundbar? Eingegebene Texter werden nicht geprüft Der Text wird anschließend unescaped dargestellt Unsicheres JavaScript durch eingebundene Bibliotheken Durch Dateiupload eingefügtes JS
#3 Cross Site Scripting (XSS) Wie schütze ich mich? Escapen von eingegebenen und wiedergegebenen Textfeldern z.b. mit apex_util.escape_html Rückgriff auf die APEX-eigenen Optionen zum Escapen von Steuerungszeichen Display Only Items
#4 Broken Access Control Kombiniert die bisherigen Punkte Datenzugriffe und unsichere Objektreferenzen. Wann bin ich verwundbar? Master-Detail Ansichten mit numerisch aufsteigendem Primary Key Public Functions, die innerhalb von APEX zur Verfügung gestellt werden
#4 Broken Access Control Wie schütze ich mich? Rückgriff auf Mapping oder UUID Prüfsummen per Session State Protection aktivieren Autorisierungsschemata definieren und innerhalb der Anwendung großzügig verwenden Keine Funktionen zur Verfügung stellen, die den Status des Anwenders nicht überprüfen
#5 Security Misconfiguration Wann bin ich verwundbar? Veraltete Architekturkomponenten Standardkonfigurationen werden ungeprüft übernommen Default Accounts nicht deaktiviert (siehe Mongo DB) Error Stacks mit sensiblen Informationen für den Anwender sichtbar
#5 Security Misconfiguration Wie schütze ich mich? Datenbankschemata nur die nötigsten Berechtigungen geben Deaktivieren aller nicht benötigten Accounts keine Stack Traces nach außen gelangen lassen Session Timeouts Patchen
#6 Sensitive Data Exposure Dieser Punkt gewinnt vor allem vor den neuen Datenschutzregelungen an Relevanz: Sensible Daten im Klartext vorhanden Sind diese nötig? Gibt es Möglichkeiten diese verschlüsselt zu nutzen? Unverschlüsselte Übertragung über das WWW Veraltete Verschlüsselungsalgorithmen Werden alle nötigen Headerinformationen übertragen?
#6 Sensitive Data Exposure Wie schütze ich mich? Kommunikation verschlüsseln Authentifizierung Übertragene Daten Standardalgorithmen vor Eigenentwicklungen Schlüsselablage sinnvoll organisieren Salt & Pepper implementieren Daten im Session State verschlüsseln
#7 Insufficient Attack Protection Wie äußert sich die Verwundbarkeit? Keine Implementierung für den Angriffsfall Erkennung Behandlung Blockierung Manuell oder automatisiert durch Tools testen Außerdem sollte man die Grenzen dieser Tools kennen
#7 Insufficient Attack Protection Wie schütze ich mich? Erkennen von Angriffen Beobachten von ungültigen Zuständen Verhaltensmuster analysieren und bewerten Auf Angriffe reagieren Blocken von Requests, IP Adressen oder IP Bereichen Deaktivieren auffälliger Accounts Zeitnah patchen, insbesondere wenn Verwundbarkeiten bekannt werden
#8 Cross-Site Request Forgery (CSRF) Wann bin ich verwundbar? Schlechtes und unsicheres Tokenhandling Vorhersehbare Token Rückgriff auf mit dem Browser versendete Informationen (IP- Adresse, Session Cookies), da diese nicht fälschungssicher sind Ermöglicht das Einbetten von Requests in dritten, manipulierten Seiten Diese Requests greifen die ungenügend gesicherte Session auf und manipulieren im Namen des Nutzers Daten
#8 Cross-Site Request Forgery (CSRF) Wie schütze ich mich? Tokenhandling implementieren Prüfsummen per Session State Protection aktivieren Packages liefern Möglichkeiten eigene Links zu erzeugen Ohne korrekten Token wird ein Fehler geworfen
#9 Using Components with Known Vulnerabilities Wann bin ich verwundbar? Schwierig festzustellen, da viele Leaks erst mal unbekannt sind Manche werden stillschweigend gefixt Wie schütze ich mich? Alle Komponenten möglichst auf dem neuesten Stand halten. Also APEX, JS, Plugins Überwachung entsprechender Mailinglisten und Datenbanken
#10 Underprotected APIs Wann bin ich verwundbar? Rückgriff auf Schnittstellen, insbesondere externe Exotische, nicht gut dokumentierte und standardisierte Formate, diese bieten selten Frameworks Wie schütze ich mich? Kommunikation verschlüsseln Authentifizierung und Autorisierung für APIs Berücksichtigen Sie Schnittstellen in den Tests
Fazit & Tipps
Fazit Prinzipiell können einige, viele oder alle dieser Punkte zutreffen. Analysieren Sie, welche Angriffsszenarien für Ihre Anwendung relevant sind Beurteilen Sie diese Szenarien mit einer Risikogewichtung Lernen Sie die Thematik kennen, Einstiegspunkte sind bspw.: OWASP Developer Guide OWASP Cheat Sheets Beschäftigen Sie sich mit Tools: APEX-spezifisch: ApexSec
Tipps Implementieren Sie Security frühzeitig Schaffen Sie Regeln für Fälle, in denen Sie nicht den sicheren Weg gehen können Nutzen Sie Standardalgorithmen, wo immer es geht Verschlüsseln Sie die Kommunikation mittles HTTPS Patchen Sie Ihre Systeme Hören Sie nicht bei der Top 10 auf
Fragen und Antworten??? Haben Sie noch Fragen???? merlin.zwo InfoDesign GmbH & Co. KG Sebastian Wittig
merlin.zwo merlin.zwo InfoDesign GmbH & Co. KG Sebastian Wittig Elsa-Brändström-Straße 14 76228 Karlsruhe Tel. 0721 132096-44 sebastian.wittig@merlin-zwo.de http://www.merlin-zwo.de