Как разрешить определенные символы с помощью OWASP HTML Sanitizer?

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

например: 

HtmlPolicyBuilder htmlPolicyBuilder = new HtmlPolicyBuilder();
stripAllTagsPolicy = htmlPolicyBuilder.toFactory();
stripAllTagsPolicy.sanitize('a+b'); // return a+b
stripAllTagsPolicy.sanitize('foo@example.com'); // return foo@example.com

когда у меня есть поля, такие как адрес электронной почты, который есть + в нем, например,foo+bar@gmail.com Я заканчиваю с неправильными данными в базе данных. Итак, два вопроса:

  1. такие символы, как + - @ опасные сами по себе они действительно должны быть закодировано?
  2. как настроить очиститель OWASP html, чтобы разрешить определенные символы, такие как + - @?

Вопрос 2 является более важным для меня, чтобы получить ответ.

7
java owasp sanitization security xss

3 ответов

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

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

пример первый стратегия:

пользователь вводит данные (с html-кодом)

  1. сервер удалить все опасные символы
  2. измененные данные хранятся в базе данных
  3. некоторое время спустя сервер считывает измененные данные из базы данных
  4. сервер вставляет измененные данные на веб-страницу другому пользователю

пример второй стратегии:

  1. пользователь вводит данные (с html-кодом)
  2. немодифицированные данные, с опасными символы, хранится в базе данных
  3. некоторое время спустя сервер считывает немодифицированные данные из базы данных
  4. сервер html-кодирует опасные данные и вставляет их на веб-страницу другому пользователю

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

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

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

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

1

вы можете использовать API ESAPI для фильтрации определенных символов. Хотя, если вы хотите разрешить определенный HTML-элемент или атрибут, вы можете использовать следующие allowElements и allowAttributes.

// определение политики.

Function<HtmlStreamEventReceiver, HtmlSanitizer.Policy> policy
     = new HtmlPolicyBuilder()
         .allowElements("a", "p")
         .allowAttributes("href").onElements("a")
         .toFactory();

 // Sanitize your output.
 HtmlSanitizer.sanitize(myHtml, policy.apply(myHtmlStreamRenderer));
2

честно говоря, вы действительно должны делать белый список против всех пользовательских входных данных. Если это адрес электронной почты, просто используйте OWASP ESAPI или что-то еще для проверки ввода против их валидатора и регулярных выражений электронной почты.

Если вход проходит белый список, вы должны пойти вперед и сохранить его в БД. При отображении текста обратно пользователю, вы всегда должны HTML кодировать его.

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

1