The %00 is the famous null character when encoded in a URL. It is interesting to see how
different web servers behave when a null character is there in the GET request.
I use a simple python program that accepts the website name and URL to get, responds with the
web server version if available in the header and HTTP response code.
% ./uget.py
usage: ./uget.py <website name> <url>
Now for the observations. Lets see how our April 2007 top 5 web servers
by netcraft behave.
% ./uget.py www.santabanta.com “/fo%00o”
+ using proxy: 172.31.1.3:8080
+ Status : 400
The IIS web server responds with a 400 i.e bad request.
% ./uget.py www.youtube.com “/fo%00o”
+ using proxy: 172.31.1.3:8080
+ Web Server: Apache
+ Status : 404
The apache web server responds with a 404 i.e not found.
% ./uget.py upload.wikimedia.org “/%00foo”
+ using proxy: 172.31.1.3:8080
+ Web Server: lighttpd/1.4.13
+ Status : 404
lighthttpd too responds with a 404.
% ./uget.py www.sun.com “/fo%00o”
+ using proxy: 172.31.1.3:8080
+ Web Server: Sun-Java-System-Web-Server/6.1
+ Status : 404
The Sun’s web server too responds with a 404.
% ./uget.py dxbec.ihep.su “/fo%00o”
+ using proxy: 172.31.1.3:8080
+ Web Server: NCSA/1.5.2
+ Status : 404
The NCSA web server too says 404.
Hence the odd one out as always is; the IIS web server, hence a clear distinction
can be made by using a %00 in a GET request that the web server is IIS or not.