[Owasp-antisamy] New attack technique affects antisamy

Jim Manico jim at manico.net
Fri Mar 13 16:41:38 EDT 2009


You are right on. Empty tags were first introduced in XHTML 1.0 transitional.

"XHTML, however, also introduces a new shortcut: an XHTML tag may be opened and closed within the same tag, by including a slash before the end of the tag like this: <br/>. The introduction of this shorthand, which is not used in the SGML declaration for HTML 4.01, may confuse earlier software unfamiliar with this new convention."

- http://en.wikipedia.org/wiki/HTML
  ----- Original Message ----- 
  From: Jason Li 
  To: Jerry Hoff 
  Cc: owasp-antisamy at lists.owasp.org 
  Sent: Friday, March 13, 2009 5:29 AM
  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 at owasp.org-

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

    While testing 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 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 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


  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/5ec68bca/attachment.html 

More information about the Owasp-antisamy mailing list