Не делайте этого с регулярными выражениями. Помните, что вы не защищаете только от правильного HTML; Вы защищаете от DOM, который создают веб-браузеры. Браузеры могут быть легко обмануты для создания действительного DOM из недействительного HTML.
Например, см. Этот список обфусцированных XSS-атак . Готовы ли вы приспособить регулярное выражение для предотвращения настоящей атаки на Yahoo и Hotmail на IE6 / 7/8?
<HTML><BODY>
<?xml:namespace prefix="t" ns="urn:schemas-microsoft-com:time">
<?import namespace="t" implementation="#default#time2">
<t:set attributeName="innerHTML" to="XSS<SCRIPT DEFER>alert("XSS")</SCRIPT>">
</BODY></HTML>
Как насчет этой атаки, которая работает на IE6?
<TABLE BACKGROUND="javascript:alert('XSS')">
Как насчет атак, которые не перечислены на этом сайте? Проблема с подходом Джеффа состоит в том, что это не белый список, как утверждается. Как кто-то на этой странице умело отмечает:
Проблема в том, что HTML
должен быть чистым. Есть случаи, когда
Вы можете перейти на взломанный HTML, и это
не будет соответствовать этому, в этом случае это будет
вернуть взломанную строку html как
не будет соответствовать ничего, чтобы заменить. это
не только в белом списке.
Я бы предложил специальный инструмент, подобный AntiSamy . Он работает, фактически анализируя HTML, а затем обходя DOM и удаляя все, что не входит в белый список configurable . Основным отличием является способность изящно обрабатывать искаженный HTML.
Самое приятное то, что он фактически выполняет модульные тесты для всех XSS-атак на вышеуказанном сайте. Кроме того, что может быть проще, чем этот вызов API:
public String toSafeHtml(String html) throws ScanException, PolicyException {
Policy policy = Policy.getInstance(POLICY_FILE);
AntiSamy antiSamy = new AntiSamy();
CleanResults cleanResults = antiSamy.scan(html, policy);
return cleanResults.getCleanHTML().trim();
}