1 PROTOKOLLKONFORME ATTACKEN IN Technische Universität Berlin Sicherheitsaspekte in der Softwaretechnik
Inhalt 2 Hypertext Transfer Protokoll Grundlagen & Funktion Request & Response URL-Exkurs Authentifizierung Cross-Site Scripting (XSS) Cross-Site Request Forgery (CSRF) Risiko 2.0 Gegenmaßnahmen Quellen
-Grundlegendes 3 übersetzt Hypertext-Übertragungsprotokoll wurde 1989 vom britischen Informatiker Timothy John Berners-Lee mit dem URL und der HTML entwickelt Protokoll zur Übertragung von Daten über ein Netzwerk hauptsächlich eingesetzt um Webseiten und andere Daten aus dem WWW in einen Browser zu laden gehört der Anwendungsschicht von Netzwerkmodellen an im Kern ist ein zustandsloses Protokoll ist zur Kommunikation auf ein Transportprotokoll angewiesen (TCP-Protokoll)
-Funktionsweise 4 Beispiel-URL: http://www.webseite.de zuerst wird die URL über das DNS-Protokoll in eine IP-Adresse umgewandelt zur Übertragung wird das TCP-Protokoll auf den Standard-Port 80 benutzt der -Servers erhält vom Webbrowser (der -Client) eine -Anfrage (- Request) in Form eines URL-Aufrufs der -Server antwortet mit einem - Response
URL Exkurs 5 URL(Uniform Resource Locator) = einheitlicher Quellenanzeiger: URL ist eine Unterart von URI (Uniform Resourse Identifier) URLs identifizieren eine Ressource über das verwendete Netzwerkprotokoll URL-Aufbau: http://user: pwd@www.webseite.de:80/index.php?lang=de#anker2 Protokoll://Benutzer:Passwort@Host:Port/Pfad?Anfrage#Anker URL-Kodierung: enthält der Anfragelink nicht erlaubt Zeichen werden diese mit dem URL-Encoding umgewandelt, zur Kodierung werden nur bestimmte Zeichen des ASCII-Zeichensatzes verwendet
Protokollversionen 6 zur Zeit werden 2 Protokollversionen verwendet /1.0 & /1.1 beide Versionen enthalten -Requests wie GET, PUT, POST, DELETE,... PUT und DELETE werden von den meisten Webservern mit dem -Statuscode 405 Method Not Allowed abgelehnt bei /1.0 wird für jede Anfrage eine Verbindung aufgebaut und nach Übertragung der Antwort wieder geschlossen bei /1.1 können mehrere Anfragen und Antworten pro Verbindung gesendet werden zusätzlich können bei /1.1 abgebrochene Übertragungen fortgesetzt werden
-Request 7 für die Anfragen an einem Webserver stehen mehrere Methoden zur Verfügung: GET: Inhalte vom Server angefordert, Parameter per URI übergeben POST: ähnelt dem GET, Parameter diskret übergeben werden HEAD: nur der -Header wird angefordert PUT: Dateien unter Angabe einer Ziel-URI auf einen Webserver hochladen DELETE: löscht eine angegebene Datei auf dem Server TRACE: liefert eine Anfrage so zurück, wie der Server sie empfangen hat, um zu überprüfen ob und wie die Anfrage auf dem Weg zum Server verändert worden ist OPTIONS: liefert eine Liste der vom Server unterstützen Methoden und Features CONNECT: wird von Proxyservern implementiert, die in der Lage sind, SSL-Tunnel zur Verfügung zu stellen
-Request mit GET und POST 8 GET-Request am Beispiel: http://www.webseite.de/index.php?lang=de&search=swt hier werden die Argument lang und search mit der URL übergeben Argumente werden mit? an die URL abgehangen und mit einem & von einander getrennt Anfrage sieht dann so aus: GET /index.php? lang=de&search=swt /1.1 Host: www.webseite.de POST-Request durch diskrete Übergabe der Argument: Argumente per Variablen(Key-Value Paare) im Body-Teil übergeben POST /index.php /1.1 Host: www.webseite.de Content-Type: application/x-www-form-urlencoded Content-Length: 18 lang=de&search=swt
-Response 9 Webserver antwortet mit dem -Respone, diese beinhalten den -Statuscode: 1## Informationen 2## Erfolgreiche Anfrage 3## Umleitung 4## Client-Fehler 5## Server-Fehler Zusätzlich enthält der Header eine Beschreibung des Fehlers im Klartext, z.b. ist ein Fehler 404 an dem Header zu erkennen: /1.1 404 Not Found
-Response Beispiel 10 Header /1.1 200 OK Date: Sat, 26 Jan 2008 20:18:30 GMT Server: Apache/2 Last-Modified: Sat, 26 Jan 2008 20:18:20 GMT Content-Length: 85179 Cache-Control: max-age=0 Expires: Sat, 26 Jan 2008 20:18:30 GMT Connection: close Content-Type: text/html; charset=iso-8859- Bedeutung Datei gefunden und Zugriff berechtigt Zeitangaben für die Übertragung verwendeter Webserver/OS Uhrzeit und Datum der letzten Aktualisierung der Datei Länge der übertragen Bytes Dauer, für die ein Proxy-Server die Datei in einem Zwischenspeicher ablegen darf Zeitpunkt der Löschung & Neuanforderung vom Server Verbindung offenhalten(keep-alive) oder schließen(close) Angaben über den Dateityp 1
-Cookie 11 Informationen, die vom Webserver gesendet werden Webclient speichert diese zwischen Webclient sendet diese später zurück werden mit -Header übertragen realisieren Session durch Session-ID (Cookie)
-Authentifizierung 12 Basic Authentication: Webserver fordert mit WWW-Authenticate: Basic realm="realmname" eine Authentifizierung an RealmName stellt eine Beschreibung des geschützten Bereiches dar Browser sucht nach Benutzername/Passwort für bzw. fragt nach Browser sendet Authentifizierung mit dem Authorization-Header in der Form Benutzername:Passwort Base64-codiert an den Server Zum Beispiel für Benutzername user und Passwort swt : Authorization: Basic dxnlcjpzd3q= Nachteil: die Daten werden zwar codiert, jedoch nicht verschlüsselt Schutzziel: Vertraulichkeit
-Authentifizierung 13 Quelle: Webdatenbank-Applikationen mit PHP und MySQL, 2. Auflage, Kapitel 11, O'Reilly Verlag GmbH
-Authentifizierung 14 Digest Access Authentication: Server sendet zusammen mit dem WWW-Authenticate- Header eine selbst erzeugte zufällige Zeichenfolge der Browser berechnet davon eine Prüfsumme (MD5) die Prüfsumme sendet er im Authorisation-Header mit dem Benutzername und der zufälligen Zeichenfolge an den Server zurück der Server berechnet wieder die Prüfsumme und vergleicht Vorteil: Abhören der Kommunikation nützt dem Angreifer nichts, da sich die Prüfsumme nicht entschlüsseln lässt und für jede Anforderung anders lauten muss
S 15 Syntaktisch ist S identisch mit dem Schema für, die zusätzliche Verschlüsselung der Daten wird mit SSL/TLS bewerkstelligt: durch Verwendung des SSL-Handshake-Protokolls findet eine geschützte Identifikation und Authentifizierung der Kommunikationspartner statt dann wird mit Hilfe asymmetrischer Verschlüsselung ein gemeinsamer symmetrischer Sitzungsschlüssel ausgetauscht dieser wird zur Verschlüsselung der Daten verwendet Standard-Port für S-Verbindungen ist 443 neben den Server-Zertifikaten können auch signierte Client- Zertifikate erstellt werden, dies ermöglicht eine Authentifizierung der Clients gegenüber dem Server
S 16 Quelle: Webdatenbank-Applikationen mit PHP und MySQL, 2. Auflage, Kapitel 11, O'Reilly Verlag GmbH
S 17 Entscheidung, ob S- statt einer -Verbindung genutzt wird, kann unterschiedlich erfolgen: serverseitig ausschließlich S zugelassen: Online-Banking Einwahl wird über https erzwungen, dann wird ein -Cookie im Browser gesetzt und der weitere Dienst unverschlüsselt abgewickelt Login per http-adresse kann vom Anwender manuell in ein sicheres Login per https-adresse geändert werden um eine Verschlüsselung zu bewirken (freenet.de, web.de, gmx.de => E-Mail) nach Anwahl der https-adresse wird der Client-Browser dem Anwender zuerst das Zertifikat des Servers anzeigen Entscheidung, gegebenenfalls nach Prüfung der angegebenen Links, ob dem Zertifikat für diese Sitzung oder permanent vertraut wird andernfalls wird die S-Verbindung nicht hergestellt
Sessions 18 bei zustandslosen Protokollen (z.b. ) keine stehenden Verbindungen zwischen Client und Server keine Daten (IP-Nummer, Kennung des Client) um Besucher eindeutig zu identifizieren bei jedem Zugriff auf einen Webserver wird eine eindeutige Session-ID mitgeschickt zusammenhängende Sitzung Sitzungsdaten werden serverseitig gespeichert
Cross-Site Scripting (XSS) 19 Dynamische Websites enthalten oft von Nutzer eingegebene Daten Javascript wertet die Interaktion zwischen Website und Nutzer auf Ausnutzung des Javascript-Features: Angreifer sendet Javascript (über Webformular) zum Server Server baut gesendete Daten in die dyn. Website ein Bei der Anzeige der Website wird das Javascript ausgeführt
Cross-Site Scripting (XSS) 20 Beispiel: <script>alert("testing XSS vulnerability");</script> Popup öffnet sich bei erfolgreichen Einfügen Webserver übernimmt eigene Javascripts in generierte Websites Angreifer kann prinzipiell jedes Javascript einfügen
Möglichkeiten durch XSS 21 Laden von weiterem Javascript Code von einem Server Dynamisches Anpassen der Website bei der Darstellung Auslesen der aktuell verwendeten Session-ID und damit Übernahme einer Session Auslesen weiterer sensibler Daten eines Nutzers Integrität und Vertraulichkeit verletzt
XSS - Ablauf 22
Cross-Site Request Forgery (CSRF) 23 Im Allgemeinen auch als Session Riding bezeichnet Voraussetzungen: Session Informationen werden automatisch in Request eingefügt z.b. Cookies oder Basic Authentication Informationen Angreifer hat Wissen über Webanwendung oder erlangt es leicht!!! Zielnutzer ist in Webanwendung eingeloggt!!!
Cross-Site Request Forgery 24 (CSRF) Angriff per GET-Request benötigt keine Javascript Unbemerkbarer Angriff durch Request im IMG- Tag z.b. <IMG SRC=http://www.vulnerable.site/webapp/delete?item=123> Worst Case: Target Application ist Carrier Application Jeder Nutzer der Webanwendung führt automatisch die Attacke aus
CSRF - Ablauf 25
Risiko 2.0 Ajax & XSS 26 Ajax nutzt clientseitig JavaScript Für Sicherheit soll Same Origin Policy sorgen Wenn eine Seite JavaScript mitliefert, dann ist dieses JavaScript vertrauenswürdig Es darf die Seite ändern Verhindert laden von Skripten anderer Domains Durch async. Requests wird nicht mehr garantiert, dass Daten erst bei Klick auf Submit verschickt werden Datenaustausch im Hintergrund möglich
Risiko 2.0 Ajax & XSS 27 Same Origin Policy wird ausghebelt durch: Proxy-Servlets um Services von Drittanbietern zu nutzen Cross-Site Scripting Server kann async. Anfrage von sync. Anfrage nicht unterscheiden Antwortbehandlung im Client individuell Fehlenden Rückmeldungen Schutzziel Verbindlichkeit nicht gewährleistet
Risiko 2.0 Javascript Hijacking 28 Ermöglicht das Abhören von übertragenen Daten in Echtzeit Voraussetzung: Erfolgreich durchgeführte XSS-Attacke Datenübertragung im JSON-Format Javascript klont Objekte aus existierenden nativen Objekten Ablauf: Basiskonstruktor Object() überschrieben Abändern der Setter-Methoden welche per JSON übertragen werden Setter startet zusätzliche Methoden zum Abhören/Manipulieren
Risiko 2.0 XSS Prototype Hijacking 29 Objekte können zur Laufzeit erweitert werden Ablauf: Erfolgreich ausgeführte XSS-Attacke Überschrieben des XMLHttpRequest-Objektes, altes Objekt ist als Attribut des Wrappers Send()-Methode überschreiben, so dass Methoden fürs Abhören/Manipulieren vorher aufgerufen werden Alle neu erzeugten Objekte werden vom Wrapper geklont und können abgehört/manipuliert werden
Risiko 2.0 - Beispiel 30 MySpace Samy Samy hatte ca. 70 Freunde, zu wenig! Aber er hatte JavaScript-Knowhow JavaScript im eigenen Profil, dass Samy per XMLHttpRequest zum Freund macht Nach 20 Stunden hatte Samy mehr als 1.000.000 Freunde!
Gegenmaßnahmen 31 Input-Validierung zur Verhinderung von Injection Angriffen Whitelisting ist Blacklisting vorzuziehen Möglichst kleine Zeichenmenge bei Whitelisting benutzen Einfache Filter verwenden, komplexe durch sequentielle Verwendung der einfachen Filter nachbilden Länge/Größe/Datentyp von Form-Variablen begrenzen Beispiele: SQL: % _ [ ( ) @ ; + = <> # -- Sonstige: alle nicht druckbaren Zeichen von Hex-0 bis Hex-19 das Null-Byte \0, URL-enkodiert: %00 Carriage Return (CR), \r, URL-enkodiert: %0a Linefeed (LF) \n, URL-enkodiert: %0d Tabulator \t, URL-enkodiert: %09
Gegenmaßnahmen 32 Output-Validierung Alle Zeichen invalidieren, die als Code interpretiert werden könnten bzw. in den Code-Modus umschalten Soll Benutzer begrenztes Markup erlaubt werden, muss eigene Markupsprache definiert werden Beispiele: & & < < > > " ' Markup: {img src=/images/img.gif width=1 height=1 img} Anmerkung: Das &-Zeichen und das ;-Zeichen sind als erstes zu ersetzen, da sie wieder als Metazeichen gebraucht werden.
Gegenmaßnahmen 33 Behandlung von manipuliertem Input 1. Fehleingaben des Benutzers Reaktion mit Wahrung des Minimalitätsprinzips 2. Bewusste Manipulation Kriterien für den Abbruch der Verarbeitung: Zusätzliche oder fehlende Form-Variablen Session-Cookie enthält nicht vergebene Zeichen oder entspricht nicht der definierten Länge HIDDEN-, SELECT-, CHECKBOX-Variablen entsprechen nicht dem vergebenen Muster bzw. Wert wurde verändert Quelle der Variablen stimmt nicht überein Mögliche Reaktionen: Vortäuschung des korrekten Umgangsmit den Eingaben Homepage/neutrale Seite anzeigen Explizite Warnung über Angriffsversuch ausgeben Vorhandene Session: beenden und invalidieren
Gegenmaßnahmen 34 Session-Management Nach Authentisierung die SessionID erneuern Generierung eines Session-Codes (One-Time-Token) Aktionsradius des Session-Cookies einschränken Domain-Cookies grundsätzlich vermeiden Secure-Flag im Session-Cookie setzen, wenn Anwendung SSL-Verschlüsselung benötigt Session beenden wenn: Timeout Max. Idletime Logout durch Benutzer Fehlersituation Session-Cookie löschen
Fazit 35 ist täglich benutztes Medium Zugriff auf Daten sehr einfach durch Klartextübertragung Schutzmaßnahmen sehr aufwendig aber notwendig Kein Verhältnis von Schutzmaßnahmen zum Schutzziel bzw. Funktion der Webanwendung 100%iger Schutz ist vollkommen unmöglich
Quellen 36 Hacker Web Exploitation Uncovered, Marsel Nizamutdinov, A-LIST Publishing, 2005, ISBN:1931769494 Cross-Site Scripting Explained, Amit Klein, whitepaper from Watchfire, http://www.watchfire.com Webdatenbank-Applikationen mit PHP und MySQL, 2. Auflage, Kapitel 11, O'Reilly Verlag GmbH, ISBN 978-3-89721-387-6 Session Riding, A Widespread Vulnerability in Today's Web Applications, Thomas Schreiber, SecureNet GmbH, Dec 2004, http://www.securenet.de Computermagazin c't 2/2008, S. 130, Risiko 2.0 Wikipedia, http://www.wikipedia.de