Primero, desde el principio, no sé qué intenta lograr el presunto atacante. Tal vez haya un script PHP o una versión PHP vulnerable a algún ataque extraño de ID de sesión, no lo sé. Sin embargo, probablemente no tenga nada de qué preocuparse.
Su servidor se comportó exactamente como se esperaba. 200 es el código esperado en esa situación particular debido a cómo Apache interpreta la URL que se le pasa.
Primero, http://allrequestsallowed.comse trata como el encabezado 'Host:' más habitual ( tenga en cuenta que no creo que esto se especifique en el RFC y que otros servidores no puedan interpretarlo de esta manera. Estaba equivocado, esto se especifica en RFC 2616 en la sección 5.1. 2, aunque los clientes rara vez parecen usar ese formulario. Disculpe, necesito arreglar una implementación de servidor HTTP que escribí hace un tiempo ...).
Ahora, presumiblemente no tiene un sitio llamado 'allrequestsallowed.com'. Entonces, ¿qué sucede cuando Apache obtiene un Host:encabezado (o equivalente) para un nombre de host que no reconoce? Elige el primer host virtual como predeterminado. Este es un comportamiento bien definido y documentado para Apache. Entonces, sea cual sea su primer host virtual (o solo la configuración del servidor principal si no hay ningún host) se hace cargo, sin importar cómo se llame.
Ahora, el resto de la URL dada consta de dos partes: la ruta /y un parámetro GET (el ?PHPSESSID...bit).
Ahora, la ruta /debería estar presente en casi todos los servidores web que existen. En la mayoría de los casos, se asigna a algo como index.htmlo tal vez un index.phpscript, aunque, por supuesto, puede anular todo esto.
Si se asigna a un archivo HTML estático, no ocurre absolutamente nada inusual: se devuelve el contenido del archivo, y eso es todo, simplemente se ignora el parámetro. (Suponiendo que no tenga determinadas directivas de configuración avanzadas establecidas, y casi con seguridad no las tiene).
Por otro lado, si se trata de un script de algún tipo, esa PHPSESSIDvariable se pasará al script. Si el script realmente usa esa variable (en este caso particular, solo los scripts PHP que usan el manejo de sesión incorporado de PHP probablemente lo harán), su comportamiento dependerá de los contenidos.
Sin embargo, con toda probabilidad, incluso si se /asigna a un script PHP usando sesiones, no ocurrirá nada notable. El ID de la sesión probablemente no exista de todos modos, y será ignorado o el script mostrará un error.
En el caso improbable de que la ID de la sesión exista, bueno, el atacante podría secuestrar la sesión de otra persona. Eso sería malo, pero en realidad no es un agujero de seguridad en sí mismo: el agujero estaría donde el atacante obtuviera la información de ID de sesión (rastrear una red inalámbrica es un buen candidato si no está usando HTTPS). En realidad, no podrían hacer nada que el usuario cuya sesión originalmente no pudo hacer.
Editar: Además, el '% 5C' dentro del SESSIONID se asigna a un carácter de barra diagonal inversa. Esto parece ser una prueba para ataques transversales de directorios en hosts de Windows.
curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. La configuración predeterminada parece devolver una página de "Bienvenido a nginx" sin contenido significativo, en nuestro sistema ubuntu. Por lo tanto, es una respuesta 200, pero es una simple página general: en realidad no estamos representando la solicitud en otro lugar ni nada de eso.