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.