On 10/06/11 04:22, peasth...@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. -- 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/4df1c83c.1010...@gmail.com
