2011-01-03 2 views
4

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

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

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

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

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

+0

Никогда не думайте. Вы никогда не знаете, что могут сделать эти мошенники! – BoltClock

+0

Конечно, нет :) это необработанные значения из uri – RobertPitt

+1

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

ответ

7

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

В вашем случае, можно было бы использовать эту уязвимость с:

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

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

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

Удачи вам!

+0

Спасибо,/это/то, о чем я просил. Мы не можем доверять переменной, потому что ее содержимое зависит от браузера, отлично. – dimo414

+1

+1 Обратите внимание на важную часть информации. Дело не в том, что вы не можете * использовать * данные; это только то, что вы не можете * доверять * ему :) –

1

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

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

1

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

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

0

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

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

0

Это еще один из тех случаев, когда использование 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); 
filter_input(INPUT_POST, 'another_field'); 

Подробнее here

Смежные вопросы