Является ли $ _SERVER ['QUERY_STRING'] безопасным для XSS?

Question

Мне нужно создать форму, действие которой возвращает вас на ту же самую страницу - включая параметры GET. Я думаю, что могу сказать что-то с эффектом:

echo '<form action="'.$_SERVER['SCRIPT_NAME'].'?'.$_SERVER['QUERY_STRING'].
     '" method="post">'

Кажется, что это работает, и тестирование прохождения нескольких XSS-атак кажется успешным, так как выходные данные QUERY_STRING, похоже, закодированы в виде URL. Однако PHP-документация не упоминает об этом, поэтому я не уверен, что могу доверять этому поведению.

Безопасно ли использовать QUERY_STRING, как я выше? Если нет, что я могу сделать вместо этого? Ссылки на документацию приветствуются.

Обновление переключился на SCRIPT_NAME, просто перепутал, какой из них был в порядке, а какой был плохим в моей голове, спасибо, что поймали меня. action="" действительно разрешает мою конкретную проблему, но мне все еще любопытно, если QUERY_STRING предварительно обработан, так что это безопасно для использования или нет, поскольку в других случаях вы можете захотеть повторно использовать строку запроса, предполагая, что это безопасно сделать это.

Answer 1

Вы никогда не должны доверять $ _SERVER ['QUERY_STRING'], поскольку он может использоваться для атак XSS.

В вашем случае уязвимость можно использовать с помощью:

http://your.server.com/your_script.php?"><script>alert(111);</script>

Примечаниечто приведенный выше код работает в IE;FireFox и Chrome эффективно кодируют строку запроса перед отправкой ее на веб-сервер.

Я бы всегда заключал ее в htmlentities (учитывайте параметр double_encode), как и при каждом вводе пользователем.

Удачи!

Answer 2

Если XSS может использовать его, сначала вам нужно узнать, какая атака.В приведенном здесь коде есть только одна простая атака с использованием PHP_SELF.

Но, чтобы избежать любой проблемы, вы можете просто оставить действие формы пустым.Это отправит форму на ту же страницу, включая строку запроса.

Answer 3

Прежде всего, вы не можете доверять $ _SERVER ['PHP_SELF'] ( 1 ) - используйте вместо него $ _SERVER ['SCRIPT_NAME'].

Что касается $ _SERVER ['QUERY_STRING '], вы должны рассматривать это как любой другой пользовательский ввод.Отфильтруйте его перед использованием в выходных данных.Я бы не рекомендовал какой-то общий фильтр в этом случае.Было бы лучше собрать строку запроса из определенных частей, которые вы ожидаете там найти.

Answer 4

Это еще один из тех случаев, когда использование PHP filter_input - это путь. Мой IDE NetBeans (ненавижу или люблю его) всегда жалуется, когда я открываю код, который обращается к $_POST, $_GET, $_SERVER и $_COOKIE напрямую, не проходя через filter_input.

Это из-за причин, изложенных выше - вы говорите, что доверяете внешним данным, когда, если они могут вводиться или манипулироваться пользователями, вы не можете.

filter_input(INPUT_POST, 'id', FILTER_SANITIZE_NUMBER_INT);
filter_input(INPUT_SERVER, 'QUERY_STRING', FILTER_SANITIZE_STRING);

Подробнее здесь

Answer 5

Я не могу вспомнить ни одной атаки, которая бы работала от руки, но PHP_SELF сам по себе уязвим, и вы используете QUERY_STRING без какой-либо фильтрации, что кажется странным.

Почему бы просто не оставить параметр action пустым и позволить браузеру принять решение? Вы можете использовать Javascript для правильного применения этого поведения на стороне клиента, если вы хотите быть вдвойне уверенным.