Primeiro, na frente, não sei o que o suposto atacante está tentando realizar. Talvez haja um script PHP ou uma versão PHP vulnerável a algum ataque estranho de ID de sessão, não sei. Você provavelmente não precisa se preocupar com nada.
Seu servidor se comportou exatamente como o esperado. 200 é o código esperado nessa situação específica, devido à maneira como o Apache interpreta a URL que está sendo passada para ele.
Primeiro, http://allrequestsallowed.comé tratado como o cabeçalho 'Host:' mais usual ( observe que eu não acho que isso esteja especificado na RFC e outros servidores não possam interpretá-lo dessa maneira. Eu estava errado, isso está especificado na RFC 2616 na seção 5.1. 2. Embora os clientes raramente usem esse formulário, desculpe-me, preciso corrigir uma implementação de servidor HTTP que escrevi há algum tempo ...).
Agora, presumivelmente, você não tem um site chamado 'allrequestsallowed.com'. Então, o que acontece quando o Apache obtém um Host:cabeçalho (ou equivalente) para um nome de host que ele não reconhece? Ele escolhe o primeiro host virtual como padrão. Esse é um comportamento bem definido e documentado para o Apache. Portanto, seja qual for o seu primeiro host virtual (ou apenas a configuração principal do servidor, se não houver vhosts), não importa o nome.
Agora, o restante da URL fornecida consiste em duas partes - o caminho /, e um parâmetro GET (o ?PHPSESSID...bit).
Agora, o caminho /deve estar presente em praticamente todos os servidores web disponíveis. Na maioria dos casos, ele é mapeado para algo como index.htmlou talvez um index.phpscript, embora você possa substituir qualquer um disso, é claro.
Se ele mapeia para um arquivo HTML estático, absolutamente nada de anormal acontece - o conteúdo do arquivo é retornado, e é isso, o parâmetro é simplesmente ignorado. (Supondo que você não tenha determinadas diretivas de configuração avançadas definidas e quase certamente não.)
Por outro lado, se for algum tipo de script, essa PHPSESSIDvariável será passada para o script. Se o script realmente usar essa variável (nesse caso em particular, provavelmente somente os scripts PHP que usam o tratamento de sessões embutido no PHP), seu comportamento dependerá do conteúdo.
Com toda a probabilidade, no entanto, mesmo se você /mapear para um script PHP usando sessões, nada de notável acontecerá. O ID da sessão provavelmente não existirá de qualquer maneira e será ignorado ou o script mostrará um erro.
No caso improvável de que o ID da sessão exista, bem, o invasor pode possivelmente seqüestrar a sessão de outra pessoa. Isso seria ruim, mas não é realmente uma brecha de segurança em si mesma - a brecha seria onde o invasor obteve as informações de ID da sessão (cheirar uma rede sem fio é um bom candidato se você não estiver usando HTTPS). Na verdade, eles não seriam capazes de fazer nada que o usuário cuja sessão foi originalmente não pudesse fazer.
Editar: Além disso, o '% 5C' dentro do SESSIONID é mapeado para um caractere de barra invertida. Este parece ser um teste para ataques de travessia de diretório nos hosts do Windows.
curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. A configuração padrão parece retornar uma página "Bem-vindo ao nginx" sem conteúdo significativo em nosso sistema ubuntu. Portanto, é uma resposta de 200, mas é uma página simples e abrangente - na verdade, não estamos proxyando a solicitação em outro lugar ou algo assim.