Во-первых, я не знаю, что пытается совершить предполагаемый злоумышленник. Может быть, есть сценарий PHP или версия PHP, уязвимая для какой-то странной атаки ID сессии, я не знаю. Вам, вероятно, не о чем беспокоиться.
Ваш сервер вел себя точно так, как ожидалось. 200 - ожидаемый код в данной конкретной ситуации из-за того, как Apache интерпретирует передаваемый ему URL.
Во-первых, http://allrequestsallowed.comобрабатывается как более обычный заголовок «Host:» ( обратите внимание, что я не думаю, что это указано в RFC, и другие серверы могут не интерпретировать это так, как я ошибался, это указано в RFC 2616 в разделе 5.1. 2, хотя клиенты, кажется, редко используют эту форму. Извините, мне нужно исправить реализацию сервера HTTP, которую я написал некоторое время назад ...).
Теперь, по-видимому, у вас нет сайта с именем «allrequestsallowed.com». Так что же происходит, когда Apache получает Host:заголовок (или эквивалент) для имени хоста, которое он не распознает? Первый виртуальный хост выбирается по умолчанию. Это хорошо определенное и задокументированное поведение для Apache. Таким образом, какой бы ни был ваш первый виртуальный хост (или просто конфигурация основного сервера, если нет никаких vhosts), все равно, независимо от того, как он называется.
Теперь оставшаяся часть URL состоит из двух частей - пути /и параметра GET ( ?PHPSESSID...бит).
Теперь путь /должен присутствовать практически на каждом веб-сервере. В большинстве случаев он сопоставляется с чем-то вроде index.htmlили, возможно, index.phpсценарием, хотя вы, конечно, можете переопределить все это.
Если он отображается в статический HTML-файл, абсолютно ничего необычного не происходит - возвращается содержимое файла, и все, параметр просто игнорируется. (Предполагая, что у вас нет определенных расширенных директив конфигурации, и вы почти наверняка этого не сделаете.)
С другой стороны, если это какой-то скрипт, эта PHPSESSIDпеременная будет передана в скрипт. Если сценарий фактически использует эту переменную (в данном конкретном случае, вероятно, только сценарии PHP, использующие встроенную обработку сеансов PHP), его поведение будет зависеть от содержимого.
Однако, по всей вероятности, даже если вам /случится сопоставить скрипт PHP с использованием сессий, ничего удивительного не произойдет. Идентификатор сеанса, вероятно, в любом случае не будет существовать и будет либо проигнорирован, либо скрипт выдаст ошибку.
В маловероятном случае, когда идентификатор сеанса существует, злоумышленник может предположительно захватить чужой сеанс. Это было бы плохо, но это на самом деле не дыра в безопасности - дыра была бы там, где злоумышленник получил информацию об идентификаторе сеанса (прослушивание беспроводной сети - хороший кандидат, если вы не используете HTTPS). На самом деле они не смогут сделать ничего, чего не смог бы сделать пользователь, для которого он изначально был сеансом.
Изменить: Кроме того, «% 5C» внутри SESSIONID отображается на символ обратной косой черты. Похоже, что это тест для атак через каталоги на хостах Windows.
curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. Кажется, что конфигурация по умолчанию возвращает страницу "Welcome to nginx" без содержательного содержимого в нашей системе Ubuntu. Таким образом, это ответ 200, но это простая всеобъемлющая страница - на самом деле мы не передаем запрос в другом месте или что-то в этом роде.