Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

IT Sicherheit > Serverseitige Angriffe > Flashcards

Serverseitige Angriffe Flashcards

1
Q

Wie defniert sich ein Angreifer?

A

über seine Möglichkeiten mit dem System zu unteragieren

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Arten von Angreifern:

A
  • Netzwerk-Angreifer
  • Web-Angreifer
  • Lokal-Angreifer
  • Entfernter-Angreifer
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Netzwerk-Angreifer:

Netzwerk = NW

A
  • sitzt an der Kommunikationsverbindung
  • Fähigkeiten: Beobachtung, Erzeugung, Unterbrechung des NW-Verkehrs
  • Man in the middle
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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”
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

weitere HTTP Verbs:

A
  • HEAD
  • PUT, DELETE
    TRACE, OPTIONS, CONNECT; PATCH
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Schema URL:

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

HTTP Response besteht aus…:

A
  • dem Response-Code
  • Liste von Response-Headern
  • einer Leerzeile
  • Response-Body
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Bsp. Web-Applikation

A
  • Ziel: Schreibe eine Anwendung, die einen Benutzernamen und ein Passwort entgegen nimmt und sie dann anzeigt
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)

IT Sicherheit (12 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions