CompTIA SY0-701: Anwendungs- & Websicherheit — Lernleitfaden

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Teil des CompTIA Security+ SY0-701 — Lernleitfaden. Üben Sie mit verifizierten Antworten im CompTIA-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Moderne Anwendungen befinden sich an der Schnittstelle von Geschäftslogik, sensiblen Daten und nicht vertrauenswürdigen Benutzereingaben. Da Web- und mobile Frontends dem gesamten Internet ausgesetzt sind, stellen sie eine der größten und am häufigsten ausgenutzten Angriffsflächen in jedem Unternehmen dar. Ihre Verteidigung erfordert mehrschichtige Kontrollen, die bei der Art und Weise, wie Code geschrieben wird, beginnen und sich über Laufzeitschutz, Integritätsprüfung und kontinuierliche Tests erstrecken.

Injection-Angriffe

Injection bleibt die archetypische Web-Schwachstelle. Sie tritt auf, wenn eine Anwendung nicht vertrauenswürdige Eingaben mit einem Interpreter – einer SQL-Abfrage, einem Shell-Befehl, einem LDAP-Filter, einem XML-Parser oder einer Template-Engine – verknüpft, ohne Code und Daten sauber zu trennen. Bei einer SQL-Injection (SQLi) manipuliert ein Angreifer eine Abfrage so, dass die Datenbank vom Angreifer gesteuerte Logik ausführt. Ein klassisches anfälliges Muster in PHP sieht wie folgt aus:

$query = "SELECT * FROM users WHERE username = '" . $_GET['user'] . "'";

Die Eingabe von admin' OR '1'='1 wandelt die Abfrage in eine Tautologie um, die jede Zeile zurückgibt. Fortgeschrittenere Varianten umfassen Union-basierte Extraktion (' UNION SELECT credit_card FROM payments--), blinde boolesche oder zeitbasierte Inferenz (' AND SLEEP(5)--) und Out-of-Band-Exfiltration durch DNS-Callbacks. Die endgültige Lösung sind parametrisierte Abfragen oder Prepared Statements, die die Abfragevorlage und ihre Parameter als separate Strukturen an die Datenbank senden:

cursor.execute("SELECT * FROM users WHERE username = %s", (user_input,))

Command-Injection folgt demselben Muster, zielt aber auf die Shell des Betriebssystems ab. Code wie os.system("ping " + host) ermöglicht es einem Angreifer, 8.8.8.8; cat /etc/passwd zu übermitteln und beliebige Befehle auszuführen. Die Behebung erfordert die vollständige Vermeidung von Shell-Aufrufen, die Verwendung von APIs, die Argument-Arrays akzeptieren (subprocess.run(["ping", host], shell=False)), und die Anwendung einer strengen Allow-List-Validierung für jeden Wert, der eine Shell erreichen muss.

Cross-Site-Scripting und CSRF

Cross-Site-Scripting (XSS) ist die Einschleusung von bösartigem Skriptcode in Seiten, die von einer vertrauenswürdigen Anwendung gerendert werden. Dies führt dazu, dass der Browser des Opfers den Code des Angreifers innerhalb des Ursprungs der Website ausführt. Reflected XSS schleudert Payloads über einen anfälligen Parameter zurück; Stored XSS speichert den Payload in der Datenbank und liefert ihn an jeden Betrachter aus; DOM-basiertes XSS findet vollständig im clientseitigen JavaScript statt, das nicht vertrauenswürdige Daten in innerHTML, document.write oder ähnliche Sinks schreibt. Die Folgen reichen von Session Hijacking und Keylogging bis hin zur vollständigen Übernahme des Kontos durch erzwungene Aktionen.

Cross-Site Request Forgery (CSRF) ist ein eigenständiger, aber komplementärer Angriff. Dabei wird die automatische Einbindung von Cookies durch den Browser missbraucht, um einen authentifizierten Benutzer dazu zu verleiten, eine unerwünschte Anfrage zu senden – zum Beispiel ein verstecktes Formular auf einer bösartigen Website, das einen POST-Request an bank.com/transfer sendet. Zu den Abwehrmaßnahmen gehören Synchronizer-Token (zufällige, pro Sitzung erstellte Werte, die in Formulare eingebettet und serverseitig überprüft werden), das Cookie-Attribut SameSite=Lax oder SameSite=Strict und die Forderung nach einer erneuten Authentifizierung für sensible Aktionen. XSS und CSRF werden oft verwechselt, aber XSS führt Code im Browser des Opfers aus, während CSRF den Browser lediglich veranlasst, eine Anfrage zu senden. Bemerkenswert ist, dass ein erfolgreicher XSS-Angriff die meisten CSRF-Abwehrmaßnahmen aushebeln kann.

Sichere Programmierung: Eingabevalidierung vs. Ausgabekodierung

Zwei Kontrollmechanismen werden häufig verwechselt, obwohl sie unterschiedliche Probleme lösen. Die Eingabevalidierung stellt sicher, dass Daten einer erwarteten Struktur entsprechen – Länge, Typ, Zeichensatz, Bereich, Format –, bevor die Anwendung darauf reagiert. Sie sollte auf dem Server stattfinden, wobei nach Möglichkeit Allow-Lists verwendet werden sollten (^[A-Za-z0-9_]{3,20}$ für einen Benutzernamen). Die clientseitige Validierung mit JavaScript ist nur ein Usability-Feature; sie kann mit jedem HTTP-Proxy umgangen werden und darf niemals die Sicherheitsgrenze darstellen.

Die Ausgabekodierung stellt sicher, dass Daten in jedem Kontext, in den sie fließen, sicher gerendert werden. Dieselbe Zeichenfolge, die eine vollkommen gültige Eingabe ist, muss je nach Zielort möglicherweise unterschiedlich behandelt werden: Der HTML-Body-Kontext erfordert eine HTML-Entity-Kodierung (< → <), der Attribut-Kontext eine Kodierung für Attribute in Anführungszeichen, der JavaScript-Kontext ein \xHH-Escaping und URLs eine Prozent-Kodierung. Ein Benutzername wie O'Brien ist eine legitime Eingabe, muss aber als O'Brien kodiert werden, wenn er in HTML platziert wird. Eingabevalidierung kann die Ausgabekodierung nicht ersetzen, und Kodierung kann die Validierung nicht ersetzen – sie lösen unterschiedliche Probleme an unterschiedlichen Punkten im Datenlebenszyklus.

Zusätzliche Härtungsmaßnahmen umfassen Content Security Policy (CSP)-Header zur Einschränkung von Skriptquellen, HttpOnly- und Secure-Flags bei Sitzungs-Cookies sowie parametrisierte APIs an jeder Vertrauensgrenze.

WAFs und Schutzmaßnahmen für Datei-Uploads

Eine Web Application Firewall (WAF) inspiziert den HTTP-Verkehr und blockiert Anfragen, die bekannten bösartigen Mustern entsprechen – SQLi-Signaturen, XSS-Payloads, Path-Traversal-Sequenzen, Protokollanomalien. Eingesetzt als Reverse Proxy (ModSecurity mit dem OWASP Core Rule Set, AWS WAF, Cloudflare, F5) bietet sie wertvolles virtuelles Patching, wenn eine Schwachstelle entdeckt wird, bevor der Code korrigiert werden kann. Eine WAF ist jedoch eine kompensierende Kontrolle und kein Ersatz für sichere Programmierung. Erfahrene Angreifer umgehen WAFs routinemäßig durch Kodierungstricks, HTTP Parameter Pollution und Payload-Fragmentierung.

Datei-Uploads verdienen besondere Aufmerksamkeit, da sie nicht vertrauenswürdige Inhalte mit serverseitiger Speicherung und oft auch Ausführung kombinieren. Zu den Schutzmaßnahmen gehören die Validierung des Dateityps durch Überprüfung der Magic Bytes anstatt dem Vertrauen auf die Dateierweiterung oder den Content-Type-Header, das Speichern von Uploads außerhalb des Web-Roots, das Umbenennen von Dateien in serverseitig generierte Bezeichner (um Directory Traversal durch manipulierte Dateinamen zu verhindern), das Scannen mit Antivirensoftware vor der Speicherung und das Ausliefern von benutzergenerierten Inhalten von einer separaten Domain, um die Ausführung von Skripten im selben Ursprung (Same-Origin) zu verhindern.

Praktisches Szenario: SQL-Injection führt zur vollständigen Kompromittierung der Datenbank

Der Produktsuche-Endpunkt eines Einzelhandelsunternehmens akzeptierte einen category-Parameter, der ohne Bereinigung direkt in eine SQL-Abfrage verkettet wurde. Ein Sicherheitsforscher entdeckte, dass die Übermittlung von ' UNION SELECT table_name,null,null FROM information_schema.tables-- eine Liste aller Datenbanktabellen in der Antwort zurückgab. Nachfolgende Anfragen extrahierten die customers-Tabelle, was zur Preisgabe von 1,2 Millionen Datensätzen führte, einschließlich Namen, E-Mail-Adressen und mit bcrypt gehashten Passwörtern. Der Angreifer entdeckte auch eine Stored Procedure, die per SQL-Injection aufgerufen werden konnte, um Dateien in das Web-Root-Verzeichnis zu schreiben, was die Bereitstellung einer Webshell und die vollständige Kompromittierung des Servers ermöglichte. Die Schwachstelle bestand seit drei Jahren und wurde bei zwei früheren Penetrationstests übersehen, da die Tester nur das Anmeldeformular und nicht den Such-Endpunkt getestet hatten. Die Lektion: Tests auf Injection-Schwachstellen müssen jeden Parameter in jedem Endpunkt abdecken, nicht nur die offensichtlichen Authentifizierungspfade.

← Vorfallreaktion · Alle Domänen · Cloud- →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →