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
Q
Angriffe auf Web-Applikationen Server-seitige Probleme:
A
- SQL Injection
- Remote Code Injection
- Path Traversal
26
Q
Ungeprüfte Eingaben (untrusted input):
A
- 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
Q
Prüfung der Eingaben:
A
- 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
Q
Was ist untrusted input?:
A
- Ziel-URLs
- Parameter (P) (GET-P in der URL, POST P im Body)
- Header
- Metadaten von übertragenen Objekten
- abgeleitete Code Injection
29
Q
Vertraue dem Client nie:
A
- 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
Q
Client-Seitige Validierung:
A
- 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
Q
versteckte Felder in Forms:
A
- sind für Angreifer sichtbar => kann sie lesen und manipulieren
- Deshalb: keine Geheimnisse und nicht beeinflusbare-Werte reinschreiben (Preis Online-Shopping)
32
Q
Injection Attacks:
A
- 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
Q
SQL Injection:
A
- innerhalb einer existierenden Anwendung SQL-Kommandos in die Datenbank-Engine zu injizieren
- besonders weit verbreitet
- gefährliche Form einnes Injection-Angiffs
34
Q
SQL Injection Szenario:
A
- 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
Q
Bsp.: SQL-Injection Password:
A
36
Q
Gewinnung von Informationen mit Hilfe von Fehlermeldungen:
A
- 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
Q
Datenbank auskundschaften:
A
- 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
Q
Datenbank auskundschaften, Spaltenanzahl:
A
39
Q
Datenbank auskundschaften, Spaltenname:
A
Eine Querymit falschemSpaltennamenliefert einen Fehler
40
Q
Datenbank auskundschaften, Ermittekn weiterer Tabellen mit UNION:
A
41
Q
weitere Beispiele für SQL-Angriffe:
A
- 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
Q
SQL-Injection für Fortgeschrittene:
A
- Webapplikationen ändern lassen oft das ‘ und “ weg => verhindert die meisten SQL-Injection-Angriffen
- bei großen Anwendnungen keine Strings sondern sondern Zahlen
43
Q
SQL-Injection im Blindflug:
A
- typische Gegenmaßnahme ist die Anzeige von Fehlermeldungen zu überprüfen
44
Q
SQL-Injection im Blindflug:
A
- 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
Q
Timing basierte Information Leak:
A
- 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
Q
SQL Injection Solution:
A
- 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
Q
prepared statements:
A
- 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
Q
Andere Möglichkeiten SQL-Injection vor zu beugen als prepared statements:
A
- 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
Q
Warnung bei eigenen Sicherheitsvorkehrungen:
A
- man muss das Rad nicht jedes Mal nue erfinden?
- eigene Implementierung kann lückenhaft sein
- Zeitaufwand für Fehlersuche/ Korrektur und Testen
50
Q
Remote Code-Injection:
A
- 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
Q
Path traversal:
A
- Folgen: Information leakage (Konfigurationsdateien)
- Gegenmaßnahmen:
- normalisiere alle Pfade
- Positivlsten (Whitelists)
- sensible Daten außerhalb solcher Pfade
52
Q
String basierte Code-Injection:
A
- Code und User Eingaben vermischen sich, da Code auch dynamisch erzeugt wird
53
Q
Kontrollfluss bei Web-Applikationen:
A
- 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
Q
Vorgesehene und erwartete HTTP-Request:
A
- 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
Q
HTTP Verb-Tampering:
A
- 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
Q
Fehlende Kontrollfluss Integrität:
A
- 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
Q
Race Conditions:
A
- 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
Q
File Upload:
A
- 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)
