Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Verifying Security of a Hosted Site?

timothy posted more than 3 years ago | from the just-wait-for-the-spam dept.

Databases 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?"

cancel ×

182 comments

Sorry! There are no comments related to the filter you selected.

first post (-1)

Anonymous Coward | more than 3 years ago | (#36325448)

OH yeah!

First step, don't use a hosted site (0)

Anonymous Coward | more than 3 years ago | (#36325460)

Second step, don't use a hosted site

Re:First step, don't use a hosted site (2, Informative)

mysidia (191772) | more than 3 years ago | (#36325576)

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.

Re:First step, don't use a hosted site (1)

Anonymous Coward | more than 3 years ago | (#36325608)

No, there's a little thing called a dedicated (or colocated) server. If you are sharing a server, which most people would call "hosted," then you are vulnerable to whatever problems they introduce.

Re:First step, don't use a hosted site (0)

Anonymous Coward | more than 3 years ago | (#36325896)

Pretty much. If you share the server, then by definition you don't control the server. If you don't control the server, you have no way of verifying it's security to any reasonable degree. To extrapolate:
1. Buy server
2. Secure server
3. Pay someone reliable to power it, cool it, and connect it to the internet
4. ???
5. Probably lose a lot of money, the economy's in the shitter and I guarantee someone else already made a website does whatever the fuck your website does, and they do it better.

Re:First step, don't use a hosted site (0)

Anonymous Coward | more than 3 years ago | (#36326134)

"Seriously... you have to host things"

No, you don't. You can house them.

"or it will be very expensive to put your site up"

From the site I come from, what it takes for a business, it takes for a business. Telling that doing what needs to be done for your users' data is "very expensive" is declaring yourself a cheap bastard.

"you cut corners and not have the protections"

You can cut *your* protections all you want, the problem is when you are talking about cutting your *customers'* protections. Using a hosted database you don't know how to properly manage is just risking data that it is not yours to start with.

""Not hosting the site" is not a realistic solution for most people."

Well, I don't have the financial muscle to be in the big infrastructures business, so I am not in that business. What I don't do is telling that all that security measures for highways are "very expensive" and try to cut corners... on the security of people.

"You need to pick a hosting provider that will work with you to ensure security"

There's no damn hosting provider that will take care for you programs' security. You know why? Because they are *hosting* providers, not service providers. The service is up to you, and if you are not up to the service I really better prefer you just not trying.

Its called colocation... (1)

Local ID10T (790134) | more than 3 years ago | (#36326172)

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.

Re:Its called colocation... (1)

hedwards (940851) | more than 3 years ago | (#36326524)

Indeed, also do yourself a favor and make sure that you have at least one set of servers that's within some sort of sane drive from your home or office. The last thing you're going to want to do is drive 6 hours because the people on site don't have a key. Sure you can allow them to have a key, just make sure that there's a sane system in place to track the keys at all times so that there aren't times when some random person has a key or worse where one key can unlock multiple sets of servers.

Re:Its called colocation... (1)

mysidia (191772) | more than 3 years ago | (#36326878)

I don't know what you're talking about keys for. There aren't any colocation providers I know of that will let you colocate a few U or a half rack, lock it, and take the keys off site.

Usually such a customer doesn't even have the keys to the rack. If they have any access to the rack other than escorted-by-security during business hours only (8x5) and watched-like-a-hawk while they pull their server out/put their server in, they're paying through the nose for it.

Things like on-site hands from the facility or remote KVM are as-available, and very expensive. Much more expensive than hosting for a small operation of just one web server and one db server.

Re:Its called colocation... (1)

mysidia (191772) | more than 3 years ago | (#36326858)

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 mean that's your hardware hosted in a rack in their server room.

Whether that rack is in a cage and locked or not will depend. In any case, they have the keys, not you.

And if you have a Layer 1 (physical) issue, you are in for a lot more downtime than a professionally hosted dedicated server. With the hosted option, there will probably be spares on site. With a colocation option, you will be driving in, and waiting for an escort to let you in to try and troubleshoot your server, and then take it out with you, to hunt around your place (or some store) to buy replacement components.

The option of colocation is only really sane for personal stuff that doesn't matter, or for large companies that rent out entire racks with 24x7 access, and have dedicated staff near the colo.

Re:Its called colocation... (1)

mysidia (191772) | more than 3 years ago | (#36326922)

The option of colocation is only really sane for personal stuff that doesn't matter, or for large companies that rent out entire racks with 24x7 access, and have dedicated staff near the colo.

P.S. And even with colocation, usually the provider has the right to gain entry to your server by force, if they feel they need to. And the possibility remains an unauthorized person could steal your server or use physical access to root it.

The security risk is hardly any different from hosting a dedicated server; and just comes down to you owning the piece of metal vs a provider owning the piece of metal. What can be done with that piece of metal under either arrangement is spelled out in a contract.

And if the contract is adequate, including things like giving you a right to buy your server or allowing you in to copy the data off the server and then format the server, in case of account termination, you're equally protected, security-wise even if a provider owns the metal.

No matter who owns the metal, you having a server in someone else's location creates an external dependency risk that should be managed.

Many firms specialize in site hosting (4, Insightful)

klubar (591384) | more than 3 years ago | (#36325930)

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.

contract some guys (1)

JonySuede (1908576) | more than 3 years ago | (#36325468)

contract some penetration tester like the one from offensivesecurity

contract some gays (-1)

Anonymous Coward | more than 3 years ago | (#36325706)

Try the GNAA [gnaa.eu] . They have hardcore operatives with impressive penetration tools.

Re:contract some guys (4, Interesting)

hellkyng (1920978) | more than 3 years ago | (#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.

Re:contract some guys (1)

TooMuchToDo (882796) | more than 3 years ago | (#36326330)

PCI and SAS70 audits are a joke. PCI "tests" are self-administered (and the "scans" are usually run by some firm charging top dollar to run open source vulnerability scanners against an IP or two), and merchant account providers simply ask if you completed and fulfill the requirements. SAS70? A get-rich-quick scheme from financial/accounting firms who perform the audit. Note they aren't technical consulting firms, but accounting firms. *insert troll face/problem? here*

Use SSL. Ensure your site doesn't have any SQL injection vulnerabilities. Encrypt credit card numbers (if you need to store them; preferably you don't). Only allow ports 80/443 from the world, and only admin ports from known IP addresses. Use semi-complicated passwords. Ecommerce doesn't require rocket science or expensive audits.

Re:contract some guys (1)

hellkyng (1920978) | more than 3 years ago | (#36326626)

PCI definitely is a joke but not for the reasons you listed. Self assessments are only done when a company is pretty small and processes a limited number of card transactions. In a large firmer like hosting companies they probably have to have a QSA conduct a formal and more rigorous audit. Companies like heartland were pci compliant when breached so it's definitely not perfect.

But on the other hand a pci and sas70 are most likely the only insight your likely to get into the companies security unless your going to be a huge client. It not perfect but it can certainly be used as part of a layerd security assessment.

Otherwise your advice is good but only a small part of what needs to be done to ensure an entire site is secure. Reading through the pci requirements might not be a bad idea either. Sure they are a checklist, but if you take the guidance and ensure you implement in ways that make sense and don't just check boxes you will do alright.

Re:contract some guys (0)

Anonymous Coward | more than 3 years ago | (#36326896)

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.

Better yet put everything in that guide that is relevant to your system/s in a script that you can run automatically (and that spits out notices when things do change). Ideally you'd probably want to use a configuration management system (Puppet, Chef, Cfengine) for the task.

Re:contract some guys (0)

Anonymous Coward | more than 3 years ago | (#36326122)

yeah, you can never have too much snake oil

Re:contract some guys (1)

Z00L00K (682162) | more than 3 years ago | (#36326178)

I think that the first step is to watch the design of the website itself and use a layered approach to limit access to services and functionality of the server.

For example - if you use a Tomcat/Java web server it shall be executed in a security manager using a security policy that limits what the application in Tomcat is able to do - like only specific classes may access specific ports/services on the server. And anything in Tomcat shall never access the database itself but instead only a secondary business layer that contains the logic of the application. That layer may access the database. It will make any access to the database a lot harder for anyone looking into penetrating the system since they have to learn the design of it and try to work around the security policy of Tomcat.

And what's executing in Tomcat shall only be the presentation layer, not much business logic.

Anyone that directly accesses the database from their presentation layer is making things easy for intruders since it may only take a single flaw like a bug in PHP to get direct access to the database.

And of course - the web server shall be executing as one non-privileged user and the business logic server as another and the database engine as a third. None of them shall have admin rights. That's what compartmentalization is about. I'm not saying that it's a design that's impossible to penetrate, but it takes time to penetrate it if you want direct access to the database. And if it takes time it will increase the risk of discovery, especially if you in the code build in traps that notifies you or anyone monitoring security on the way. A trap sprung may mean that there is an intrusion and it's time to start monitoring and take counter-measures.

Re:contract some guys (1)

JonySuede (1908576) | more than 3 years ago | (#36326570)

I assumed that he was ready to go live and that he already had the basic covered. But sure first implement what parent post said first. But still I think that before going live the best thing that you can do is to have a penetration test done by a pro. Not some stupid audit shit like PCI (credits cards) and SAS70 (software assurance service).

Re:contract some guys (2)

John Hasler (414242) | more than 3 years ago | (#36326894)

Or get it done free: antagonize Anonymous.

SIMPLE !! (-1)

Anonymous Coward | more than 3 years ago | (#36325482)

Assume everything is peachy !! Sure to win at Vegas !!

owasp (4, Informative)

badran (973386) | more than 3 years ago | (#36325484)

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.

'); DROP TABLE Comments; -- (0)

Anonymous Coward | more than 3 years ago | (#36325492)

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.

Re:'); DROP TABLE Comments; -- (1)

dzr0001 (1053034) | more than 3 years ago | (#36325780)

Uhh, right, because a poorly written web application won't be able to execute SQL if another DBMS is used.

Do not use mySQL (0, Funny)

Anonymous Coward | more than 3 years ago | (#36325494)

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.

Re:Do not use mySQL (2)

JordanL (886154) | more than 3 years ago | (#36325766)

MySQL is not uniquely prone to injection attacks. All that requires is unescaped user input.

Re:Do not use mySQL (5, Informative)

Anonymous Coward | more than 3 years ago | (#36325818)

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 (0)

Anonymous Coward | more than 3 years ago | (#36325922)

DO make users for your database that have the least amount of permissions required to run your app (Only UPDATE, INSERT, DELETE, SELECT)

even better
DO make your database operations into stored procedures and only give your database user the execute rights on those procedures and NOTHING else

Re:Do not use mySQL (1)

guybrush3pwood (1579937) | more than 3 years ago | (#36326648)

DO make your database operations into stored procedures and only give your database user the execute rights on those procedures and NOTHING else

As opposed to what, mister? Writing SQL in PHP?

Re:Do not use mySQL (4, Informative)

billcopc (196330) | more than 3 years ago | (#36326194)

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.

Re:Do not use mySQL (1)

Ksevio (865461) | more than 3 years ago | (#36326518)

DO run all user-sourced input through "mysql_escape_string" or your DBMS' equivalent. Most DAO implementations already do this.

...and make sure to put user input in quotes (or back quotes) in the final query as even an escaped string can cause problems:
Basic query: "SELECT * FROM tbl WHERE x = ?"
Input: "1 OR 1=1"
Final: "SELECT * FROM tbl WHERE x = 1 OR 1 = 1"

Re:Do not use mySQL (1)

Anrego (830717) | more than 3 years ago | (#36326606)

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.

I've generally managed this by dynamically building the query, preparing it, then dynamically building the data statement. Requires a little extra work, but I'll take it any day to mucking with various escape_string methods.

Code wise, I've found it makes it a little prettier to abstract the "search" from the SQL. So you have a "SearchComponent" object that contains say, field, comparator, value .. your advanced search is comprised of a collection of arbitrary SearchComponents.. you then iterate through this array when building your query (inserting the appropriate operation and token where appropriate) .. then iterate through the collection again when building your DATA statement. This works just as well for optional arguments.

negating what little advantage the prepared statements offered.

I strongly disagree with "little advantage". Personally I think decoupling query from data and essentially eliminating most injection attacks and escaping/formatting nightmares is a pretty substantial advantage. Plus you get a performance boost when executing the same insert query over and over.. as it can cache a lot of the execution plan.

Re:Do not use mySQL (1)

LordLucless (582312) | more than 3 years ago | (#36325934)

Also, don't listen to clueless Anonymous Cowards on Slashdot who don't know anything but the subject at hand - but comment anyway

MySQL (0)

Anonymous Coward | more than 3 years ago | (#36325500)

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.

Some simple rules that will catch most things (1)

sirsnork (530512) | more than 3 years ago | (#36325506)

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

Re:Some simple rules that will catch most things (1)

mysidia (191772) | more than 3 years ago | (#36325654)

These are foregone conclusions, but they do not secure against the most common attacks. It is rare that the SQL server is attacked directly, even if it is listening on the right report -- this is MySQL he's talking about, not MSSQL. Even if you do open mysql port to the world, the footprint is not that large, and common practice is not to create users that can connect remotely.

Use parameters (and stored procedures) exclusively if at all possible

Using parameterized queries exclusively, will avoid most SQL injection attacks; you still have possibility XSS/CSRF issues to be concerned about; those follow right after injection, and of course..... the issue of simply failing to properly authorize queries submitted, the class of vulnerabilities called 'trusting the client'.. e.g. not preventing a user from changing a &customer_id= in the POST form and submitting that order to someone else's account, changing random form variables to enable the user to do something they aren't supposed to do that the Web UI doesn't expose, or changing an &item_id= and ordering an item that is supposed to be hidden/not listed for sale, best yet... changing a &price= or &shipping= in the post form, and revising their terms of sale when hitting the 'finalize order' button.
Stored procedures and other extension-fu are generally a bad idea... not portable when you need to switch SQL implementations.

Re:Some simple rules that will catch most things (1)

Caladrius (1118023) | more than 3 years ago | (#36325826)

Keep things like customer_id and user_id in the session instead. That way no one can change them and submit a POST.

Re:Some simple rules that will catch most things (1)

LordLucless (582312) | more than 3 years ago | (#36325964)

Stored procedures and other extension-fu are generally a bad idea... not portable when you need to switch SQL implementations.

How many times have you switched SQL implementations on a project? Personally, I've never seen it done. Unless everyone involved is extremely careful to follow only very restrictive ANSI standards, chances are stuff will break. Hell, even LIMIT clauses are generally proprietary. If you think you're going to be switching database backends:
1) Do your research first, and use the right one from the beginning
2) Use an ORM that supports both

Re:Some simple rules that will catch most things (1)

JonySuede (1908576) | more than 3 years ago | (#36326652)

How many times have you switched SQL implementations on a project? Personally, I've never seen it done. Unless everyone involved is extremely careful to follow only very restrictive ANSI standards, chances are stuff will break.

We did it with brilliant success here at work (on a code base from the middle 90) and maybe we are going to move again in the next month. When you are not a lazy slob writing compliant SQL code is not that hard. However you have to have a good dba to make it perform.

Re:Some simple rules that will catch most things (1)

Caladrius (1118023) | more than 3 years ago | (#36325874)

Use parameters (and stored procedures) exclusively if at all possible

I think you mean prepared statements?

Stored procedures can be useful for certain things, but if every bit of SQL is written as one, it'll be a huge pain to read the code.

Re:Some simple rules that will catch most things (0)

Anonymous Coward | more than 3 years ago | (#36326216)

"I think you mean prepared statements?"

Which you would use depends entirely on the RDBMS you are using.

Re:Some simple rules that will catch most things (1)

Yvanhoe (564877) | more than 3 years ago | (#36326336)

Sanitize all the user entered data. Expect Bobby Tables.

simple (0)

Anonymous Coward | more than 3 years ago | (#36325508)

Be sure the host has the word 'Sony' somewhere in their name.

simple (0)

Anonymous Coward | more than 3 years ago | (#36325528)

Just outsource it to Indians who are promising to do it cheap. They are knowing SQL!

Ask them (1)

Scott Lockwood (218839) | more than 3 years ago | (#36325530)

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.

Re:Ask them (2)

mysidia (191772) | more than 3 years ago | (#36325708)

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?

All eCommerce sites that deal with primary account numbers such as CC numbers (and don't use PayPal for everything) are supposed to be following PCI anyways. It's not as if the PCI requirements are optional rules vendors are allowed to ignore and still process payments --- if you have a payment processor, PCI is going to be included in the contract you signed somewhere.

So that one... should be easy to leverage to your advantage... If you are hosting your site on a shared hosting provider, ask if they comply with the PCI requirements for shared hosting providers.

Specifically, ask if they meet the requirements including not running different users CGI/PHP scripts as the same UID as other users or as the webserver UID.

Re:Ask them (1)

Anonymous Coward | more than 3 years ago | (#36325790)

Technically, PCI are voluntary. Quite expensive to find one that will exempt you though. On the level of ~7.6%+$1000/monthly bill when I was last dealing with it.
Some of the most annoying things ever. "We dont process orders through the website, it lists a phone number to call" "Must be PCI Compliant!" "It never even sees customer directed emails, they go through a different machine" "must be compliant!" "Oh, hey, we don't have a website" "Thank you, compliance passed"

Re:Ask them (2)

mclearn (86140) | more than 3 years ago | (#36325968)

You do realize that PCI compliance covers things like the PoS terminals and the like, right? PCI Compliance is a security guideline document that is supposed to be used if you receive customer credit card information at all.

Period.

Do you use a PoS to process those cards? Is it secured? Is it connected to an open network or on a dedicated line? Is the credit card number printed on the slip? Are those slips secured in a safe place? Does the minimum number of people have access to this slips? etc.

It is NOT a system just for web e-commerce, but most people seem to think that it is.

Re:Ask them (0)

Anonymous Coward | more than 3 years ago | (#36326202)

Yes, i know it attempts to cover the entire 'credit card interaction' area.
I also know i was on the phone with this particular processor for over 4 hours to get him to accept the machine they were demanding 'be made pci compliant' was 100% unrelated to that in any way, shape, or form.
Wasn't in the building, didn't connect to their data in anyway, it was, basically, a splash page that said 'Call us at ######'
Still insisted that it had to pass their certification or we could sign a 'Pci Compliance wavied contract' for the higher cash.
Finally I dropped the DNS, told him there was no site, and hey it was approved.

Security is important and PCI Compliance isnt a bad set of guidelines. but they have no common sense at all sometimes and it isnt strictly mandatory. just expensive; and often useless

our checkout system is PCI compliant, doenst print cards, etc, but the security cameras can read the whole card # pretty well

Common Sense (1)

The Bringer (653232) | more than 3 years ago | (#36325534)

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.

If you don't know how... (1)

TWX (665546) | more than 3 years ago | (#36325542)

...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.

PCI Compliance Standards (1)

Anonymous Coward | more than 3 years ago | (#36325566)

Follow these: https://www.pcisecuritystandards.org/ and profit.

Re:PCI Compliance Standards (1)

phek (791955) | more than 3 years ago | (#36326296)

pci compliance standards aren't really that good, especially for determining web application security.

Sleep Soundly - Install The Best OS (-1)

Anonymous Coward | more than 3 years ago | (#36325572)

from MicroCRAP [microsoft.com] .

Your customers will thank you.

Yours In Novosibirsk,
Kilgore T.

Penetration Testing (1)

hugheseyau (2222722) | more than 3 years ago | (#36325600)

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!

Anonymous (-1)

Anonymous Coward | more than 3 years ago | (#36325634)

Set up a separate domain. Host pictures and videos of torturing animals. Post to /b/.

Encrypt your data (0)

Anonymous Coward | more than 3 years ago | (#36325642)

Then you won't have to trust your hosting site. Someone steals your data, they get nothing.

Host and manage it yourself. (0)

Anonymous Coward | more than 3 years ago | (#36325688)

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.

Make them tell you. (5, Informative)

RichardJenkins (1362463) | more than 3 years ago | (#36325690)

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:Make them tell you. (0)

Anonymous Coward | more than 3 years ago | (#36326916)

Is there ever a reason to run SSH on port 22?

Customer Security (0)

Anonymous Coward | more than 3 years ago | (#36325716)

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.

Don't be an asshat (0)

Anonymous Coward | more than 3 years ago | (#36325748)

Just treat your customers fairly and with respect. It seems like everyone who is getting hacked has some bad karma.

Uhh.... (1)

the eric conspiracy (20178) | more than 3 years ago | (#36325768)

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.

There is much to do to secure a MySQL db. (2, Interesting)

Anonymous Coward | more than 3 years ago | (#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

audit (1)

vldcnst (1832302) | more than 3 years ago | (#36325848)

If you want I can offer you a web site security audit (specialized company), for free.

PCI compliance (0)

Anonymous Coward | more than 3 years ago | (#36325856)

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.

Hire someone to check it out. (1)

zaunuz (624853) | more than 3 years ago | (#36325898)

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

You are the... (0)

Anonymous Coward | more than 3 years ago | (#36325900)

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. :\

Start here (1)

Syncerus (213609) | more than 3 years ago | (#36325948)

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

Stick with tried-and-true (1)

lamber45 (658956) | more than 3 years ago | (#36325978)

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.

Backtrack? (1)

kernelphr34k (1179539) | more than 3 years ago | (#36325980)

Depending on your technical abilities, and the feedback from your host I would try backtrack (http://www.backtrack-linux.org)

Wrong DBMS (1)

leandrod (17766) | more than 3 years ago | (#36326014)

MySQL has appalling code quality, and a critical piece of proprietary technology. Use PostgreSQL: safer, more standards-compliant, more robust, totally free, more scaleable.

Re:Wrong DBMS (0)

Anonymous Coward | more than 3 years ago | (#36326334)

Yawwnnn. Why is it you posgresql zealots are unable to stop spouting shit? Get over it, PS flunked because it's slow, it's clunky, and it's unusable in real world sites without tearing out the engine. If you have nothing to offer the poster, go away and have a wank.

Be Prepared (0)

Anonymous Coward | more than 3 years ago | (#36326032)

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.

MySQL Reverse Proxy (0)

Anonymous Coward | more than 3 years ago | (#36326100)

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.

So you're going to beat them? (1)

holophrastic (221104) | more than 3 years ago | (#36326114)

Given all of the public break-ins, of huge companies, don't try.

Bounty (0)

Anonymous Coward | more than 3 years ago | (#36326136)

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.

Scanning Vendor (0)

Anonymous Coward | more than 3 years ago | (#36326158)

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

Re:Scanning Vendor (0)

Anonymous Coward | more than 3 years ago | (#36326430)

I currently work for a firm that provides these scans as well and I would highly recommend them. Since you're on a shared server a network scan may not be the best idea but many of these companies are now offering web application scans as well now. Many people here have suggested PCI scans... that's not what you want. A PCI scan is primarily a network scan. It would however be a good idea to ask your ISP if their shared servers have passed PCI compliance and if so to see proof. If they haven't attempted a PCI scan, then you should probably ask them if it's ok to run one against their servers.

As others have mentioned, hiring a pen tester would be a great idea but this could be pricey. If you're not willing to pay anything/much there are some free and cheap tools out there to do a web app scan yourself such as burp suite but I would highly recommend against this since you probably aren't that familiar with web security. Also reading the owasp documentation for web security would be a great idea.

If you cant.. (0)

Anonymous Coward | more than 3 years ago | (#36326182)

If you can't protect it, don't collect it.

Simple yet effective website security test: (4, Funny)

nuckfuts (690967) | more than 3 years ago | (#36326184)

Post some inflammatory content concerning Anonymous. Include boasts about being invulnerable to retaliation.

Re:Simple yet effective website security test: (1)

memyselfandeye (1849868) | more than 3 years ago | (#36326820)

And encrypt your passwords [geekosystem.com] with DES... and login as root... and don't forget to smudge taco sauch on that post-it-note with that command "yum update" written on it.

Seriously, don't listen to all the naysayers. Just because you call yourself smart and have a million users doesn't make you smart. And just because you don't have a million users and don't think you're smart doesn't make you stupid. Work hard, subscribe to mailing distribution and software mailing lists, and ALWAYS make it a point to check your logs. It might sound pointless, but at least you'll be logging into a shell more often than you clean your gutters.

If that fails, there is always Plan B [xkcd.com] .

Nope. (0)

Anonymous Coward | more than 3 years ago | (#36326264)

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

First, make sure your webapp is secure (0)

Anonymous Coward | more than 3 years ago | (#36326346)

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.

Not possible on a shared host (2)

pushf popf (741049) | more than 3 years ago | (#36326368)

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.

Oblig (1)

Pop69 (700500) | more than 3 years ago | (#36326370)

Should always be posted when mentioning databases

http://xkcd.com/327/ [xkcd.com]

Re:Oblig (0)

Anonymous Coward | more than 3 years ago | (#36326554)

http://i.imgur.com/MOUfk.jpg

potentially useful service, nothing to install (0)

Anonymous Coward | more than 3 years ago | (#36326382)

maybe a service like Stopthehacker.com can be useful

Assume you've already been hacked... (1)

pasv (755179) | more than 3 years ago | (#36326406)

What then?? after you've taken all the steps described in the above comments it's well worth the time to design an incident response plan.

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.

Mod parent up (1)

wurp (51446) | more than 3 years ago | (#36326566)

Only, chroot every service you provide that could be accessed over the network.

Secure coding? (0)

Anonymous Coward | more than 3 years ago | (#36326426)

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.

Veracode (0)

Anonymous Coward | more than 3 years ago | (#36326458)

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.

Depends - what's the "hosting service"? (0)

Anonymous Coward | more than 3 years ago | (#36326538)

(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 [amazon.com] ; I also suspect they've got way more datacenter security than Bob's House of Colo and Boiled P-Nuts can manage....

Security through Obscurity (1)

metalmaster (1005171) | more than 3 years ago | (#36326684)

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.

It's not rocket science. (3, Informative)

gellenburg (61212) | more than 3 years ago | (#36326752)

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.

Bottom up (1)

Jaime2 (824950) | more than 3 years ago | (#36326764)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>