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?"
owasp (Score:4, Informative)
This is a good starting point:
http://code.google.com/p/owasp-development-guide/ [google.com]
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.
Re:First step, don't use a hosted site (Score:2, Informative)
Second step, don't use a hosted site
Make sure not to use a server application or OS someone else wrote or maintains either. Definitely don't use anything that requires a third party to provide the updates or patches.
On second thought: "Third step, don't connect the web site to the internet."
Seriously... you have to host things, or it will be very expensive to put your site up by building all the infrastructure yourself, or you cut corners and not have the protections (like design, cooling redundancy, power redundancy), a real datacenter operation provided by a hosting provider would.
Trying to host a web site on home/business DSL is bound to be a failure. Good luck dealing with unexpected load spikes, also.
"Not hosting the site" is not a realistic solution for most people.
You need to pick a hosting provider that will work with you to ensure security, and who had third party validations to show you, is willing to cooperate with third parties to validate security, and will attest to / provide you some documentation of their own security practices (esp. physical security with regards to servers you colocate), OR their practices for dedicated servers (second best security option) -- e.g. who has access, what controls exist, etc; shared servers (where multiple customers have sites on the same OS install) are potentially dangerous in some regards.
Make them tell you. (Score:5, Informative)
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 ;)
Re:Do not use mySQL (Score:5, Informative)
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)
Re:Do not use mySQL (Score:5, Informative)
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.
It's not rocket science. (Score:4, Informative)
Easy -
Request, log, and record, only that information that is absolutely necessary and nothing more, and keep it only for as long as you'll need it and not a bit longer.
You can save yourself some heartache by not storing any PII and PFI.
Don't store payment information.
Don't store credentials. Consider using OpenID or Google or (shudder) Facebook Connect for accounts.
Keep sensitive information off any internet-accessible systems.
And last, don't trust any input from your visitors.
Sanitize all input.
Declare all variables.
Don't assume anything.
If you're expecting an integer, make sure you convert the submitted form data to an integer for that variable implicitly.
Same for dates, strings.
Normalize all input.
Sanitize all input.
Never trust any input.
Consider using a database abstraction library with well documented and mature APIs. Don't code things yourself.
Don't turn on ssh password authentication. Require only public/ private keys.
Turn register globals off in PHP. Use safe mode.
Make sure MySQL is on a separate server, with an RFC-1918 address, accessible from a dedicated NIC that is not on the Internet.
Consider a security audit and professional code review if you're planning on taking any money.