Филтриране на заявки за качване в периферията: възможности и рискове

Накратко: Филтрирането на заявки за качване в периферията означава POST заявки от тип multipart/form-data да се отхвърлят на прокси сървъра, уеб сървъра или в WAF, ако не са насочени към известен път за качване. Специалисти го предлагат като временна, неофициална мярка срещу PHP2Shell. Тя може да счупи формуляри и качвания и никога не замества актуализацията. Действайте на три стъпки: протоколирайте, определете изключения, едва тогава блокирайте, с твърда крайна дата.

Предложение от специализираната дискусия

Докато един сървър не е пачнат, операторите търсят всичко, което намалява риска. В специализираната дискусия за PHP2Shell се появи предложение: POST заявките във формат multipart/form-data, тоест формата за качване на файлове и някои формуляри, да се допускат само там, където приложението наистина ги очаква. Всички останали се отхвърлят на прокси сървъра или в Web Application Firewall.

Важно е да се разбере контекстът. Предложението не идва от php.net, а от специализирани автори и изрично е предвидено като временна мярка. php.net посочва собствени преходни мерки, събрани в Незабавни мерки, когато още не можете да пачнете. Филтърът може да ги допълва, не да ги замества.

Тук описваме как да го въведете контролирано. Подробностите защо той би могъл да помага срещу кои атаки, пропускаме съзнателно.

Какво постига филтърът и къде вреди

Идеята зад него е намаляване на повърхността за атака. Повечето страници на един сайт не се нуждаят от качване на файлове. Ако само няколко известни пътя приемат такива заявки, голяма част от възможните опити за атака изобщо не стига до PHP.

Обратната страна е също толкова ясна. Всяка функция, която изпраща multipart заявки и липсва в списъка с изключения, отпада. Това засяга не само очевидните формуляри за качване.

Към това се добавя принципен проблем: Cloudflare, която сама е внедрила защитни правила срещу PHP2Shell, предупреждава, че правила само по данните от заявката не са достатъчни. Как да мислите двата слоя заедно, описва WAF или актуализация: защо са нужни и двете.

Стъпка 1: първо протоколирайте, после блокирайте

Преди да блокирате нещо, установете кои пътища изобщо получават multipart заявки. Стандартните логове не показват типа на съдържанието. За Nginx затова създайте временно собствен протокол:

# в блока http
map $uri $upload_pfad {
    default 0;
    ~^/kontakt/upload\.php$ 1;
    ~^/admin/medien/ 1;
}

map "$request_method:$upload_pfad:$content_type" $multipart_fremd {
    default 0;
    "~*^POST:0:multipart/form-data" 1;
}

log_format multipart '$time_iso8601 $remote_addr "$request" "$content_type" $status';

# в блока server
# Внимание: access_log в блока server замества наследения протокол,
# затова посочете тук отново нормалния лог.
access_log /var/log/nginx/access.log combined;
access_log /var/log/nginx/multipart-test.log multipart if=$multipart_fremd;

Записите в $upload_pfad са примери. Започнете с празен списък с изключения, тогава тестовият протокол показва всички multipart POST заявки. В Apache същото се постига с променлива на средата:

# във VirtualHost
SetEnvIfNoCase Content-Type "^multipart/form-data" ist_multipart
CustomLog ${APACHE_LOG_DIR}/multipart-test.log combined env=ist_multipart

Оставете протокола да работи няколко дни, в идеалния случай през период, в който са били активни редакцията, кандидатите и интерфейсите.

Стъпка 2: определете изключения и блокирайте контролирано

От тестовия протокол извеждате пътищата, които легитимно се нуждаят от качвания. Сверете списъка с отговорните лица: кой поддържа съдържанието, какви формуляри има, кои услуги изпращат данни?

1. Изгответе списъка с изключения от протокола и допълнителни въпроси и го въведете в $upload_pfad респективно в редовете RewriteCond.
2. Активирайте филтъра първо в тестова среда или в спокоен времеви прозорец.
3. Изиграйте сами всички формуляри, качвания и пътища за поръчка.
4. Наблюдавайте протокола за грешки за отхвърлени заявки (статус 403) и при нужда допълнете списъка.
5. Определете крайна дата: след актуализацията на PHP и рестартирането на всички worker процеси филтърът се премахва отново.

В Nginx за това допълвате в блока server блокирането:

# в блока server, след оценката във фазата на протоколиране
if ($multipart_fremd) {
    return 403;
}

В Apache задачата поема mod_rewrite. Няколко условия според документацията на Apache се свързват с логическо И:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} =POST
RewriteCond %{HTTP:Content-Type} ^multipart/form-data [NC]
RewriteCond %{REQUEST_URI} !^/kontakt/upload\.php$
RewriteCond %{REQUEST_URI} !^/admin/medien/
RewriteRule ^ - [F]

Ако ползвате CDN или облачна WAF, същата логика често може да се изгради като собствено правило. И там важи: първо в режим на протоколиране, после блокиране.

Правилно разбиране на мярката

Филтърът за качване принадлежи към редица други предложения, които в момента се разпространяват. Някои са смислени, други вредни. Преглед кои съвети специалистите отхвърлят, например блокирането на всички заявки със сесийна бисквитка, дава Опасни фалшиви съвети за PHP2Shell.

Как PHP обработва качванията вътрешно и защо форматът multipart/form-data играе при това особена роля, обяснява Как PHP обработва качването на файлове. За повечето фирми най-важната стъпка обаче не е филтърът, а ясна дата за актуализацията.

Извод: инструмент за дни, не за месеци

Филтърът за качване в периферията е типичен пример за аварийна мярка: може да намали повърхността за атака в преходния период, но има странични ефекти и няма официална подкрепа от php.net. Използван правилно, с фаза на протоколиране, съгласуван списък с изключения, тестове и твърда крайна дата, той е приемлив. Без тези стъпки рискувате изгубени кандидатури, блокирани редакции и тихи грешки в интерфейсите.

Затова вземете решението съзнателно и запишете кой кога го е взел. И помнете реда: първо идва актуализацията на PHP с рестартиране на всички worker процеси, преходните мерки на php.net запълват времето дотогава, а филтърът е най-много допълнителен слой.

Как помага PHP SOS конкретно?

• Оценка на положението: изясняваме дали филтър за качване изобщо е смислен във Вашата ситуация или актуализацията е възможна по-бързо.
• Протоколиране и анализ: настройваме фазата на протоколиране и извеждаме списъка с изключения от истински достъпи.
• Контролирано блокиране: активираме филтъра, тестваме формуляри и пътища за поръчка и следим отхвърлените заявки.
• Чисто премахване: в рамките на WAF и виртуално пачване премахваме филтъра отново след актуализацията.

Често задавани въпроси

Източници

• php.net: Съобщения за сигурност
• Nginx: ngx_http_map_module
• Apache: mod_rewrite
• Блог на Cloudflare