W3C home > Mailing lists > Public > www-forms@w3.org > November 2004

Re: XForms - Secure or Insecure?

From: Darin Fisher <darin@meer.net>
Date: Tue, 23 Nov 2004 03:50:24 +0000 (UTC)
To: www-forms@w3.org
Message-ID: <loom.20041123T041411-128@post.gmane.org>

Klotz, Leigh <Leigh.Klotz <at> pahv.xerox.com> writes:

> Aaron,
> Are you saying that today's HTML 4 browsers prohibit JavaScript (in a body
> onload or form onsubmit or href="javascript:" or event) from accessing the
> DOM object for two different forms and copying data from one to another
> based on the URI of the form action attribute?  While that is true for Java,
> it is not true for today's browsers with HTML and JavaScript.  A quick
> experiment proves it.
> The following HTML 4 form will take data from one form and copy it to
> another (invisible) form on destined for another host, within the same page
> and then submit it to that second place, unrelated to either the first form
> or the source of the original web page.
>   <html>
>   <head>
>   <title>forms</title>
>   </head>
>   <body>
>   <h1>forms</h1>
>   <form name="foo" method="post"
> action="http://xformstest.org/cgi-bin/echo.sh">
>   <input name="a" type="hidden" value="">
>   <input name="b" type="hidden" value="">
>   <!-- <input type="submit"> -->
>   </form>
>   <form name="bar" method="get" action=""
> action="http://graflex.org/klotz/forms.html">
>   a: <input type="text" name="a" value="data from second form a">
>   b: <input type="text" name="b" value="data from second form b">
>   <input type="button" onclick="document.foo.a.value=document.bar.a.value;
> document.foo.b.value=document.bar.b.value; document.foo.submit()"
> value="Submit Query">
>   </form>
>   </body>
> In XForms, data can come from multiple sources and go to multiple sources.
> Data can't be shared between different XForms models in the same page,
> except by a UI operation copying the data (select or select1) or by
> something external, such as JavaScript.  I believe that XForms is actually
> easier to validate than Java bytecodes, because (absent extension functions
> implemented by a browser) the only operations that XForms provides are
> operations on the instance data and on the user interface.
> Leigh.
> -----Original Message-----
> From: www-forms-request <at> w3.org [mailto:www-forms-request <at> w3.org] On
> Of Aaron Reed
> Sent: Thursday, August 26, 2004 8:11 AM
> To: www-forms <at> w3.org
> Subject: Re: XForms - Secure or Insecure?
> T. V. Raman <tvraman <at> us.ibm.com> writes:
> > 
> > I think Aaron might be confusing cross-site scripting attacks
> > with cross-site Web Service invocations.
> > 
> > The former --- as evinced by all of today's heavily scripted Web
> > is a dangerous hole, and one should certainly not allow for code
> > that comes from one site to execute within another --- leave
> > alone code across sites executing in the same page.
> > 
> > The world of Web Services is *different* from cross-site
> > scripting; The whole  point is that a Web Service allows a
> > provider to expose a  specific piece of information in a form
> > that is independent of browser-specific HTML; no presentation, no
> > scripts please--
> > and the "last mile of web services" -- which is what ForsPlayer
> > with Web Services demonstrates today --- i.e. integrating data
> > from different Web Services into a consistent whole---
> > is still achieved with no cross-site scripting.
> > 
> > So let's keep our threads untangled:
> > 
> > Cross-site scripting: BAD
> > Cross-Site Web Services Integration: GOOD
> > 
> > 
> > 
> I don't want to make a big deal out of this, since I obviously don't see
> this
> in the same light than many others do.  I can foresee the very fine and
> practical uses of SOAP  combined with XForms.  I love the work that
> formsPlayer
> has done.  It is pretty
> cool.  
> I'm just saying that there could be issues if a XForms processor doesn't
> take
> security into consideration.  For example, I am a user sitting at my desk at
> work.  I accidently click on a piece of spam.  It is xforms, so my xforms
> processor kicks in.  Completely under the covers, unbeknownst to me, this
> XForm
> could farm information from web services internal to my company and ship it
> out
> to another web service.  Currently, web browsers prevent this kind of cross
> domain capability.  We are just hoping that 1.1 covers this possibility and
> how
> a processor should handle it.
> --Aaron


The concern is not at all about sharing data between two HTML forms in the
document.  The concern is with XML submission over HTTP to _any_ server.
There are two issues:

(1) XML submission means that an evil web site may send, for example, SOAP
requests to any Web Service.

(2) XML submission replace="instance" means that an evil web site may
additionally read the response from any Web Service.

So, lack of same-origin restriction for XML submission by a web browser is
very dangerous.  Indeed, it is especially dangerous when that web browser
is used to browse content or interact with Web Services that live behind a
corporate firewall.  An evil website with knowledge of internal Web
Services could easily exploit a user of a browser, with access to those
internal Web Services, to gain access to private data or cause undesired
transactions to occur.

I provided a more detailed example in my previous post.  Please re-consider
the security implications of not restricting XForms XML submission to same
origin.  For Mozilla, we plan to restrict XForms XML submission to same
origin by default because that is consistent with our policy for other means
of XML I/O over HTTP.

Darin Fisher
Received on Tuesday, 23 November 2004 05:28:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:14 UTC