Как защититься от xss при сохранении данных и при их отображении - PullRequest
Новая
       33

Как защититься от xss при сохранении данных и при их отображении

0 голосов
/ 20 февраля 2019

Допустим, у меня есть простое приложение CRUD с формой для добавления нового объекта и редактирования существующего.С точки зрения безопасности я хочу защититься от межсайтовых скриптов.Во-первых, я бы подтвердил ввод представленных данных на сервер.Но после этого я бы избегал значений, отображаемых в представлении, потому что, возможно, у меня в базе данных было написано более одного приложения (какой-то разработчик по ошибке вставляет непроверенные данные в БД в будущем).Так что у меня будет jsp: 

<%@ taglib prefix="esapi" uri="http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API" %>
<form ...>
   <input name="myField" value="<esapi:encodeForHTMLAttribute>${myField}</esapi:encodeForHTMLAttribute>" />
</form>

<esapi:encodeForHTMLAttribute> делает почти то же самое, что и <c:out>, это HTML экранирует чувствительные символы, такие как < > " и т.д.

Теперь, если я загружуобъект, который каким-то образом был сохранен в базе данных с myfield=abc<def, на входе будет правильно отображаться значение abc<def, а значение в html будет abc&lt;def.

Проблема когда пользователь отправляет эту форму без изменения значений, сервер получает значение abc&lt;def вместо того, что отображается на странице abc<def.Так что это не правильно.Как мне реализовать защиту в этом случае?

1 Ответ

0 голосов
/ 21 февраля 2019

Проблема в том, что когда пользователь отправляет эту форму без изменения значений, сервер получает значение abc&lt;def вместо того, что видно на странице abc

Easy.В этом случае HTML декодирует значение, а затем проверяет.

Хотя, как отмечено в нескольких комментариях, вы должны увидеть, как мы работаем с проектом OWASP ESAPI-Java .По умолчанию мы всегда канонизируем данные, что означает, что мы запускаем серию декодеров для обнаружения многократного / смешанного кодирования, а также для создания безопасной строки для проверки с помощью регулярных выражений.

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

Кодировка - это лучшая защита для XSS, и я на самом деле рекомендовал бы ее ДО проверки правильности ввода, если по какой-то причине вам пришлось выбирать.

Я говорю может , потому что в целом я считаю плохой практикой хранить измененные данные.Это может сделать поиск неисправностей рутиной.Это может быть еще сложнее, если вы используете такую ​​технологию, как TinyMCE, текстовый редактор в браузере.Он также отображает HTML, так что это похоже на работу с браузером в браузере.

...