http
Service Names in Windows
Zwischen Linux und Windows ist ja vieles anders, oder auch einfach nur bewusst inkonsistent gehalten.
Beispiel: Samba unter Linux – heißt in Windows „Server“. Überraschenderweise sogar in der deutschen Version.
Aber schlimmer wirds beim Webserver. In Linux schon unter vielen Namen bekannt, je nach Distribution als: apache, apche2, httpd für den Apache2 Webserver oder eben lighttpd, nginx oder was da sonst noch so kreucht und fleucht. Als was würde man den Windows Internet Information Server Dienst suchen? Als Microsoft IIS, IIS, Internet Information Irgendwas, Windows Internet Information, Windows Web, Windows HTTP? Nein, alles Falsch. Der Dienst heißt World Wide Web Publishing Service.
Link des Tages
Für eine schnelle Überprüfung, ob eventuell sicherheitsrelevante HTTP Header gesetzt sind: securityheaders.io
Apache AllowEncodedSlashes
Webserver zeigen manchmal ein ganz lustiges Verhalten, etwa wenn ein URL encoded Base64 String übergeben wird.
Benutzt wird das zum Beispiel beim Aufruf eines OCSP Responders wo die Information über das zu prüfende Zertifikat als urlencodetes Base64 übergeben wird.
Ein Beispiel in Base64
jA0EAxMcxamDRMfOGV5/gyZPnyX1BBPOQAE4BHbh7=
Und urlencoded
jA0EAxMcxamDRMfOGV5%2FgyZPnyX1BBPOQAE4BHbh7%3D
Wird jetzt der String „jA0EAwMCxamDRMfOGV5%2FgyZPnyX1BBPOQAE4BHbh7%3D“ z.B. als http://example.com/test/jA0EAwMCxamDRMfOGV5%2FgyZPnyX1BBPOQAE4BHbh7%3D aufgerufen, macht ein Apache draus wieder den Schrägstrich und meldet einen „404 File not found“ zurück, weil das als Pfad und Datei interpretiert wird. Eigentlich sollte das aber wie alle URLs unter /test/ an ein Backend übergeben werden.
Lösung: Per Default ist die Option AllowEncodedSlashes auf Off, wird die Option gesetzt, wird der String sauber durchgereicht.
Die Beispiele sind übrigens Kauderwelsch und haben keine tatsächliche Bedeutung.
wget and the http protocol version
Found some scripts using wget, which suddenly stopped working after a server upgrade. Strange thing, using curl still worked. Using a proxy server also worked.
So what was the problem?
The new server version didn’t support HTTP version 1.0 and discarded the requests with HTTP status 403, forbidden. But why in all the possible worlds would wget send an HTTP 1.0 header? Oh, it’s just because its a freaking old wget version 1.12 used by Red Hat which simply won’t support HTTP 1.1!
Check out the version information at Wikidpedia.
Wget 1.13, released August 2011, supports HTTP/1.1
Any newer version than this old version from September 2009 wouldn’t have caused troubles.
If I understand this question at Stackoverflow correctly HTTP 1.1 was introduced in 1996 … but the wget version from 2009 won’t support that.
HTTP Header
Beim Testen von Webservern oder PHP-Scripts die die HTTP-Header auswerten sollen, hab ich bisher noch keine zufriedenstellende Lösung gefunden.
– Ein erster Ansatz war es Telnet zu verwenden, was sich als äusserst Mühsam herausstellt.
– Bald darauf landet man bei der Firefox Extension "Tamper Data" mit der sich die Header-Daten Manipulieren lassen. Da aber für jeden Request wieder angefragt wird, ob überhaupt Daten geändert werden sollen, und bei jedem Request wieder vergessen wird
– Noch eine Möglichkeit sind Curl-Aufrufe. Diese bieten sich für Scripte und automatische Verarbeitung an – sind aber ansonsten genau so mühsam.
– Eine geniale Lösung ohne Plugins stellt Opera mit Opera Dragonfly zur Verfügung:
Starten von Dragonfly 
Auswählen von Netzwerk -> "Anfrage Starten" 
Voll automatisch lassen sich Requests wiederholen. Alle Header lassen sich überschreiben. Und der Browser merkt sich, was als letztes Aufgerufen wurde. Eigentlich alles was man sich wünscht, nachdem man bisher mit den anderen Lösungen gelebt hat.