Startup Security

At my presentation last night on web application security, I demo’ed a SQL Injectable Ruby on Rails application.

One of the questions that resulted from that, somewhat in shock, was how long this bug had existed in a public open-source project. Referring back to the original discoverer, it seems this bug has persisted through the lifetime of the Rails project (i.e. Rails 1.2 and 2.0 were vulnerable as well).

Looking back in time, we can actually see the March 2005 commit where the limit functionality was added to the MySQL adapter. If you have javascript enabled, I’ve pulled out the relevant bits below. The interesting thing to notice is that some sanitization is performed if both a limit and offset parameter exist, but if only the limit parameter exists…no sanitization is done.

There is some good discussion about how to exploit this :limit bug on the Ruby on Rails Security Project blog.

Finally, we can see where this SQL Injection was fixed earlier this year. And if you’re curious, here’s what sanitize_limit does.

That being said, I suppose we could enter into the old argument of whether closed or open-source is a more secure model. But realistically, bugs exist in any project – it’s the process and integration of security into that specific project’s development that determine it’s resulting security and risk profile.

I’ve giving a talk tomorrow at a Seattle co-working space, StartPad, about startups and security. You can find more information and register for the event on the StartPad website: Hacking and Compliance in a Web 2.0 World.

If you’re in Seattle and want to learn about web application security, stop on by!

What: StartPad Countdown 2 — Startup Security: Hacking and Compliance in a Web 2.0 World
Who: Damon Cortesi
When: 6:00 pm, Tuesday November 25th, 2008
Where: StartPad offices — 811 First Avenue, Suite 480, Seattle, WA 98104
Cost: Free!

Pizza and drinks will be served.

One of the things any organization should be prepared for is a potential “incident”. The definition of incident can vary widely, but it can be anything from an unauthorized internal data access to a “hacker” breaking in.

Monitoring is a big part of detecting incidents and perhaps a post for another day. If you do suspect somebody has unauthorized access to one of your systems, though, there are certain steps that should be taken. I recently came across a good cheat sheet for server administrators that should be kept handy in the event of an incident. There’s also a cheatsheet for those responding to potential incidents.

I came across these cheatsheets over on the SANS Internet Storm Center blog, a good feed to have in your reader to keep up-to-date on the latest security incidents around the net.

Enjoy, and hopefully you won’t need to reach for these in the near future. But they are good to have on hand!

ZoneAlarm Pro, a personal firewall, is free today. Details at zonealarm.com.

Personally, I’m a Mac guy and both OS X and XP/Vista have a firewall built in, but ZoneAlarm does offer some better granularity and access control. When I was a Windows guy, though, my personal favorite was Sunbelt Personal Firewall (formerly Kerio, formerly Tiny). Yes, I am anal retentive enough to restrict my browsers outbound access to ports 80 and 443…

On the Mac, I do like Little Snitch for outbound access control and monitoring.

There’s been quite a bit of discussion recently in the security community regarding partial disclosure due to that DNS bug and the zomg my camera is on bug. What I’d like to do briefly is take a step back and look at the startup community and reporting vulnerability issues to small companies that don’t have the resources and experience of large enterprise. Why? Because they may be the next enterprise, you never know.

Over the course of the past few months, as I’ve been involved with my own startup, I’ve been paying a lot more attention to that industry. With a quick and dirty development model, it’s often easy for devs to overlook security. Although some frameworks address a lot of the usual concerns (SQL Injection, XSS), they are susceptible as well.

Let’s take a look at a couple examples that enterprises such as Microsoft and Google now understand, that small development teams might not.

1. Put an email address on your website.

Yes. I’m serious.

I’ve come across several issues on startup sites recently and being the responsible security researcher that I am, have wanted to report them. Spending a half-hour spidering the site trying to find a single contact email is a lose-lose situation. I’m either going to discard the bug and the site will remain vulnerable, or somebody else will publicly disclose it and the typical ‘hair on fire’ scenario will ensure.

2. Respond to the email.

If you don’t respond, I have no clue if you’re addressing the issue. A timeline for a potential fix might also be nice, but not always necessary.

Additionally, security researchers generally like the cred associated with finding a bug (ego boost and resumé builder, you know?). So if you do make an update and have some release notes, why not thank the researcher for preventing your hair from catching on fire more than it already is?

3. Don’t write off the security guy.

6 years ago, there was a large back-and-forth on a Mozilla bug. This year, it was confirmed as a vulnerability known as clickjacking. That Mozilla thread is a pretty classic example of the security disclosure process. If a security researcher is writing to you to report a vulnerability, engage in conversation to understand the concern. Yes, we do sometimes get a little paranoid. But if we emailed you, we’re really just trying to help.

4. Don’t sue the security guy (aka have a disclosure policy).

One reason that I frequently hold off on reporting bugs I may come across is that I can’t find a disclosure policy on the site. As an example, both eBay and Microsoft allow for easy reporting of security vulnerabilities. Most sites, however, don’t and it has happened in the past where a security report has been misconstrued as “hacking”. Providing some assurance that this sort of action won’t be taken or an easy means to report vulnerabilities will open up the communication channel necessary.

Hopefully these short notes will help small companies become more open and willing to accept security bugs from external researchers. Occasionally, we come across issues in the course of our normal web activity and wish to report them. Having a published and easy means of doing this is important in allowing for this communication.

Far back in the days of GeoCities and Tripod, JavaScript was a cool little scripting language you could use to make some awesome rollovers on your links and take your site to the next level beyond the blink tag. Today, JavaScript drives what many call Web 2.0 – a user experience that has made it possible to put desktop applications (email, office) on the web.

The evolution of JavaScript and its place in security perfectly parallels the transition from server-side security to client-side security.

~History~

Before network firewalls were commonplace, the juiciest targets to go after were servers. In what is now unthinkable, it was common for systems to be deployed directly on the Internet with no firewall whatsoever. This is part of the reason that Code Red, Nimda, and Slammer were so successful. The opposite is true now. Network firewalls are commonplace, Windows XP has the firewall turned on by default, and Server 2008 will be the first Microsoft Server OS to be deployed with the firewall enabled by default. As such, attackers moved on to the next target – client workstations and the primary way users interact on them.

~/History~

So why should you, as a startup, care about all this? Two reasons.

1. Protect your site from common attacks
2. Protect yourself from being a victim

To address the first one, there’s a common attack known as Cross-Site Request Forgery. I’ll get into it in more detail in another post, but effectively it allows one site to take action on another if that target site has not put effective controls in place. A common mitigation is ensuring that all data modification methods occur via POST requests (per HTTP standard). However, if you don’t have tokens associated with those POST requests, another site could utilize javascript to craft and submit fake POST requests to take actions on a logged-in users behalf. Does your site have a “remember me” checkbox? Do user sessions not time out? This could be a problem for you. This issue has been widely known for at least four years (Chris Shiflett on CSRF), but it’s only recently been gaining a lot of attention. I’m surprised more frameworks don’t have protection for this enabled by default, but it could likely impact development testing. The general approach to fixing this is by utilizing some sort of server-generated token that’s inserted as a hidden form field and verified on user submittal.

To address the second, an example is necessary. JavaScript, for the most part, is fairly essential to a number of sites that you may visit on a regular basis. The danger however, is malicious JavaScript that may get executed without you even knowing it. That script could be on that site and trying to take action on a different site, or sourced from a remote site altogether. Take, for example, poor David Airey who lost his domain due to a GMail CSRF vulnerability. The basics behind the attack are as such: At one point, David visited a page that had a malicious JavaScript. That script posted back to his GMail account, reconfiguring it so the attacker could hijack emails. That reconfiguration including forwarding and deleting all domain-related emails. Once David went on vacation, the attacker went to work and David lost his domain.

So how can you protect against this second attack? I personally make use of the Firefox extension NoScript. This handy extension prevents JavaScript code from automatically executing when you visit a web page, unless you’ve previously whitelisted that site. While it can be a little annoying, it’s much better than unknown JavaScript executing in the context of my browsers…where I spend a good majority of my day.

Dove-tailing off my previous post about the Basics of Analyzing Web Site Security, there are some very common places in web applications that I come across typical issues. These are the places I will look at first on a web app to get a general idea of the rest of the site security.

• Search Forms

  Search forms generally re-display the search term entered by the user. These terms are quite frequently not properly encoded, either, leading to Cross-Site Scripting (XSS) attacks.

• Jobs and Events

  Jobs and Events pages frequently utilize a database behind the scenes to manage job postings and event listings. Further, they’re usually pretty easy to check as they have the job or event id in the URL for page rank, etc. I’ll commonly look for these for easy injection vectors.

• Cookies

  Utilizing the fantastic Web Dev extension, I’ll take a quick look at the cookies. If I see anything more than a session ID, I’ll start modifying and manipulating the cookies to verify that server-side checks are in place. Cookies can also frequently lead to XSS.

• Hidden Form Fields

  If there’s a contact page with a form, the first thing I do is look for hidden form fields to see what parameters the web developers might have thought that a user wouldn’t see by putting them in a “hidden” field. I’ve come across everything from spam gateways to arbitrary file access due to simple issues like this.

• Typical Directory Structures

  Finally, I’ll commonly poke around in typical directory structures to see if I get lucky. Things like /admin/, /logs/, and /config/, among others, often are not intended for public consumption or linked to, but are present on the site.

There you go – those are generally the first places I look if I need to take a quick look at a web site. Beyond that, I start digging into more complex input locations within the application, logic happening behind the scenes, and potential user authorization issues.

Since Mike recently linked here from his PCI Blog (Cloud computing security and PCI), let’s take a brief look at what PCI means for a startup.

PCI Compliance

PCI Compliance has probably been one of the strongest driving factors of security compliance in the US in recent years, particularly for retailers. So what is it? PCI stands for Payment Card Industry and the PCI Data Security Standard is an accepted standard among the payment brands (Visa, MasterCard, Amex, Discover, etc) that defines a set of 12 requirements that merchants who handle cardholder data must be compliant with. *you can breathe now* With that broad statement, there are a few things to point out.

Cardholder Data

Straight from the PCI website…

Cardholder data is defined as the primary account number (“PAN,” or credit card number) and other data obtained as part of a payment transaction, including the following data elements:

• PAN
• Cardholder Name
• Expiration Date
• Service Code
• Sensitive Authentication Data: (1) full magnetic stripe data, (2) CAV2/CVC2/CVV2/CID, and (3) PINs/PIN blocks)

This effectively means that if you store, process, or transmit a credit card number, alone or in combination with the data listed above, you are subject to PCI DSS. I should note, however, that there are different requirements based on your size and processing volume and you should contact your acquirer, payment brand, or local Qualified Security Assessor (QSA) to determine your PCI DSS validation requirements.

The Requirements

So, 12 requirements, huh? Yup. Each with several sub-requirements, too. While you can read the details on the PCI DSS site (click “Download the Specification”), I think it’s more important for startups to realize that there are very specific requirements surrounding the handling of cardholder data and to consider those requirements when extending into such areas as e-commerce. Ultimately the goal is to manage the risk of storing cardholder data by means of network segregation, data encryption, audit logging, policy and security testing (among others). Options are also available for outsourcing credit card transactions, which can relieve the strain of PCI compliance for a startup.

One More Thing

Are you a software developer building a payment application but not actually storing cardholder data yourself? You still need to be aware of PCI and the Payment Application Data Security Standard. This ties in to my previous post about third-party components and is PCI’s attempt to ensure safe handling of credit card data for payment applications created by software vendors.

One of my favorite “free” HTTP proxies (because it’s under active development) is the Burp Suite. It seems the author(s?) is hard at work on a new version and is promoting it with a Month of Burp Pr0n, a post every day on the new features that are coming in version 1.2. It looks like the new version will have active scanning and target filtering, which have definitely been on my personal wishlist.

One of my favorite features of the tool is Burp Intruder. In instances where authorization bypass is a possibility, or incrementing integers are utilized for record id’s, Intruder is a very handy way of brute-forcing your access to data you may not have authorization for. As an example, I just used Intruder to increment through a few hundred id’s on an application to gain access to and analyze data I shouldn’t have access to.

Burp is great and in addition to the features mentioned above, it looks like it may also have passive scanning like ratproxy by Google. Exciting stuff!

A quick note on this Sunday evening regarding third-party components.

Your site is only as secure as the software you install.

I’ll be posting some more info regarding some work I’ve done in this area recently, but I did want to make a quick post about the security of third-party components.

When you download that plugin or code written by somebody else, are you doing a sanity check to make sure it’s secure? Here are a few quick things to think about in order to identify the attack surface.

• Does it write to disk?
• Does it communicate with the database?
• Does it interact with the user?

Why should you be asking these questions? To determine if it protects against the following attacks.

• Can I modify the file that it reads/writes to?
• Does it protect against SQL Injection?
• Does it sanitize or validate input?

Security should definitely be a concern when installing any third-party components or plugins on your site. While it’s difficult to verify the security of external code, you can at least do a quick profile of it and understand what your primary risks are as noted above. A perfect example is the recent WP Comment Remix Security Bulletin – installation of that plugin allowed for both SQL Injection and Cross-Site Scripting.