Serverseitige Angriffe Flashcards
1
Q
Wie defniert sich ein Angreifer?
A
über seine Möglichkeiten mit dem System zu unteragieren
2
Q
Arten von Angreifern:
A
- Netzwerk-Angreifer
- Web-Angreifer
- Lokal-Angreifer
- Entfernter-Angreifer
3
Q
Netzwerk-Angreifer:
Netzwerk = NW
A
- sitzt an der Kommunikationsverbindung
- Fähigkeiten: Beobachtung, Erzeugung, Unterbrechung des NW-Verkehrs
- Man in the middle
4
Q
Entfernter Angreifer:
A
- kann mit entferntem System über ein Netzwerk interagieren
- Remotysystem durch benutzung/ Missbrauch der verfügbaren Interfaces zu kompromittieren
- Ziele: Ausführung von Code, Abschöpfen von Infos, Denual of Service
5
Q
lokaler Angreifer:
A
- führt beliebigen Code aus (aber mit beschränktem Zugriffsrechten)
- Hauptziel: Gewinnung von zusätzlichen Rechten
- “Man in the Computer”
- Bsp.: Schadsoftware, Jailbreaker
6
Q
Web-Angreifer:
A
- neues Angreifermodell
- spezifisch für Web-Anwendungen
- “Man-in-the-Browser” => erzeugt HTTP-Anfragen aus dem Browser des Benutzers
- XSS-Angreifer => JavaScript im clientseitigen Kontext der angegriffenen Anwendung ausführen
7
Q
Auf einem typischen Web Server…
A
- sind die Ports 80/443/ 8080 geöffnet
- läuft das Betriebssystem und der Web Server (Hauptanwendung, Plug-Ins)
8
Q
Grundlagen HTTP und Web-Anwendungen:
A
- alle HTTP-Transaktionen folgen dem selben allgemeinen Muster
- jede Anfrage des Clients und jede Serverantwort besteht aus drei Teilen
1. Anfrage-, Antwortzeile
2. dem Header
3. optional: Nachrichteninhalt
9
Q
HTTP ist … :
A
- … zustandslos
- nur Request und Response sonst nichts
- kein Handshake, keine Initialisierung
- … menschenlesbar
- damit ist Anfrage abgeschlossen (Nachdem die TCP-Verbindung geöffnet ist, wird die Anfrage-Syntax zum Server hin gestreamt)
10
Q
HTTP Request besteht aus :
A
- der Anfragezeile (GET/index.html HTTP/1.1)
- Liste von HTTP-Headern, getrennt durch durch (bsp. Cookies, Host)
- einer leeren Zeile
- optional: “message body”
11
Q
HTTP Request:
A
- Allgemeine Form der HTTP Anfragezeile: Verb Path Protocol
- Verb: bezeichnet die Aktion, die mit der Zielressource ausgeführt werden soll (Get)
- Pfad (path): gibt Ressourcen an (index.html)
- Protokoll: im Web Entweder HTTP…
- 1.0 oder
- 1.1 der
- 2.0
12
Q
HTTP GET:
A
- Zweck: Ressource abrufen
- sollte keine Seiteneffekte auf den Zustand des Webservers haben
- Enthält keinen Message-Body
- Parameter werden in der URL übergeben
13
Q
HTTP Post:
A
- Zweck: Daten zum Server senden
- diese Daten im Message Body
- diese Methode sollte füt Zustandsändernde Anfragen verwendet werden
14
Q
weitere HTTP Verbs:
A
- HEAD
- PUT, DELETE
TRACE, OPTIONS, CONNECT; PATCH
15
Q
Schema URL:
A
16
Q
HTTP Response besteht aus…:
A
- dem Response-Code
- Liste von Response-Headern
- einer Leerzeile
- Response-Body
17
Q
HTTP Response Code Beschreibung:
A
- Angreifer muss Informationen über sein Ziel zusammentragen bevor er seinen Angriff starten kann
- können eine Menge an Infos liefern wenn man sie richtig liest (insbesondere failed request)
18
Q
HTTP Response Codes:
A
- 2xx Success (200 OK)
- 3xx Redirection (301,302,303,2307)
- 304 Not Modified
- 4xx Client Error (400 Bad Request, 401 Unauthorized, 403 Forbidden)
- 5xx Server Error (500 Intrenal Server Error, 502 Bad Gateway)
19
Q
HTTP Response Headers:
A
- jeder HTTP Response kann belibig viele Response-Header enthalten
- Syntax:
- Name-Wert-Paar als Strings
- getrennt durch carriage return und line feed
- liefert Informationen über:
- Meta- und Serverinformationen
- wie soll der response body weiter verarbeitet werden
- Beispiele: (Set-Cookie, Contect-Type, Content-Length)
- viele Sicherheitsmechanismen basieren auf HTTP-Response Headern
20
Q
HTTPS:
A
- Kombi aus HTTP und SSL (oder TLS)
- verschlüsselt die Kommunikation
- schützt vor Man-In-The-Middle und snooping
- schützt Benutzerauthentifizierung
- Schützt nicht vor Angriffen gegen die Web-Anwendung selbst
21
Q
Web Proxies:
A
- Zwischenstationen die HTTP-Verkehr abfangen, untersuchen und weterleiten
- Zweck: catching, filtern
- Client und Netzwerk-Proxys müssen dem Browser bekannt sein (alle Anfragen werden an Progy geschickt)
- client-seitige Proxys können Sicherheitsaufgaben übernehmen (persönliche Firewalls)
22
Q
Web-Server-Scripting:
A
- bald nach der Entstehung des WWW reichtte es nichtt mehr aus, nur statische HTML-Seiten auszuliefern
- Idee: HTML-Code programmatisch “on the fly”
- Methoden
- CGI (Common Gateway interface) => gibt Daten aus Request an Programm
- Methoden Forts)
- Webserver-Modul => schneller und bessere Schnittstellen (Bsp. mod_perl, mod_php)
- spezieller Anwendngsserver (Bsp. Tomcat, Websphere)
23
Q
Bsp. Web-Applikation
A
- Ziel: Schreibe eine Anwendung, die einen Benutzernamen und ein Passwort entgegen nimmt und sie dann anzeigt
24
Q
Angriffe auf Web-Applikationen Client-seitige Probleme:
A
- Cross-Site Scripting (XSS -> JavaScript)
- Cross-Site Request Forgery (CSRF)
25
Angriffe auf Web-Applikationen **Server-seitige Probleme:**
* SQL Injection
* Remote Code Injection
* Path Traversal
26
Ungeprüfte Eingaben (untrusted input):
* Web-Anwendungen nutzen Eingaben aus HTTP-Request (und auch Dateien) um ihre Antworten zu bestimmen
* Angreifer manipulieren HTTP-Request =\> Sicherheitsmaßnahmen werden umgangen
* Bsp.: XSS, SQL-Injection, Overflow, cookie poisoning)
* einige Seiten probieren sich zu schützen, indem sie bekannte schädliche Eingaben herausfiltern (Problem es gibt viele)
27
Prüfung der Eingaben:
* Eingaben denen man nicht vertraut sollten gegen eine "positive" Spezifikation validiert werden
* diese definiert folgendes
* Datentyp (string, integer, real, etc...)
* Zulässige Zeichenmenge –
* Minimale und maximale Länge
* ob null zulässig ist
* ob der Parameter zwingend benötigt wird (requires) oder nicht
* ob mehrere/doppelte Werte zulässig sind
* das numerische Intervall –
* spezifische erlaubte Werte (enumeration)
* spezifische Muster (regular expressions)
28
Was ist untrusted input?:
* Ziel-URLs
* Parameter (P) (GET-P in der URL, POST P im Body)
* Header
* Metadaten von übertragenen Objekten
* abgeleitete Code Injection
29
Vertraue dem Client nie:
* kann unter vollständiger Kontrolle des Angreifers stehen
* kann alle Aspekte des Web User-Interfaces lesen und ändern
* kann jegliche Sicherheitsmaßnahmen auf Client-Seite untergraben
30
Client-Seitige Validierung:
* versuche nicht Benutzereingaben auf der Client-Seite zu überpüfen
* Dont'Do:Passwort Vorgaben durchsetzten
* =\> kann leicht von Client-Seite (Angreifer) ganz leicht unschädlich gemacht werden durch
* Client-Seitige Manipulation von HTML
* Benutzung eines Abhör-Web-Proxy auf Cliebt Seite
31
versteckte Felder in Forms:
* sind für Angreifer sichtbar =\> kann sie lesen und manipulieren
* Deshalb: keine Geheimnisse und nicht beeinflusbare-Werte reinschreiben (Preis Online-Shopping)
32
Injection Attacks:
* viele Web-Anwendungen rufen Interpreter auf
* SQL, Shell Command
* Interpreter führen die Befehle aus, die durch Parameter in den Eingabedateien gegeben sind
* =\> Benutzer kann eigene Befehle (wen Parameter seiner Kontrolle unterliegen) an den Interpreter injizieren
33
SQL Injection:
* innerhalb einer existierenden Anwendung **SQL-Kommandos in die Datenbank-Engine zu injizieren**
* besonders weit verbreitet
* gefährliche Form einnes Injection-Angiffs
34
SQL Injection Szenario:
* Anwendung nutzt DBS zu dauerhaften Datenspeicherung (Kommunikation mit SQL Befehlen)
* Problem: dymanische Eingaben
* um SQL-Injection Schwachstelle auszunutzen muss Angreifer Paramter finden den die Web-Anwendung nutzt um DB-Abfrage zusammen zu bauen
* =\> dann kann er SQL-Befehle sorgfältig an geeigneten Stellen des Parameters einfügen um die Webanwendung dazu zu bringen schadhafte Abfrage an DB weiter zu geben
* Daten können abgerufen, manipuliert, zerstärt werden
35
Bsp.: SQL-Injection Password:
36
Gewinnung von Informationen mit Hilfe von Fehlermeldungen:
* Fehlermeldungen, die die Anwendung ausgibt, helfen möglicherweise dem Angreifer.
* Stelle sicher, dass du keine unnötigen Debugging- und Fehlermeldungen an Benutzer ausgibst.
* Für das Debugging ist es besser Logfiles zu benutzen
37
Datenbank auskundschaften:
* wenn Mehrfachabfragen (wie in MySQL) in einer Verbindung nicht erlaubt sind, lässt sich Informations-leakage mit komplexeren Vorgehensweisen erreichen
* durch hinzufügen von boolschen Bedingungen
* Infos aus anderen Tabellen mithilfe von Subquerys
38
Datenbank auskundschaften, Spaltenanzahl:
39
Datenbank auskundschaften, Spaltenname:
Eine Querymit falschemSpaltennamenliefert einen Fehler
40
Datenbank auskundschaften, Ermittekn weiterer Tabellen mit UNION:
41
weitere Beispiele für SQL-Angriffe:
* select \* ...; insert into user values(“user”,”h4x0r”); •
* Der Angreifer legt einen neuen Benutzer auf Datenbankebene an.
* select \*... ; drop table SensitiveData;
* Ein “;” anzuhängen funktioniert nicht bei allen Datenbanken. Das kann abhängig vom Datenbanktreiber sein (z.B. bei MySQL)
42
SQL-Injection für Fortgeschrittene:
* Webapplikationen ändern lassen oft das ' und " weg =\> verhindert die meisten SQL-Injection-Angriffen
* bei großen Anwendnungen keine Strings sondern sondern Zahlen
43
SQL-Injection im Blindflug:
* typische Gegenmaßnahme ist die Anzeige von Fehlermeldungen zu überprüfen
44
SQL-Injection im Blindflug:
* Daten können sogar durchsickern, wenn überhaupt keine Rückmeldung an den user/attacker gesandt wird:
* z. B. SQL-Injection-Verwundbarkeiten in Logging-Funktionen
* **Der Trick besteht darin, das Antwortverhalten des Webservers zu beeinflussen:**
* “timing based information leaks”
45
Timing basierte Information Leak:
* Erstelle eine Query, die entweder sehr schnell abgearbeitet ist oder aber sehr lange braucht,abhängig von einem abgefragten Wert.
* Durch Messen der Antwortzeit erhält man Informationen über den Wert
* true/false Information = ein Bit
46
SQL Injection Solution:
* Entwickler dürfen es nicht lassen, dass vom Benutzer eingegebene Daten SQL-Statements verändern
* beste Schutz: Applikation von SQL trennen
* Persistenz-Fraemeworks können helfen
* benötigte Statements sollten als prepared statememts realisiert sein
47
prepared statements:
* Konzept: Keine dynamische String-Concatenation •
* Stattdessen vorgefertigte SQL-Statements mit Platzhaltern.
* Damit bleibt die syntaktische Struktur der Anweisung statisch.
* Einfügen von SQL-Syntax ändert dann nicht die Semantik des Statements
* trzdm verwundbar wenn sich Angreifer schlau anstellt
48
Andere Möglichkeiten SQL-Injection vor zu beugen als prepared statements:
* Validierung der Benutzereingaben die in den SQL-Statements landen
* nur Daten akzeptieren, die genau den Erwartungen entsprechen (Typ, Größe)
* Entfernen oder escapen von Anführungszeichen die in Benutzerdaten sind
* aus ' wird \'
* schweigsam sein (keine SQL Errors) =\> Response Code 500 sagt genug
* Zugriffsrechte beschränken
49
Warnung bei eigenen Sicherheitsvorkehrungen:
* man muss das Rad nicht jedes Mal nue erfinden?
* eigene Implementierung kann lückenhaft sein
* Zeitaufwand für Fehlersuche/ Korrektur und Testen
50
Remote Code-Injection:
* Gegenmaßnahmen
* validiere und escape dynamische Kommandos
* nimm ausführenden System-User so viele Privilegien wie möglich weg
* besser: gar keine Shell-basierte Kommunikation/ Ausführung
51
Path traversal:
* Folgen: Information leakage (Konfigurationsdateien)
* Gegenmaßnahmen:
* normalisiere alle Pfade
* Positivlsten (Whitelists)
* sensible Daten außerhalb solcher Pfade
52
String basierte Code-Injection:
* Code und User Eingaben vermischen sich, da Code auch dynamisch erzeugt wird
53
Kontrollfluss bei Web-Applikationen:
* Der Kontrollfluss einer Web-Applikation wird bestimmt durch die Abfolge der HTTP-Requestsund -Responses.
* Die HTTP-Requests, die die Applikation (auf Serverseite) erwartet, ergeben sich aus den Aktionen in ihrem User-Interface
54
Vorgesehene und erwartete HTTP-Request:
* Die vorgeseheneFormdereingehenden Requestswird bestimmt durch das UI der Web-App
* Die interne Logik der Applikation ist auf dieses erwartete Schema hin programmiert.
* Der Angreifer kann ausgehende HTTP–Requests bis aufs letzte Bit kontrollieren
* Also kann der Programmierer sich nicht auf die Einschränkungen durch das erwartete Format und den Ablauf der Requests verlassen
* Das Bedeutet, er kann nicht davon ausgehen, dass alle eingehenden Requests sich an das Schema halten, das vom UI der Applikation vorgegeben wird
55
HTTP Verb-Tampering:
* HTTP ist gutmütiges Protokoll
* man kann beliebiges Wort als HTTP-Method verwenden, nicht nur GET oder POST
* im schlimmsten Fall:
* Default authorization = ALLOW
* Die Berechtigungsprüfungen hängen an spezifischen HTTPVerben –GET,POST
* Alle unbekannten oder unerwarteten Verben werden durchgelassen –Lässt sich mit einem „WURST“-Request austricksen
56
Fehlende Kontrollfluss Integrität:
* wenn INtegrität des Workflows nicht eingehalten wird, kann Angreifer von a nach c springen und b überspringen
* besonders schwer wenn Kontrollfluss über mehrere Parteien erstreckt
57
Race Conditions:
* Problem mit der Nebenläufigkeit
* meiste Web-Entwickler sind sich nicht im klaren, dass sie hochgradig multithreaded Code schreiben
* jeder HTTP Request ist ein Thread?
58
File Upload:
* Nachlässigkeit kann schwerwiegende Sicherheitsprobleme verursacht:
* Dateien sind vom Angreifer kontrolliert (Dateinamen, Dateiinhalt)
* nach Upload liegt Datei auf dem Server und in den Sicherheitsgrenzen der Anwendung wo sie verarbeitet wird
* Tipps:
* Prüfe alles gründlich und akzeptiere nur das, was du erwartest
* Beurteile Dateien nicht nur aufgrund ihrer Dateiendung
* Lass es nicht zu, dass der Benutzer den Filenamen wählt.
* Sonst könnte er die Datei z.B. ../etc/passwd nennen.
* Beschränke die Größe der Dateien – Sonst könnte ein Angreifer damit einen DoS-Angriff auf die Anwendung fahren.
* Wandle Bilddateien um (reformat)
