08 - Server-seitige Angriffe Flashcards
Fähigkeiten: Netzwerk-Angreifer (3)
1) Beobachtung des Netzwerkverkehrs
2) Erzeugung von Netzwerkverkehr
3) Unterbrechung von Netzwerkverkehr
Definition: Netzwerk-Angreifer
Dieser Angreifer sitzt an der Kommunikationsverbindung zwischen zwei Teilnehmern
Definition: Remote-Angreifer
Dieser Angreifer kann mit einem entfernten System über ein Netzwerk interagieren. Danach wird versucht das Remotesystem durch Benutzung/Missbrauch der verfügbaren Interfaces kompromittieren.
Ziele: Remote-Angreifer (3)
1) Ausführung von Code
2) Abschöpfen von Information
3) Denial of Service
Arten von Angreifer (4)
1) Remote-Angreifer
2) Lokaler Angreifer
3) Web-Angreifer
4) Netzwerk angreifer
Definition: Lokaler Angreifer
Dieser Angreifer führt beliebigen Code aus und versucht damit zusätzliche Rechte zu gewinnen.
Definition: Web-Angreifer
Hier handelt es sich um Angriffe auf Web-Anwendungen. Indem HTTP-Anfragen aus dem Browser des Users erzeugt werden oder JS in clientseitigen Kontext der angegriffenen Anwendung ausführen.
Eigenschaften: HTTP (3)
1) Stateless (Zustandslos) - gibt Anfragen und Antworten und sonst nichts.
2) Menschenlesbar
3) Nachdem die TCP-Verbindung geöffnet ist, wird die Anfrage-Syntax zum Server hin gestreamt.
Bestandteile: HTTP Request
1) Anfragezeile
2) Eine Liste von HTTP-Headern, getrennt durch < CR > < LF >
3) Einer leeren Zeile
4) Optionalen message body
Zweck: HTTP GET
Eine Ressource abrufen
Zweck: HTTP POST
Daten zum Server senden
Eigenschaften: HTTP GET (2)
1) Enthält keinen Message-Body
2) Parameter in der URL übergeben
Eigenschaften: HTTP POST (2)
1) Zu sendenden Daten werden im Message-Body transportiert
2) Für Zustandsändernde Anfragen zu verwenden
Bestandteile: HTTP Response (4)
1) Response-Code
2) Liste von Response-Headern
3) Leerzeile
4) Response body
Nachteil: HTTP Response
HTTP Responses können Angreifern viele Informationen über das Opfersystem liefern. Insbesondere bei fehlgeschlagenen Requests steigt die Aussagekräftigkeit
Definition: HTTPS
HTTPS ist eine kombination aus HTTP und SSL (oder TLS). Dieses Protokoll verschlüsselt Kommunikation und kann vor snooping und man-in-the-middle Angriffen schützen.
Definition: Web Proxies
Sind Zwischenstationen, die HTTP-Verkehr abfangen, untersuchen und weiterleiten. Sie können Client-sietig, Server-seitig oder an Netzwerk-Grenzen platziert werden. Ihre Aufgabe ist Caching und feindliche Requests zu filtern. Diese Proxies müssen aber dem Browser bekannt sein.
Angriffe auf Web-Applikationen: Client-Seitig (2)
1) Cross-Site Scripting
2) Cross-Site Request Forgery
Angriffe auf Web-Applikationen: Server-Seitig (3)
1) SQL Injection
2) Remote Code Injection
3) Path Traversal
Arten von Input Validation (6)
So kann gegen untrusted Input geschützt werden, wenn die folgenden Charakteristiken geprüft werden:
1) Datentyp
2) Zulässige Zeichenmenge
3) Minimale und Maximale Länge
4) ob null zulässig ist
5) Das numerische Intervall
6) Zählt der Input zu einem der enums
Arten von Untrusted Input (5)
1) Ziel-URLs
2) GET-Parameter in der URL und POST-Parameter im Body
3) Cookie Header
4) Metadaten von übertragenen Objekten
5) Abgeleitete Code-Injection
Warum keine Client-Seitige Sicherheitsmaßnahmen?
Dem Client kann nie vertraut werden, da er alle Aspekte des Web User-Interfaces lesen und ändern kann um somit die Web-Anwendung manipulieren kann.
Definition: SQL-Injection
Besteht daraus, innerhalb einer existierenden Anwendung (z.B. Input Felder) SQL-Kommandos in die Datenbank-Engine zu injizieren
Vorgehensweise: SQL Injection (3)
1) Angreifer sucht nach einem Parameter, den die Web-Anwendung dafür benutzt, eine DB-Abrage zusammen zu bauen
2) Schadhafte SQL-Befehle an geeignete Stelle des Parameters einfügen um die Web-Anwendung dazu zu bringen, die schadhafte Abfrage an die DB weiter zu geben.
3) Danach werden vom Angreifer Datenbankinhalte entweder abgerufen, manipuliert oder sogar vernichtet.
Sicherheitsmaßnahmen: SQL-Injections (7)
1) Keine unnötigen Debuggung- und Fehlermeldungen an den Benutzer ausgeben und stattdessen dafür Logfiles benutzen.
2) “ und ‘ Zeichen für String-werte in der DB escapen mit ' (Wehrt natürlich nicht alle SQL-Injections ab)
3) Prepared Statements auf dem DB-Server die für die Anwendung benötigt wird
4) Applikation von SQL zu trennen (z.B. mit Persistenz-Frameworks)
5) Benutzereingaben die in SQL-Statements landen validieren
6) Nur Daten akzeptieren, die exakt deinen Erwartungen entsprechen - konservativer Ansatz.
7) Zugriffsrechte der Anwendung auf der DB beschränken
Sicherheitsmaßnahmen: Remote Code-Injections (3)
1) Validiere und escape dynamische Kommandos
2) Nimm dem ausführenden System-User so viele Privilegien wie möglich weg.
3) Benutze gar keine Shell-basierte Kommunikation/Ausführung
Injection mittels Path Traversal
Mit parameter injections nach einer spezifischen Datei oder einem Dateipfad suchen. Oft sind Konfigurationsdateien oder hardcoded Credentials das Ziel.
Sicherheitsmaßnahmen: Path Traversal (3)
1) Alle Pfade vor der Benutzung normalisieren
2) Whitelists um Zugriff auf erlaubte Dateien und Verzeichnisse einzuschränken.
3) Sensitive Daten außerhalb solcher Pfade ablegen.
Fragen für String-Verwendung (5)
1) Baue ich gerade Computer-Code zusammen?
2) Falls ja: Welcher Interpreter wird ihn ausführen
3) Welche Semantik steckt hinter den Daten / dem Code
4) Welcher dynamischer Teil meiner Daten könnte von einem Angreifer beeinflusst werden?
5) Wie bereinige ich die Daten in der jeweiligen Programmiersprache?
Definition: Kontrollfluss bei Web-Applikationen
Der Kontrollfluss wird von einer Reihenfolge von HTTP-Requests und -Responses vom User im UI zu einem gewissen Maße gesteuert.
Problem: Kontrollfluss bei Web-Applikationen
Der Angreifer kann ausgehende HTTP-Requests bis aufs letzte Bit kontrollieren und sich somit kann sich der Programmierer nicht auf die Einschränkungen durch das erwartete Format und den Ablauf der Requests verlassen. D.h. er kann nicht davon ausgehen, dass alle eingehenden Requests sich an das Schema vom vorprogrammierten UI halten.
Verwundbarkeiten: Kontrollflusse (4)
1) Sicherheitseigenschaften direkt von HTTP-Parametern (oder anderen Teilen) des eingehenden Requests abgeleitet.
2) Annahme, dass der Angreifer nur auf diejenigen URLs zugreift, die im UI auftauchen.
3) Andere HTTP-Verben verwenden die vom Applikationsserver zugänglich sind.
4) Fehlende Kontrollfluss Integrität (Reihenfolge der HTTP-Requests ist vom Angreifer beeinflussbar)
Probleme: Kontrollfluss-Integrität bei Multi-Party Web-Applikationen
1) Bei Multi-Party Web-Applikationen müssen sich mehrere Parteien abstimmen und so könnte es zu mehr Verwundbarkeiten kommen.
2) URL-Inhalte können vom Angreifer zwischen Diensten Modifiziert werden
3) Ein weiterer Bösartiger Dienst kann sich am Dienstnetzwerk anschließen und somit z.B. den Bezahlungsvorgang manipulieren
Gegenmaßnahme: Kontrollfluss-Integrität für Multi-Party Web-Applikationen
Zwischen den Diensten sollte von den einzelnen Diensten eine Form von Signatur einführen, damit die letze Signatur von z.B. den Inhalten einer Bestellung verifiziert
Definition: Race Conditions
Hier werden mehrere Threads generiert, die jeweils eine HTTP-Request ausführen. Diese Threads teilen sich Ressourcen wie das Filesystem, die DB und alle übrigen applikationsfremden Ressourcen.
Angriffe auf Web-Applikationen (5)
1) Race-Conditions (Nebenläufigkeit von Threads)
2) Injections (SQL, Path-Traversal, JSON usw…)
3) Server-Side Scripting
4) Kontrollflussmanipulation
5) File-Uploads
Probleme: File-Uploads
Dateien sind hier vom Angreifer Kontrolliert und er kann Bösartige Dateien so an den Server schicken wo sie auch verarbeitet werden.
Gegenmaßnahmen: File-Uploads (5)
1) Nur Files akzeptieren die man Erwartet
2) Files als BLOB in der DB speichern
3) Nicht zulassen, dass der Benutzer den Filenamen wählt.
4) Größe der Dateien beschränken
5) Bilder Reformatten
