xsltforms-support

[Xsltforms-support] Can't put file to current directory

[Chester W. <ch...@de...>]

Hello,

I'm trying to learn xforms and have been going through some of the examples
in the wiki book. The simple submit example at
http://en.wikibooks.org/wiki/XForms/Submit that puts a file to the current
directory does not work on either Firefox or Safari. I'm using the example
verbatim (adding the xsltforms invocation at the top of the file of course)
and I've tried changing the form of the filename, using
action="file:./myData.xml", for example. I've also tried using a
file:///absolute_pathname  and that makes it worse.

This example works fine with the Firefox xforms extension.

I've tried the beta3 release of xsltforms, also beta3RC, and the latest
build, 496.

Here's the debugging output from firefox (the output on Safari is slightly
less informative)

0 -> Dispatching event xforms-submit on <SPAN class="xforms-submission"
id="save"/>
0 -> Dispatching event xforms-submit-serialize on <SPAN
class="xforms-submission" id="save"/>
1 -> Submit put - application/xml - myData.xml - true
0 -> Access to restricted URI denied

( Why would the current directory be restricted???)

I also get a popup (from Firebug perhaps?) that says:

XSLTForms Exception
--------------------------

Error initializing :

([object Object],[object
XMLHttpRequest])@file:///Users/chet/src/xforms/reminv/build/xsltforms.js:2932
([object Object],[object XMLHttpRequest],[object
DOMException])@file:///Users/chet/src/xforms/reminv/build/xsltforms.js:2969
()@file:///Users/chet/src/xforms/reminv/build/xsltforms.js:2916
([object
Event])@file:///Users/chet/src/xforms/reminv/build/xsltforms.js:7407
([object
HTMLSpanElement],"xforms-submit")@file:///Users/chet/src/xforms/reminv/build/xsltforms.js:7305
([object HTMLSpanElement],[object Element],[object
Event])@file:///Users/chet/src/xforms/reminv/build/xsltforms.js:3300
([object HTMLSpanElement],[object Element],[object
Event])@file:///Users/chet/src/xforms/reminv/build/xsltforms.js:3161
([object HTMLSpanElement],[object Element],[object
Event])@file:///Users/chet/src/xforms/reminv/build/xsltforms.js:3146
(-2)@file:///Users/chet/src/xforms/reminv/build/xsltforms.js:1319


TypeError

req.getAllResponseHeaders() is null

Thanks for your help...

Chester Wood

Re: [Xsltforms-support] Can't put file to current directory

[COUTHURES A. <ala...@ag...>]

Chester,
> I'm trying to learn xforms and have been going through some of the 
> examples in the wiki book. The simple submit example at
> http://en.wikibooks.org/wiki/XForms/Submit that puts a file to the 
> current directory does not work on either Firefox or Safari. I'm using 
> the example verbatim (adding the xsltforms invocation at the top of 
> the file of course) and I've tried changing the form of the filename, 
> using action="file:./myData.xml", for example. I've also tried using a 
> file:///absolute_pathname  and that makes it worse.
Please try with just "file://". For security reasons, XSLTForms will 
always prompt the user for the folder and name of the file.

Thanks!

-Alain

Re: [Xsltforms-support] Can't put file to current directory

[Chester W. <ch...@de...>]

Thanks for the tip. That works, sort of. But it is very clumsy. Is there
anything that can be done to ease the security?

In this case, there is not really any security issue at all. I'm loading my
xforms page using a file: URL from a local directory, and using src to pull
in instance data from a file in the same directory. My xforms will modify
the data and when I click Submit, I want to write the modified data out to
the same file. Very simple. The user should not have the opportunity to
write it to some other file, as this could create a lot of confusion.

thanks,

chester

On Thu, Mar 31, 2011 at 2:30 AM, COUTHURES Alain <
ala...@ag...> wrote:

> Chester,
>
>  I'm trying to learn xforms and have been going through some of the
>> examples in the wiki book. The simple submit example at
>> http://en.wikibooks.org/wiki/XForms/Submit that puts a file to the
>> current directory does not work on either Firefox or Safari. I'm using the
>> example verbatim (adding the xsltforms invocation at the top of the file of
>> course) and I've tried changing the form of the filename, using
>> action="file:./myData.xml", for example. I've also tried using a
>> file:///absolute_pathname  and that makes it worse.
>>
> Please try with just "file://". For security reasons, XSLTForms will always
> prompt the user for the folder and name of the file.
>
> Thanks!
>
> -Alain
>
>

Re: [Xsltforms-support] Can't put file to current directory

[COUTHURES A. <ala...@ag...>]

Chester,
> Thanks for the tip. That works, sort of. But it is very clumsy. Is 
> there anything that can be done to ease the security?
I think that it is important to let know that a file is about to be 
read/written in a folder and that it is still possible to abort this.

I don't want to include in XSLTForms an applet that would permit anyone 
to crash a system.
>
> In this case, there is not really any security issue at all. I'm 
> loading my xforms page using a file: URL from a local directory, and 
> using src to pull in instance data from a file in the same directory. 
> My xforms will modify the data and when I click Submit, I want to 
> write the modified data out to the same file. Very simple. The user 
> should not have the opportunity to write it to some other file, as 
> this could create a lot of confusion.
The default behavior is to propose the last file name which was used. 
You want to change this with your own file name, is it right?

It is already possible to enter a full name such as 
"file://test/myfile.xml" but I don't think it's a recommended notation. 
This full name will be used to initialize the file dialog box.

If so, you could also need to get the chosen fullname from the latest 
file dialog box. This is not specified in the XForms Recommendation but 
surely the event() function could be used for that. Would you like me to 
ask the W3C Forms Work Group about that?

Thanks!

-Alain

Re: [Xsltforms-support] Can't put file to current directory

[Chester W. <ch...@de...>]

Alain,

Thanks very much for the reply.

On Thu, Mar 31, 2011 at 1:19 PM, COUTHURES Alain <
ala...@ag...> wrote:

>
>> I don't want to include in XSLTForms an applet that would permit anyone to
> crash a system.


Sorry, I'm no security expert, but I don't get how anyone could crash the
system. When running the browser as an ordinary user, all processes inherit
my privileges, so if my xforms script tries to write somewhere dangerous,
the OS will prevent this. When I run the example program under the Firefox
xforms extension, it creates the file with me as the owner. I would not be
able to overwrite any file that I don't have OS permissions to write to.
In order to be able to do this, xlstforms would have to be running setuid,
and I'm quite sure that it's not.

>
>
>> The default behavior is to propose the last file name which was used. You
>> want to change this with your own file name, is it right?
>
>
> It is already possible to enter a full name such as
> "file://test/myfile.xml" but I don't think it's a recommended notation. This
> full name will be used to initialize the file dialog box.
>
> If so, you could also need to get the chosen fullname from the latest file
> dialog box. This is not specified in the XForms Recommendation but surely
> the event() function could be used for that. Would you like me to ask the
> W3C Forms Work Group about that?
>
>
No, I'm not sure what you're suggesting, but I don't want a file dialog box
at all. The dialog is appropriate for the <upload/> control, but not the
<submission/> element. There the file name is hard-coded (or calculated).
Many examples of this exist in sample code in xforms tutorials. Here's a
simple example from Steven Pemberton's
tutorial<http://www.w3.org/MarkUp/Forms/2010/xforms11-for-html-authors/part2.html#Repeat>
:

<model>
   <instance src="todo-list.xml"/>
   <submission method="put" action="todo-list.xml" replace="none"/>
   <bind nodeset="todo/date" type="xsd:date"/>
</model>

In this example a do list is read from a file and written back. The OS will
not allow the file write unless the user running the browser has privileges
to do the write.

Now what if a malicious (or ignorant) xforms designer sent me an xform that
tried to write to someplace bad? First, I would have to install the host
document somewhere (we're only talking about host documents that are opened
with "file://" URL's; if the document were opened with "http://", then the
browser would prohibit local writes as a cross-domain issue).

Then, after saving the host document as a file, I would have to  log in as
root to run the browser or somehow allow the privileges to be escalated by
typing in a password. If I were stupid enough to do that (and sure, it is
possible!), one thing that would mitigate the damage here would be if
xlstforms were to only allow writes to the current directory or its
subdirectories, i.e., prohibit access to any path with ".." in it. I noticed
that the Firefox browser enforces that, in fact it will not follow such a
path for read references either.

So that is the only security enforcement that xlstforms needs to do IMHO.

Thanks for listening

Chester Wood


Thanks!
>
> -Alain
>
>

Re: [Xsltforms-support] Can't put file to current directory

[COUTHURES A. <ala...@fr...>]

Chester,
>
> Sorry, I'm no security expert, but I don't get how anyone could crash 
> the system. When running the browser as an ordinary user, all 
> processes inherit my privileges, so if my xforms script tries to write 
> somewhere dangerous, the OS will prevent this. When I run the example 
> program under the Firefox xforms extension, it creates the file with 
> me as the owner. I would not be able to overwrite any file that I 
> don't have OS permissions to write to.
> In order to be able to do this, xlstforms would have to be running 
> setuid, and I'm quite sure that it's not.
Unfortunately, when creating Windows, Microsoft didn't want to declare a 
default ordinary user but an administrator and, today, a huge portion of 
browsers are running with maximal permissions. That's why Javascript is 
strongly restricted. I didn't test it myself but I think that using a 
Java applet allows anything so the worst too!
>
> No, I'm not sure what you're suggesting, but I don't want a file 
> dialog box at all. The dialog is appropriate for the <upload/> 
> control, but not the <submission/> element. There the file name is 
> hard-coded (or calculated).
The only secure possibility for me is to allow to inhibit the file 
dialog just when the domain is localhost or when the page is in fact 
itself loaded directly from the local disk. Would it be OK for you?
> Many examples of this exist in sample code in xforms tutorials. Here's 
> a simple example from Steven Pemberton's tutorial 
> <http://www.w3.org/MarkUp/Forms/2010/xforms11-for-html-authors/part2.html#Repeat>:
>
> <model>
> <instance src="todo-list.xml"/>
> <submission method="put" action="todo-list.xml" replace="none"/>
> <bind nodeset="todo/date" type="xsd:date"/>
> </model>
>
> In this example a do list is read from a file and written back. The OS 
> will not allow the file write unless the user running the browser has 
> privileges to do the write.
This is not a file:// example but an XRX example: the submission is sent 
to the server not to the local disk.
>
> Now what if a malicious (or ignorant) xforms designer sent me an xform 
> that tried to write to someplace bad? First, I would have to install 
> the host document somewhere (we're only talking about host documents 
> that are opened with "file://" URL's; if the document were opened with 
> "http://", then the browser would prohibit local writes as a 
> cross-domain issue).
The applet allows to save locally even if the document is opened with 
"http://" !
>
> Then, after saving the host document as a file, I would have to  log 
> in as root to run the browser or somehow allow the privileges to be 
> escalated by typing in a password. If I were stupid enough to do that 
> (and sure, it is possible!), one thing that would mitigate the damage 
> here would be if xlstforms were to only allow writes to the current 
> directory or its subdirectories, i.e., prohibit access to any path 
> with ".." in it. I noticed that the Firefox browser enforces that, in 
> fact it will not follow such a path for read references either.
Linux is surely much protective that Windows ;-)

Thanks!

-Alain