On Wed, March 21, 2007 4:36 am, Manuel Vacelet wrote: > My main question is "What happens if there is bug in my application, > if someone exploit a vulnerability of php or apache?". You will never ever have 100% guarantee that it's safe. Anybody who tells you that you do is lying. Or very stupid. Or quite possibly both. :-) So the answer to this one will always be "There *might* be some way this can be cracked" Your job is to reduce risk, not eliminate it completely. If your boss or client is telling you differently, you might as well quit right now, because they don't understand your job, and you are taking all the risks, not they, and that's just plain wrong. > First threat: > Due to the usage of PHP as an apache module, a vulnerability in one of > these 3 elements can let cracker by pass the application security > model (by pass the group access rights) because I cannot have > protection at the OS level (because to be able to server the file for > all groups my application must be able to read all the data whatever > the protection is). You could consider reducing this risk by having a separate pool of Apache servers for each group, with their own user running Apache, so that they do not have read access to the other groups' files. Performance may suck, particularly for a large number of groups, and this will not "scale" well. Another option, as I understand it, is to run one Apache, but a different FastCGI per vhost, with different user and files owned by that user. (I'm less certain that this is possible...) FCGI performance rivals Module, and also scales well, as I understand it. > Second threat: > As I already explained, a cracker could upload with standards > procedure a dangerous executable and with some vulnerabilities makes > it executable and runs it. To reduce this risk, you could attempt to closely monitor users, and limit access to the box as much as possible. A cron job to do ps auxwwww and then grep out the jobs you EXPECT to see, and raise an alarm for anything "unusual" might be do-able. This is a "blacklist" approach, so not perfect, but worth trying, considering the effort it would take (minimal, really) Store the executables on a DIFFERENT box, with, perhaps, only root and nobody user. Kinda hard for 'nobody' to get access. And if they get 'root', well, it's game over for that box anyway. You could even consider applying a "secret" reversible function (such as 2-way encryption) that would make the file saved on disk non-operable as an executable file. I.e., your potential cracker has to gain access to the box, get the file to be 'executable', *AND* guess which algorithm you did to the file and undo that into another file, and then execute the un-scrambled file. It is somewhat of "security through obscurity" but as another hurdle in a line of defence, is worth at least considering. > I hope this clarify my needs, You may want to try to get in touch with OpenSource people who host binary files in large numbers, such as SourceForge, and ask what they do. It's not really PHP-specific, at the level that you are worrying about. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
