Bei HTTP-Statuscodes denkt jeder erst mal an den allseits bekannten 404 – nicht gefunden. Das dürfte in der Regel auch der sein, den man am häufigsten antrifft. Nämlich immer dann, wenn eine Webseite oder eine andere über einen Webserver ausgelieferte Ressource nicht angefunden wurde. Sei es aus einem Schreibfehler heraus oder weil die Ressource tatsächlich nicht oder nicht mehr existiert. Neben diesem sehr wichtigen Code gibt es aber noch zwei weitere bemerkenswerte und aus unserer Sicht vielleicht etwas unterschätzte Codes: 401 – Unauthorisiert und 403 – Verboten; bzw. auf englisch 401 – unauthorized und 403 – forbidden. Doch was sind die Unterschiede oder kann man beide einfach synonym verwenden?
HTTP-Status-Was?
HTTP-Status-Codes sind tatsächlich fester Bestandteil des HTT-Protokolls aber meistens bekommt man beim Surfen im Web nichts davon mit. Jede Anfrage wird mit einem solchen Code in der Antwort versehen. Da es jedoch in den eher unsichtbaren Meta-Daten steckt (übrigens nicht verwandt oder verschwägert mit dem großen Konzern ;)), bekommt man nicht sonderlich viel davon mit. Daher ist es wenig überraschend, dass der bekannteste und am häufigsten gesendete Code 200 ist. 200 bedeutet in dem Fall „OK“. Damit jetzt nicht hier alle 5 Klassen und deren Unterelemente vorgestellt werden müssen, verweisen wir für einen weiteren Quereinstieg in das Thema auf die entsprechende Seite im Wikipedia.
HTTP-Codes 400er-Reihe
Was man aber an Wissen aus dem bisherigen Text ableiten kann ist, dass es wohl eine 400er „Reihe“ geben muss – diese befasst sich mit den Client-Errors. Technisch gesehen also eher ein Statuscode des Browsers – obwohl auch diese Statuscodes i.d.R. eher vom Server gesendet werden. Im Allgemeinen bedeutet ein 400er Statuscode aber vor allem nicht, dass der Server ein grundlegendes Problem hat, sondern viel mehr, dass eben der Client irgendwas falsches in seine Anfrage gepackt hat. Das kann beim klassischen 404 eben sein, dass in der angefragten URL etwas nicht stimmt. Oder das die URL zwar an sich richtig ist, es die Ressource (also das Bild, das PDF, die Seite selbst) am Server nicht oder nicht mehr präsent ist. Insofern ist das wahrscheinlich ein bisschen hybrid zu sehen zwischen Server und Client. Was aber absolut klar ist: Irgendwas stimmt mit der Anfrage nicht!
HTTP 401 – Unauthorized
Ein eher unscheinbarer Code. Damit dieser zum Tragen kommt, muss man entweder in der Programmierung diesen explizit setzen (in PHP z.b. via header(„HTTP 401 – Unauthorized“);) oder sowas wie einen passwortgeschützten Ordner einrichten (im Apache via .htpwd Datei). Das Ergebnis ist jeweils dasselbe: Der Browser gibt keine schön designte Seite aus (es sei denn, man hat eigene Fehlerdokumente hinterlegt – aber dazu in einem anderen Post mehr). Doch was besagt dieser Code? Wie sich vermuten lässt aus den passwortgeschützten Verzeichnissen wollte der Anfrager auf eine Ressource zugreifen, die irgendeine Art Authorisierung erfordert – meistens ein Username/Passwort Gespann. Und dieses wurde entweder gar nicht mitgeliefert oder enthält einen Fehler (Schreibfehler, unbekannter Benutzername, Passwort falsch). Was genau nicht stimmt lässt sich hierüber leider nicht rausfinden. Wobei das aus Sicherheitsaspekten durchaus gut ist – aber dazu auch gleich nochmal mehr!
HTTP 403 – Forbidden
Einige werden jetzt sehr logisch rangehen und sagen „Hä? Das ist doch im Prinzip dasselbe!?“. Und wie immer ist die klassische Antwort darauf: Jain. Aber mal der Reihe nach. ein Code „Forbidden“ braucht technisch gesehen keine Logindaten. Es spielt bei dem Statuscode absolut keine Rolle ob jemand vielleicht sogar einen administrativen Zugang zu einem Bereich hat: Es ist schlicht und ergreifend verboten, zuzugreifen. Dieses Verboten ist jedoch recht „weich“, also es muss gar nicht zwingend sein, dass ein wirkliches Verbot vorliegt, es genügt z.B. schon, dass eine Ressource mit http statt https aufgerufen wurde und der Server so konfiguriert ist, dass http-Aufrufe eben verboten sind (kommt seltener zum Tragen, weil die meisten Server eine http-Anfrage stillschweigend auf https „upgraden“). Wie auch beim 401 wird hier keine weitere Erklärung mitgeliefert, warum das Verbot gilt. Auch das ist gut und auch dazu gleich nochmal mehr.
Weil du unauthorized bist, ist der Zugriff verboten
Jetzt könnte man ja sagen, man schenkt sich den einen oder den anderen http-Code weil jeder Zugriff, der ohne ein passendes Login daherkommt, gleichzeitig auch verboten ist. Und umgedreht? Ist jeder verbotene Zugriff auch gleich unauthorized? Leider nicht ganz. Rein technisch haben wir ja eben gerade schon beschrieben, dass bei 403 – Forbidden nicht zwingend vorher eine Username/Passwort Abfrage „schuld“ sein muss. Insofern gilt – rein technisch bzw. logisch gesprochen – zwar das eine, aber nicht das andere zwangsläufig. Natürlich kann man den Statuscode jeweils umschreiben und einen Server wie den Apache oder das eigene PHP-Programm so gestalten, dass eben nur einer von beiden Statuscodes zum Tragen kommt. Schließlich geht es ja nur darum, dem Client irgendwie etwas mitzuteilen, warum seine Anfrage zumindest gerade und mit den situativen Umständen nicht geht. Und es macht aus unserer Sicht manchmal sogar ein bisschen Sinn.
Zum Hintergrund: Natürlich wissen auch diverse – auch schädliche – Bots und auch Angreifer den Unterschied zwischen den verschiedenen Statuscodes. Sende ich also ein 401 – Unauthorized, weiß der Client fast automatisch, dass es die Ressource prinzipiell gibt, es aber einen gesonderten Login oder eine andere Sicherungsmaßnahme bedarf um darauf zuzugreifen. Das ist für einen Angreifer durchaus schon eine lohnende Info. Denn am Anfang steht meist erst mal das Informationen sammeln zur jeweiligen Umgebung. Das heißt es geht noch gar nicht darum, direkt auf irgendwas zuzugreifen, sondern schlicht um einen Gesamteinblick.
