Analizando implementacion del HTTP en Servidores Web
Posted on 10:42 by Xianur0
Vamos a ver un poco de como se puede analizar la forma que implementan el protocolo HTTP, con diferentes fines, por ejemplo para detectar que tan buen uso le dan al protocolo y que tan susceptibles serian ante diferentes clases de ataques, vamos a dar unos ejemplos:
Servidor Web: Apache
Open-Source: Si
Programado en: C
HTTP Pipelining: Soportado y activado por default
Vamos a hacer unas pruebas (con www.apache.org):
Enviado:
HEAD / HTTP/1.1
Host: www.apache.org
Content-Length: 7
xianur0TRACE / HTTP/1.1
Host: www.apache.org
Resultado:
HTTP/1.1 200 OK
Date: Wed, 03 Feb 2010 18:52:06 GMT
Server: Apache/2.3.5 (Unix) mod_ssl/2.3.5 OpenSSL/0.9.7d mod_fcgid/2.3.2-dev
Last-Modified: Wed, 27 Jan 2010 08:40:59 GMT
ETag: "b95834-8667-47e215c92fcc0"
Accept-Ranges: bytes
Content-Length: 34407
Cache-Control: max-age=86400
Expires: Thu, 04 Feb 2010 18:52:06 GMT
Vary: Accept-Encoding
Content-Type: text/html
HTTP/1.1 200 OK
Date: Wed, 03 Feb 2010 18:52:06 GMT
Server: Apache/2.3.5 (Unix) mod_ssl/2.3.5 OpenSSL/0.9.7d mod_fcgid/2.3.2-dev
Transfer-Encoding: chunked
Content-Type: message/http
2a
TRACE / HTTP/1.1
Host: www.apache.org
0
Conclusion:
Podemos determinar mediante esta simple consulta que sin importar el metodo que se esta usando, el servidor web apache considera el Content-Length, es decir se lee lo enviado como POSTDATA (contenido que se envia por POST), esto tendria como consecuencia algunos detalles por ejemplo un retardo (minimo) al intentar leer el Content-Length y parsear el postdata segun el largo dado. Esto es, apache no considera muy afondo la estructura del HTTP, pues segun la estructura del protocolo, solo se puede enviar postdata mediante el metodo POST, en caso de que el metodo sea GET, solo se pueden enviar parametros en el campo de uricontent, es decir no sera POSTDATA, sino uricontent.
Servidor Web: IIS/7.5
Open-Source: NO (ni soñando xD)
HTTP Pipelining: Soportado y activado por default
Vamos a hacer unas pruebas (con www.microsoft.com):
HEAD / HTTP/1.1
Host: www.microsoft.com
Content-Length: 40
TRACE / HTTP/1.1
Host: www.microsoft.com
Resultado:
HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Length: 1020
Content-Type: text/html
Last-Modified: Mon, 16 Mar 2009 20:35:26 GMT
Accept-Ranges: bytes
ETag: "67991fbd76a6c91:0"
Server: Microsoft-IIS/7.5
VTag: 279999051900000000
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
X-Powered-By: ASP.NET
Date: Wed, 03 Feb 2010 19:29:13 GMT
Conclusion:
La misma que con apache...
Servidor Web: Cherokee Web Server/0.99.39
Open-Source: Si
Programado en: C
HTTP Pipelining: Soportado y activado por default
GET / HTTP/1.1
Host: www.cherokee-project.com
Content-Length: 51
HEAD / HTTP/1.1
Host: www.cherokee-project.com
Resultado:
HTTP/1.1 200 OK
Connection: Keep-Alive
Keep-Alive: timeout=60
Date: Wed, 03 Feb 2010 19:42:47 GMT
Server: Cherokee/0.99
ETag: 4b61ed6d=219b
Last-Modified: Thu, 28 Jan 2010 20:02:53 GMT
Content-Type: text/html
Content-Length: 8603
[...]
HTTP/1.1 200 OK
Connection: Keep-Alive
Keep-Alive: timeout=60
Date: Wed, 03 Feb 2010 19:42:47 GMT
Server: Cherokee/0.99
ETag: 4b61ed6d=219b
Last-Modified: Thu, 28 Jan 2010 20:02:53 GMT
Content-Type: text/html
Content-Length: 8603
Conclusion:
Cherokee si respeta el metodo antes de leer las cabeceras, por lo cual pierde menos tiempo procesando lo inutil.
Cherokee Win!
1 comentarios:
Es realmente increible que siendo relativamente poco conocido cherokee si respete correctamente el protocolo y filtre bien el contenido de las cabeceras. Igualmente en el caso del iis como mucho supondran, no hay nada que me asombre, muy buen material xianur0.
Gracias por la info.
Publicar un comentario