HTTP/0.9
Esta técnica se basa en que basicamente todos los servidores HTTP manejan de diferentes formas esta versión (pasa lo mismo con proxys), Ejemplo:
GET /
Este ya es un GET valido de la versión 0.9 del protocolo HTTP, pero ahora vamos a ver como lo reconocen los diferentes servidores web:
Tabla de respuestas:
Apache: Solo HTML
IIS: Encabezado y contenido.
GWS: Encabezado y contenido.
Sun-Java-System-Web-Server: Solo HTML
Esto es IIS y GWS toman al 0.9 exactamente igual que a todas las demás versiones del protocolo, cuando en esta versión únicamente se respondía el contenido de la web solicitada.
Tabla de respuestas:
Apache: Solo HTML
IIS: Encabezado y contenido.
GWS: Encabezado y contenido.
Sun-Java-System-Web-Server: Solo HTML
Esto es IIS y GWS toman al 0.9 exactamente igual que a todas las demás versiones del protocolo, cuando en esta versión únicamente se respondía el contenido de la web solicitada.
Errores y el Encabezado Server
algo que no muchos toman en cuenta es que cuando causamos un error (ya sea a un proxy o una aplicación que integre mecanismos similares) el servidor en cuestión responde cambiando muchas veces el encabezado Server, por ejemplo si enviamos un GET a un IIS7 y en el encabezado Host establecemos localhost, esto causara un error y el servidor nos respondera con un encabezado similar a:
Server: Microsoft-HTTPAPI/2.0
Lo cual obviamente es un IIS7 o similar.
En el caso de los proxys, tenemos por ejemplo a NetCache, enviando el mismo tipo de paquete que a un IIS7 (en el caso de los proxys lo toman como un loop infinito pues estaríamos diciendo que se conecten a si mismos) este nos responderá con algo similar a:
Server: NetCache appliance (NetApp/5.4R2D2)
lo mismo con Squid y proxys similares.
En otros casos no cambiara el encabezado Server, pero si responderá con estado 500 o 403 (o algún otro estado de error interno ).
Hay 2 tokens altamente utilizados para establecer el estado de la conexión: Connection y Proxy-Connection, este ultimo tal y como suena se utiliza para servidores proxy, cuando están estos dos en una consulta y hay un proxy en la conexión, nos responderá con Proxy-Connection en lugar de Connection (en la mayoría de los casos).
Este método desde el inicio se pensó para explorar la red (aunque se utilice para otras cosas), por lo cual respetando la idea central podemos utilizarlo para debuggear que leen o cambian los servidores proxy, en otras palabras, si enviamos un trace y la respuesta es diferente al paquete enviado entonces algo en la red (diferente a un servidor web el cual por lo regular no edita los paquetes) cambio el paquete (por lo regular un proxy) antes de llegar al servidor destino.
De momento terminamos con este breve texto, también se puede jugar con Content-Length y sacar cosas interesantes ;).
Bytez!
Server: Microsoft-HTTPAPI/2.0
Lo cual obviamente es un IIS7 o similar.
En el caso de los proxys, tenemos por ejemplo a NetCache, enviando el mismo tipo de paquete que a un IIS7 (en el caso de los proxys lo toman como un loop infinito pues estaríamos diciendo que se conecten a si mismos) este nos responderá con algo similar a:
Server: NetCache appliance (NetApp/5.4R2D2)
lo mismo con Squid y proxys similares.
En otros casos no cambiara el encabezado Server, pero si responderá con estado 500 o 403 (o algún otro estado de error interno ).
Proxy-Connection
Hay 2 tokens altamente utilizados para establecer el estado de la conexión: Connection y Proxy-Connection, este ultimo tal y como suena se utiliza para servidores proxy, cuando están estos dos en una consulta y hay un proxy en la conexión, nos responderá con Proxy-Connection en lugar de Connection (en la mayoría de los casos).
TRACE
Este método desde el inicio se pensó para explorar la red (aunque se utilice para otras cosas), por lo cual respetando la idea central podemos utilizarlo para debuggear que leen o cambian los servidores proxy, en otras palabras, si enviamos un trace y la respuesta es diferente al paquete enviado entonces algo en la red (diferente a un servidor web el cual por lo regular no edita los paquetes) cambio el paquete (por lo regular un proxy) antes de llegar al servidor destino.
De momento terminamos con este breve texto, también se puede jugar con Content-Length y sacar cosas interesantes ;).
Bytez!
0 comentarios:
Publicar un comentario en la entrada