Tout d'abord, je ne sais pas ce que l'attaquant présumé essaie d'accomplir. Peut-être existe-t-il un script PHP ou une version PHP vulnérable à une étrange attaque d'ID de session, je ne sais pas. Mais vous n'avez probablement rien à craindre.
Votre serveur s'est comporté exactement comme prévu. 200 est le code attendu dans cette situation particulière en raison de la façon dont Apache interprète l'URL qui lui est transmise.
Tout d'abord, http://allrequestsallowed.comest traité comme l'en-tête `` Host: '' le plus habituel ( notez que je ne pense pas que cela soit spécifié dans le RFC et que d'autres serveurs ne puissent pas l'interpréter de cette façon, j'avais tort, cela est spécifié dans le RFC 2616 dans la section 5.1. 2, même si les clients semblent rarement utiliser ce formulaire. Excusez-moi, je dois aller corriger une implémentation de serveur HTTP que j'ai écrite il y a quelque temps ...).
Maintenant, vous n'avez probablement pas de site nommé «allrequestsallowed.com». Que se passe-t-il donc quand Apache obtient un en- Host:tête (ou équivalent) pour un nom d'hôte qu'il ne reconnaît pas? Il sélectionne le premier hôte virtuel par défaut. Il s'agit d'un comportement bien défini et documenté pour Apache. Quel que soit votre premier hôte virtuel (ou simplement la configuration du serveur principal s'il n'y a pas de vhosts), il prend le relais, quel que soit son nom.
Maintenant, le reste de l'URL donné se compose de deux parties - le chemin d'accès /et un paramètre GET (le ?PHPSESSID...bit).
Maintenant, le chemin /devrait être présent sur à peu près tous les serveurs Web. Dans la plupart des cas, il correspond à quelque chose comme index.htmlou peut-être à un index.phpscript, bien que vous puissiez remplacer tout cela bien sûr.
S'il correspond à un fichier HTML statique, rien d'inhabituel ne se produit - le contenu du fichier est retourné, et c'est tout, le paramètre est simplement ignoré. (En supposant que vous n'avez pas défini certaines directives de configuration avancées, et ce n'est certainement pas le cas.)
D'un autre côté, s'il s'agit d'un script quelconque, cette PHPSESSIDvariable sera transmise au script. Si le script utilise réellement cette variable (dans ce cas particulier, seuls les scripts PHP utilisant la gestion de session intégrée de PHP sont susceptibles de le faire), son comportement dépendra du contenu.
Selon toute vraisemblance, cependant, même si votre /mappage avec un script PHP à l'aide de sessions, rien de remarquable ne se produira. L'ID de session n'existera probablement pas de toute façon et sera soit ignoré, soit le script affichera une erreur.
Dans le cas peu probable où l'ID de session existe, eh bien, l'attaquant pourrait éventuellement détourner la session de quelqu'un d'autre. Ce serait mauvais, mais ce n'est pas vraiment un trou de sécurité en soi - le trou serait là où l'attaquant a obtenu les informations d'ID de session (renifler un réseau sans fil est un bon candidat si vous n'utilisez pas HTTPS). En fait, ils ne seraient pas en mesure de faire quoi que ce soit que l'utilisateur dont la session était à l'origine ne pouvait pas faire.
Edit: En outre, le '% 5C' à l'intérieur du SESSIONID correspond à un caractère barre oblique inverse. Cela semble être un test pour les attaques de traversée de répertoire sur les hôtes Windows.
curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. La configuration par défaut semble renvoyer une page "Bienvenue sur nginx" sans contenu significatif, sur notre système ubuntu. C'est donc une réponse de 200, mais c'est une simple page fourre-tout - nous ne procurons pas réellement la demande ailleurs ou quelque chose comme ça.