Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Databases Privacy Security

Ask Slashdot: Verifying Security of a Hosted Site? 182

edi_guy writes "I'm getting ready to launch a small commercial website that will contain customer information in a MySQL database that will be run by a web-hosting service. While I have good experience with SQL databases from a programming point of view, I'm not an expert on securing them. Given all of the publicity around break-ins and data theft on a seemingly daily basis, it seems prudent to review this now rather than later. What are suggestions on resources that would help verify that both myself and my hosting service are following best practices on securing a database backed website?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Verifying Security of a Hosted Site?

Comments Filter:
  • by Anonymous Coward on Thursday June 02, 2011 @06:15PM (#36325814)

    1. Do not use the MySQL root pass as the application password. Do not use the root user as your application user.
    2. Setup an application specific id and only give it SELECT, UPDATE, DELETE for the specific tables of the application or to the application schema only.
    3. Passwords for these ids must be 15 chars long
    4. DB Passwords stored in application files must have the correct ACLs.
    5. Learn how to use the creation of the user id to lock the db for access only from the application server. For example if your app server is at 192.168.0.4 then the application user would be applicationuser@192.168.0.4. This 'locks' the db from only accepting traffic from the server listed. If the db is colocated with the app server, then specify the user like this - applicationuser@localhost. Also assuming you need to login to the DB server to do maint then your root user would be root@localhost. This would force you to have localhost access before you could login as root.
    6. Use a Object Relational Mapping technology to front the DB, thus preventing SQL injection attacks. If you must script, NEVER EVER concatenate SQL. If no ORM is availble, use whatever languages parameterized SQL scheme.

    There is probably more here, but this should give you a fairly good start.

    Good luck

  • by hellkyng ( 1920978 ) on Thursday June 02, 2011 @06:24PM (#36325914)

    Not a bad component to have a pen tester come in. You might want to start however by working through a hardening guide like the ones available over at the Center for Internet Security. They are very detailed, easy to follow, and do an excellent job of security your target. Test in development first though as it is too secure in a lot of cases and will kill needed functionality.

    Once you've accomplished that have a pen tester look things over and see if its secure. Then put in logging and monitoring, ensure your security controls don't change and that you aren't seeing suspicious activity in the logs.

    In terms of evaluating the hosting company, it depends on how open they will be with you. See if they have audit results from PCI or SAS70 and request them. See if they have pen test results available for you as well. Check and make their encryption looks reasonable, are they using SSL etc. Ask their security staff basic questions and see how knowledgeable they are. Request references with highly audited customers to see what they think.

    That should keep you busy for a little bit.

HELP!!!! I'm being held prisoner in /usr/games/lib!

Working...