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

RE: XForms - Secure or Insecure?

From: Klotz, Leigh <Leigh.Klotz@pahv.xerox.com>
Date: Thu, 2 Sep 2004 12:05:03 -0700
Message-ID: <0ED0D6D8F7234E44B40AF1110A966BC480B95C@mercury.ADOC.xerox.com>
To: "'Aaron Reed'" <mozillaxforms@yahoo.com>, "'www-forms@w3.org'" <www-forms@w3.org>


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.


  <form name="foo" method="post"
  <input name="a" type="hidden" value="">
  <input name="b" type="hidden" value="">
  <!-- <input type="submit"> -->

  <form name="bar" method="get" action=""
  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">

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.


-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
Of Aaron Reed
Sent: Thursday, August 26, 2004 8:11 AM
To: www-forms@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
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
has done.  It is pretty

I'm just saying that there could be issues if a XForms processor doesn't
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
could farm information from web services internal to my company and ship it
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
a processor should handle it.

Received on Thursday, 2 September 2004 19:06:05 UTC

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