- From: Aaron Reed <mozillaxforms@yahoo.com>
- Date: Wed, 25 Aug 2004 20:04:28 +0000 (UTC)
- To: www-forms@w3.org
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
Received on Thursday, 26 August 2004 15:10:36 UTC