По-перше, спереду, я не знаю, що намагається зробити зловмисник. Можливо, там є PHP-скрипт або PHP-версія, вразлива для якоїсь дивної атаки ідентифікатора сеансу, я не хочу. Вам, мабуть, нема про що турбуватися.
Ваш сервер поводився точно так, як очікувалося. 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. Конфігурація за замовчуванням, схоже, повертає на нашу систему ubuntu сторінку "Ласкаво просимо на nginx" без змістовного вмісту. Отже, це відповідь у 200, але це проста сторінка, що займає загальну інформацію - ми фактично не звертаємось до запиту в іншому місці чи щось подібне.