Primeiro, na frente, não sei o que o invasor presumido está tentando realizar. Talvez haja um script PHP ou uma versão do PHP lá fora vulnerável a algum estranho ataque de ID de sessão, eu não sei. Você provavelmente não tem nada para se preocupar, no entanto.
Seu servidor se comportou exatamente como esperado. 200 é o código esperado nessa situação em particular devido à forma como o Apache interpreta o URL que está sendo passado para ele.
Primeiro, http://allrequestsallowed.com é tratado como o mais usual cabeçalho 'Host:' ( note que eu não acho que isso é especificado no RFC e outros servidores podem não interpretar desta forma I estava errado, isso é especificado na RFC 2616 na seção 5.1.2, embora os clientes raramente parecem usar esse formulário.Por favor, eu preciso ir corrigir uma implementação de servidor HTTP que escrevi um tempo atrás ...).
Agora, presumivelmente você não tem um site chamado 'allrequestsallowed.com'. Então, o que acontece quando o Apache recebe um Host: header (ou equivalente) para um hostname que ele não reconhece? Ele escolhe o primeiro host virtual como o padrão. Esse é um comportamento bem definido e documentado para o Apache. Então, qualquer que seja o seu primeiro host virtual (ou apenas a configuração do servidor principal, se não houver nenhum vhosts), não importará o nome dele.
Agora, o restante do URL fornecido 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 da web disponíveis. Na maioria dos casos, ele é mapeado para algo como index.html ou talvez um index.php script, embora você possa sobrescrever isso, é claro.
Se ele mapear 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 certas diretivas avançadas de configuração definidas, e você quase certamente não tem.)
Por outro lado, se for um script de algum tipo, essa variável PHPSESSID será passada para o script. Se o script realmente usa essa variável (neste caso, é provável que apenas scripts PHP usando manipulação de sessão interna do PHP), seu comportamento dependerá do conteúdo.
Com toda a probabilidade, no entanto, mesmo que o seu / aconteça com 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 atacante poderia seqüestrar a sessão de outra pessoa. Isso seria ruim, mas não é realmente uma brecha de segurança em si - o buraco seria onde quer que o invasor pegasse as informações de identificação da sessão (farejar uma rede sem fio é um bom candidato se você não estiver usando HTTPS). Eles não poderiam realmente fazer nada que o usuário cuja sessão originalmente era não pudesse fazer.
Edit: Além disso, o '% 5C' dentro do SESSIONID é mapeado para um caractere de barra invertida. Este parece ser um teste para ataques de passagem de diretórios em hosts do Windows.