Infrastructure security is one of those things that falls prey to the typical ad-hoc growth of startups as it relates to security. You may start out small, but once the project starts growing you need to put a development environment online, as well as a staging environment. These tend to grow organically, with the specific needs of an organization. In addition to that, it’s sometimes necessary to toss the odd server or site online for other testing purposes. What isn’t always considered here, is the availability and accessibility of those resources.

Let’s take the example of a staging site. Frequently made Internet accessible for testing purposes, staging sites are a perfect example of the gap between typical web users and more curious, perhaps malicious ones. While typical users will go to x.com and completely interact with the application there, it is not outside the realm of possibility for a curious individual to try staging.x.com, a well-known scheme for staging sites. If this exists, it could reveal information to a potential attacker through verbose error messages or debug information. Besides simply making this public available, here are a couple other flaws I have seen on live staging sites.

  1. Having debug information available

    One startup allowed users browsing to their staging site to set a cookie that showed debug information. This debug information included exact SQL statements that were getting sent to the database. Having this information readily accessible could provide an attacker with the information needed to craft a custom attack.

  2. Not locking down all avenues

    After it was publicly disclosed, this same startup restricted access to that staging site using basic authentication. Verifying this out of curiosity, I tried to access it via HTTPS. To my surprise, I was not prompted for authentication.

Another common problem is that of putting a site online in the early stages of a startup. Maybe you need to demo the site to a potential investor or client. Maybe you have outsourced some testing. In any case, the one thing to remember is that if you open a port to the Internet, it’s not private. Port scans, especially for web servers, are extremely common. Combine that with the re-use of IP addresses (*cough*The Cloud*cough*) and your “private” site may be crawled by search engines within the hour. I’m sure most of you are familiar with the statistic that an unpatched XP system only lasts 20 minutes on the net without being found and compromised. If you do restrict access to this, here are a few things to remember.

  • Use strong passwords

    When encountered with an authentication prompt of an application that I’ve been hired to review, some of the first things I try are:

    1. admin/admin
    2. guest/guest
    3. demo/demo
    4. Names of, or relating to, the site or application
    5. And a few more…

    You may or may not be surprised with the number of “protected” sites I’ve been able to gain access to by applying this simple logic.

  • Use multiple layers, if possible

    A combination of authentication techniques is much preferred to only one. For example, usernames and passwords can be shared and frequently are. IP filters will help limit where access is allowed from and is a very effective method of restricting access.

  • Know your external attack surface

    Only by knowing what services or servers you have Internet accessible, can you adequately address the potential risk.

Maintaining infrastructure is not an easy task, but limiting access to exposed services can help limit the risk to an environment. Beyond that, keeping up-to-date on security patches, applying them in a reasonable time frame, and applying common sense security to system administration are all very important. When the environment becomes larger, the toolset necessary to manage these different aspects also becomes important.