But the fault here isn't with PHP. Ethan couldn't do what he wants, the way he seemingly has things set up, with any programming language.
Compiled code might let him obscure things a little, and also potentially help hide the credentials used to access the db, but it would still be a totally insecure environment. In a *nix environment (note -- I don't think it's clear what OS he is using) you might be able to chroot the "user". This would mitigate things some, but there are still many holes. He could set up VMs on his single physical box and get client/server separation that way. That would improve things markedly. In the end, however, the "user" has direct control of the physical box which leaves a range of options for access to the [user] data (which is more important to protect than any code) that should cause this setup to fail even fairly basic security audits. There are ways to approach this, but it seems to need rather serious re-engineering -- with data privacy and security as the key element. - Richard ------------ Original Message ------------ > Date: Wednesday, February 18, 2015 10:14:43 -0500 > From: Mark Murphy <jmarkmur...@gmail.com> > To: Taco Mathijs Hillenaar-Meerveld <tm.hillen...@gmail.com> > Cc: php-db@lists.php.net, Guru <nagendra802...@gmail.com>, Karl DeSaulniers <k...@designdrumm.com> > Subject: Re: [PHP-DB] Re: Code Security > > @Taco, Read back through the whole thread and you will understand. > Ethan just can't do what he wants to with PHP. > On Feb 18, 2015 9:59 AM, "Taco Mathijs Hillenaar-Meerveld" < > tm.hillen...@gmail.com> wrote: > >> Sorry if i misread and put my reply in a wrong context. >> but from how i read this question it is all about preventing a >> user to open a terminal window. >> >> if Mr. Nice is logged in then i assume he has all rights as the >> topic starter is afraid Mr. ugly can look at his code. >> >> as far as i know it is not common practice to work direct on a >> server and have all rights and allow other people using that >> computer when connected to the specific server. >> Ethan also pointed out that he made a POS (Point of Sale) program >> to work in that store. there are 2 account types: 1>admin >> 2>worker. >> >> the worker should not have any rights and the admin account >> should only be able to change/edit things within that program. >> -------- >> >> i don't see why anyone (the admin included) would need to have >> access on the stand alone server apart for maintainance duties to >> keep it all up and running. >> the server needs to be locked in a server room or another place >> that will fit. but definately locked. >> >> if someone can get on that server through a terminal it will mean >> something has gone horrible wrong. >> >> i am not sure if Ethan is trolling though. but if i understand >> his question right and it's a honest question, it sounds kind of >> weird to me. >> >> when i get an order to install a server, my first question would >> be like: - who is going to use it? >> - who has access to it? >> - who need to have access to it? >> - where will this server be placed? (server room, datacenter, >> store). >> >> once the server is installed i have a root account, an admin >> account with certain rights and i have made a couple of >> 'administrator groups' . the programs like apache are in this >> group aswell. but this has nothing to do with the administrator >> account from the POS. >> >> so are we here talking about securing the code of the POS and its >> content or are we talking about the basics of securing a Linux >> server? if it is the latter, the Topic starter better read about >> how to secure his server. btw, i'm wondering what his question >> has got to do with PHP and databases :-/ >> >> in addition: >> >> *as soon we talk about 'looking at code' and 'user is logged in >> as an administrator with all rights to delete content' you will >> make ANY administrator* >> *nervous :) i know a couple of admins, trust me, they are >> paranoid and won't trust anyone near their machines. not to speak >> about getting access to a server!* >> >> >> On Fri, Feb 13, 2015 at 6:28 PM, Guru <nagendra802...@gmail.com> >> wrote: >> >> > Put a redirect code in www folder to your index page. >> > On Feb 13, 2015 10:55 PM, "Karl DeSaulniers" >> > <k...@designdrumm.com> >> wrote: >> > >> > > Set up a password or a salt that Mr. Nice has to call you to >> > > get and expires on logout. >> > > >> > > Lol >> > > >> > > Best, >> > > Karl >> > > >> > > >> > > Sent from losPhone >> > > >> > > > On Feb 13, 2015, at 8:47 AM, >> > > > erosenb...@hygeiabiomedical.com wrote: >> > > > >> > > > >> > > > Ethan, >> > > > It seems like you're looking for a programmatic solution to >> > > > a >> physical >> > > > security problem. In the end, your most viable solution >> > > > will likely be to train Mr. Goodguy to remove the key the >> > > > same way he needs to remember his ATM card after a >> > > > withdrawal. I've seen programmatic work-arounds to solve >> > > > similar issues, but they have always ended up being >> > > > significantly arduous for the end users... >> > > > Respectfully, >> > > > Joshua D. Arneson >> > > > -----Original Message-----From: Ethan Rosenberg >> > > > [mailto:erosenb...@hygeiabiomedical.com] Sent: Friday, >> > > > February 13, 2015 9:12 AMTo: php...@lists.php.netSubject: >> > > > Re: [PHP-DB] Code Security >> > > > On 02/13/2015 02:58 AM, Karl DeSaulniers wrote:> Prevent >> > > > THIS from ever happening.>> On Feb 12, 2015, at 11:03 PM, >> > > > Ethan Rosenberg wrote:>>> He asks Mr.[naive]Nice if he >> > > > could look at the computer while it is logged in.>>> >> > > > Otherwise, I would say an external key that has a salt >> > > > stored on it that the user has to insert in the computer >> > > > before the system can be accessed.> Like an access key card. >> Immediate >> > > > shut down when tampered and/or removed.>> Just a stab in >> > > > the dark though.>> Best,>> Karl DeSaulniers> Design Drumm >> > > > Karl - >> > > > Thanks. >> > > > The key is already plugged in. Mr [Naive] Nice is using the >> > > > computer, and is logged in. Mr. Ugly just want to "look at" >> > > > the computer. Ethan-- >> > > > Joshua - >> > > > My apologies for an HTML message. That is all I have at >> > > > work. >> > > > >> > > > How about this - >> > > > Block access to Ctrl-Alt-Del for Mr. Nice. >> > > > TIA >> > > > Ethan >> > > > >> > > > >> > > >> > > -- >> > > PHP Database Mailing List (http://www.php.net/) >> > > To unsubscribe, visit: http://www.php.net/unsub.php >> > > >> > > >> > >> ------------ End Original Message ------------ -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
