Erstens weiß ich nicht, was der mutmaßliche Angreifer zu erreichen versucht. Vielleicht gibt es da draußen ein PHP-Skript oder eine PHP-Version, die für einen seltsamen Sitzungs-ID-Angriff anfällig ist, weiß ich nicht. Sie müssen sich jedoch wahrscheinlich keine Sorgen machen.
Ihr Server hat sich genau wie erwartet verhalten. 200 ist der erwartete Code in dieser bestimmten Situation, da Apache die an ihn übergebene URL interpretiert.
Erstens wird http://allrequestsallowed.comes wie der üblichere 'Host:' - Header behandelt ( beachten Sie, dass ich nicht glaube, dass dies im RFC angegeben ist und andere Server es möglicherweise nicht so interpretieren, wie ich mich geirrt habe. Dies wird in RFC 2616 in Abschnitt 5.1 angegeben. 2, obwohl Clients dieses Formular selten zu verwenden scheinen. Entschuldigung, ich muss eine HTTP-Server-Implementierung reparieren, die ich vor einiger Zeit geschrieben habe ...).
Vermutlich haben Sie keine Site mit dem Namen "allrequestsallowed.com". Was passiert also, wenn Apache einen Host:Header (oder einen gleichwertigen Header) für einen Hostnamen erhält, den er nicht erkennt? Es wird der erste virtuelle Host als Standard ausgewählt. Dies ist ein genau definiertes und dokumentiertes Verhalten für Apache. Was auch immer Ihr erster virtueller Host ist (oder nur die Hauptserverkonfiguration, wenn keine vhosts vorhanden sind), übernimmt unabhängig davon, wie er heißt.
Der Rest der angegebenen URL besteht nun aus zwei Teilen - dem Pfad /und einem GET-Parameter (dem ?PHPSESSID...Bit).
Jetzt sollte der Pfad /auf so ziemlich jedem Webserver vorhanden sein. In den meisten Fällen wird es so etwas wie index.htmloder vielleicht einem index.phpSkript zugeordnet, obwohl Sie natürlich alles überschreiben können.
Wenn es einer statischen HTML-Datei zugeordnet wird, passiert absolut nichts Ungewöhnliches - der Inhalt der Datei wird zurückgegeben, und das heißt, der Parameter wird einfach ignoriert. (Angenommen, Sie haben bestimmte erweiterte Konfigurationsanweisungen nicht festgelegt, und Sie tun dies mit ziemlicher Sicherheit nicht.)
Wenn es sich jedoch um ein Skript handelt, wird diese PHPSESSIDVariable an das Skript übergeben. Wenn das Skript diese Variable tatsächlich verwendet (in diesem speziellen Fall werden wahrscheinlich nur PHP-Skripte verwendet, die die integrierte Sitzungsbehandlung von PHP verwenden), hängt ihr Verhalten vom Inhalt ab.
Aller Wahrscheinlichkeit nach wird jedoch /nichts Bemerkenswertes passieren , selbst wenn Sie mithilfe von Sitzungen einem PHP-Skript zugeordnet werden. Die Sitzungs-ID ist wahrscheinlich sowieso nicht vorhanden und wird entweder ignoriert oder das Skript zeigt einen Fehler an.
In dem unwahrscheinlichen Fall, dass die Sitzungs-ID vorhanden ist, könnte der Angreifer möglicherweise die Sitzung eines anderen entführen. Das wäre schlecht, aber es ist nicht wirklich eine Sicherheitslücke an sich - die Lücke wäre überall dort, wo der Angreifer die Sitzungs-ID-Informationen erhalten hat (das Aufspüren eines drahtlosen Netzwerks ist ein guter Kandidat, wenn Sie kein HTTPS verwenden). Sie würden tatsächlich nichts tun können, was der Benutzer, dessen Sitzung es ursprünglich war, nicht tun konnte.
Bearbeiten: Zusätzlich wird '% 5C' in der SESSIONID einem Backslash-Zeichen zugeordnet. Dies scheint ein Test für Directory Traversal-Angriffe auf Windows-Hosts zu sein.
curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. Die Standardkonfiguration scheint auf unserem Ubuntu-System eine Seite "Willkommen bei Nginx" ohne aussagekräftigen Inhalt zurückzugeben. Es handelt sich also um eine Antwort von 200, aber es handelt sich um eine einfache Sammel-Seite - wir stellen die Anfrage nicht an eine andere Stelle oder ähnliches.