Заботясь о XSS

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

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

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

$_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;
}

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

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

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

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

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

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

I THINK people would only be able to hack themselves

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

The recommendation is to do this: echo htmlentities($_POST[‘input’], ENT _QUOTES, ‘UTF-8’);

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

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

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

На самом деле это не так уж и много лишних хлопот.