XSS в PHP: htmlspecialchars или правило Apache URL Rewrite?

Я не знаком с PHP, и наш продукт написан не на PHP. Мы используем поставщика, который создает для нас документацию с использованием PHP. Недавно мы обнаружили XSX-атаку в PHP-коде. Атака XSS была произведена, когда злоумышленник получил доступ к

vendor.php/%22onmouseover=%22alert%281310%29%22

Обычный доступ похож на

vendor.php?param1=val1&param2=val2

После исследования кода я нашел проблемную строку:

$SelfURL = $_SERVER['PHP_SELF'];

Я исправил это, используя эту замечательную ссылку PHP_SELF и XSS:

$SelfURL = htmlspecialchars($_SERVER['PHP_SELF'], ENT_QUOTES, "utf-8");

Мы отправили исправление поставщику и попросили исправить PHP. Ответ меня удивил: поставщик утверждает, что их PHP без проблем и что мы должны включить на нашем сервере Apache правила перезаписи URL, которые не позволят получить доступ к таким страницам, как vendor.php/.

Я попытался объяснить, что у нас нет правил перезаписи URL, и только доступ к его странице создает атаку (из-за $SelfURL = $_SERVER['PHP_SELF']). Поскольку я не знаком с PHP, я хочу перепроверить:

  1. Достаточно ли использовать htmlspecialchars?
  2. Должны ли мы создавать правила перезаписи URL?

php security xss penetration-testing
person Michael    schedule 01.06.2013    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Важно действительно запретить доступ к определенным файлам. Вы можете сделать это с помощью файла .htaccess и переписать правила. Но также всегда дезинфицируйте пользовательский ввод! Никогда не рискуйте!

person Patrick Brouwers    schedule 01.06.2013
comment
Спасибо (+1)! У вас есть соответствующий пример правила перезаписи? Кроме того, я просмотрел пару ответов, связанных с PHP XSS, и никто не говорит о правилах перезаписи. - person Michael; 01.06.2013
comment
Попробуйте <Files vendor.php> order deny,allow deny from all </Files> - person Patrick Brouwers; 02.06.2013

arrow_upward
1
arrow_downward

Достаточно ли использовать htmlspecialchars?

Чтобы решить проблему HTML-инъекций, да. Но если вы нашли хоть одно место, где им не удалось экранировать HTML-контент таким тривиальным способом, может показаться, что у них нет последовательно применяемого подхода к экранированию... так что вполне вероятно, что их больше.

Использование автоматизированного сканера и/или поверхностной проверки кода будет следующим шагом для оценки того, является ли это частью более серьезной проблемы.

Поставщик утверждает, что их PHP работает без проблем.

Это не признак ответственного отношения к безопасности. Совсем не воодушевляет.

мы должны включить на нашем сервере Apache правила перезаписи URL, которые не позволят получить доступ к таким страницам, как vendor.php/

Вам не нужен доступ к этой странице?

Если они предоставили вам набор административных страниц, которые не должны быть доступны, им необходимо задокументировать, какие страницы задействованы, чтобы вы могли удалить к ним доступ.

Обычно вы не используете перезапись, чтобы заблокировать доступ к странице. Было бы разумнее использовать директиву Deny или, что лучше всего, если это возможно, просто удалить страницу-нарушитель из развертывания.

person bobince    schedule 02.06.2013