Всегда избегать вывода в поле зрения? Зачем?

Question

В руководстве * Zend Framework 1002 * говорится следующее:

60.3.1. Выходящий выход

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

Почему 'всегда'? Почему я должен экранировать переменные, которые не были созданы или изменены пользовательским вводом?

Answer 1

Пользователи - не единственный источник хитрых строк в выводе. Рассмотрим, например, кажущуюся безопасной строку «Romeo & Juliet», выходящую из базы данных. Там нет межсайтовых скриптов, говорите? Правда достаточно. Однако вставьте его на веб-страницу, и необработанный амперсанд может вызвать некоторые интересные проблемы с проверкой, анализом и т. Д.

Экранирование вывода - это не просто защита от злонамеренного или случайно пропущенного ввода, оно обеспечивает тщательную очистку и обработку вывода как не имеющего особого значения в окружающем формате вывода, будь то HTML, XML, JSON и т. 1003 *

Answer 2

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

Если вы используете представление, $this->escape($variableToEscape) должно быть достаточно.

Answer 3

Другое дело, что часто вещи, которые жестко запрограммированы в один день, становятся пользователями или, по крайней мере, база данных создается в другой день. Лучше всего управлять выводом переменных в вашем коде.

Answer 4

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

Экранирование по умолчанию предотвратит эту атаку.

Другая причина более концептуальна: в MVC вся ваша разметка, которая по определению является «представлением», должна быть в ваших шаблонах представлений. Так что, если ваш контроллер определяет представление, а представление содержит всю разметку, почему бы не экранировать ваши переменные?

Answer 5

Я думаю, что лучшая практика здесь всегда экранировать, если вы не собираетесь выводить необработанный фрагмент HTML.Даже «безопасные» данные могут содержать символы, которые необходимо экранировать.Например, рассмотрим адрес электронной почты «Боб»».Если вы не избежите этого, браузер подумаетэто тег.

Answer 6

Вы можете посмотреть на это так: вы всегда должны кодировать переменные HTML, если вы не знаете, что они уже были закодированы.

Скажем, у вас есть переменная, которая содержит:

foo <b>bar</b>

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

Конечно, это означает, что

foo & <b>bar</b>

- неверное значение; вам нужно убедиться, что это:

foo &amp; <b>bar</b>

Answer 7

Что ж, если у вас есть жестко запрограммированные значения (скажем, языковые переводы, которые вы читаете из базы данных или файла XML), вам не нужно избегать их.

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