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?"
Second step, don't use a hosted site
contract some penetration tester like the one from offensivesecurity
Jehovah be praised, Oracle was not selected
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.
Given that most of these high-publicity break-ins were facilitated by simple exploits, get your web interface sorted out (and I mean really sorted out), and you're at least halfway there.
You will be open to SQL injection attacks. Also, do not say anything negative about the Chinese or Hillary Rodham Clinton, and do not Tweet pictures of your crotch to Hillary Rodham Clinton.
While certainly there are things you should check (remote accessibility, credentials, etc)... I have to say that the vast majority of the data breaches I see are simple sql injection attacks, not people breaking into mysql by exploiting something about the service itself. If you're more of the programmer sort, I'd guess you probably know about religiously cleaning user input, etc.
Don't have the SQL server exposed to the internet. Firewall it so only the Web server(s) can access it.
Only expose the web servers HTTP port(s) to the internet and keep them up to date.
Use parameters (and stored procedures) exclusively if at all possible
Normal people worry me!
Be sure the host has the word 'Sony' somewhere in their name.
Just outsource it to Indians who are promising to do it cheap. They are knowing SQL!
Ask them what their security plan is? How often do they conduct internal and external security scans? Do they conform to any security standards, like NIST, SANS, or even PCI? Also, ensure you have permission to conduct your own security scans, and ask them if you get results where there is a CVSS score of 4.0 or greater.
But this is slashdot. A slashdoter who didn't build his own computer is like a Jedi who didn't build his own lightsaber!
From what I know, I would say that having a good password policy is first and foremost. Secondly, ensure that your MySQL server is only accessible from IP Addresses on the whitelist. Hash your passwords and make sure you salt them. No one likes a good hash without some salt. The biggest threat is an injection. Make sure you sanitize every single input on your site, don't trust cookies for security, and make sure you're regularly validating your security tokens. Oh, and don't be an idiot. There is no reason for you to store anything more than the last four digits of a customers credit card number anywhere on your server.
...then you have to go back to basic principles, which isn't compatible with a hosted site.
In an ideal world, you'd have a public network (the Internet connection) and a DMZ/semi-private network, with the DB server. The web daemon wouldn't run on the DMZ side, and would have to forward requests through to the other server.
It's been a really long time since I dealt with this stuff firsthand, but I suppose that on a single box one could create a virtual network or use loopback to connect the web daemon to the DB daemon, and then restrict the DB daemon to only communicate on the virtual side, but you'd probably still need local root access to set everything up.
From what I gather, many hosting companies that offer space on a box with multiple other customers typically have a DB guy on staff to work with this kind of thing, and they typically charge for the both the cgi bin and for the DB component. As I said though, it's been a LONG time since I've dealt with this stuff personally (like, people were still using compiled-C for server-side coding), so things might have evolved from my mindset.
Do not look into laser with remaining eye.
Follow these: https://www.pcisecuritystandards.org/ and profit.
Get your site penetration tested. Ask you host if they have had thier server's standard build (or SOE) reviewed by security experts also. I can help with these if you need, drop me a line!
Then you won't have to trust your hosting site. Someone steals your data, they get nothing.
If you don't host and managed the DB yourself you will never know. What the company tells you and what they actually do may be two very different things.
As people posted here. Not allowing the database to listen on the "public Internet" is good, but what about local access? Is this shared hosting? Can other customers on their network access the same server?
Do they do regular security updates? How can you verify?
Use strong passwords. Limit user privileges. Restrict IP address to localhost (or your host). Don't use the root account. Sanitize all input to the DB. Encrypt data.
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 ;)
You had better check on the recent laws that have gone into effect. Both State and Federal laws requiring encryption of customer data have been enacted. I suggest finding a security expert in your state that knows the law and have him make a plan for you. If you don't have a plan and you get hacked, you can be sued for very large amounts of money. In fact, quite a few companies have been put out of business because of a hack when they did not have a plan and did not properly protect the customer data. It is more than avoiding a SQL injection.
Just treat your customers fairly and with respect. It seems like everyone who is getting hacked has some bad karma.
1. Read up on SQL injection attacks. Escape all parameters coming in on the pipes.
2. Put the db on a different server and firewall it so it cannot be accessed from the internet. Ideally you would have a 3 layer design with the web host passing requests to an application running on a firewalled server not accessible to the internet, and the application would pass requests through another firewall to the db server running on a machine not accessible to the web host.
3. Don't store anything you don't have to.
4. If you have to store it, encrypt it.
5. Use SSL whenever receiving or transmitting private information.
6. Teach you end users about password security.
7. Under no circumstances store unhashed passwords or send passwords out via email.
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
If you want I can offer you a web site security audit (specialized company), for free.
If you plan on taking credit cards for payment, host with someone like Volusion or BigCommerce to make sure your shopping cart is PCI (Payment Card Industry) compliant. This means credit card information (including, but not limited to, card numbers, expiration dates, CVV2 numbers (the 3-digit number on the back of the card), and cardholder data) is thoroughly encrypted. You can be hit with MAJOR fines (and be banned by the card issuers) for having credit card numbers in cleartext, whether it's a spreadsheet on your office machine or on your website.
Get the documents. Have you and your host assess your setup.
https://www.pcisecuritystandards.org/security_standards/index.php
Also have security scan firms run scans of your site.
As mentioned earlier, hire someone to check out your security measures. Many companies do this. Sadly i can't remember any names off the top of my head, but google is probably not completely clueless.
And obviously: Make sure that the contractors are legit and not just in it to rig the system with backdoors
this is probably the most boring sig in the world
Only allow for the local app to access the SQL ie 127.0.0.1, and if the SQL server is separate lock down the communication. Be sure all client facing code isn't susceptible to injection. Keep your shit updated, just because everything is working doesn't mean you shouldn't update. Be sure people who shouldn't have access to the server DON'T. Always know who has access to what, you never want to inadvertently spill the beans to prying eyes. A managed hosted solution by a third party is always a security risk. All in all just have decent infrastructure, and keep tools off the innards. Audit = Audit = Audit. IMO It sounds like you are the security risk. :\
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.
Not to belabour the obvious, but why not start here:
http://dev.mysql.com/doc/mysql-security-excerpt/5.5/en/security.html
That and never, ever insert user-supplied data into a query without using the vendor approved escape mechanism, even if you've done your own safety checks.
http://dev.mysql.com/doc/refman/5.5/en/string-functions.html#function_quote
"Man is nothing without the works of man" -- Helvetius
1. Start with a hosting service you can trust. Either look at the ads in a five-year-old edition of "PC Magazine" and choose one that's still in business, or find a brick-and-mortar business in your hometown. Do a background-check on the owners. Ask for references. 2. Use stable open-source software (Joomla, OScommerce, whatever) as much as possible instead of rolling your own. Watch out for security patches. If you do write your own code for the site, hire another set of eyes to look at it. 3. Develop a backup plan early on ... ideally before the site goes live.
Depending on your technical abilities, and the feedback from your host I would try backtrack (http://www.backtrack-linux.org)
MySQL has appalling code quality, and a critical piece of proprietary technology. Use PostgreSQL: safer, more standards-compliant, more robust, totally free, more scaleable.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Unfortunately, since you are handing the actual management of the database and the webserver off to a third party, you probably will not have much control over their diligence or architecture. I have not seen a low cost provider that is not rickety in core elements, such as their billing, admin management interface or other threat surfaces -- and that is setting aside the possibility of compromise of their own support team.
The worst part is, these companies will lie to you, very directly, about their threat posture and pretend that they offer ironclad security -- without offering real guarantees. If you decide to use one of these services, you should prepare for the possibility of compromise and insure for the appropriate level of risk.
A MySQL reverse proxy would help as well as a firewall. Just Google "mysql reverse proxy". It'll require a VPS or Dedicated Server though.
Given all of the public break-ins, of huge companies, don't try.
Offer a bounty for security holes and then fix them, or since that is just an open invitation to get hacked, honeypot the bounty with a fake replica site.
I used to work for an internet security firm that provides external security scans. I would recommend it as they will scan your site on a regular basis so that as new security vulnerabilities are found, those will be tested as well.
This is a good place to start
https://www.pcisecuritystandards.org/approved_companies_providers/approved_scanning_vendors.php
Security Metrics is the company that I used to work for and they have a good scanning system in place
Leasing a colocated server is a relatively inexpensive intermediate option. Most decent ISPs have the option available. Prices typically range from $50 to 200/month depending on hardware specifications/bandwidth requirements.
The next step up is to lease space in a colocation rack from the ISP. That is your hardware in a locked rack in their server room.
"You want to know how to help your kids? Leave them the fuck alone." -George Carlin
If you can't protect it, don't collect it.
Post some inflammatory content concerning Anonymous. Include boasts about being invulnerable to retaliation.
Sorry, you're doomed. SQL is horribly insecure, esp. MSSQL and MySQL.
My recommendation: NEVER keep customer data online- keep it on your own computer.
(Or, even better, keep it on an encrypted, password protected external disk set to DBAN itself if you type the password wrong, and never access the data unless you are on a non-networked computer. Then, power down and wait about 10-15 minutes, then turn the computer back on, so your RAM is cleared and overwritten. THEN, throw the computer in a lake while it is still on, and beat the external disk with a very large hammer made entirely of strong magnets.)
Sorry I have to be the bearer of bad news.
Good luck! ;-D
The webapp, not the hosting environment is typically where the vast majority of the security issues come up. Once you've covered your app, ask the hosting company what their security policies are. Then, have someone knowledgable look at them.
If you don't control everything on the box, you can't ensure security.
Regardless of what they claim or what they do, you're essentially sharing the box with hundreds or thousands of other users who potentially have access to run whatever they feel like.
I would suggest a Virtual Private Server on Linode. Your server is yours and security will live or die by how you configure it.
Should always be posted when mentioning databases
http://xkcd.com/327/
maybe a service like Stopthehacker.com can be useful
The best security is one that admits that it can be defeated, a layered approach is best. After they've hacked the webserver where can they go from there? your SQL server will be wide open.
Consider using a grsec patched kernel, chrooting your webserver and restricting everything that isn't absolutely necessary. Grsec supports the feature to prevent binaries from executing on a specified chroot, this may prevent many attacks that would escalate their access. Don't provide compilers, don't have perl/ruby/etc available unless you need to. They may be able to penetrate with a staged payload dropping the privilege escalating exploit at the end and in this case the chroot may restrict their access. If they do manage to break past the chroot you want a fully configured RBAC system. Root shouldn't mean ring 0 in most cases. Disable loading kernel modules, disable /dev/kmem access, disable write access to boot directory and require password at reboot (this prevents them from loading a new unrestricted kernel).
If you can afford it put a bridged firewall/IDS between the webserver and the database. Log everything, make sure your alerts work! Alerts are extremely important in that you can detect a hack in progress and possibly prevent further data extraction! Use white-listing instead of blacklisting. Only allow the absolute minimum. The idea here is that you want to reduce your attack surface as much as possible whilst still keeping functionality.
That is just on the IT aspect tho. Consider the scenario in which an employee goes rogue: disable firewire port (DMA attacks are easily possible), disable usb ports, lock the server room, immediately lock out/revoke IDs to an employee about to be fired (preferably before they're fired), and for god's sake screen your applicants.
Besides the things mentioned above about server security, ask yourself if you have done everything to follow secure coding guidelines for your application. Keywords are: XSS, CSRF, SQL injection etc.
Keep in mind that pen testers will typically find a subset of issues, only. This assumes a typical timeboxed engagement.
How small a business? Veracode () can do a variety of automated scans (on the software and on the site). The cost is trivial for a large business, large for a trivial business.
(1) If it's shared hosting (many clients on one system), do the world a favor and just go bankrupt before launch.
(2) If it's something at least somewhat reasonable (VPS, etc), follow some basic precautions:
- DON'T write shitty code that allows SQL injection. If you don't know what SQL injection is, go to (1) - seriously, this isn't something that can just get "tidied up" pre-launch, you've either got good code or you've got a future security hole.
- DON'T store anything worth stealing. Sounds sarcastic, but this frequently comes down to (a) unsalted and/or cleartext passwords and (b) credit card / banking information. (a) is bad because users frequently reuse passwords; thankfully there's wide support for things like bcrypt that produce strong password hashes - don't roll your own, unless you've neglected to mention a degree in cryptanalysis in your posting. As for (b), there are plenty of solutions for avoiding that storage (CC tokenization, etc) - let the people who build *those* services worry about the details.
If you *really* need to be sure about security, you're likely going to have to step beyond a generic "hosting service" and get something more dedicated (colo, etc). You may also want to consider checking out EC2, as they were certified as a Level 1 PCI Service Provider; I also suspect they've got way more datacenter security than Bob's House of Colo and Boiled P-Nuts can manage....
Only, chroot every service you provide that could be accessed over the network.
Dont do anything to piss off a vengeful hacker collective.
Lemme draw some parallels to home burglary. Your opportune thief is going to look at one or 2 attack vectors. If he cannot get in he'll move on. Contrast this with a professional burglar. He'll watch a target for days, weeks or months all while taking precious notes about weaknesses in security like a time of day where the property is unguarded or maybe a fault in your automated garage door. He's determined to get inside for something and eventually he will. It's far better to be shrugged off by the opportune thief than grab the attention of the professional burglar.
Truth be told, you're going to forget something or there will be an attack vector you simply cannot do anything about. There's no such thing as 100% secure. I'd rather be a target for a script kiddie whose exploiting known and patched holes than piss off a group of dedicated hackers who do their own pentests and wont give up til they've found something to bring you down.
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.
Draw out the communications architecture of your system and only allow those communications paths that are necessary. For example, users won't need to send packets to database servers.
Look through the OWASP guidelines, make notes, and do a thorough code review. No matter how secure the systems are, the application must be secure too. There is a lot more knowledge out there on securing OSes and Web Servers, leave that to your hosting company. You need to concentrate on your application.
Encrypt, then pray.
For certain kinds of data (health records, credit card numbers) there are published standards you can look at. [Hint: You are not going to comply with them hosting your app on a shared server.] You also need to know about the physical security of the hardware and (always hardest) the physical security of any backup media with your data on it.
If you asking the question, the risk is high. You don't even know the scope of your ignorance. But risk is meaningless by itself; what you really need to figure out is the risk * your potential loss, I.e. the expected value.
Consider the scenario in which an employee goes rogue: disable firewire port (DMA attacks are easily possible), disable usb ports, lock the server room, immediately lock out/revoke IDs to an employee about to be fired (preferably before they're fired), and for god's sake screen your applicants.
Beyond the many war stories, I went to a security conference back in 1999 (yes, that early) where the then-primary IT security guy for the Navy told us that in real-world penetration testing 'red team' exercises, the average cost to bribe a systems administrator to let you into the machine room and do whatever you want was just $7000.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
You should consider adding 2FA authentication token such as a Yubikey which has lots of great extensions or for more security a ShieldPass access card which has the mutual authentication capability.
What type of hosting are you getting? Shared hosting where you don't have the ability to do anything but setup a database, or you getting bare metal hosting where you can choose the OS and how to setup every detail of it, or you supply the hardware and routing equipment to a hosting facility . I suggest getting the bare metal or sending your own hardware, then using the docs you can get from the NSA on securing the servers. http://www.nsa.gov/ia/guidance/security_configuration_guides/operating_systems.shtml Like many people have said, make sure that you don't have direct access to the MySQL server from the outside, and that it only talks to the webserver to give data from the database. Even setup a management server where you can do WSUS and remote desktop stuff from if you are going Windows, or another Linux box that you can SSH into to then access all the other servers. If you do your own hardware you can supply your own firewall and setup VPN connection to it. Blah Blah Blah, you are getting the idea from what everyone is posting. So you should hopefully have a good starting point.
-----BEGIN PGP SIGNATURE-----
12345
-----END PGP SIGNATURE-----
> Poor programming practices opens you up to SQL injection.
Insecure programming practices, you mean. They're poor only in 99.9% of situations, i.e. where the need for security justifies the brief additional time. You may not need them, for example, in an in-house diagnostic script you're using for a small company that only two admins can use--provided that you are disciplined enoight not to let that spill over into your more secure coding.
-- IANAL, this isn't legal advice, and definitely isn't legal advice for you. Also, Squee!
The OP specifically mentioned that he is in a hosted environment. So any pen testing he is doing at the OS level or against a multi-teneted MySQL environment means that he is very possibly committing a crime unless he seeks permission. Testing your website it self for vulnerabilities might be safe waters, running an aggressive Nessus scan against the server could be construed as attempting to breach 50 other websites and their databases.
Fling poop whenever possible.
Next, think about whether you need reversible encryption. If you're just validating passwords, use a one-way function. Similarly, if you only need the data for infrequent audit or forensics, you can encrypt it asymmetrically, where the system does not contain the private key. (Secure the private key somewhere else for emergency use.) The data goes into a black hole unless you manually intervene.
The real problem with shared hosting (virtual or otherwise) means you have to trust the real host not to let someone else at your raw data. Since the real host can see into all the virtual machines, you have to trust it and secure it as well. If your not doing that, who is?
Best way, hire a good 3rd party auditor sign an NDA with them. You get another set of eyes on the setup. Plus they will use a number of tools to scan your product and the servers you host it on that you may not have easy access to. For example, IBM's AppScan is designed to scan web applications and test for SQL injections, XSS vulnerabilities, etc.
At some point you may want to look at purchasing a copy of AppScan, however that would all depend on how often your code/environment will be changing. WatchFire was recently (last couple of years) purchased by IBM, which is how they acquired AppScan. I've tried most of the tools out there, AppScan is light years ahead of any others and it's priced that way too.
Good luck!
And I'll check it out for you...
If you're holding customer credit card info, you'll need to meet PCI compliance regs. If you're not, you should look at PCI compliance regs anyway, because they're a good guideline.
Then, when that has scared you enough, wake up look up prepared statements, and then don't use MySQL, especially if you are using PHP. Views don't work properly, subqueries bite, and you can't have joins in a delete statement that makes doing compound deletes virtually impossible without serious pain and suffering. If you were planning on using Amazon RDS, know that if you're tables are MyISAM based, the backups don't work.
Have a nice life.
Everyone is living in a personal delusion, just some are more delusional than others.
If you don't own the iron you can't stop anybody who does doing anything they like with it. Even if you can trust them (and you shouldn't even contemplate it if you don't) you have to rember the warning that was put in big letters on the QEMU web site years ago - "virtualisation is not security". It can't be trusted with full seperation as much as Solaris zones or even different user accounts on the same machine because security was never the aim and is only an afterthought. If somebody else is running their stuff in a virtual container on the same machine there may be flaws that can give them access to yours, since less thought has gone into preventing that than seperating the users on a simpler multi-user system. The odds are that you would have to be very unlucky to have somebody malicous and aware of such flaws on the same hardware as your virtual machine - but it's going to happen to somebody somewhere and is likely to get some press and get people asking you questions when it does.
Then there's the simple resource issues where somebody else on the same box could be hammering the disk or taking all the bandwidth.
Your own box in somebody else's rack is a different story. If you can trust everything on it, virtual machines or not, then the only others you have to trust are the people with keys to the door.
Little Bobby Tables
"The Most Fun Possible on 4 wheels" is at SunBuggy in Las Vegas
There are some automated tools like skipfish . They help finding possible problems but can't replace the eyes of someone with security expertise looking over the code and setup.
Have you considered using Opa? I may be biaises on this topic (I'm a member of the Opa team), but it sounds to me like it's a very good match for your issue. It's an open-source web development platform designed for security - it's an Owasp project, btw. Among other things, it guarantees that your application is invulnerable to XSS and SQL injection, and it performs a large number of analyses on your code, on the inputs, etc. to greatly improve security.
Depending on the current status of your code, you can either use this as a foundation for the whole application, or just as a front-end.
More info on the teaser website, on my blog, or on IRC (freenode, channel #opalang).
One thing to check is the userid that your application code (php, jsp or whatever it is) runs under... Many shared hosting providers run all this stuff under a single shared user, which means that user needs to be able to read things like your database config including password... So if someone compromises another customer, they now have the ability to read all your files...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
One tip I can give you is to do a vulnerability pentest on a copy of your system or before you launch. http://www.websecurify.com/ is a greyhat tool specifically built do a thorough testing (really, it's impressive software) of your site and it's extremely easy to use.
The hosting company is the apartment complex. All they do is allow traffic to your door.
;)
What you do in the apartment is your concern.
You may wish to involve a web programmer, or learn a whole bunch.
-rant-
If the site will be taking money, beware PCI compliance. Experience shows most of the companies offering this "service" are just scammers. Just last night one of my sites failed due to alleged existence of a file that in reality is not even on the server. Not even the directory exists, yet it was flagged for this brand new "critical problem", and supposedly Visa can financially penalize the client due to "failure".
They're mostly a bunch of lazy crooks cashing in on FUD.
-/rant-
Good advice previously.
In general, if you aren't the sole admin user on the box, you shouldn't play. You can co-locate, sure. But you must be the person who is responsible for everything on that box. The ONLY access the co-location provider should be able to have is the ability to execute a shutdown script to protect themselves from your rogue processes.
If you are not the sole owner, then you are dependent on their security being up to snuff.
If your application is small, you may be able to work with a virtual cluster of machines running on a single box.
I would give serious consideration to encrypting all sensitive information in the database. Even if the keys are wired into the application, it means that data extraction has to work through the application to get data.
I would also give serious consideration to putting large quantities of meaningless information into the database allong with some means of filtering for your own use. A Black hat who gets 2 million email addresses from your machine, but finds that 99% of them are bogus will not earn the gratitude of his client.
Third Career: Tree Farmer Second Career: Computer Geek First Career: Teacher, Outdoor Instructor, Photographer.
If Google can't secure their servers, what make you believe that you can?
a) Expect to be hacked.
b) Have a plan for when it does.
c) Tell the client that is will happen, eventually.
d) Hope for the best.
Keep as much data off that host as possible. Transactions over 30 days old probably don't need to be online on that web host. Limit the customer data stored there to only what is necessary to perform a specific task. Limit all public access as much as possible. Use a filtering, reverse proxy, if you must have a SQL DB, lock it down, only allow transactions from known locations. Enable encryption of the DB records. Most of your servers shouldn't be available to the public at all.
I've sat down with multiple CEOs and had this same discussion. "We will be hacked. There isn't anything that can be done and you can't afford to do everything necessary to prevent it. Having a plan for dealing with a hack is the best we can accomplish."
Get them to sign a peice of paper saying that and provide them with a mitigation plan.
If you are only deploying a single server, you sir, are an idiot. Clearly, this is just a troll's opinion, but most PHP programming types simply do not have the appropriate background and experience for system design roles.
So, from what I saw, you're asking about the security of the MySQL backend, which is the place where the hosting provider has the most control and you have the least. All the talk about hardening standards that you should read up on is rubbish; you don't get to harden the systems, they're already as hard as they will ever be (whether hard or not) because of the way the hosting provider has provisioned the system. So what you're really into is a situation where you need to know how to spot a secure architecture and good standards, and then get them to show you their architecture and provisioning standards so you can see for yourself how solid they are.
All the talk about PHP hardening, pen-testing, etc. is fine, but the main concern I would have is about what happens if someone gets to their backend database(s) via someone else's insecure website...becuase that website exists today among their customers, has been there already, and will continue to be there in the future. What protections are there to ensure that an attacker who gets through to the database backend of "Insecure Website Inc." won't also be able to leverage their way laterally to your backend? This is as much an architectural design question as a security hardening standards question; both come into play. I'd look for things like reuse of passwords (if they provision every MySQL database separately, are there any credentials that are common to all of them?) and ways they make sure that getting control of the database won't result in gaining access to the things like the underlying operating system or provisioning infrastructure.
Oh, another thing...the security guidelines that a lot of people are bandying about in earlier responses aren't necessarily enough. There are a whole set of other concerns for a multitenant environment, as found in a hosting center...so make sure that whatever you work with contains that bit of awareness. They'll call it out explicitly, if they cover it.
For your security, this post has been encrypted with ROT-13, twice.
While any server that is not completely within your level of control opens up possibilities of having it compromised, there is also no 100% guaranteed secure configuration that you could do even if it were 100% in your control. I would knock out the obvious first by doing a port scan on the server address to see what services may be running that aren't needed. Also make sure that MySQL is bound to the loopback IP and not the public IP (unless you have multiple servers accessing a central database server, in which case setup SSH secure tunnels with permission restrictions limiting only those servers - although it would be better to just install a second NIC on each server and also run a private network link between the servers). Code wise, I'd make sure that you are validating all submissions and are protected against SQL injection attacks. You can also change settings in PHP to be restrictive in memory usage, file upload size, and handling of requests by setting the minimum required value that your code base would need or use. This can be done in the Apache virtual host configuration, if they don't want to use those settings globally on a shared server. Lastly, when all else that can be done is handled, make sure to encrypt any sensitive data in the MySQL tables. Sure, if the server is compromised, the hash key string or other methodology key is contained either in the code base or in the unique key to the MySQL install, but it's one additional step and would require them to have much more data downloaded - which if nothing else, buys you time that they would need and for you to find them in the process. Oh, and depending on if your running in your own chroot setup, you can use non-standard ports for services like MySQL. Let's face it, the majority of hacking is done by script kiddies that are executing code or things they don't even fully understand. Protecting against the other 5% is a bit more involved, but also unlikely if you protect against the common automated attacks.
Good luck with your new site, and hope you have great success. If you take pride in your product, regardless of what it is, and make it as well as can be made and sold for a fair price - you may not make a boatload of cash overnight that screws the consumer like every other company in the world, but you will have steady and long lasting profit, as well as providing a value to the world. At least that's my two cents on a world with declining business ethics. 8-)
1. MySQL SQL injection. Every single parameter fed to the database needs to be run through the mysql_real_escape_string function. To be future proof, queries should be sent as prepared statements. If you don't know what this stuff is, go to php.com and start reading. mysql_real_escape_string() is a good stopgap measure you can easily implement to scrub your parameters, however, long term you should be using prepared statements. Prepared statements tell the database "This parameter is to be treated as data and not interpreted as SQL". They separate the meat from the milk so to speak. This is the future proof way to secure your SQL queries. Stored procedures do NOT secure your code simply by being stored procedures, although, strongly typed input helps a great deal. No matter what you will be accepting strings/char etc in your database and that's where you'll be vulnerable. Prepared statements when used within stored procedures help, but you can SQL inject your way out of a non-prepared stored procedure call too, even if the sql within is a prepared statement. Make your stored proc calls with prepared statements, then the SQL within the stored procs should also be prepared statements. Do some reading about this stuff. Read it til you understand.
2. XSS. Every variable you get from GPCS (get, post, cookie, session) or database should be wrapped with htmlentities() before display on a web page. This prevents people from phishing your users by neutralizing javascript code they may try to inject. Javascript will simply display on your page and not get executed, making it harmless. If your regexes aren't the greatest, javascript can be sent to your db, then displayed as content. That's why even if it's coming from your db, you should htmlentities() it before displaying it.
3. Scrub your input. Input should only consist of printable characters. scrub it before processing to remove binary data, nulls and other potentially harmful stuff (unless you are handling binary such as a file upload or something). There are regex recipes all over the place for doing this for removing javascript, sql etc. None of them are perfect and that's why you absolutely must adhere to rules 1 and 2. You should also limit the length of the input to prevent buffer overflows that your scripting language people may have missed in their language.
Naturally the usual stuff about securing your server etc apply. Admins are really good at this stuff. However the average off the shelf app will have a lot of vulnerabilities. Almost all of them will be one of the 3 listed above. They are easily fixed. The hard part is finding them. Use grep.... look for "insert, GET, POST, update) etc and other keywords related to sql inserts, updates, delete, create and select.
If the app you are thinking of using doesn't do this stuff, walk away. Find another one. It's also good to force your users to use strong passwords and all that other stuff people mentioned, but you can have the most secure box in the world but if the application running on it is insecure, you will be pwned.
Security is more than just web app security but web app security is where 99.9999% of FAIL occurs and 99% of that happens in items 1-3.
Don't kid yourself. It's the size of the regexp AND how you use it that counts.
Well, the short answer is that if you're in a shared hosting environment, you probably can't do much and in that situation I probably would not recommend storing sensitive information. Assuming you are on a dedicated server or VPS, you can secure your server, but what you need to worry about is what type of security do they have in the network as far as IDS/IPS, network segmentation, and firewalling, as well as what type of physical security they have. I.E. where are the machines physically located, who has access to them, are they under NDAs, what type of background checks have been run on these people, etc. Unfortunately, the truth is that a lot of this stuff may be spelled out in a service agreement, but it may not actually be practiced. If you care about CYA, then get it in writing. If you actually care about not having a breach so you can keep your customers, then the answer is probably something more along the lines of host it yourself in a secure physical environment, or colo a box that you own at a place that you trust, do not give root priviliges to the colo provider, and hash/encrypt the sensitive data on it.
If you must script, NEVER EVER concatenate SQL. If no ORM is availble, use whatever languages parameterized SQL scheme.
I'm looking for an easy-to-use alternative to concatenation in cases like these. For the example, the right side of SQL operator IN is a 1-column table:
But some DBMS APIs do not support table-valued parameters, only scalar-value parameters. I could parameterize the values in the table on the right side of IN, but only if I have to know in advance how many placeholders to use (for example, username IN (?, ?, ?)), and I almost never do. So without concatenation, how do I build the right side of an SQL IN expression? Or do you recommend CREATE TEMPORARY TABLE with one column, executing a parameterized statement to INSERT values into this table one at a time, and then using this table as the right side of an IN or JOIN?