REST Web Services и где поставить защиту XSS

Question

Мне интересно, где лучше всего разместить защиту XSS на нашем сайте.Наша команда разделена на команды, работающие на стороне и на стороне, и использует REST в качестве API между нашими двумя группами, поскольку мы используем разные платформы.У нас есть поле, которое может содержать подмножество HTML, которое должно быть защищено, и мне было интересно, на каком уровне это должно быть сделано?

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

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

Answer 1

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

Однако, ради удобства использования, мы часто выбираем дружественную проверку и отчеты об ошибках в пользовательском интерфейсе.Я только что закончил заполнять онлайн-форму на веб-сайте, который блокирует слой службы, если какое-либо поле содержит не буквенно-цифровую форму.Было бы так намного лучше, если бы пользовательский интерфейс подтвердил точку входа, а не отклонил мой запрос после 3 страниц ввода.

(Не говоря уже о том, что веб-сайт запрашивает)Вы за имя работодателя, и имя фактически содержит апостроф, который вы, кажется, немного запутали!)

Answer 2

Вы должны использовать оба.Типичным примером является попытка санации страшных данных при входе (и вы действительно должны отклонить запрос, если санация необходима для данного значения) и кодирование при выходе.

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