[Owasp-antisamy] New attack technique affects antisamy

Arshan Dabirsiaghi arshan.dabirsiaghi at aspectsecurity.com
Fri Mar 13 11:34:52 EDT 2009

This same kind of XHTML-in-HTML hilarity was reported in issue #36 "Non empty elements are converted to a minimized form in xhtml":
http://code.google.com/p/owaspantisamy/issues/detail?id=36&can=1 <http://code.google.com/p/owaspantisamy/issues/detail?id=36&can=1> 


From: owasp-antisamy-bounces at lists.owasp.org on behalf of Jason Li
Sent: Fri 3/13/2009 11:29 AM
To: Jerry Hoff
Cc: owasp-antisamy at lists.owasp.org
Subject: Re: [Owasp-antisamy] New attack technique affects antisamy

I bet it's actually a case of the browser trying to apply HTML 4.0 to an XHTML thing.

Someone can correct me if I'm wrong, but I believe the notion of an empty tag (<tag/>) is XML specific and only works in XHTML. I wouldn't be surprised if in HTML, browser ignored the / --- I think I've encountered problems with this before in terms of development with image tags.

Let's continue researching, but I bet if we stick a XHTML header at the top, it won't work.

-Jason Li-
-jason.li <http://jason.li/> @owasp.org-

On Fri, Mar 13, 2009 at 11:27 AM, Jerry Hoff <jerry.hoff at aspectsecurity.com> wrote:

	While testing antisamy.net <http://antisamy.net/>  last night, I noticed some very strange behavior concerning the form tag. Formjacking anyone?  Here is the ensuing conversation.
	-----Original Message-----
	From: Jerry Hoff
	Sent: Fri 3/13/2009 10:21 AM
	To: Arshan Dabirsiaghi
	Cc: Jason Li
	Subject: poor man's unchecked redirect
	Hey guys,
	Last night i noticed some of the style sheets allow the form element.  We should probably remove that.
	attack string:
	Now, when the user hits the "update profile" button, the user will be redirected to google.com <http://google.com/>  and google steals the form data.
	From: Jason Li
	Sent: Fri 3/13/2009 10:40 AM
	To: Jerry Hoff; Arshan Dabirsiaghi
	Subject: RE: poor man's unchecked redirect
	This isn't a stylesheet problem - it's a problem in the form tag.
	It's actually interesting behavior... I wouldn't have expected the form action to fire since the Update Profile button is part of a different form.
	I haven't tried this in IE, but I'm thinking Firefox doesn't correctly interpret the <form ... /> as one, empty element (i.e. it doesn't recognize the implicit </form> in that tag). As a result it swallows our form due to some browser quirk.
	Incidentally, these are good conversations - but I think we should be having them on the mailing list in the future for archival purposes.
	-----Original Message-----
	From: Arshan Dabirsiaghi
	Sent: Fri 3/13/2009 10:58 AM
	To: Jason Li; Jerry Hoff
	Subject: RE: poor man's unchecked redirect
	I immediately Googled with Jerry on this. It works in IE too. Definitely a cross-browser "bug" even though it smacks of intended behavior. The same behavior works with empty i, b and u tags. Self-contained tags == affect the rest of the page for some reason.
	Jerry, why don't you fwd this to the AntiSamy list? It's a new, useful attack technique and I think we'll have to whitelist the form actions to only point to good.com <http://good.com/>  to prevent this type of attack.
	Immediately what I can see an attacker doing is:
	    * use it to steal data (what if that form was a login form rather than a profile update?)
	    * as Jerry points out, unchecked redirect to a phishing page

	Owasp-antisamy mailing list
	Owasp-antisamy at lists.owasp.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-antisamy/attachments/20090313/b573ab9f/attachment-0001.html 

More information about the Owasp-antisamy mailing list