Web Hosting Forums

Page 1 of 2 1 2 LastLast
Results 1 to 15 of 21

This is a discussion on security question in the Hosting Talk & Chit-chat forum
I have a bit of a security concern and am hoping others have thought this through. I'm hoping this isn't as bad as I think ...

  1. #1
    Loyal Client
    Join Date
    Mar 2002
    Posts
    7

    security question

    I have a bit of a security concern and am hoping others have thought this through. I'm hoping this isn't as bad as I think it is.

    First, As far as I can tell from poking around the server, I have to grant read access for "everyone" to the files I want to be available as part of my web page(chmod 704).

    Second, in order to use the mySQL database the account info must be stored in your php(or whatever) scripts to be used in the connect string. Normally this is done my putting all settings for your app in a config file and using an "include" statement. These could be stored a level up from the public_html to protect them from web viewers, but still need to be readable by "everyone" for apache to read them.

    So, anyone who has an account on the server I am on can view my php files(cat /home/mydirectory/www/index.php) with my SQL login information, and from there modify data in the database. Also, I'd bet alot of people use the same password for their databases as they do for their master account login.

    Why do all of our files have us as both owner and group, instead of having a group we could assign read access to to allow apache to read our files without allowing everyone else to? It shouldn't be so hard to set it up so we could do something like "chmod myid:apache *" and "chmod 740 *" to allow apache to read our files without allowing everyone else to.

    With as many customers as Aletia has, I can't be the only person to notice this... so what am I missing? How can I prevent other users from viewing the source of my php files?

  2. #2
    Royal pain in the @$$ timechange's Avatar
    Join Date
    Nov 2001
    Posts
    1,559
    Wrong.

    Put the files that you want to include outside the public folder, for example in:

    /home/username/secretfolder/

    Other users won't be able to tell which folder you put the includes in, because you cannot list the contents of the user's home directory.
    Hot domain auctions on ebay: http://timechange.com/ebay/

  3. #3
    Loyal Client
    Join Date
    Mar 2002
    Posts
    7
    I don't think so.

    The "secret" directory you keep your include file in has to be pointed to in the php file it is included in. So someone can "cat index.php", read the line where you say "include (../secretfolder/config.php)", then know the name of secretfolder to use in their next "cat".

    Your right that you can't read my home directory, but you can read my home directory/public_html, since it has read for everyone, and you can read anything that is "hidden", but set to allow apache to include it.

    Also, since some people write their own stuff, they might want to not give away the php scripts they write.

    I think it's common sense to use the group membership to allow apache to access our files instead of making stuff world readable.

  4. #4
    Royal pain in the @$$ timechange's Avatar
    Join Date
    Nov 2001
    Posts
    1,559
    Which server are you on?
    Hot domain auctions on ebay: http://timechange.com/ebay/

  5. #5
    Loyal Client
    Join Date
    Mar 2002
    Posts
    7
    I'm on hamster.

  6. #6
    Royal pain in the @$$ timechange's Avatar
    Join Date
    Nov 2001
    Posts
    1,559
    I am on a different server and I don't have the same issue.

    I would send support a ticket asking for the /home directory to be chmod 711; this way you would not be able to see a list of users.
    Hot domain auctions on ebay: http://timechange.com/ebay/

  7. #7
    Loyal Client
    Join Date
    Mar 2002
    Posts
    7
    That still doesn't really solve the problem, does it? Hiding the user names only makes the hole slightly harder to exploit, but their are other ways to find out the usernames. Like listing the domain names in /usr/local/apache/domlogs and guessing, for example. Or cat /etc/passwd.

    I will go ahead and forward my original question to support to see what they have to say, and I thank you for your suggestions.

  8. #8
    Loyal Client
    Join Date
    Sep 2002
    Posts
    17
    Yeah, the only thing can really be done is to put "nobody" into a group and let us chgrp our web files to that group. We could then 750 the files and prevent other people from reading them.

    As an aside, PHP would have have to be running in Safe Mode and CGI would either have to be switching to our individual UID's or also be wrapped. Otherwise, it would be pretty trivial to write a web script that accesses other people's files (since it's running under Apache, it runs as "nobody").

  9. #9
    Loyal Client
    Join Date
    Mar 2002
    Posts
    7
    True, but would still be an improvement. So far on the ticket I opened they (Ron) chgrp'd my public_html directory to nobody. But since I'm not allowed to chgrp my files apache still can't open read them when I set them to 704.

  10. #10
    Loyal Client
    Join Date
    Mar 2002
    Posts
    7
    Uh, that was supposed to read "apache still can't read them UNLESS I set them to 704."

  11. #11
    Loyal Client
    Join Date
    Oct 2001
    Posts
    216
    Timechange, what Truk talks about is the same way on every server. It's the default setting of unix/linux servers in general work with permissions and apache.

    And chgrp, also by design, can only be run as root. So we are still vulnerable. That's one of the worst things about having a shared server. I've been thinking of these for a while, and haven't found a good way without forcing Aletia to charge more, because it'd require less users per servers. And I'm not willing to pay 100 a month for my puny page that gets maybe 100 hits a month.

    Truk, I think at this point, the best you can do is to make things obscure as possible. flipdoubt implements something a little more obscure than what you guys have already mentioned, so I'd speak to him(privately) It's still far from secure, but it'll turn away *some* of the lazy "hackers."

  12. #12
    Royal pain in the @$$ timechange's Avatar
    Join Date
    Nov 2001
    Posts
    1,559
    I've no doubt that they will take care of that; I received a response from Ron on this and I know he is very much knowledgable, however their priority at this point is to resolve the other issues that have been flooding the ticketing system so far.

    I can also assure you that the same settings exist in other hosts I used.
    Hot domain auctions on ebay: http://timechange.com/ebay/

  13. #13
    Loyal Client
    Join Date
    Oct 2001
    Posts
    216
    Originally posted by timechange
    I can also assure you that the same settings exist in other hosts I used.
    Yes, the problem exists on most webhosts out there. I'm not picking on Aletia. The problem exists from the way webservers are run and unix permissions are set. From what I see, there's not too much Aletia or other webhosts can do without raising costs.

    I honestly wouldn't expect Ron to be able to fix this, or anybody else.

    It's a difficult problem attributed to having a shared webhost, and each customer has to do their own risk assessment and know what they are getting into.

  14. #14
    Loyal Client
    Join Date
    Jan 2002
    Posts
    636
    Originally posted by cfactor


    Yes, the problem exists on most webhosts out there. I'm not picking on Aletia. The problem exists from the way webservers are run and unix permissions are set. From what I see, there's not too much Aletia or other webhosts can do without raising costs.

    I honestly wouldn't expect Ron to be able to fix this, or anybody else.

    It's a difficult problem attributed to having a shared webhost, and each customer has to do their own risk assessment and know what they are getting into.
    cfactor or anyone

    Would you explain to me like the dummy I am, the way to avoid this with the raised cost to customers... and allowing for fewer users each machine because of it?

  15. #15
    Loyal Client
    Join Date
    Oct 2001
    Posts
    216
    I was thinking of user-mode linux or similar environment where each user gets a full-blown virtual system to themselves. Then their system is isolated from other users. But this does require much more resources. I'd imagine that you can't put more than 30 or so users on each machines this way.

    You can also run a separate copy of apache for each user. But that can be messy.

    I'm sure there are other methods of user isolation.

Page 1 of 2 1 2 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •