Schutz von Datenbanken vor fehlerhaften Webanwendungen

Transkript

1 Schutz von Datenbanken vor fehlerhaften Webanwendungen

2 Agenda 1. Problemstellung 2. Appliance zum Schutz von Webanwendungen 3. Prototyp 4. Ausblick Benjamin Große 2

3 Agenda 1. Problemstellung 2. Appliance zum Schutz von Webanwendungen 3. Prototyp 4. Ausblick Benjamin Große 3

4 Webanwendungen absichern gegen Insecure Direct Object References (OWASP TOP 10 A4) Insecure Direct Objekt References sind direkte Verweise auf interne Objekte OWASP Top 10 Platz #4 Bekannt gewordene Pannen: Citibank (2011) Kreditkarten-Informationen von 1% der Kunden wurden in Nordamerika entwendet IKEA (2000) Profildaten aller Onlinekunden waren frei zugänglich Benjamin Große 4

5 Unsere Forschung baut auf Ergebnissen der letzten Jahren auf 2007 Roichman und Gudes: Fine-grained access control to web databases 2011 Prijovic und Trommler (D-A-CH Security): Zugriffskontrolle in der Datenbank: Vamos eine Fallstudie 2012 Rossel, Große, Prijovic, Trommler (D-A-CH Security): Zugriffskontrolle in Webdatenbanken mit Query Rewriting Benjamin Große 5

6 Die Webanwendung kontrolliert den Datenzugriff Kontrolle Daten Komplexität Benjamin Große 6

7 Der Kontrollpunkt wird nahe an die Daten verschoben um die Komplexität zu verringern Kontrolle Daten zusätzliche Kontrolle Komplexität Benjamin Große 7

8 Die Webanwendung hat nur Zugriff auf benötigte Daten Benutzer A Benutzer B Benutzer C Cart_ID Product_ID Benjamin Große 8

9 Es entsteht eine Sandbox für die persönlichen Daten Benutzer A Cart_ID Product_ID Sandbox: Private Daten pro Benutzer Gruppen und Rollen Eingrenzung Unabhängig von der Rechtestruktur in der Webanwendung Benjamin Große 9

10 Agenda 1. Problemstellung 2. Appliance zum Schutz von Webanwendungen 3. Prototyp 4. Ausblick Benjamin Große 10

11 Webanwendungen werden abgesichert ohne Eingriffe in die Anwendung selbst Benjamin Große 11

12 Mit zwei Proxies wird die Anwendung umschlossen Benjamin Große 12

13 Aktionen sind atomare Zugriffe auf Webservices Benjamin Große 13

14 Aktionen sind atomare Funktionsblöcke der Webanwendung Aktionen: Sind atomare Zugriffe auf Webanwendungen Beginnen mit einem HTTP-Request Enden mit einem HTTP-Response Werden von einem Benutzer ausgelöst Benjamin Große 14

15 HTTP-Request-Response-Paare bilden die Kommunikation mit dem Browser GET/seitenbaum/fakultaeten/informatik/startseite/page.html HTTP/1.1 User-Agent: curl/ Host: Accept:*/* HTTP/ OK Date:Tue, 26 Mar :55:43 GMT Server:Apache X-Powered-By:PHP/5.3.3 Set-Cookie:fe_typo_user=26691d94cf50f74f45dcaa237f4fe3ff; path=/; httponly Cache-Control:private Transfer-Encoding:chunked Content-Type:text/html; charset=utf-8 Vary:Accept-Encoding Benjamin Große 15

16 Jeder HTTP-Request enthält den Benutzer und Parameter Benjamin Große 16

17 Jeder HTTP-Request enthält den Benutzer Benutzer lassen sich aus HTTP basic HTTP digest Formular-basierten Anmeldungen OpenID TLS (SSL) mit RSA-Schlüsseltausch TLS terminiert an der Appliance Benutzer lassen sich innerhalb von Sessions auf Basis von Cookies URL encoded Session-Ids Session-Ids als HTTP-Parameter extrahieren. wiedererkennen. Benjamin Große 17

18 SQL-Abfragen versorgen die Webanwendung mit den benötigten Daten Benjamin Große 18

19 Zu welchem Benutzer gehört die Datenbankabfrage? Eine Aktion kann mehre SQL-Abfragen auslösen Eine SQL Abfrage gehört zu einer Aktion SQL-Abfragen sind zunächst anonym Aktionen einer Klasse führen immer ähnliche SQL-Abfragen aus. SQL-Abfrage samt ihrem Benutzer ermöglicht feingranulare Zugriffskontrolle (Rewriting Engine Rossel et al 2012) Benjamin Große 19

20 Können SQL-Abfragen unterscheiden werden? Eine Zuordnung kann klar entschieden werden, wenn: Die ausgeführten Aktionen seriell, also zeitlich versetzt sind Die Aktionen parallel sind und unterschiedliche Datenbankabfragen erzeugen Die Aktionen parallel sind und Parameter enthalten Schwierig ist die eindeutige Zuordnung paralleler Zugriffe, wenn: Die SQL-Abfragen keine Parameter enthalten Die SQL-Abfragen Parameter enthalten, diese sich jedoch nicht verarbeiten lassen Benjamin Große 20

21 Mehrdeutigkeiten können durch Serialisierung verhindert werden HTTP-Requests können verzögert werden Abfrage 3 Benutzer A Es wird so sichergestellt, dass nur Aktionen einer Klasse aktiv sind Abfrage 2 Benutzer B Alle klassenspezifischen SQL-Abfragen sind damit eindeutig dieser Aktion zuzuordnen Abfrage 1 Benutzer A Benjamin Große 21

22 Zwei Datenströme werden zusammengeführt um Benutzer zuzuordnen Benjamin Große 22

23 Der zentrale Synchronisationspunkt ist der Signatursatz Benjamin Große 23

24 Die Konfiguration ist ein Modell einer Webanwendung Eine Sammlung von Aktionsklassen Lernen durch Beobachten Eine Aktion zur Zeit Single Request Modus Alle Anfragen gehören zu dieser Aktion Nachlese und Regelerstellung durch Fachpersonal Benjamin Große 24

25 Agenda 1. Problemstellung 2. Appliance zum Schutz von Webanwendungen 3. Prototyp 4. Ausblick Benjamin Große 25

26 Der Prototyp ist fertig Die Testanwendung konnte vollständig abgesichert werden Echte Anwendungen lassen sich absichern Der Zeitverlust verschwindet in der Latenz Benjamin Große 26

27 Agenda 1. Problemstellung 2. Appliance zum Schutz von Webanwendungen 3. Prototyp 4. Ausblick Benjamin Große 27

28 Diese interessanten Ansätze sollten weiter untersucht werden Regel- und Modellerstellung Anlernen im Produktivbetrieb Mustererkennung Künstliche neuronale Netze Andere Sicherheitslücken SQL-Injections (OWASP Top A1) Sensitive Data Exposure (OWASP Top A6) Ein Produkt für den Markt Projektplanung ist bereits gestartet Benjamin Große 28

29 Vielen Dank! Fragen und Diskussion erwünscht Benjamin Große 29