Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Databases Privacy Security

Ask Slashdot: Verifying Security of a Hosted Site? 182

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

Ask Slashdot: Verifying Security of a Hosted Site?

Comments Filter:
  • contract some penetration tester like the one from offensivesecurity

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

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

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

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

      That should keep you busy for a little bit.

      • 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

        • 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 g

        • Do PCI and SAS70 issue certificates that they find your site to be secure? If so that could prove invaluable CYA material in case something does go wrong after all, as you have at least something to prove you tried, and that that you were up to "industry standard".

          • Was Sony's PSN infrastructure PCI or SAS70 compliant? Is it going to cost them any less if they are?

          • SAS70 has nothing to do with being secure, it's really just a "report on controls placed in operation and tests of operating effectiveness". It's not a checklist audit. What that exactly means varies from company to company (every company's procedures vary) and the firm performing it.

        • by tepples ( 727027 )

          Ensure your site doesn't have any SQL injection vulnerabilities.

          I use parameterized statements where I can, and even in those two cases where parameterized statements are more trouble than they're worth [pineight.com], I do my best to minimize those parts where I have to do manual escaping, and I test those places with "Bobby Tables" style patterns to make sure single quote characters are handled properly. What tools help for finding places that I may have missed?

          Encrypt credit card numbers (if you need to store them; preferably you don't).

          Ordinarily, I don't. But if I encrypt something in a database, what are best practices to store the decryption keys?

          Only allow ports 80/443 from the world


    • by Z00L00K ( 682162 )

      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

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

    • Or get it done free: antagonize Anonymous.

    • by grcumb ( 781340 )

      contract some penetration tester like the one from offensivesecurity

      Why pay?

      Just buy a domain called iheartsony.com (or similar), load it up with insults against Vladimir Putin and every member of the Chinese politburo and top it off with gay porn images with the head of the king of Thailand 'shopped onto the bodies.

      If your server is still standing after a week, it's secure....

      (NOTE: This does not guarantee that you will still be standing at the end of the week.)

  • owasp (Score:4, Informative)

    by badran ( 973386 ) on Thursday June 02, 2011 @05:41PM (#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.

  • 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

    • by mysidia ( 191772 ) *

      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

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

      • 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

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

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

        Switching SQL implementation will be easier to manage if you only have to port the SQL procedures instead of having to search all the SQL queries in your application for the DB specific quirks.

    • by Yvanhoe ( 564877 )
      Sanitize all the user entered data. Expect Bobby Tables.
  • 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.

    • by mysidia ( 191772 ) *

      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 incl

      • by Anonymous Coward

        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"

        • by mclearn ( 86140 )

          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.


          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

  • 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 reaso
  • ...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 th

  • by Anonymous Coward

    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!
  • Make them tell you. (Score:5, Informative)

    by RichardJenkins ( 1362463 ) on Thursday June 02, 2011 @06:00PM (#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 ;)

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


  • by Anonymous Coward

    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 yo

    • 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 [pineight.com]. For the example, the right side of SQL operator IN is a 1-column table:

      SELECT username, joinDate FROM dxt_users
      WHERE username IN ('filbert', 'bluebear', 'chief')

      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

  • If you want I can offer you a web site security audit (specialized company), for free.
  • 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

  • Not to belabour the obvious, but why not start here:

    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.

  • 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. De
    • by wbean ( 222522 )
      Joomla may be secure but look out for the third-party components. I've been upgrading a bunch of them to Joomla 1.6 and I can't tell you how many I've found to be open to sql injection.
  • MySQL has appalling code quality, and a critical piece of proprietary technology. Use PostgreSQL: safer, more standards-compliant, more robust, totally free, more scaleable.

    • by tepples ( 727027 )
      If I'm tired of MySQL, how do I convince more web hosting companies to offer PostgreSQL on shared hosting or low-tier VPS?
      • It's hard b/c it seems that for many companies they perceive (maybe accurately) Postgres as more expensive to operate in a shared environment than MySQL. I believe there's been a fair bit of work to fix this over the last few years in PG, but it's still a problem in the field. Plus the demand from devs for PG is much lower than MySQL (kind of chicken and egg).

        I've found support from providers at all levels for PG. My personal web host is www.geekisp.com and they do a great job giving me the tools I want, in

        • by leandrod ( 17766 )

          Can you expand on why would PostgreSQL be more expensive to operate? My experience is ðe opposite.

          • This is second hand info but the providers I've talked with over the years say that partitioning users, databases, rights, resources, etc in MySQL is more built from the ground up for a co-sharing environment, whereas PG isn't as easy to setup and manage in that configuration. It can be done for sure (geekisp.com does it well) but maybe it requires more expertise or care/feeding or something. I don't know, but that's what I've been told. HTH

            • by leandrod ( 17766 )

              Sounds like a poor excuse for incompetence Postgres is actually simpler to do properly.

              • We are talking about MySQL vs Postgres -- isn't that the general rule between the two for almost everything? The fact is that it's much easier to find shared hosting on the cheap that supports MySQL than PG. I myself never use MySQL -- agreeing with you that Postgres is better for everything I need, at least afaik.

      • by leandrod ( 17766 )

        Demand, demand, demand. It is ðe demand!

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

    • No no, use it. Register a domain like SonySomething.com. Put some Sony-related content on the first page and your database (filled with fake data) in the back.

      It will take a while for Sony to take your domain from your for cybersquatting. If your content remains safe the whole time, your database is probably secure. If you find the content downloadable from Lulzsec, you have more work to do.

  • by nuckfuts ( 690967 ) on Thursday June 02, 2011 @06:54PM (#36326184)
    Post some inflammatory content concerning Anonymous. Include boasts about being invulnerable to retaliation.
    • 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 yo

  • by pushf popf ( 741049 ) on Thursday June 02, 2011 @07:23PM (#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.

  • by Pop69 ( 700500 )
    Should always be posted when mentioning databases

    http://xkcd.com/327/ [xkcd.com]
  • 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 eventual
  • by gellenburg ( 61212 ) <george@ellenburg.org> on Thursday June 02, 2011 @08:15PM (#36326752) Homepage Journal

    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.

    • by Trolan ( 42526 )

      Turn register globals off in PHP. Use safe mode.

      Yes on the first, be aware on the second. It's been deprecated, as noted at http://php.net/manual/en/features.safe-mode.php [php.net] Safe mode is really a band-aid on an open wound. mod_security, suhosin, proper file ACLs, etc. are all likely better options for dealing with the sorts of things safe_mode buys you, and all but suhosin are applicable to anything that isn't PHP.

      Aside from that, a good list. The one thing that can't be said enough: NEVER TRUST CLIENT INPUT. VERIFY, VERIFY, VERIFY.

    • by Shoten ( 260439 )

      You know that just about none of this information is at all helpful or relevant, right? It's a hosted solution; he has no control over any of this. Furthermore, he's asking about database security from the perspective of the hosting provider; 'sanitize all input' isn't something they can do for him. And finally, if your PHP hardening advice consists of "Turn register globals off in PHP. Use safe mode," I really have to wonder if you are just quoting something you heard in a seminar once during your 3-ye

  • 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.
  • 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.sh [nsa.gov]
  • 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 w

  • 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

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

  • 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 archite

  • 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 a

Houston, Tranquillity Base here. The Eagle has landed. -- Neil Armstrong