Подход 2011 года к XSS в PHP?

Question

Я пытаюсь получить обновленную информацию о доступных и соответствующих контрмерах, которые активно снижают вероятность попадания поезда XSS в течение 2011 года.

Я погуглил, как никогда раньше, и обнаружил, что в Интернете есть множество доступных библиотек, которые должны помочь с проблемами XSS, которые гордо и смело заявляют, что « доллар XSS / SQL-инъекций здесь останавливается ».

Я обнаружил, что эти библиотеки страдают по крайней мере от одного из двух следующих симптомов:

• Библиотека настолько огромна, что, вероятно, имеет собственное сердцебиение.
• Библиотека относится к тем временам, когда мальчики из Бич играли по радио.

PHP существует уже некоторое время, и далеко не приличный strip_tags сопровождается такими функциями, как, например, filter_var. Я далеко не эксперт в этих вопросах безопасности и действительно не могу сказать, обеспечит ли это в будущем хорошие ночи сна или нет.

Какой у меня наилучший шанс сократить инъекции XSS в течение 2011 года без взлома моего кода, с или без устаревших библиотек?

Answer 1

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

Если вы застряли без реального шаблона, используйте htmlspecialchars () .

Answer 2

Я не могу больше согласиться с Матти Вирккуненом или с тем, что, по моему мнению, подразумевается в ответе Матти, поэтому позвольте мне сказать это громко и ясно: ничего"удалит весь вредоносный код". Вы никогда не можете знать, как данные будут использоваться в других частях приложения или в будущем. Вы можете «очистить» его для SQL, но вы не должны помещать в SQL ничего неэкранированного. Вы можете «очистить» его для HTML, но вы никогда не должны включать какие-либо данные, не экранированные в HTML. Вы можете «очистить» его для включения в параметр awk в сценарии оболочки, но ... вы поняли.

Даже проблема остановки неразрешима, тем более злонамеренные намерения любого данного кода или данных. Любые методы ввода «очистки» бесполезны в долгосрочной перспективе. Что необходимо, так это правильное экранирование данных. Всегда. Поэтому, если вы хотите включить что-либо в запрос SQL, включите его как данные , а не как код. Если вы хотите напечатать имя пользователя в записи блога, включите его как текст , а не как HTML. Никто никогда не пострадает, увидев комментарий от "Mr. alert ('XSS'); ", если имя пользователя закодировано в HTML или динамически добавлено в DOM как текстовый узел.

Все инструменты автоматической очистки - это не что иное, как волшебная пыль, добавляемая в вашу программу для обеспечения ее безопасности. Они говорят: «Здесь - мы сделали все ваши данные кошерными, чтобы вы могли теперь использовать их небезопасно и не беспокоиться о границах данных!» Это только приводит к ложному чувству безопасности. Мы, как разработчики, должны взять на себя ответственность за вывод наших данных и никогда не предполагать, что все отлично, потому что у нас есть инструмент, который делает все наши данные «безопасными», что бы это ни значило на входе.

Answer 3

Я рекомендую HTMLPurifier для пользовательских данных:

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

Answer 4

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

Answer 5

Реальные изменения в 2011 году в браузерах. Например, IE был первым, кто внедрил xss фильтр .

Если честно, SQL Injection и XSS можно позаботиться о наличии безопасного MVC. Например, если данные отправляются в представление, они должны быть обработаны для просмотра. В php smarty это можно сделать, установив «Фильтр переменных». Для инъекции SQL необходимо использовать параметризованные запросы ADODB или PDO.

В обоих этих случаях потенциально испорченная переменная очищается непосредственно перед использованием. Вы точно знаете, как вы используете данные, поэтому понятно, как их нужно чистить.