Vollständiger Leitfaden zu HTTP-Statuscodes: 400er-Serie

Probleme mit einem User-Agent-Client reichen von Anfragen nach Ressourcen, die nicht mehr verfügbar sind (durch eine falsch getippte URI), bis zur Reaktion des Servers auf Anfragen, die der Signatur eines Angriffs entsprechen.

Der häufigste ist der 404. 404 Not Found wird zurückgegeben, wenn ein Client eine Ressource anfordert, die der Webserver nicht finden kann:

Sehen wir uns die häufigsten und interessantesten Antwortcodes der 400er-Serie etwas genauer an.

400 Bad Request

400 Bad Request ist (in der Regel) das Ergebnis eines User-Agents, der in der Anfrage etwas sendet, das der Webserver nicht verarbeiten konnte. Erzeugen wir einen 400 Bad Request, um zu verstehen, was diesen Fehler verursachen kann.

Wir machen es auf die alte Art unter Linux und verwenden ein Werkzeug namens netcat. Mit netcat lassen sich Rohdaten über Sockets senden. Schließlich sind HTTP/1.1-Anfragen genau das: roher Text.

Zuerst senden wir eine gültige HEAD-Anfrage an google:

Erzwingen wir einen 400 Bad Request:

image: src /blog/wp-content/uploads/2017/12/3CEEAuo-e1513087453173.jpg (unchanged); alt: Erzwungene fehlerhafte Anfrage, die einen 400 erzeugt

Wir haben absichtlich eine Anfrage gesendet, die der Server nicht verstehen konnte. Sehen wir uns die verwendete Anfragemethode an:

$ nc www.google.com 80
BAD / HTTP/1,1
Host: www.google.com

Der Webserver konnte die Methode nicht verarbeiten: BAD

Es ist unwahrscheinlich, dass ein moderner Webbrowser fehlerhafte Anfragen wie die oben gezeigte sendet. Wenn Sie jedoch eine selbst entwickelte HTTP-Anwendung wie einen Web-Scraper verwenden, ist es Zeit für Debugging.

Diese Schritte lösen die häufigsten 400-Fehler.

1. Prüfen Sie die URL

Wenn Sie auf einen Link klicken, ist es gut möglich, dass dem Autor der Seite ein Tippfehler unterlaufen ist. Prüfen Sie die gesamte URL und achten Sie besonders auf Pfad, Dokumentname und Query-String.

2. Löschen Sie alle Cookies und den Cache

Das Löschen von Cookies und Cache behebt viele 400-Fehler und ist auch bei vielen anderen 400er-Statuscodes ein guter erster Schritt.

1. löschen Sie alle Cookies und den Browserverlauf
2. wiederholen Sie die Anfrage

In Chrome, Edge und Firefox findet sich die Option in den Browsereinstellungen unter Datenschutz, meist mit dem Namen «Browserdaten löschen». Die Menünamen unterscheiden sich je nach Version. Oft genügt es, nur die Cookies der betroffenen Website zu löschen.

Das Löschen aller Cookies und des Verlaufs stellt sicher, dass alles Zwischengespeicherte oder Beschädigte (wie Cookies) weg ist. Das behebt häufig einen 400 Bad Request.

3. Größe der hochgeladenen Datei

Das Problem kann durchaus ein Backend-Skript sein, der Upload einer zu großen Datei oder einer Datei mit falschem Medientyp.

1. Tritt der 400 bad request beim Hochladen einer Datei auf, versuchen Sie eine kleinere Datei.
2. Stellen Sie sicher, dass der Dateityp zulässig ist.
3. Beim Hochladen eines Bildes versuchen Sie beide Formate, jpeg und png.
4. Beim Hochladen eines Dokuments sind Klartext und gängige Office-Formate in der Regel erlaubt.

4. Fehlerhafte Header

Fehlerhafte Header sind ein eher hardwarenahes Problem und können durchaus die Webanwendung selbst verantwortlich machen.

Die Entwicklerwerkzeuge, die jeder moderne Browser mitbringt (der Tab Netzwerk), lassen uns die gesamte HTTP-Transaktion auf Ungewöhnliches beobachten.

5. Aktualisieren Sie Ihren Browser und deaktivieren Sie Plugins

Ist Ihr Browser veraltet, sendet er möglicherweise veraltete Header und Anfragen.

Versuchen Sie außerdem, alle Plugins und Erweiterungen zu entfernen oder zu deaktivieren. Dieselbe Anfrage in einem anderen Browser zu versuchen kann ebenfalls helfen, das Problem einzugrenzen.

6. Melden Sie sich ab

Wenn Sie eine Webanwendung mit Benutzeranmeldung und Sessions verwenden, melden Sie sich ab und löschen Sie anschließend den Browser-Cache.

(hr)

401 Unauthorized

401 Unauthorized wird zurückgegeben, wenn ein Webserver Anmeldedaten für ein geschütztes Dokument verlangt.

403 Forbidden

403 Forbidden ist in der Regel eines von vier Dingen:

• Verzeichnislisten sind nicht erlaubt
• der aktuell angemeldete Benutzer hat keine ausreichenden Rechte
• der Webserver-Prozess hat unzureichende Rechte
• die anfragende Adresse wurde gesperrt

Verzeichnisliste nicht erlaubt

Hier erlaubt der Webserver keine Verzeichnislisten für nicht angemeldete Benutzer. Die einfachste Lösung ist, eine Index-Datei in das Verzeichnis zu legen. Andernfalls müssen Verzeichnislisten für nicht angemeldete Benutzer ausdrücklich eingerichtet werden.

Angemeldeter Benutzer hat keine Rechte

Die beste Methode in diesem Fall ist, eine Gruppe für alle Benutzer anzulegen, die Zugriff auf eine Ressource brauchen. Geben Sie dieser Gruppe die nötigen Rechte auf Dateisystemebene. Fügen Sie dann die berechtigten Benutzer der Gruppe hinzu.

Webserver-Prozess hat keine ausreichenden Rechte

image: src /blog/wp-content/uploads/2017/12/XSkGl4h-e1513087253567.jpg (unchanged); alt: Zugriff verweigert

Wir können die Seite test.php im Webroot unter /var/www/html nicht aufrufen. Unter RHEL und seinen Ableitungen (Oracle Linux, AlmaLinux, Rocky Linux) gibt es zwei Dinge zu prüfen: die klassischen Dateirechte und den SELinux-Kontext.

Prüfen Sie zuerst Eigentümer und Rechte:

# ls -ld /var/www/html/
drwx------. 3 root root 4096 Nov 24 03:47 /var/www/html/

Das Verzeichnis gehört dem Benutzer root und der Gruppe root, ohne Zugriff für andere, sodass der Webserver-Prozess (Benutzer apache bei Apache httpd, nginx bei nginx) es nicht lesen kann. Geben Sie der Gruppe des Webservers Leserecht, ohne Schreibrecht:

# chgrp -R apache /var/www/html
# chmod 750 /var/www/html
# chmod 640 /var/www/html/test.php
# ls -ld /var/www/html/
drwxr-x---. 3 root apache 4096 Nov 24 03:47 /var/www/html/
# ls -l /var/www/html/test.php
-rw-r-----. 1 root apache 91 Nov 16 06:52 /var/www/html/test.php

Prüfen Sie zweitens den SELinux-Kontext. Dateien, die von anderswo in das Webroot verschoben wurden, behalten ihr altes Label, und SELinux blockiert den Webserver dann selbst bei korrekten Rechten:

# ls -Z /var/www/html/test.php
# restorecon -Rv /var/www/html

Inhalte unter /var/www/html sollten den Typ httpd_sys_content_t tragen. Korrigieren Sie das Label mit restorecon. Deaktivieren Sie niemals SELinux, um einen 403 verschwinden zu lassen.

Als bewährte Sicherheitspraxis sollte die Gruppe des Webservers keine Schreibrechte auf Dateien und Ordner haben. Wo ein Content-Management-System schreiben muss (zum Beispiel ein Uploads-Ordner), gewähren Sie Schreibrecht nur auf diesen Ordner und geben Sie ihm unter RHEL den SELinux-Typ httpd_sys_rw_content_t.

Das Verweigern von Schreibrechten auf Dateien und Ordner kann eine zusätzliche Sicherheitsebene bieten, falls ein Angreifer eine Schwachstelle der Webanwendung ausnutzt, um Inhalte zu verändern, Dateien zu löschen oder Dateien hinzuzufügen.

In einer Staging-Umgebung nehmen Sie die Entwickler in die Gruppe des Webservers auf und geben dieser Gruppe Schreibrecht. Halten Sie die Produktion schreibgeschützt.

Ein weiteres häufiges Szenario für einen 403 Forbidden kann eine IP-Adresse oder ein IP-Bereich sein, die der Serveradministrator in einer .htaccess-Datei gesperrt hat.

404 Not Found

404 Not Found bedeutet, dass der Webserver eine angeforderte Ressource nicht finden konnte. Bei einem 404-Fehler können Sie einige Dinge tun:

• prüfen Sie die Schreibweise von Host, Domain, Pfad und Dokument
• prüfen Sie Groß- und Kleinschreibung von Datei und Pfad. Webserver unter Linux und Unix unterscheiden (sofern nicht anders konfiguriert) in der Regel Groß- und Kleinschreibung, traditionell wird alles klein geschrieben.
• suchen Sie mit Google eine alternative URL für die Ressource
• versuchen Sie eine archivierte Kopie der Seite in der Wayback Machine des Internet Archive

Erweiterte Google-Suchoperatoren verwenden

image: src /blog/wp-content/uploads/2017/12/KbnaNqB-e1513087331180.jpg (unchanged); alt: Google: alle PDF-Dateien finden

Eine Abfrage wie die oben gezeigte, mit Operatoren wie site: und filetype:, findet oft ein Dokument, dessen alter Link jetzt einen 404 zurückgibt.

Wurde die Seite entfernt, hält die Wayback Machine des Internet Archive möglicherweise noch eine ältere Kopie vor.

405 Method Not Allowed

Ein 405 Method Not Allowed erscheint, wenn eine Anfragemethode versucht wird, die der Webserver nicht erlaubt.

406 Not Acceptable

406 Not Acceptable wird zurückgegeben, wenn der Server die Ressource in keinem der Inhaltstypen, Kodierungen, Sprachen oder Zeichensätze liefern kann, die der Client nach eigener Angabe akzeptiert.

Um einen 406 zu lösen, sehen Sie sich die Anfrage-Header in den Entwicklerwerkzeugen Ihres Browsers an (Tab Netzwerk).

Vom Client gesendete Header-Werte, die sich zu prüfen lohnen:

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language

Moderne Browser lösen das selten aus. Tut Ihrer es, versuchen Sie ein Upgrade auf eine neuere Version.

407 Proxy Authentication Required

407 Proxy Authentication Required bedeutet in der Regel, dass der User-Agent Anmeldedaten übermitteln muss, um auf einen Proxy-Server zuzugreifen.

image: src /blog/wp-content/uploads/2017/12/GpVOCul.jpg (unchanged); alt: Proxy-Anmeldedaten unter Linux übermitteln

408 Request Timeout

408 bedeutet, dass der Server zu lange darauf gewartet hat, dass der Client das Senden seiner Anfrage abschließt. Das deutet meist auf eine langsame oder instabile Client-Verbindung hin, nicht auf den Server.

429 Too Many Requests

429 bedeutet in der Regel, dass auf dem Server Rate Limiting aktiviert wurde. Rate Limiting erlaubt nur eine bestimmte Anzahl von Anfragen in einem festgelegten Zeitraum.

Wenn Sie 429 Too Many Requests erhalten, drosseln Sie. Der Server sendet möglicherweise einen Retry-After-Header, der angibt, wie lange vor dem nächsten Versuch zu warten ist. Gut erzogene Clients und Skripte respektieren ihn und halten sich zurück.

451 Unavailable for Legal Reasons

451 wird zurückgegeben, wenn der Server rechtlich verpflichtet ist, den Zugriff auf eine Ressource zu sperren, zum Beispiel nach einer gerichtlichen Anordnung.