заботиться о XSS

Question

Я запустил приложение для ручного тестирования, и оно обнаружило кучу ошибок XSS, в частности, я виновен в том, что отправляю непроверенные данные обратно в браузер через строку запроса.

В частности, запуск этого добавляет javascript на мою страницу. http://www.mywebsite.com/search.php?q=%00'" [ScRiPt]% 20% 0a% 0d> alert (426177032569)% 3B [/ ScRiPt].

К счастью, нет, где я могу позволить пользователям сохранять данные в базе данных и отображать их другим пользователям, поэтому я ДУМАЮ, что люди смогут взломать себя только с этой проблемой, но я все еще хочу ее исправить.

Рекомендуется сделать это:

echo htmlentities($_POST[‘input’], ENT_QUOTES, ‘UTF-8’);

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

array_walk($_POST, 'htmlentities');  

Мне нужно сделать это и для COOKIE, и для GET. Я никогда не использую _REQUEST.

Спасибо

Answer 1

Выход из HTML на пути, очевидно, является неправильным, но может быть временным исправлением, пока вы не замените код чем-то правильным. В долгосрочной перспективе это будет невозможно поддерживать, и у вас будет множество странных ошибок на уровне приложения везде, где вы начнете делать подстроки (включая усечение, которое ваша база данных может делать автоматически) для & -кодированных символов. Это вряд ли приведет к нарушениям безопасности, хотя вы не можете сказать, не посмотрев на приложение более подробно.

Если вы начнете кодировать вещи в $ _SESSION каждый раз, вы получите многократно закодированные слишком длинные строки, такие как & amp; amp; amp; amp; amp; amp; amp; усилитель, усилитель; очень быстро.

Я думаю, что люди смогут взломать только себя

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

Рекомендую сделать это: эхо htmlentities ($ _ POST [‘input’], ENT _QUOTES, ‘UTF-8’);

Нет необходимости в htmlentities и всех этих параметрах - используйте htmlspecialchars.

Вы можете сэкономить несколько нажатий клавиш, используя что-то вроде:

function h($s) { echo(htmlspecialchars($s)); }
...
<?php h($POST['input']) ?>

Это действительно не так уж много лишних хлопот.

Answer 2

Слепое экранирование всего ввода в интерфейсе означало бы, что любая часть вашей программы, которая имела дело с этим вводом, должна была бы обрабатывать html-экранированные версии <,>, & и т. Д. Если вы храните данные в базе данных , тогда у вас будут html-экранированные данные в вашей базе данных. Если вы используете данные в не HTML-контексте (например, при отправке электронного письма), люди увидят & lt; вместо <и т. д. </p>

Возможно, вы просто хотите уйти при выводе.

Answer 3

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

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

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

Answer 4

приведенный выше код не работает, но это работает:

$_POST = clean_input($_POST);
$_GET = clean_input($_GET);
$_COOKIE = clean_input($_COOKIE);
$_SESSION = clean_input($_SESSION);

function clean_input($array){
    if(count($array)){
        foreach ($array as $key => $value) {
            $array[$key]=htmlentities($value, ENT_QUOTES, 'UTF-8');
        }
    }
    return $array;
}

Я просто пытаюсь понять, что здесь может пойти не так.