In Penetrationstests stellt sich häufig die Frage, ob ein offener Port 80 automatisch als Schwachstelle zu bewerten ist. Port 80 ist der Standard-Netzwerkport für HTTP, also für unverschlüsselte Webkommunikation. Moderne Webanwendungen verwenden dagegen in der Regel HTTPS über Port 443, wodurch die Verbindung mittels TLS-Verschlüsselung geschützt wird.
Ein offener Port 80 ist jedoch nicht grundsätzlich eine Sicherheitslücke. Die Bewertung hängt stark vom Kontext der Anwendung, von den verwendeten Protokollen und von den implementierten Sicherheitsmechanismen ab. Daher wollen wir einmal erläutern, in welchen Fällen Port 80 problematisch sein kann und wann er aus Sicherheitsperspektive akzeptabel ist.
Wann ein offener Port 80 als Schwachstelle bewertet wird
Üblicherweise wird ein offener Port 80 nur dann als Schwachstelle bewertet, wenn darüber auch tatsächlich die unverschlüsselte Übertragung sensibler Daten möglich ist.
Unverschlüsselte Protokolle wie HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol) oder Telnet übertragen Daten im Klartext über das Netzwerk. Das bedeutet, dass Inhalte von Angreifer:innen mitgelesen oder verändert werden könnten, wenn diese Zugriff auf den Datenverkehr erhalten.
Auch wenn ein Webserver sämtliche Anfragen automatisch auf Port 443 (HTTPS) weiterleitet, kann dies in bestimmten Szenarien als Risiko bewertet werden. Besonders bei maschineller Kommunikation (z. B. zwischen Anwendungen oder APIs) besteht die Möglichkeit, dass ein Client zunächst eine Anfrage über HTTP sendet. Dabei könnten sensible Informationen wie API-Token bereits über den unverschlüsselten Kanal übertragen werden.
Wann Port 80 keine Schwachstelle darstellt
Ein offener Port 80 ist jedoch nicht in jedem Fall problematisch. Entscheidend ist, ob die Sicherheitsziele – insbesondere Vertraulichkeit und Integrität – auf einer anderen Protokoll- oder Systemebene umgesetzt werden.
Ein Beispiel sind Tor Hidden Services. Das Tor-Netzwerk stellt bereits eine Ende-zu-Ende-Verschlüsselung und Anonymisierung bereit. Selbst wenn die Anwendung innerhalb dieses Netzes über HTTP kommuniziert, ist der Datenverkehr bereits durch Tor geschützt.
Ein weiteres Beispiel sind APT-Repositorys (Software-Paketquellen für Linux-Distributionen). Diese können über HTTP erreichbar sein, da die heruntergeladenen Pakete üblicherweise kryptographisch signiert sind. Dadurch wird ihre Integrität (Unveränderbarkeit) überprüft, auch wenn die Übertragung selbst nicht verschlüsselt ist.
Weiterleitungen von HTTP zu HTTPS im Webbrowser
In vielen Webanwendungen dient Port 80 lediglich dazu, Besucher automatisch auf HTTPS (Port 443) umzuleiten. Diese Praxis gilt als Best Practice für Anwendungen, die ausschließlich über moderne Webbrowser genutzt werden.
Ein Grund dafür sind technische Anforderungen bestimmter Internet-Standards, etwa Certificate Revocation Lists (CRL). Dabei handelt es sich um Listen zurückgerufener Zertifikate, die laut RFC 2585 über HTTP oder FTP bereitgestellt werden müssen.
Zur Absicherung kann außerdem der Mechanismus HSTS (HTTP Strict Transport Security) gemäß RFC 6797 eingesetzt werden. HSTS weist Browser an, eine Website künftig ausschließlich über HTTPS aufzurufen.
Beim HSTS-Preloading wird eine Domain bereits in eine fest integrierte Liste moderner Browser aufgenommen. Dadurch greifen Browser automatisch auf HTTPS zu, selbst wenn der:die Nutzer:in nur http:// eingibt.
Downgrade-Angriffe
Ein weiteres Risiko ist ein sogenannter Downgrade-Angriff. Dabei versucht ein:e Angreifer:in, eine eigentlich sichere Verbindung auf ein unsicheres Protokoll umzuleiten.
Dies kann im Rahmen einer Machine-in-the-Middle-Attacke (häufig auch Man-in-the-Middle-Attacke) geschehen. Dabei positioniert der:die Angreifer:in eine Maschine zwischen zwei Kommunikationspartner:innen und kann so unverschlüsselten Datenverkehr manipulieren, mitlesen oder umleiten.
Schutzmaßnahmen wie HSTS-Preloading reduzieren dieses Risiko erheblich, da Browser dann gar nicht erst versuchen, eine HTTP-Verbindung aufzubauen.
Besondere Situation bei APIs
Bei Anwendungsschnittstellen (APIs) ist die Situation oft kritischer als bei klassischen Webanwendungen. Während moderne Browser viele Sicherheitsmechanismen automatisch unterstützen, ist bei API-Clients nicht immer bekannt, wie sie implementiert sind.
Ein schlecht implementierter Client könnte beispielsweise zunächst über HTTP kommunizieren oder Weiterleitungen unsicher behandeln. Deshalb wird ein offener Port 80 bei API-Systemen häufig strenger bewertet.
Also?
Ein offener Port 80 ist nicht automatisch eine Schwachstelle. Entscheidend ist der konkrete Einsatzkontext und welche Sicherheitsmechanismen zusätzlich implementiert sind.
Problematisch wird Port 80 insbesondere dann, wenn darüber unverschlüsselte Kommunikation mit sensiblen Daten möglich ist oder wenn Clients potenziell unsicher implementiert sind.
Ist Port 80 dagegen ausschließlich für Weiterleitungen auf HTTPS vorgesehen oder werden Sicherheitsziele bereits auf anderen Ebenen – etwa durch kryptographische Signaturen oder durch Ende-zu-Ende-Verschlüsselung – erfüllt, kann der offene Port legitim sein.
Für öffentlich erreichbare Webanwendungen empfiehlt sich eine konsequente Umsetzung moderner Schutzmechanismen wie HTTPS-Weiterleitung, HSTS und HSTS-Preloading sowie einer sicheren DNS- und Zertifikatskonfiguration, um die Sicherheitsrisiken durch Machine-in-the-Middle-Angriffe zu reduzieren.
Flora Schäfer