Startup Security

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.

So as part of my recent Life Reboot, I’ve been getting pretty deeply embedded in the (Seattle) Startup world. One of the fun things is completely changing gears after being embedded in the security world for so long and digging in to a new group of people and technology. This means, of course, that I’ve been paying much more attention to the little startups that crop up all over the place.

And what I’m finding is a little disappointing.

Perhaps I’ve become a little jaded in the past few years as a security consultant. Working with some large organizations where people usually “get” security makes most (yes, there is definitely still a decent level of feedback) conversations surrounding security fairly straightforward. Not only that, but large organizations generally have the benefit of staff that understand security risks and can effectively merge them with the desires of the business to reach a reasonable solution. But let’s take a brief tour over what I’ve come across recently. (Names left out to protect the innocent.)

Exhibit 1 – A random startup (Company A) allows signups on its web page. As with any new service, I’m sure reporters would have liked to have seen who was signing up from what companies, particularly in order to validate Company A’s claims of rampant success and signups. Company A, unfortunately, would display a users’ email address on the confirmation signup page. That confirmation signup page had a parameter that could be incremented up or down to reveal email addresses of anybody that signed up.

Class: Basic design flaw, forced browsing.
Status: Fixed, within a half-hour of reporting.

Exhibit 2 – Another random startup (Company B) has a new service that claims to solve some of your email woes. One of the features of this service is that you can subscribe to RSS feeds of your Inbox. Unauthenticated RSS feeds. Yes, yes, there’s a SHA-256 hash in the URL, but both Google Reader and Bloglines are searchable, not to mention the potential for referral sniffing or just plain information leakage issues.

Class: Design flaw, lack of authentication.
Status: Removed, within a half-hour of reporting. Put back into place using HTTPS. Authentication still not used.

Exhibit 3 – Company C has a sweet iPhone app. They also have a web page that is somewhat integrated into the application. That web page is vulnerable to SQL Injection.

Class: Input validation, SQL Injection.
Status: Reported, twice. No response. Depression ensues.

Exhibit 4 – Company D releases an update to their product and is highly regarded as their service no longer requires the installation of an additional component. Unfortunately, the new feature that permits for that is Cross-Site Scriptable.

Class: Input validation, Cross-Site Scripting.
Status: Reported on October 13. Waiting.

I guess what depresses me is that some of these are pretty basic issues. With all of these problems, I came across them within 5 minutes of using the application. I suppose this post is a plea to the startup’s of the world…

Please, if you aren’t familiar with security, take the time to either talk to somebody that is or bring in a security person for even just half a day to take a look at your product. If nothing else, it’s one less fire that you’ll have to put out. You can even contact me directly if you’re not sure what questions to ask, although I’ll probably put a post up about that at some point.

Granted, the statement above applies to everybody as even Russ McRee frequently points out on his HolisticInfoSec blog, many other organizations struggle with basic security flaws regardless of their size or status.