Re: File URI & security; was Re (2): File URIs
On 10/06/11 04:22, peasthope@shaw.ca wrote:
> 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".
Yes. I am not reasonable. The severity of a scenario rates higher than
the likelihood. An intruder or malware gaining control/access is just as
worrying as a page not loading properly or a dead-link - clients
overlook uptime when there's any downtime.
I've also learnt that a secure architecture is only secure as long as
the applications that use it don't change - which is a rarity. HTML5,
cloud apps, ,IE9, CSS2, are all coming changes with unknown risks.
>> 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.
It was software. An unpatched Apache vulnerability (from memory).
Nothing to do with hardware.
>
>> 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.
The rdp:// exploits were platform agnostic.
>
> Must we talk about that? =8-)
My intention was only to demonstrate that it's impossible to quantify
unknown risks...
>
>> 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.
And you can then use .htaccess files to add additional control/security,
and to change that (apparent) path.
>
> 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.
Soft links'll work fine.
>
> Is a Web server really needed just to get past this pesky security.checkloaduri?
No. That's a different subject.
> Seems weird!
Don't it?
Now if you can link to the root of the web server that'll do the trick.
>
>> 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.
Agreed.
>
>> 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!
:-)
I meant web servers *are* for publishing html. Sometimes they are used
for purposes other than what (the owner/manager) intended. Ask Lizzie
Borden.
>
>> 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.
The webpages only need to be accessed locally, the netbooks lack grunt
already, the support fees are very low - and I wont' be asked to do
support until they're completely broken (by which time Wheezy will be
stable), and I can run the application under a separate user account.
These are Eee 380Ds with 512MB of RAM running Squeeze Trinity - not a
lot of grunt available anyway. Tight margins all-round.
<snipped>
>
> 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~|
No argument there.
Just suggesting you keep everything that is served by the webserver in
the one place. If not for security then for simplicity.
There are tens of thousands of insecure sites. I think you'll avoid
becoming a FakeMalware vendor - especially as you lack sql injection
vulnerabilities!
Cheers
--
Tuttle? His name's Buttle.
There must be some mistake.
Mistake? [Chuckles]
We don't make mistakes.
Reply to: