Po pierwsze, nie wiem, co rzekomo atakujący stara się osiągnąć. Może istnieje skrypt PHP lub wersja PHP podatna na dziwny atak identyfikacyjny sesji, nie wiem. Prawdopodobnie nie masz się czym martwić.
Twój serwer zachowywał się dokładnie tak, jak oczekiwano. 200 jest oczekiwanym kodem w tej konkretnej sytuacji ze względu na to, jak Apache interpretuje przekazywany do niego adres URL.
Po pierwsze, http://allrequestsallowed.comjest traktowany jak zwykły nagłówek „Host:” ( zauważ, że nie sądzę, że jest to określone w RFC, a inne serwery mogą nie interpretować tego w ten sposób, że się myliłem, jest to określone w RFC 2616 w sekcji 5.1. 2, chociaż klienci rzadko używają tej formy. Przepraszam, muszę naprawić implementację serwera HTTP, o której pisałem jakiś czas temu ...).
Teraz prawdopodobnie nie masz witryny o nazwie „allrequestsallowed.com”. Co się stanie, gdy Apache otrzyma Host:nagłówek (lub odpowiednik) dla nazwy hosta, której nie rozpoznaje? Domyślnie wybiera pierwszego wirtualnego hosta. Jest to dobrze zdefiniowane i udokumentowane zachowanie Apache. Niezależnie od tego, jaki jest Twój pierwszy wirtualny host (lub tylko główna konfiguracja serwera, jeśli nie ma żadnych vhostów), niezależnie od tego, jak się nazywa.
Teraz reszta podanego adresu URL składa się z dwóch części - ścieżki /i parametru GET ( ?PHPSESSID...bit).
Teraz ścieżka /powinna być obecna na prawie każdym serwerze WWW. W większości przypadków, mapuje do czegoś podobnego index.html, a może w index.phpskrypcie, choć można przesłonić tego oczywiście.
Jeśli jest mapowany na statyczny plik HTML, absolutnie nic się nie dzieje - zawartość pliku jest zwracana, i to po prostu parametr jest ignorowany. (Zakładając, że nie masz określonych zaawansowanych dyrektyw konfiguracji i prawie na pewno nie masz.)
Z drugiej strony, jeśli jest to jakiś skrypt, PHPSESSIDzmienna zostanie przekazana do skryptu. Jeśli skrypt faktycznie używa tej zmiennej (w tym konkretnym przypadku prawdopodobnie tylko skrypty PHP korzystające z wbudowanej obsługi sesji PHP), jego zachowanie będzie zależeć od zawartości.
Jednak najprawdopodobniej nawet jeśli /zdarzy się, że mapujesz skrypt PHP za pomocą sesji, nic niezwykłego się nie wydarzy. Identyfikator sesji prawdopodobnie i tak nie będzie istniał i albo zostanie zignorowany, albo skrypt wyświetli błąd.
W mało prawdopodobnym przypadku, gdy istnieje identyfikator sesji, osoba atakująca może przypuszczalnie przejąć sesję innej osoby. To byłoby złe, ale tak naprawdę nie jest to luka w zabezpieczeniach sama w sobie - dziura byłaby wszędzie tam, gdzie atakujący uzyskał informacje o identyfikatorze sesji (wąchanie sieci bezprzewodowej jest dobrym kandydatem, jeśli nie używasz HTTPS). Nie byliby w stanie nic zrobić, czego nie mógł zrobić użytkownik, którego sesja pierwotnie była.
Edycja: Dodatkowo „% 5C” wewnątrz SESSIONID odwzorowuje znak odwrotnego ukośnika. To wydaje się być testem na ataki na katalogi na hosty Windows.
curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. Domyślna konfiguracja wydaje się zwracać stronę „Witamy w nginx” bez znaczącej zawartości w naszym systemie Ubuntu. Jest to więc odpowiedź 200, ale jest to prosta strona typu catch-all - właściwie nie zastępujemy żądania w innym miejscu ani nic takiego.