Проверка (vs) Санитария в Symfony2 + Twig?

Мне нужно, чтобы мои пользователи вводили URI своего персонального веб-сайта в свой профиль, чтобы другие пользователи могли видеть и нажимать на него. Я обеспокоен тем, что это может привести к атакам XSS, если результат не будет правильно обработан.

Как в этой очень упрощенной схеме ниже:

Я использую полный стек Symfony2 framework, Doctrine как ORM и Twig в качестве механизма шаблона. Я знаю, что Symfony предоставляет некоторые удивительные инструменты проверки и что TWIG предоставляет автоматическое выходное экранирование (что не обязательно в данном конкретном случае), а также некоторые фильтры для очистки данных.

Я прочитал следующее о как очистка дескрипторов symfony2 и twig:

Доктрина поставляется с дезинфекцией для базы данных (SQL). Кроме того, нет рекомендуемых/предоставленных входной дезинфекции на уровне контроллера в Symfony2. Однако, используя Twig в просмотр, дезактивация продукции.

В качестве примера, в CakePHP:

Санитарная обработка данных реализована как Utility, которая может быть доступный из любого места (контроллер, компонент, модель.. даже просмотр). Это следует подходе с использованием санитарии-все-ввода с фиксированным набором предопределенных фильтры санитарии. Санирование конкретных материалов с помощью специальных правил возможно, но, похоже, его не поощряют. Существующие правила сосредоточиться на SQL и HTML-инъекциях и отфильтровывать общие подозрительные символы Unicode.

1 Как пользователи symfony2 + twig обрабатывают входную санитацию? Они полностью отбрасывают санитарию ввода и, например, полагаются только на проверку? Или они пишут свою собственную функцию полезности для фильтрации пользовательских входов? или, возможно, использовать библиотеку, например owasp-esapi-php?

2 Как пользователи symfony2 + twig обрабатывают обработку данных? Они полагаются только на фильтры, предоставляемые двигателем ветки? Например, существуют ли какие-либо инструменты, которые можно использовать для дезинфекции введенного пользователем URI, что-то похожее на это?

3 В этой ситуации, как бы вы обрабатывали хранилище базы данных и отображали введенный пользователем URI, как в приведенном выше примере, вы вообще не заботитесь о дезинфекции ввода? или вы используете только санацию на выходе и сохраняете URI как есть?

Ответ 1

Вы не должны беспокоиться о дезинфекции входных данных, Doctrine невосприимчив к инъекции sql
По умолчанию все выходные данные экранируются. Так что даже если $text имеет теги script, он будет экранирован; видимый как текст, но не выполненный браузером. И если вы хотите, чтобы http://example.com clickable, есть плагины jquery, которые могут сделать это для вас.
Я бы поставил только проверку, есть
```
new Symfony\Component\Validator\Constraints\Url() ;
```

для вас

Ответ 2

Существует также красивый набор symfony2, который позволяет пользователям реализовывать фильтрацию ввода в сущностях, использующих аннотации. Вот так:

/**
* @Filter\StripTags()
* @Filter\Trim()
* @Filter\StripNewlines()
*
* @var string
*/
public $email;

Пакет: dms-filter-bundle

Ответ 3

Я думаю, что Symfony и CakePHP являются фреймворками, и процесс сохранения не может правильно знать входной контекст и что он будет сохранять в БД. Разработчик знает контекст, если он URL, HTML, SQL и т.д., Даже при выводе данных, поэтому часто выбирают санацию вывода, и если разработчик хочет внедрить санацию ввода, он всегда может и использует некоторые существующие инструменты.

Вы можете использовать HTML Purifier для "очистки" всех пользовательских входов.

https://github.com/Exercise/HTMLPurifierBundle

Ответ 4

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

Вам следует рассмотреть вопрос о добавлении теста для url-шаблона, различные

Другие пользователи уже указали, что вы защищены от различных attax с использованием компонентов (csrf, проверка типов/свойств (symfony-form), sql-injection (Doctrine) и xss (twig) и, конечно, различная аутентификация доступа)

Итак, для конкретной атаки, которую вы задаете, необходимо, чтобы плохой пользователь отправил script -tag, а некоторые бедные пользователи получили это отображение и выполнение, вы можете легко избежать этого в своем приложении с помощью простого регулярного выражения

preg_replace ('/(<'. 'script'. ' > ) (. *) (</'. 'script'. ' > )/g', '', $text);

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