16.5 Webangriffe: SQL Injection, XSS, CSRF und unsichere Webanwendungen
Webanwendungen sind häufige Angriffsziele, weil sie oft öffentlich erreichbar sind und direkt mit Benutzern, Datenbanken, APIs und Backend-Systemen kommunizieren.
Typische Webangriffe sind:
- SQL Injection
- Cross-Site Scripting
- Cross-Site Request Forgery
- Directory Traversal
- File Upload Attack
- Session Hijacking
- Broken Authentication
- Broken Access Control
- unsichere API
- unsichere Fehlerausgaben
- unsichere Konfiguration
Merksatz:
Webangriffe nutzen häufig fehlerhafte Eingaben,
fehlende Zugriffskontrollen
oder unsichere Sitzungen aus.
Warum Webanwendungen gefährdet sind
Webanwendungen sind oft besonders angreifbar, weil sie:
öffentlich erreichbar sind
Benutzeranfragen verarbeiten
Datenbanken nutzen
Dateien entgegennehmen
Sitzungen verwalten
APIs bereitstellen
externe Dienste anbinden
mit sensiblen Daten arbeiten
Merksatz:
Je mehr Eingaben und Schnittstellen eine Anwendung hat,
desto größer ist die Angriffsfläche.
Eingaben als Risiko
Viele Webangriffe beginnen mit Benutzereingaben.
Beispiele für Eingaben:
Loginformular
Suchfeld
Kontaktformular
URL-Parameter
Cookie
HTTP-Header
Datei-Upload
API-Request
JSON-Daten
Formularfelder
Problem:
Die Anwendung vertraut Eingaben zu stark
oder verarbeitet sie unsicher.
Merksatz:
Benutzereingaben niemals blind vertrauen.
Client und Server unterscheiden
Client:
Browser oder App des Benutzers
Server:
Webserver,
Anwendung,
API
oder Backend-System
Wichtig:
Prüfungen im Browser allein reichen nicht aus.
Warum?
Ein Angreifer kann Browserprüfungen umgehen
und direkt eigene Anfragen an den Server senden.
Merksatz:
Sicherheitsprüfungen müssen serverseitig erfolgen.
Frontend-Validierung
Frontend-Validierung prüft Eingaben im Browser.
Beispiel:
Pflichtfeld prüfen
E-Mail-Format prüfen
Zeichenanzahl begrenzen
Vorteil:
bessere Benutzerführung
Nachteil:
leicht umgehbar
Merksatz:
Frontend-Validierung hilft Benutzern,
ist aber keine Sicherheitsgrenze.
Backend-Validierung
Backend-Validierung prüft Eingaben auf dem Server.
Sie ist sicherheitsrelevant.
Beispiele:
Datentyp prüfen
Wertebereich prüfen
erlaubte Zeichen prüfen
Dateityp prüfen
Berechtigung prüfen
Pflichtfelder prüfen
Länge begrenzen
Merksatz:
Sicherheitsrelevante Prüfung gehört ins Backend.
SQL Injection
SQL Injection ist ein Angriff auf Datenbankabfragen.
Dabei schleust ein Angreifer SQL-Code in Eingaben ein.
Ziel:
Daten auslesen
Daten verändern
Login umgehen
Daten löschen
Datenbankstruktur ausspähen
Rechte ausweiten
Merksatz:
SQL Injection nutzt unsicher zusammengesetzte Datenbankabfragen aus.
SQL Injection einfach erklärt
Eine Anwendung erwartet zum Beispiel:
Benutzername
und
Passwort
Wenn die Anwendung Eingaben unsicher direkt in SQL einfügt, kann ein Angreifer die Abfrage manipulieren.
Problem:
Eingabe wird nicht mehr nur als Wert behandelt,
sondern als Teil des SQL-Befehls.
Merksatz:
Bei SQL Injection wird Eingabe zu Befehl.
Unsichere SQL-Abfrage als Prinzip
Unsicheres Prinzip:
SQL-Befehl wird aus Text und Benutzereingabe zusammengebaut.
Beispielgedanke:
SELECT ...
WHERE user = Eingabe
AND password = Eingabe
Wenn Eingabe nicht sauber behandelt wird, kann sie die Logik der Abfrage verändern.
Merksatz:
SQL nicht durch ungeprüftes Zusammenkleben von Text und Eingaben bauen.
Folgen von SQL Injection
Mögliche Folgen:
Login ohne gültiges Passwort
Auslesen von Kundendaten
Auslesen von Passworthashes
Verändern von Datensätzen
Löschen von Tabellen
Manipulation von Bestellungen
Zugriff auf interne Informationen
vollständige Kompromittierung der Anwendung
Merksatz:
SQL Injection kann sehr schwere Datenbankangriffe ermöglichen.
Schutz vor SQL Injection
Wichtige Schutzmaßnahmen:
Prepared Statements
parametrisierte Abfragen
Eingabevalidierung
keine SQL-Verkettung mit Benutzereingaben
Rechte der Datenbankbenutzer begrenzen
Fehlermeldungen nicht detailliert ausgeben
Code Reviews
Web Application Firewall als zusätzliche Schicht
Merksatz:
Parametrisierte Abfragen sind die wichtigste Maßnahme gegen SQL Injection.
Prepared Statements
Prepared Statements trennen SQL-Befehl und Werte.
Die Datenbank erkennt:
Das ist der SQL-Befehl.
Das sind nur Werte.
Dadurch wird verhindert, dass Benutzereingaben als SQL-Code ausgeführt werden.
Merksatz:
Prepared Statements behandeln Eingaben als Daten,
nicht als Befehl.
Datenbankrechte begrenzen
Die Webanwendung sollte nicht mit einem Datenbankkonto arbeiten, das mehr Rechte hat als nötig.
Beispiel:
Anwendung muss nur lesen und schreiben,
aber keine Tabellen löschen.
Dann sollte das Datenbankkonto auch keine DROP-Rechte haben.
Merksatz:
Weniger Datenbankrechte begrenzen Schaden bei Angriffen.
Cross-Site Scripting
Cross-Site Scripting wird abgekürzt:
XSS
Bei XSS wird schädlicher Code in eine Webseite eingeschleust, der im Browser anderer Benutzer ausgeführt wird.
Meist geht es um JavaScript im Browser.
Merksatz:
XSS greift Benutzer über die Webseite und den Browser an.
XSS einfach erklärt
Eine Webseite zeigt Benutzereingaben wieder an.
Beispiel:
Kommentar
Profilname
Suchbegriff
Chatnachricht
Wenn die Eingabe nicht korrekt behandelt wird, kann ein Angreifer Skriptcode einfügen.
Dieser Code läuft dann im Browser anderer Benutzer.
Merksatz:
XSS entsteht,
wenn Eingaben ungefiltert als aktive Webseite ausgegeben werden.
Folgen von XSS
Mögliche Folgen:
Session-Cookies stehlen
Benutzeraktionen auslösen
Webseiteninhalt manipulieren
Phishing innerhalb echter Webseite
Tokens auslesen
Benutzer umleiten
Schadcode nachladen
Formulardaten abgreifen
Merksatz:
XSS kann echte Webseiten für Angriffe gegen Benutzer missbrauchen.
Stored XSS
Stored XSS bedeutet:
Schadcode wird dauerhaft gespeichert.
Beispiel:
Kommentar mit Schadcode wird in Datenbank gespeichert.
Wenn andere Benutzer die Seite öffnen, wird der Schadcode ausgeführt.
Merksatz:
Stored XSS bleibt gespeichert und trifft mehrere Benutzer.
Reflected XSS
Reflected XSS bedeutet:
Schadcode wird über eine Anfrage eingeschleust
und direkt in der Antwort zurückgegeben.
Beispiel:
manipulierter Link enthält Schadcode.
Benutzer klickt den Link, die Webseite gibt den Inhalt zurück, Browser führt ihn aus.
Merksatz:
Reflected XSS funktioniert oft über manipulierte Links.
DOM-based XSS
DOM-based XSS entsteht, wenn JavaScript im Browser unsicher mit Daten arbeitet.
Dabei muss der Schadcode nicht unbedingt vom Server direkt eingefügt werden.
Problematisch sind zum Beispiel:
unsichere Verarbeitung von URL-Fragmenten
unsichere DOM-Manipulation
ungeprüftes innerHTML
unsichere Client-Skripte
Merksatz:
DOM-XSS entsteht im Browser durch unsicheren JavaScript-Code.
Schutz vor XSS
Wichtige Schutzmaßnahmen:
Ausgaben korrekt escapen
Eingaben validieren
Content Security Policy
HttpOnly Cookies
Secure Cookies
SameSite Cookies
sichere Frameworks nutzen
keine ungeprüften HTML-Ausgaben
Code Reviews
gefährliche Funktionen vermeiden
Merksatz:
Gegen XSS ist korrektes Escaping bei der Ausgabe besonders wichtig.
Escaping
Escaping bedeutet:
Sonderzeichen werden so umgewandelt,
dass sie nicht als Code ausgeführt werden.
Beispiel:
Ein kleiner-als-Zeichen wird nicht als HTML-Tag interpretiert,
sondern als sichtbares Zeichen ausgegeben.
Merksatz:
Escaping macht aus potenziellem Code normalen Text.
Content Security Policy
Content Security Policy wird abgekürzt:
CSP
Eine CSP ist eine Sicherheitsrichtlinie im Browser.
Sie kann festlegen:
welche Skripte erlaubt sind
von welchen Quellen Inhalte geladen werden dürfen
ob Inline-Skripte erlaubt sind
ob externe Ressourcen erlaubt sind
Merksatz:
CSP begrenzt,
welche Inhalte der Browser ausführen darf.
Vorteil:
erschwert Cookie-Diebstahl bei XSS
Wichtig:
HttpOnly schützt nicht vor allen XSS-Folgen,
aber reduziert ein wichtiges Risiko.
Merksatz:
HttpOnly schützt Cookies vor direktem JavaScript-Zugriff.
Vorteil:
Cookie wird nicht über unverschlüsselte HTTP-Verbindungen gesendet.
Merksatz:
Secure Cookies gehören zu HTTPS-Webanwendungen.
SameSite steuert, ob Cookies bei seitenübergreifenden Anfragen mitgesendet werden.
Es hilft besonders gegen CSRF.
Mögliche Prinzipien:
streng
teilweise erlaubt
ohne Einschränkung
Merksatz:
SameSite begrenzt Cookie-Versand bei fremden Webseiten.
Cross-Site Request Forgery
Cross-Site Request Forgery wird abgekürzt:
CSRF
Bei CSRF wird ein angemeldeter Benutzer dazu gebracht, unbewusst eine Aktion in einer Webanwendung auszulösen.
Beispiel:
Benutzer ist im Online-Portal angemeldet.
Benutzer besucht eine bösartige Webseite.
Diese Webseite löst im Hintergrund eine Anfrage an das Online-Portal aus.
Merksatz:
CSRF missbraucht eine bestehende Anmeldung für fremde Aktionen.
CSRF einfach erklärt
CSRF funktioniert, weil der Browser bei Anfragen an eine Webseite oft automatisch Cookies mitsendet.
Wenn der Benutzer dort angemeldet ist, kann die Anfrage als gültig erscheinen.
Mögliche Aktionen:
E-Mail-Adresse ändern
Passwortänderung starten
Bestellung auslösen
Einstellung ändern
Benutzer hinzufügen
Überweisung vorbereiten
Merksatz:
CSRF nutzt automatisch mitgesendete Sitzungsinformationen aus.
Schutz vor CSRF
Wichtige Schutzmaßnahmen:
CSRF-Token
SameSite Cookies
Prüfung von Origin oder Referer
erneute Bestätigung sensibler Aktionen
MFA oder Passwortabfrage bei kritischen Aktionen
keine zustandsändernden Aktionen per GET
saubere Sessionverwaltung
Merksatz:
CSRF-Token schützen,
weil fremde Seiten den gültigen Token nicht kennen.
CSRF-Token
Ein CSRF-Token ist ein zufälliger Wert, der in Formularen oder Anfragen mitgesendet wird.
Die Anwendung prüft:
Stimmt der Token zur Sitzung?
Wenn nicht, wird die Aktion abgelehnt.
Merksatz:
CSRF-Token beweist,
dass die Anfrage aus der echten Anwendung kommt.
SQL Injection, XSS und CSRF vergleichen
| Angriff | Ziel | Kernproblem |
|---|---|---|
| SQL Injection | Datenbank | Eingabe wird Teil von SQL |
| XSS | Browser anderer Benutzer | Eingabe wird als Skript ausgeführt |
| CSRF | angemeldete Sitzung | fremde Seite löst Aktion aus |
Merksatz:
SQL Injection trifft Datenbank.
XSS trifft Browser.
CSRF missbraucht Sitzung.
Directory Traversal
Directory Traversal bedeutet:
Ein Angreifer versucht,
über Pfadangaben auf Dateien außerhalb des erlaubten Bereichs zuzugreifen.
Beispielprinzip:
Statt erlaubter Datei wird versucht,
über Pfadbestandteile in übergeordnete Verzeichnisse zu gelangen.
Mögliche Ziele:
Konfigurationsdateien
Passwortdateien
Quellcode
Logdateien
Systemdateien
Merksatz:
Directory Traversal nutzt unsichere Dateipfade aus.
Schutz vor Directory Traversal
Maßnahmen:
Dateinamen validieren
erlaubte Dateien per ID statt Pfad auswählen
Pfade normalisieren und prüfen
Zugriff auf festes Verzeichnis begrenzen
keine direkten Benutzereingaben als Dateipfad nutzen
Rechte des Webserver-Prozesses begrenzen
Merksatz:
Benutzer sollten keine freien Systempfade bestimmen können.
File Upload Attack
Bei einem File Upload Attack lädt ein Angreifer eine gefährliche Datei hoch.
Beispiele:
ausführbares Skript
Webshell
Malware
manipuliertes Bild
Datei mit falscher Endung
übergroße Datei
Archivbombe
Mögliche Folgen:
Codeausführung
Malware-Verteilung
Speicherüberlastung
Angriff auf andere Benutzer
Datenabfluss
Merksatz:
Datei-Uploads sind gefährlich,
wenn Inhalt,
Typ
und Speicherort nicht geprüft werden.
Schutz bei Datei-Uploads
Maßnahmen:
erlaubte Dateitypen begrenzen
Dateigröße begrenzen
MIME-Type prüfen
Dateiendung prüfen
Inhalt prüfen
Malware-Scan
Dateien außerhalb des Webroots speichern
zufällige Dateinamen verwenden
Ausführrechte verhindern
Uploads getrennt verarbeiten
Merksatz:
Hochgeladene Dateien nie ungeprüft ausführbar speichern.
Webshell
Eine Webshell ist ein hochgeladenes oder eingeschleustes Skript, mit dem Angreifer Befehle auf einem Server ausführen können.
Risiko:
vollständige Serverübernahme
Datenabfluss
weitere Angriffe
Backdoor
Merksatz:
Webshell = Fernsteuerung über Webskript.
Broken Authentication
Broken Authentication bedeutet:
Die Anmeldung oder Sitzungsverwaltung ist unsicher.
Beispiele:
schwache Passwortrichtlinien
kein MFA
Session läuft zu lange
Session-ID wird nicht erneuert
unsichere Passwortzurücksetzung
Tokens werden unsicher gespeichert
Brute Force nicht begrenzt
Merksatz:
Broken Authentication gefährdet Benutzerkonten und Sitzungen.
Schutz gegen Broken Authentication
Maßnahmen:
MFA
starke Passwortrichtlinien
Passwortmanager unterstützen
Rate Limiting
sichere Passwortzurücksetzung
Session-Rotation nach Login
kurze Sitzungslaufzeiten je nach Risiko
sichere Token-Speicherung
Login-Monitoring
Merksatz:
Anmeldung und Sitzungen müssen besonders geschützt werden.
Broken Access Control
Broken Access Control bedeutet:
Benutzer können auf Funktionen oder Daten zugreifen,
für die sie keine Berechtigung haben.
Beispiele:
Benutzer sieht fremde Rechnung
normaler Benutzer ruft Adminfunktion auf
URL-ID wird geändert und fremde Daten erscheinen
API gibt mehr Daten zurück als erlaubt
versteckte Schaltfläche reicht als Schutz
Merksatz:
Zugriffskontrolle muss serverseitig geprüft werden.
IDOR
IDOR steht für:
Insecure Direct Object Reference
Dabei kann ein Benutzer durch Änderung einer ID auf fremde Objekte zugreifen.
Beispiel:
/rechnung/1001
wird geändert zu:
/rechnung/1002
Wenn die Anwendung nicht prüft, ob diese Rechnung zum Benutzer gehört, liegt ein Fehler vor.
Merksatz:
IDOR ist fehlende Zugriffskontrolle bei direkten Objekt-IDs.
Schutz gegen Broken Access Control
Maßnahmen:
serverseitige Berechtigungsprüfung
Rollen- und Rechtekonzept
Zugriff pro Objekt prüfen
keine Sicherheit nur über versteckte Buttons
Standardmäßig Zugriff verweigern
Adminfunktionen getrennt schützen
API-Berechtigungen prüfen
Tests mit verschiedenen Benutzerrollen
Merksatz:
Jeder Zugriff muss auf dem Server autorisiert werden.
Unsichere API
APIs sind Schnittstellen zwischen Anwendungen.
Risiken:
fehlende Authentifizierung
fehlende Autorisierung
zu viele Daten in Antwort
keine Rate Limits
unsichere Tokens
unsichere CORS-Konfiguration
fehlende Eingabeprüfung
detaillierte Fehlermeldungen
Merksatz:
APIs brauchen dieselben Sicherheitsprüfungen wie Weboberflächen.
CORS
CORS steht für:
Cross-Origin Resource Sharing
CORS steuert, welche fremden Webseiten im Browser auf eine API zugreifen dürfen.
Unsichere CORS-Konfigurationen können gefährlich sein, wenn zu viele Ursprünge erlaubt werden.
Merksatz:
CORS regelt Browserzugriffe zwischen verschiedenen Ursprüngen.
Rate Limiting bei APIs
APIs sollten Anfragen begrenzen.
Schutz gegen:
Brute Force
Scraping
DDoS auf Anwendungsebene
Missbrauch von API-Schlüsseln
unbeabsichtigte Überlastung
Merksatz:
APIs brauchen Rate Limits gegen Missbrauch und Überlastung.
Unsichere Fehlerausgaben
Fehlermeldungen können Angreifern helfen.
Problematische Informationen:
Datenbankfehler
Pfade
Stacktraces
Versionsnummern
interne IP-Adressen
verwendete Frameworks
SQL-Abfragen
geheime Konfigurationen
Merksatz:
Fehlermeldungen für Benutzer knapp,
Details nur intern loggen.
Security Headers
Security Headers sind HTTP-Header, die Browser-Sicherheitsfunktionen steuern.
Beispiele:
Content-Security-Policy
Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy
X-Frame-Options oder frame-ancestors
Merksatz:
Security Headers härten Webanwendungen im Browser.
HSTS
HSTS steht für:
HTTP Strict Transport Security
HSTS weist Browser an, eine Webseite nur per HTTPS aufzurufen.
Vorteil:
Schutz vor Downgrade auf HTTP
Merksatz:
HSTS erzwingt HTTPS im Browser.
Clickjacking
Clickjacking bedeutet:
Benutzer werden dazu gebracht,
auf etwas zu klicken,
ohne zu erkennen,
was sie tatsächlich anklicken.
Oft wird eine echte Webseite unsichtbar oder überlagert eingebettet.
Schutz:
X-Frame-Options
Content-Security-Policy frame-ancestors
Merksatz:
Clickjacking täuscht Benutzer bei Klickaktionen.
Unsichere Konfiguration
Unsichere Webkonfigurationen sind häufig.
Beispiele:
Standardpasswörter
Debug-Modus aktiv
Verzeichnislisting aktiv
unnötige Dienste
alte TLS-Versionen
unsichere Cipher Suites
fehlende Security Headers
Adminoberfläche öffentlich erreichbar
Testdaten in Produktion
Beispielseiten aktiv
Merksatz:
Sichere Webanwendungen brauchen sichere Konfiguration.
Verzeichnislisting
Verzeichnislisting bedeutet:
Webserver zeigt den Inhalt eines Ordners an,
wenn keine Startdatei vorhanden ist.
Risiko:
Dateien werden sichtbar,
die nicht sichtbar sein sollten.
Beispiele:
Backups
alte Versionen
Konfigurationsdateien
Uploads
Skripte
Merksatz:
Verzeichnislisting auf Webservern deaktivieren.
Web Application Firewall
Web Application Firewall wird abgekürzt:
WAF
Eine WAF filtert HTTP- und HTTPS-Anfragen.
Sie kann helfen gegen:
SQL Injection
XSS
bekannte Angriffsmuster
bösartige Bots
verdächtige Parameter
bestimmte Protokollverstöße
Wichtig:
Eine WAF ersetzt keine sichere Programmierung.
Merksatz:
WAF ist zusätzliche Schutzschicht,
kein Ersatz für sicheren Code.
Secure Coding
Secure Coding bedeutet:
Software wird von Anfang an sicher entwickelt.
Dazu gehören:
Eingabevalidierung
Ausgabe-Escaping
parametrisierte Datenbankabfragen
sichere Authentifizierung
Zugriffskontrolle
sichere Fehlerbehandlung
sichere Sessionverwaltung
sichere Dateiverarbeitung
Code Reviews
Sicherheitstests
Merksatz:
Sicherheit muss in der Entwicklung mitgedacht werden.
Code Review
Code Review bedeutet:
Quellcode wird von anderen Personen geprüft.
Ziele:
Fehler finden
Sicherheitsprobleme erkennen
Qualität verbessern
Wissen teilen
Standards einhalten
Merksatz:
Code Reviews helfen,
Sicherheitsfehler früh zu finden.
Penetrationstest
Ein Penetrationstest ist eine geplante Sicherheitsprüfung, bei der Systeme kontrolliert auf Schwachstellen getestet werden.
Wichtig:
klarer Auftrag
definierter Umfang
erlaubter Zeitraum
Dokumentation
keine unkontrollierte Beschädigung
Bericht mit Maßnahmen
Merksatz:
Penetrationstest ist kontrollierte Angriffssimulation.
Schwachstellenscan
Ein Schwachstellenscan sucht automatisiert nach bekannten Schwachstellen.
Er prüft zum Beispiel:
veraltete Software
offene Ports
bekannte CVEs
unsichere Dienste
fehlende Patches
schwache TLS-Konfiguration
Merksatz:
Schwachstellenscan findet bekannte Probleme,
ersetzt aber keinen vollständigen Penetrationstest.
OWASP
OWASP steht für:
Open Worldwide Application Security Project
OWASP ist bekannt für Sicherheitswissen zu Webanwendungen, zum Beispiel Listen häufiger Webrisiken.
Für Prüfungen ist wichtig:
Webanwendungen brauchen systematische Sicherheitsmaßnahmen.
Merksatz:
OWASP steht für praxisnahes Webanwendungs-Sicherheitswissen.
Typische Webschutzmaßnahmen
Wichtige Maßnahmen:
Eingaben validieren
Ausgaben escapen
Prepared Statements
CSRF-Token
sichere Cookies
Security Headers
HTTPS
HSTS
MFA
Rate Limiting
Rollen- und Rechteprüfung
sichere Datei-Uploads
sichere Fehlerbehandlung
Logging
Monitoring
Code Reviews
WAF
Patchmanagement
Merksatz:
Websicherheit braucht sichere Entwicklung,
sichere Konfiguration
und Überwachung.
Typische IHK-Fragen
In AP1 und AP2 kann zum Beispiel gefragt werden:
- Was ist SQL Injection?
- Wie schützt man sich vor SQL Injection?
- Was sind Prepared Statements?
- Was ist Cross-Site Scripting?
- Was ist der Unterschied zwischen Stored XSS und Reflected XSS?
- Wie schützt man sich vor XSS?
- Was ist Cross-Site Request Forgery?
- Wie schützen CSRF-Token?
- Was ist Directory Traversal?
- Warum sind Datei-Uploads gefährlich?
- Was ist eine Webshell?
- Was bedeutet Broken Authentication?
- Was bedeutet Broken Access Control?
- Was ist IDOR?
- Warum muss Zugriff serverseitig geprüft werden?
- Was ist CORS?
- Warum brauchen APIs Rate Limiting?
- Was ist HSTS?
- Was ist Clickjacking?
- Was ist eine WAF?
- Warum ersetzt eine WAF keine sichere Programmierung?
Typische Prüfungsfallen
Frontend-Validierung ist keine Sicherheitsgrenze.
Sicherheitsprüfung gehört ins Backend.
SQL Injection betrifft Datenbankabfragen.
Prepared Statements schützen gegen SQL Injection.
XSS betrifft Browser anderer Benutzer.
XSS-Schutz braucht korrektes Escaping.
Stored XSS wird gespeichert.
Reflected XSS kommt über Anfrage zurück.
DOM-XSS entsteht im Browser.
CSRF missbraucht bestehende Anmeldung.
CSRF ist nicht dasselbe wie XSS.
SameSite Cookies helfen gegen CSRF.
Directory Traversal nutzt Dateipfade aus.
Datei-Uploads nie ungeprüft ausführbar speichern.
Webshell kann Server fernsteuerbar machen.
Broken Authentication betrifft Anmeldung und Sitzung.
Broken Access Control betrifft Berechtigungen.
Versteckte Buttons sind keine Zugriffskontrolle.
IDOR entsteht durch fehlende Objektprüfung.
APIs brauchen Authentifizierung,
Autorisierung
und Rate Limits.
Fehlerdetails nicht öffentlich anzeigen.
HSTS erzwingt HTTPS.
WAF ersetzt keinen sicheren Code.
Wichtige Begriffe kurz erklärt
| Begriff | Kurze Erklärung |
|---|---|
| Webangriff | Angriff auf Webanwendung oder API |
| Eingabevalidierung | Prüfung von Benutzereingaben |
| Frontend | Browser- oder Client-Seite |
| Backend | Server-Seite |
| SQL Injection | Einschleusen von SQL-Code |
| Prepared Statement | getrennte SQL-Abfrage mit Parametern |
| XSS | Cross-Site Scripting |
| Stored XSS | dauerhaft gespeichertes XSS |
| Reflected XSS | XSS über zurückgespiegelte Anfrage |
| DOM-XSS | XSS durch Browser-DOM-Verarbeitung |
| Escaping | Umwandeln von Sonderzeichen |
| CSP | Content Security Policy |
| HttpOnly | Cookie nicht per JavaScript lesbar |
| Secure Cookie | Cookie nur über HTTPS |
| SameSite | Cookie-Regel für fremde Seiten |
| CSRF | Cross-Site Request Forgery |
| CSRF-Token | Schutzwert gegen CSRF |
| Directory Traversal | Zugriff über manipulierte Pfade |
| File Upload Attack | Angriff über hochgeladene Datei |
| Webshell | Webskript zur Fernsteuerung |
| Broken Authentication | unsichere Anmeldung oder Sitzung |
| Broken Access Control | fehlerhafte Zugriffskontrolle |
| IDOR | Zugriff über unsichere Objekt-ID |
| API | Programmierschnittstelle |
| CORS | Cross-Origin Resource Sharing |
| Rate Limiting | Begrenzung von Anfragen |
| Security Headers | HTTP-Sicherheitsheader |
| HSTS | HTTPS-Erzwingung |
| Clickjacking | Täuschung bei Klickaktionen |
| WAF | Web Application Firewall |
| Secure Coding | sichere Softwareentwicklung |
| Code Review | Prüfung von Quellcode |
| Penetrationstest | kontrollierte Angriffssimulation |
| Schwachstellenscan | automatisierte Suche bekannter Schwachstellen |
| OWASP | Organisation für Webanwendungssicherheit |
IHK-sichere Kurzformulierung
Webangriffe richten sich gegen Webanwendungen, APIs, Sitzungen, Eingaben und Datenbanken. SQL Injection entsteht, wenn Benutzereingaben unsicher in Datenbankabfragen eingebaut werden; Schutz bieten Prepared Statements und parametrisierte Abfragen. Cross-Site Scripting schleust Skriptcode in Webseiten ein, der im Browser anderer Benutzer ausgeführt wird; Schutz bieten korrektes Escaping, sichere Frameworks, Content Security Policy und sichere Cookies. Cross-Site Request Forgery missbraucht eine bestehende Anmeldung, um ungewollte Aktionen auszulösen; Schutz bieten CSRF-Token und SameSite Cookies. Weitere Risiken sind unsichere Datei-Uploads, Directory Traversal, Broken Authentication, Broken Access Control, unsichere APIs und unsichere Konfiguration. Eine WAF kann unterstützen, ersetzt aber keine sichere Programmierung.
Merksätze
Webanwendungen sind häufig öffentlich erreichbar.
Benutzereingaben niemals blind vertrauen.
Frontend-Prüfung ist keine Sicherheitsgrenze.
Sicherheitsprüfung gehört ins Backend.
SQL Injection macht Eingabe zu SQL-Befehl.
Prepared Statements trennen Befehl und Wert.
Datenbankrechte begrenzen.
XSS führt Skript im Browser aus.
Stored XSS wird gespeichert.
Reflected XSS kommt über Anfrage zurück.
DOM-XSS entsteht im Browser.
Escaping macht Code zu Text.
CSP begrenzt ausführbare Inhalte.
HttpOnly schützt Cookies vor JavaScript-Zugriff.
Secure Cookie nur über HTTPS.
SameSite hilft gegen CSRF.
CSRF missbraucht bestehende Anmeldung.
CSRF-Token schützt vor fremden Aktionen.
SQL Injection,
XSS
und CSRF nicht verwechseln.
Directory Traversal nutzt Pfade aus.
Datei-Uploads streng prüfen.
Webshell bedeutet Fernsteuerungsrisiko.
Broken Authentication betrifft Anmeldung.
Broken Access Control betrifft Rechte.
IDOR ist fehlende Objektberechtigung.
APIs brauchen dieselbe Sicherheit wie Weboberflächen.
CORS nicht zu breit erlauben.
Rate Limiting schützt APIs.
Fehlerdetails nicht öffentlich anzeigen.
Security Headers härten Browser-Schutz.
HSTS erzwingt HTTPS.
Clickjacking täuscht Klicks.
WAF ist Zusatzschutz.
WAF ersetzt keinen sicheren Code.
Secure Coding früh einplanen.
Code Reviews finden Fehler früh.
Schwachstellenscan findet bekannte Probleme.
Penetrationstest prüft kontrolliert tiefer.