Verhindert die Umstellung der Seite auf HTTPS SQL-Injection und XSS?
Kurzantwort
Nein. HTTPS verschlüsselt den Kanal, sodass Angreifer den Verkehr unterwegs nicht lesen oder manipulieren können, aber die bösartige Eingabe kommt an, wird entschlüsselt und von deiner App genau wie zuvor verarbeitet. SQL-Injection und XSS sind Fehler der Anwendungsschicht, die durch parametrisierte Abfragen und Output-Encoding behoben werden, nicht durch Transportverschlüsselung. Der Irrtum unterstellt, Verschlüsselung bereinige Inhalte — tut sie nicht; der Angreifer sendet die Payload einfach über die HTTPS-Verbindung.
„Wir sind jetzt auf HTTPS, also sind wir sicher” ist einer der hartnäckigsten Mythen der Web-Sicherheit. HTTPS ist essenziell, löst aber ein völlig anderes Problem als Injection. Diese Frage prüft, ob ein Kandidat ein Mittel auf der richtigen Schicht platzieren kann.
Was HTTPS tatsächlich tut
TLS (das S in HTTPS) liefert drei Dinge auf dem Netzwerkpfad: Vertraulichkeit (Lauscher können den Verkehr nicht lesen), Integrität (er kann unterwegs nicht heimlich verändert werden) und Authentifizierung des Servers. Das vereitelt Man-in-the-Middle-Angriffe, Paket-Sniffing in feindlichem WLAN und Anmeldedaten-Diebstahl über das Netz. Es ist ein Mittel der Transportschicht. Es sagt nichts darüber aus, ob die Daten in der Anfrage sicher zu verarbeiten sind.
Warum Injection unberührt bleibt
SQL-Injection und XSS sind Fehler der Anwendungsschicht. Der Angreifer übermittelt eine Eingabe wie ' OR 1=1 -- oder <script>...</script> über ein völlig normales Formular oder einen API-Aufruf. Über HTTPS wird diese Payload vom Browser zum Server verschlüsselt, dann am Server entschlüsselt und deinem Code genau wie ein harmloser Wert übergeben. Verkettet dein Code sie in einen SQL-String, feuert die Injection; spiegelt er sie ohne Encoding in HTML, läuft das Skript im Browser des Opfers. Verschlüsselung schützt die Payload vor Dritten — sie hindert die Anwendung nicht daran, sie falsch zu behandeln. Die Vorstellung, eine verschlüsselte Payload „könne die Datenbank nicht erreichen”, stellt die Architektur auf den Kopf.
Die korrekten Abwehrmaßnahmen
Behebe Injection dort, wo sie lebt, im Code:
- SQL-Injection: nutze parametrisierte Abfragen / Prepared Statements, damit Eingaben stets als Daten und nie als ausführbares SQL behandelt werden. Ergänze Datenbankkonten mit minimalen Rechten.
- XSS: wende kontextabhängiges Output-Encoding beim Rendern von Nutzerdaten an, validiere Eingaben und setze eine Content-Security-Policy als Tiefenverteidigung ein.
HTTPS und diese Mittel ergänzen einander, ersetzen sich nicht. Setze beides um. Die Kernaussage: HTTPS sichert die Leitung; parametrisierte Abfragen und Output-Encoding sichern die Verarbeitung. Andere Schichten, andere Bugs.
Wahrscheinliche Anschlussfragen
- Was behebt SQL-Injection auf Codeebene tatsächlich, und warum funktioniert es?
- Welche Abwehr adressiert XSS, und wie unterstützt die Content-Security-Policy sie?
- Nenne eine Angriffsklasse, die HTTPS wirklich verhindert.