{"id":761,"date":"2013-08-30T14:48:15","date_gmt":"2013-08-30T13:48:15","guid":{"rendered":"http:\/\/www.floyd.ch\/?p=761"},"modified":"2023-05-31T08:12:35","modified_gmt":"2023-05-31T07:12:35","slug":"owasp-antisamy-project-xss","status":"publish","type":"post","link":"https:\/\/www.floyd.ch\/?p=761","title":{"rendered":"OWASP AntiSamy Project XSS"},"content":{"rendered":"

From the OWASP AntiSamy Project page’s<\/a> “What is it” section:<\/p>\n

\nIt’s an API that helps you make sure that clients don’t supply malicious cargo code in the HTML they supply for their profile, comments, etc., that get persisted on the server. The term “malicious code” in regards to web applications usually mean “JavaScript.” Cascading Stylesheets are only considered malicious when they invoke the JavaScript engine. However, there are many situations where “normal” HTML and CSS can be used in a malicious manner. So we take care of that too.\n<\/p><\/blockquote>\n

So as far as I understand it, it is trying to prevent Cross Site Scripting (XSS). But to be fair, the user guide is a little bit more realistic:<\/p>\n

\nAntiSamy does a very good job of removing malicious HTML, CSS and JavaScript, but in security, no solution is guaranteed. AntiSamy\u2019s success depends on the strictness of your policy file and the predictability of browsers\u2019 behavior. AntiSamy is a sanitization framework; it is up to the user how it does its sanitization. Using AntiSamy does not guarantee filtering of all malicious code. AntiSamy simply does what is described by the policy file.\n<\/p><\/blockquote>\n

Anyway, I found a XSS that worked in the case of the web application I was testing:<\/p>\n

\r\n<a href="http:\/\/example.com"&\/onclick=alert(8)>foo<\/a>\r\n<\/pre>\n
Version: antisamy-1.5.2.jar with all default configuration files there are.<\/p>\n
Browsers tested (all working): Firefox 22.0 (on Mac OSX), Safari 6.0.5 (on Mac OSX), Internet Explorer 11.0.9200 (Windows 7) and Android Browser (Android 2.2).<\/p>\n
Disclosure timeline:
\nJuly 16th, 2013: Wrote to Arshan (maintainer) about the issue
\nJuly 16th, 2013: Response, questions about version and browser compatiblity
\nJuly 16th, 2013: Clarification about versions\/browser and that I only tried getNumberOfErrors(), informed that I’m planning to release this blog post end of August
\nJuly 23rd, 2013: Some more E-Mails about similar issue that was just resolved (not the same issue), including Kristian who comitted a fix
\nJuly 25th, 2013: Kristian sent a mail, he will have a look at the getNumberOfErrors() logic before releasing an update
\nJuly 31st, 2013: Asked if there are any updates on the issue, no response
\nSept 09th, 2013: Asked if there are any updates on the issue, response that it should be fixed. Requested new .jar file
\nOct 21st, 2013: Tested with the newest version available for download, antisamy 1.5.3. Problem still present. Public release.<\/p>\n
Antisamy doesn’t give any error messages and getNumberOfErrors() is 0. Although the getCleanHTML() will give back sanitised code without the XSS, people relying only on the getNumberOfErrors() method to check if an input is valid or not will have a XSS.<\/p>\n
Btw. the included configuration file names are somehow misleading (the names include company names like ebay). Those names are made up, doesn’t mean the companies use those conifg files at all. I don’t even know if they are using the antisamy project at all.<\/p>\n
I can’t recommend relying on that project. Proper output encoding<\/a> is important and is the real XSS prevention. And validating HTML with regex is hard<\/a>. Very hard. Very, very hard. Don’t.<\/p>\n","protected":false},"excerpt":{"rendered":"
From the OWASP AntiSamy Project page’s “What is it” section: It’s an API that helps you make sure that clients don’t supply malicious cargo code in the HTML they supply for their profile, comments, etc., that get persisted on the … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,39],"tags":[120,121,80,123,69,122,124,159],"class_list":["post-761","post","type-post","status-publish","format-standard","hentry","category-web-penetration-testing","category-xss","tag-antisamy","tag-html-parsing","tag-java","tag-javascript","tag-owasp","tag-regex","tag-sanitising","tag-xss"],"_links":{"self":[{"href":"https:\/\/www.floyd.ch\/index.php?rest_route=\/wp\/v2\/posts\/761","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.floyd.ch\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.floyd.ch\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.floyd.ch\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.floyd.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=761"}],"version-history":[{"count":20,"href":"https:\/\/www.floyd.ch\/index.php?rest_route=\/wp\/v2\/posts\/761\/revisions"}],"predecessor-version":[{"id":1362,"href":"https:\/\/www.floyd.ch\/index.php?rest_route=\/wp\/v2\/posts\/761\/revisions\/1362"}],"wp:attachment":[{"href":"https:\/\/www.floyd.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=761"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.floyd.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=761"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.floyd.ch\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=761"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}