Sec-07-Web Security Flashcards
Was ist das Hauptthema der Vorlesung?
Es geht um Web-Sicherheit, wobei insbesondere Angriffe auf Server und Clients behandelt werden. Dabei wird auch kurz auf Web-Sessions eingegangen, die als verbindendes Element zwischen den beiden Angriffskategorien dienen.
Welche Angriffstypen werden in dieser Vorlesung differenziert?
Die Vorlesung unterscheidet zwischen serverseitigen Angriffen (z. B. Code Injection, Path Traversal) und clientseitigen Angriffen (wie dem klassischen Cross Site Scripting). Zwischen diesen beiden Themen wird auch die Rolle von Web-Sessions erläutert.
Was versteht man unter Web-Anwendungen und welche Technologien kommen dabei zum Einsatz?
Web-Anwendungen sind Programme, die im Internet laufen. Früher beschränkte sich das meist auf die Kommunikation zwischen einem Webbrowser und einem Webserver über HTML, HTTP und HTTPS.
Heutzutage handelt es sich um ein Konglomerat aus vielen Technologien:
Clientseite: Fast immer läuft JavaScript im Browser (früher auch Flash und andere aktive Inhalte).
Serverseite: Neben traditionellen Sprachen wie PHP, ASP und JSP kommt mittlerweile auch Node.js (JavaScript) zum Einsatz.
Datenkommunikation: SQL spielt als Datenbanksprache eine Rolle, und Formate wie XML und JSON sind Standard für den Datenaustausch zwischen Browser und Server.
Wie funktioniert das einfachste Modell einer Web-Anwendung?
In der simpelsten Form sendet der Webbrowser eine HTTP-Anfrage an einen Webserver, der im Hintergrund mit einer Datenbank verbunden ist. Der Webserver verarbeitet die Anfrage und liefert daraufhin eine HTTP-Antwort zurück, die die gewünschten Daten enthält. Natürlich sind reale Anwendungen (wie Facebook, eBay oder YouTube) wesentlich komplexer und bestehen aus vielen Komponenten und Datenbanken.
Welche allgemeinen Sicherheitsprobleme können in Web-Anwendungen auftreten?
Neben Problemen auf den unteren Netzwerkschichten (wie unverschlüsselter Kommunikation oder unsicher gespeicherten Passwörtern) gibt es spezifische Schwachstellen auf Anwendungsebene.
Dazu zählen insbesondere Code Injection Angriffe – etwa SQL Injection und Path Traversal – die zu Informationsleckage sowie Beeinträchtigungen der Integrität und Verfügbarkeit führen können.
Was ist SQL Injection und wie funktioniert sie?
SQL Injection ist ein Angriff, bei dem ein Angreifer bösartigen SQL-Code in eine dynamisch zusammengesetzte SQL-Abfrage einschleust. Dadurch wird die Logik der Abfrage manipuliert.
Was ist ein klassisches Bespiel für SQL Injection ?
Ein klassisches Beispiel: Ein PHP-Skript liest HTTP-Parameter (z. B. Name und Passwort) ein und baut daraus eine SQL-Abfrage. Wird die Eingabe nicht korrekt validiert, kann der Angreifer durch das Einschleusen zusätzlicher SQL-Befehle (wie „or 1=1“) die Authentifizierung umgehen.
Wie illustriert das weitere Beispiel im PHP-Code den Ablauf einer SQL Injection?
Im Beispiel wird zunächst der Parameter „Name“ und „Password“ aus der URL ausgelesen. Anschließend wird eine SQL-Abfrage dynamisch zusammengesetzt, in der diese Parameter eingesetzt werden. Manipuliert ein Angreifer den Wert des Passworts – etwa durch das Einfügen von zusätzlichen einfachen Anführungszeichen und der Klausel „or 1=1“ –, so wird die ursprüngliche Logik der SQL-Abfrage aufgebrochen, was dazu führt, dass der Authentifizierungscheck umgangen wird.
Warum ist das dynamische Zusammenfügen von SQL-Befehlen mit Benutzereingaben gefährlich?
Durch das Zusammenfügen von Code und Daten entsteht eine Vermischung, bei der Steuerzeichen (wie einfache oder doppelte Anführungszeichen) fehlinterpretiert werden können. Dies ermöglicht es einem Angreifer, die SQL-Anweisung so zu manipulieren, dass sie nicht mehr nur Daten abfragt, sondern auch schädlichen Code ausführt.
Welche Auswirkungen kann eine erfolgreiche SQL Injection haben?
Ein Angreifer kann damit Daten auslesen, verändern oder sogar löschen.
Insert- oder Delete-Befehle lassen sich auch ausführen – abhängig von den Datenbankrechten.
In manchen Fällen können sogar Betriebssystembefehle ausgeführt werden, was schwerwiegende/ schlimme Auswirkungen auf die Vertraulichkeit, Integrität und Verfügbarkeit der Daten hat.
Welche Schutzmaßnahmen werden gegen SQL Injection empfohlen?
Die Verwendung von Prepared Statements (vordefinierte SQL-Abfragen, in die nur Parameter eingefügt werden).
Sorgfältige Eingabevalidierung und korrektes Escaping von Steuerzeichen.
Vermeidung des dynamischen Zusammenfügens von Code und Daten.
Was versteht man unter Remote Code Execution (RCE) durch Code Injection?
Remote Code Execution bezeichnet einen Angriff, bei dem ein Angreifer auf einem entfernten System beliebigen Code ausführen kann.
Dies geschieht häufig durch das unsichere Verarbeiten von Benutzereingaben, bei dem dynamisch Shell-Befehle zusammengesetzt werden.
Bei diesem Angriff kann ein Angreifer über ein manipuliertes PHP-Skript eigene Befehle ausführen.
Zum Beispiel könnte er ein Semikolon einschleusen, gefolgt von einem Befehl wie „rm -rf /“, der alle Dateien löschen würde.
Wie wird bei dem Remote Code Execution Beispiel vorgegangen?
Ein klassisches Beispiel ist ein PHP-Skript, das einen Shell-Befehl (wie beispielsweise „cat“) mit einem Parameter ausführt.
Wird dieser Parameter nicht korrekt validiert und ein Angreifer injiziert zusätzliche Befehle – etwa durch das Einschleusen eines Semikolons (;) gefolgt von einem gefährlichen Befehl wie „rm -rf /“ –, so werden dem Server zusätzliche, schädliche Kommandos übergeben.
Das kann zu Datenverlust, Systemübernahme und schwerwiegenden Sicherheitsverletzungen führen.
Welche Schutzmaßnahmen werden gegen Remote Code Execution empfohlen?
Schutzmaßnahmen umfassen die strikte Validierung und Sanitization (Säuberung) der Eingänge, die Verwendung vorbereiteter Statements und das Prinzip der minimalen Rechtevergabe, um den Schaden im Fall eines Angriffs zu begrenzen.
Was ist ein Path Traversal Angriff?
Beim Path Traversal versucht der Angreifer, durch gezielte Manipulation von Dateipfaden – beispielsweise durch Einfügen von „..“ (Punktpunkt) und URL-kodierten Slashes – auf Dateien außerhalb des vorgesehenen Verzeichnisses zuzugreifen.
Dadurch kann er sensible Dateien wie Konfigurations- oder Quellcodedateien lesen.
Wie genau funktioniert ein Path Traversal Angriff?
Der Angreifer fügt in den Dateipfad Zeichenfolgen wie „../“ ein, um aus dem aktuellen Verzeichnis auszubrechen.
Zusätzlich können Zeichen wie „%2F“ (kodierter Slash) genutzt werden, um den Angriff zu verschleiern.
So wird es möglich, auf Dateien zuzugreifen, auf die normalerweise kein Zugriff besteht.
Welche Auswirkungen kann ein Path Traversal Angriff haben und wie lässt er sich verhindern?
Durch Path Traversal können Angreifer auf sensible System- oder Konfigurationsdateien zugreifen, was als Ausgangspunkt für weitere Angriffe genutzt werden kann.
Schutzmaßnahmen umfassen:
-Die Validierung und Normalisierung von Dateipfaden (Sanitization)
Das Verwenden eines Whitelist-Ansatzes, bei dem festgelegt wird, welche Dateien überhaupt geöffnet werden dürfen.
Was ist das grundlegende Problem bei allen Formen der Code Injection?
Das Hauptproblem liegt im dynamischen Zusammenbau von Code aus Benutzereingaben, was dazu führt, dass Code und Daten vermischt werden.
Diese Vermischung erlaubt es einem Angreifer, Daten so zu manipulieren, dass sie wie ausführbarer Code interpretiert werden, wodurch Sicherheitslücken entstehen.
„Code vs. Data“
Das Beispiel zeigt, dass Entwickler in ihrem Quellcode eine klare Trennung zwischen SQL-Code (z. B. als grün markierter Teil) und später hinzukommenden Daten (z. B. lila markiert) erwarten.
Allerdings interpretiert die Datenbank diese Mischung nicht immer eindeutig – was letztlich zu Angriffen wie dem „1=1“-Szenario führen kann.
Es macht deutlich, dass die unachtsame Vermischung von Code und Daten ein großes Risiko darstellt.
Was ist die zentrale Empfehlung zur Vermeidung von Code Injection Angriffen?
*Es sollte stets darauf geachtet werden, dass eine klare Trennung zwischen Code und Daten besteht.
*Anstatt SQL-Abfragen oder Shell-Befehle dynamisch zusammenzustellen, sollten vorbereitete Anweisungen (Prepared Statements) und eine strenge Eingabevalidierung verwendet werden, um sicherzustellen, dass Eingaben niemals als ausführbarer Code falsch interpretiert werden können.
Fazit für Behebung der Server seitige Angriffen:
Die vorgestellten Beispiele – von SQL Injection über Remote Code Execution bis hin zu Path Traversal – machen deutlich, dass dynamisches Zusammenfügen von Code und Daten ein grundlegendes Sicherheitsrisiko darstellt.
Eine sorgfältige Validierung und Trennung von Eingaben ist essenziell, um die Integrität, Vertraulichkeit und Verfügbarkeit von Web-Anwendungen zu gewährleisten.
Was bedeutet es, dass HTTP/HTTPS „zustandslos“ (stateless) sind, und warum ist das in modernen Webanwendungen problematisch?
HTTP und HTTPS wurden ursprünglich als zustandslose Protokolle gestaltet.
Das heißt, jeder Request (Anfrage) wurde als in sich abgeschlossener Vorgang betrachtet („Ich hole mir die Webseite, schaue sie mir an und das war’s“).
Für moderne Anwendungen – etwa im Online-Shopping, Banking, Gaming oder sozialen Netzwerken – reicht das nicht aus, da der Server den Zustand eines Benutzers (wie etwa den Login-Status oder den Inhalt eines Warenkorbs) über mehrere Anfragen hinweg speichern muss.
Was passiert ohne Zustandsverwaltung in einer Webanwendung ?
Ohne die Zustandsverwaltung (z.B : Zustand eines Benutzers wie etwa den Login-Status oder den Inhalt eines Warenkorbs) müssten sich Benutzer bei jeder neuen Anfrage neu authentifizieren, was die Benutzerfreundlichkeit stark verringert.
Wie wird in Webanwendungen typischerweise ein „Zustand“ (Session) realisiert?
Um den Zustand eines Benutzers zu verwalten, wird eine Session (Sitzung) eingerichtet.
-> Beim ersten Kontakt mit der Anwendung wird dem Benutzer eine Session-ID zugewiesen.
-> Diese ID – in der Regel ein langer, zufälliger String – dient als eindeutiger „Staffelstab“, der über alle folgenden HTTP-Requests mitgeführt wird.
Dadurch kann der Webserver jederzeit erkennen, zu welcher Sitzung ein bestimmter Request gehört, ohne dass der Benutzer sich bei jeder Anfrage erneut authentifizieren muss.
