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.producti...@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/ . -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/171057033.42402.29997@cantor.invalid
