SitePoint Sponsor

User Tag List

Results 1 to 9 of 9
  1. #1
    SitePoint Member
    Join Date
    Dec 2003
    Location
    Palmdale, CA USA
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    How to secure databse passwords in veiwable source?

    Hello all,

    I am engaged in "enhancing web site security" for a small business client, who insists on providing ftp access to many vendors who create pages and load them on the company's server. My current focus is on securing the MySQL user and password information that is presently contained in numerous (74) Php and Perl files. Since the database has been accessed and altered by unauthorized persons in the past, the need for enhanced security has already been demonstrated.

    I am moving the MySQL credentials out of the source, into a directory which is not accessible to ftp, but this still would not prevent an attacker from viewing the Php or Perl source and creating a tiny program to read all the passwords anyway. So this approach seems very limited from a security perspective. Even if I encrypt the actual password data files, the Php and Perl programs must be able to retrieve the MySQL passwords, and so could anyone who is able to view the Php and Perl source ...

    So the problem really stems from the ad hoc nature of past development (over 1300 files with directory names hard coded) and the client's insistence on allowing vendors to have ftp access to the server, where they can freely view Php and Perl source code.

    I suppose that what is really needed to make the passwords and thus the MySQL database secure, is a complete re-write where security is designed in from the ground up. But that is presently not in the budget.

    How do you secure database user and password info that must be available to Php or Perl programs? I would be really grateful for any bright ideas.

    Regards,

    -Glen

  2. #2
    SitePoint Wizard HarryR's Avatar
    Join Date
    Dec 2004
    Location
    London, UK
    Posts
    1,376
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,
    My first thoughts are: ARGGG!

    Unless you are willing to do a little bit of re-organizing and re-configuring there isn't much that I could suggest. The first thing you need to do is completely separate the user uploaded code from the legacy code.

    Ideally I'd have them running as two seperate users and using cgiwrap (or something similar) to ensure that neither user can access the others files, or only allow access to specific files. By keeping the existing data in it's place, and moving the newly uploaded files somewhere else you can keep the hardcoded paths.

    Secondly I presume that the clients need write access to the database (otherwise you could just provide them with a seperate read-only MYSQL user). One way to get around this is to give them the read-only account, and create a seperate database which that user has write access to. Then create duplicate copies of the tables (without data) and create a script (run via a crob-job) which inserts everything into the live database. (Please note, this is a horrible hack and can lead to consistancy issues, not to mention that anybody a year down the line working on the project will probably crucify you for this).

    To be honest this sounds like a rather nasty situation that requires a fair amount of work to sort out, I'm sorry that I couldn't have suggested something better, but I'll see if anything else comes to mind later.

    Regards,
    Harry

  3. #3
    SitePoint Member
    Join Date
    Dec 2003
    Location
    Palmdale, CA USA
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the reply Harry,

    At the vary least it's helpful (maybe just comforting) to have some agreement on what a horrible mess this is. cgiwrap is probably a good idea, one more level of complexity, but given the situation it would provide better control over who could do what.

    I am not inclined to go the db-swapping route. I hope to make the current work a short term solution (optimistic, yes), that just might be completely redone at a later date after the client's current issues have settled down somewhat. I hope to avoid the large amount of development effort this would require.

    I have also looked into code obfucators for php http://pobs.mywalhalla.net/ and Perl http://liraz.org/obfus.html, to protect the embedded MySQL passwords but honestly, these things, just make the problem more complex in my mind. I guess 'security by obscurity' may be a weak security measure, but taken to a sufficient degree, perhaps it's good enough, but it sure is an UGLY solution. One that as you suggest, would be likely to get me crucified somewhere down the road not to mention that it makes server side debugging and password updates just about impossible.

    Anyway, thanks for your input.

    Regards,

    -Glen

  4. #4
    Non-Member Icheb's Avatar
    Join Date
    Mar 2003
    Location
    Germany
    Posts
    1,474
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Code obfuscators do _no_ good at _all_. You need encoders like Zend Encoder etc. if you want no one to be able to read your code.

  5. #5
    SitePoint Evangelist ldivinag's Avatar
    Join Date
    Jan 2005
    Location
    N37 33* W122 3*
    Posts
    414
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    or stick the "password.inc.php" files OUTSIDE the web path...

    or add some php code to file above so it DIEs if a variable/session isnt found.
    leo d.

  6. #6
    get into it! bigduke's Avatar
    Join Date
    May 2004
    Location
    Australia
    Posts
    847
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The only option I see here is to provide the vendors with a web interface to upload files. Ofcourse then you'd have to observe file upload security features but this is still far more secure than giving out direct ftp access. This would be an http upload and a bit slower than ftp. But then I guess its a matter of security so you can't have everything
    With a little server configuration you can also avoid the directory structure form being displayed. Also, this way you can have control over which files can be seen by them.

    If you absolutely need to provide them with ftp access, centralize the db config file, then like leo said move the file anywhere outside the web root and use server side includes to have the information included on other scripts. I'm not too sure if this would work for perl as well.

    Hope that helps

  7. #7
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Brooklyn, NY
    Posts
    359
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Use the method mentioned at the end of this article:

    http://shiflett.org/articles/security-corner-mar2004

    I've yet to see a better practice for addressing this particular problem.
    Chris Shiflett
    http://shiflett.org/

  8. #8
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,576
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Do the vendors need to update scripts or just static files? If it is the latter, then setup apache so that the folders that they can upload files into cannot execute code.

    Another somewhat painful, but possibly necessary option, is to add a little self-defensive script to the database connection script. Build a list of files allowed access, and check when it is called to see what is calling it. If it is not an allowed file, DIE();

  9. #9
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Location
    UK
    Posts
    82
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    For your PHP code, you might want to consider purchasing the ionCube encoder (www.ioncube.com), or Zend encoder (www.zend.com). These will encode/encrypt your php files so that no-one can read or edit them.

    Another (potentially cheaper) solution is the online ionCube encoder. You can purchase 'credits' which you can use to encode your files. Everytime you update a file, you'd need to encode it again (and use more credits). If you update your files a lot, one the the 'downloadable' solutions would be more appropriate, but if you only update the php files occasionally, the online encoder might be just what you need
    Alasdair Stewart
    PHPAudit - Securely License & Distribute your PHP product now!
    21% ionCube encoder discount!


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
  •