Slashdot Mirror
Ask Slashdot: Verifying Security of a Hosted Site?
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 is a good starting point:
http://code.google.com/p/owasp-development-guide/
Make sure that you setup your mysql server to only accept connections from your server(s).
And get something like Fail2ban if you are using linux to stop brute-forcing.
Store salted hashes of passwords.
Ask them what their processes and policies are in regards to this. They're your supplier, make them tell you why you should trust them with your DB.
That said....firstly understand that securing the database is a small piece of a very big complicated jigsaw made up of randomly cut pieces with an abstract painting on them. Security is hard.
My first step is always to get the infrastructure up to something I'm happy with.
* Set your firewall to block all incoming connections by default, only ever allow connections to port 80 (and 443 if necessary) on your web server/load balancer.
* Designate a couple of 'management IP addresses'. IE your home, or another location. Open up SSH to these addresses only.
* Configure SSH so the only way to access it is via certificates. Do not allow tunnelled plaintext passwords, ever.
* Try to ensure all your secret SSH keys are password protected
* For all server management issues use SSH. Use it for uploading, direct DB access, deploying etc. The only external connections to any of your servers happen on port 443/80/22.
* If you are using SSL use a secure cipher suite (running SSL Digger) will tell you if you are using any weak ciphers
* Decide on an update policy (ours is to have a human monitor all package updates daily, decide when an important one comes out, test it on stage, then update production) that ensures critical security fixes are applied quickly
* Google "security guide app" and review what the Internet says about securing Apache/Lighttpd/Squid/MySQL/RabbitMQ/Whatever. Understand it! Pay particular attention to anything the user interacts with (ie Joomla/Drupal/Wordpress)
Hmm, that's a pretty big list, mostly incomplete, and isn't even where your big security problems lie - most attack vectors are likely to come through flaws in your application. SQL Injection (shockingly!) is still happening, and if you give users the opportunity, someone WILL shoot themselves in the foot.
Man, security is hard! You can hire an agency to test things for yuo and give you a report. These tend go from quite cheap (ie the firm just ran Nessus and sent you the output) to extremely ellaborate white-box penetration testing that usually comes back with practical real world advice.
Great that you are concerned enough about this to ask Slashdot, don't work for Sony do you ;)
MySQL doesn't inherently open you up to SQL injection... Poor programming practices opens you up to SQL injection. Any SQL based database is vulnerable if someone stupid writes the program.
The standard lines about SQL injection:
DO use prepared statements with place holders e.g. "SELECT * FROM table WHERE id = ?"
DO NOT use string concatonation "SELECT * FROM table WHERE id = '" + some_string + "'";
DO sanity check anything passed into your database
DO NOT use user input as an identifier (column, table, or view name) E.G. "SELECT * FROM "+user_input+" WHERE 1=1";
DO make users for your database that have the least amount of permissions required to run your app (Only UPDATE, INSERT, DELETE, SELECT)
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.
Hosting secure, high-reliability, high-availabity web sites isn't a do-it-yourself proposition. Perhaps you should have your site hosted by a top quality vendor who has the staff and expertise to maintain the physical and software security.
The problem is that this type of hosting isn't cheap. The bargain basement hosting firms will not provide the expertise and customer support necessary.
Unless you're really going to scale up quickly, it's unlikely that you can hire (or become) expert in all of the domains necessary to provide top tier hosting. For example, can you accurate manage the A/C needs for your site hosting? Do you have guaranteed service contracts on the A/C units an N+1 back ups? Same with power, backups, hot off-site recovery, physical security, insurance, fuel for your generators, battery contracts?
I'd go with a top-tier hosting firm, and be prepared to pay significantly more than $10/month.
Post some inflammatory content concerning Anonymous. Include boasts about being invulnerable to retaliation.
Alternately,
DO create stored procs / functions and grant your scripts execute privs (and not much else). This can be a pain to implement, but it is the most "elegant" solution since you're forced to properly decouple DB functionality from front-end logic. Plus it makes it easier to add different front-ends later if you go multiplatform or something...
-or-
DO run all user-sourced input through "mysql_escape_string" or your DBMS' equivalent. Most DAO implementations already do this.
Prepared statements are a decent half-step, but they aren't easily applicable to variable-length queries such as "advanced search" or anything else with optional parameters. It's far too easy to hit one of these walls and fall back into sloppy coding to get around it, negating what little advantage the prepared statements offered.
-Billco, Fnarg.com