Lists Home |
Date Index |
1. That a malicious XForms-containing document can upload files from a
user's computer without their knowledge
(thinking outside the box here)
It seems to me that this *could* involve digital rights - that is, the
issue can be approached from the file perspective rather than the XForms
perspective. Initiatives such as the OASIS Rights Language TC  and
the W3C Open Digital Rights Language (ODRL) come to mind. However,
this would require access control policies for the XForms-containing
document (thinking of it almost as a "user") - which may be out of scope
of the issue.
Booz | Allen | Hamilton
> [I posted this primarily to XForms lists but if anyone among those on XML-Dev
> who is interested in XForms has thought about this issue, any informed
> feedback would be welcome. Thanks. ]
> I thought it would be useful ... hopefully in the sense of eliciting
> well-founded reassurance .. to raise a couple of security questions that I
> have regarding XForms.
> There are two potential sources of security concern:
> 1. That a malicious XForms-containing document can upload files from a user's
> computer without their knowledge
> 2. A malicious XForms-containing document could download a virus or other
> nasty to the user's computer.
> Let me explain how these undesirable situations might potentially arise.
> The general background is that an XForms-containing document may have more
> than one XForms model. The security concerns that I am raising could be
> hidden in one XForms model while another XForms model produces the
> functionality that the user wants or needs.
> 1. File Upload - In principle it seems possible as the Candidate
> Recommendation is drafted that a file could be uploaded from the user's
> computer in response to any arbitrary event. For example the file could be
> uploaded as soon as the XForms completes initialization. One scenario is that
> the content of the file in question is loaded into an <xforms:instance> and
> is later "submitted" to an arbitrary URL chosen by the author of the
> malicious code. If the XForms author sets the replace attributes on <
> xforms:submission> to a value of "none", the user may have no knowledge that
> the file has been "stolen" from their computer.
> 2. Virus Implantation - In principle a hidden XForms model could obtain its
> instance data from an arbitrary URL, with no indication that malicious code
> has been downloaded into the instance data, using the src attribute on <
> xforms:instance>. As with scenario 1, an arbitrary event could be used to
> "submit" i.e. save the malicious code to the user's computer using a file
> Given that an XForms-containing document could contain more than two XForms
> models, then a combined upload/virus implantation attack would be
> theoretically possible.
> I assume that the intent of the WG is that XForms implementers provide some
> form (pun intended) of sandbox to prevent such malicious practices. However,
> the current CR seems to rely largely on implementers' common sense ... a
> dangerous commodity where security is concerned ... rather than provide a
> detailed consideration of the risks (perhaps only simply to dismiss them?)
> and solution for these potential security concerns.
> I would welcome comments on whether the scenarios which I describe are
> realistic and, assuming that, on what the most appropriate way(s) forward are
> to ensure that XForms-containing documents cannot be used for malicious
> If XForms is to be accepted as an appropriate vehicle for handling valuable
> and sensitive business data, it is critical that there is well-founded
> confidence in the security provided by XForms implementations.
> Andrew Watt
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
fn:Joseph M. Chiusano