File URI & security; was Re (2): File URIs
Scott,
You are have responsibility to users or clients. I am a user
trying to make a simple Web page. We have different views of
"reasonable caution".
From: Scott Ferguson <prettyfly.productions@gmail.com>
Date: Thu, 09 Jun 2011 17:07:44 +1000
> the classic was/is
> a login to Linux based networked web cam that could be bypassed by
> adding an extra slash to the URI
So the fault was in the cam. Not in a file URI.
Conclusion: don't buy hardware which tries to provide something
which should be done by decent software.
> Then there's the buffer overflow URI exploits, and the remote protocol
> handling exploits where the protocol is changed on the published link.
> eg. file substituted with rdp etc.
See following.
> ... work on Windoof only.
Must we talk about that? =8-)
> Easier to copy the files to the root of the webserver
> than take a chance I think? :-)
Then I can change the target of the link from file:///home/peter/Category2.html
to http:///Category2.html or http://localhost/Category2.html .
The path to the file is no longer published. Good.
But a Web server shouldn't be necessary. What about making a link
/Category2.html which points at /home/peter/Category2.html ?
Then the published link file:///Category2.html doesn't reveal the path.
Is a Web server really needed just to get past this pesky security.checkloaduri?
Seems weird!
> The more information about your system available to an attacker - the
> greater the risk an attack will be successful.
Understood.
Any miscreant will know that a *nix system has user directories
in /home. With a quick glance at my network diagram he can deduce
the existence of dalton:/home/peter/. With a glance at one of my
public Web pages he knows that I have a file named Category2.html.
Therefore dalton:/home/peter/Category2.html might exist! But
dalton is firewalled and does not have Web server. The link anchor
[file:///home/peter/Category2.html] in a public page gives little
to the miscreant. Conversely, it allows me to test the page more
quickly.
> Yes. And axes are made for cutting wood.
Iceweasel's security.checkloaduri is analogous to a federal law
banning sale of axes. Of course, one can set up a forge and tools,
make the axe head and install a handle. Thankfully, we don't
have to do that to cut firewood!
> This is an application that runs on Eee PCs without a webserver. It's a
> local app running on Iceweasel with NoScript installed. Never-the-less
> there is the potential for problems from local malware, or when
> connected to a network.
A2 has a Web server and to my knowledge there has never been a
security breach of that system. It might work for you except for
lack of javascript. What about Inferno? Make it as simple as
possible but not simpler.
> Just out of curiosity - is that webserver Apache running the ldap_mod?
The server for http://members.shaw.ca/peasthope/#Links belongs to Shaw.
http://www.shaw.ca/
The W3 validator reports "Server: Apache/2.2.15 (Unix) mod_ldap_userdir/1.1.17".
Click on the icon at the bottom of the page, click on "Verbose output"
and revalidate to see that.
> Did it allow you to serve a file outside of the public_html directory
> without modification?
We're at crossed purposes here. The link is in the page served by Shaw.
I see the link and view the file on dalton using the Iceweasel on dalton.
My network diagram shows. http://carnot.yi.org/NetworkExtant.jpg
BTW, my primary data storage is a CF card used in an ETHNO system.
There has never been a security breach of an ETHNO system. The chance
of injury from a miscreant is smaller than the risk of an earthquake
shaking the computer off the desk and onto me. =8~|
Regards, ... Peter E.
--
Telephone 1 360 450 2132. bcc: peasthope at shaw.ca
Shop pages http://carnot.yi.org/ accessible as long as the old drives survive.
Personal pages http://members.shaw.ca/peasthope/ .
Reply to: