This is a big problem I've noticed with startups. Stupid web vulns are EVERYWHERE.
I've reported so many serious web vulnerabilities to startups it isn't even funny (4-5 S14 YC batch alone). Account hijacks, XSS, SQLi. Everywhere.
If you are starting a startup (or writing any web software software), PLEASE read OWASP to at least get an idea of what types of issues can exist in Web Applications. Their top 10 is a good place to start (https://www.owasp.org/index.php/Top_10_2013-Top_10)
Startups optimize for fast growth and monetization with limited resources. Time spent securing a site is considered time wasted not improving SEO or user experience. It's already well known that people will sign up for an insecure site because they really don't care until something happens, and apologies after you've gotten traction (and their money and/or data) are less risky than potentially going live later than sooner.
In other words, not only do many startups not care, they would consider application security to be actively harmful.
This is of course assuming they know. Vulnerabilities may exist in libraries, packages and frameworks which are not known about, or in the case of PHP, old and unsafe practices are easier to copy and paste and tend to proliferate on tutorial and Q/A sites.
I know a particular startup that received millions of dollars in VC to start a payment processor. I RCE'd them in under 5 minutes and they remained vulnerable for more than a month after I reported it (this was within the last two months). This is frankly ridiculous and is a good extreme that shows why appsec being harmful is just not the case.
There is a difference between emphasizing only security, and building software with appropriate security measures in place.
You're misunderstanding the point. Pretend you're a cash-strapped startup, still financially in the red. You discover a security hole in your software. You have these choices on what to do today:
1) Spend the day implementing a new feature that will very likely improve revenue/traction
2) Spend the day doing preventative security measures to protect you from something that might only be a problem when you're actually making lots of money
You choose option #1. Choosing #2 is "harmful" to you and your investors.
This might be tough to answer due to survivorship bias, but can anyone name a startup, payment focused or otherwise, that failed because of a security vulnerability/vulnerabilities?
Would you consider DigiNotar a startup? It's certainly a famous example. Also, I happen to know of "RockYou", the facebook app people who were pretty much demolished not long after their massive account breach. Co-incidence or cause? They may be still alive but under new management.
You are ignoring the argument - a fundamental tenet of economics is there is a scarcity of resources - this is even more true with a startup, and, you need to make a decision as to where you will spend those incredibly limited resources.
The point being made is that in the beginning, the primary focus has to be getting traction with your potential customers.
Yes, you need to take make commercially reasonable efforts to secure your website, but, dedicating too much effort to prevent criminals from hacking you, to the point that you are not focussing on building your business, is counter productive. You may end up with a perfectly secure site that absolutely nobody is using - far better to have an incredibly popular site, that may have some security issues, that you can then lock down once you have the resources to do so.
But, this is about startups. CurrentC has millions and millions of dollars to spend - they have zero excuse for getting hacked.
Well, it depends on the cost of a breach, and the probability thereof. Those in turn depend on how you choose to calculate them.
If my company leaks our customer's e-mail addresses and plaintext passwords, how much cost is incurred? Is it a huge cost, because some of the customers have reused their e-mail password and they lose a bunch of personal data and accounts on dozens of sites? Or is it a small cost because they should have followed good security practices by using different passwords on different sites, so it's their fault they had more than an e-mail address leaked? Or is no cost incurred at all because hey, it's our customers not us who suffer from this. It's not like we're going to pay them any compensation!
Likewise, if there are hundreds of people scanning the web trying to exploit the security problem and it's easy to automatically detect, it's almost certain to get hit - on the other hand if it's difficult to find or exploit the risks may be lower. Of course, if you coded the bug in the first place, you might not be informed enough to assess this accurately.
The unfortunate truth is that the long-term costs to startups of compromised security is low because most people don't really care about it anyway. Target, Home Depot, Adobe, et al aren't seeing a massive loss of revenue due to being compromised.
There's a lot of press about incidents for a day or maybe three, it gets posted to HN and everyone has a <stuffy>very serious and very academic</stuffy> discussion about it, and within a week it's forgotten entirely.
People just don't care. It's nothing more than a temporary nuisance to most people. There aren't any consequences that seriously impacts anyone's life.
In the real world, startups are probably correct to focus first on new features and then patch security later. In an ideal world, that would be a mistake that would kill them.
The costs to Home Depot i would argue are not known.
The danger to a startup in the payments business that gets breached before they open their doors could in fact have a long-lasting effect.
It's nothing more than a temporary nuisance to most people. There aren't any consequences that seriously impacts anyone's life. My friend who is an FDA consultant who gets called when medical device manufacturing lines get shut down would very much disagree with that statement.
The thing about the Adobe breach is that it hurts the ecosystem. Folks who put an email and a password out there that happened to use that same password for a bank or other critical resource are now more vulnerable. And the trick with the Adobe thing is that most of the folks that I surveyed that have emails out there don't remember signing up.
People just don't care. And that is the crux of the problem.
The point is that the incentives are such that it's not necessarily rational for a young startup to ensure their product stays perfectly secure.
Startups are so precarious and need so much attention on other areas that for most types of startups, security holes are not the biggest existential threat.
And those incentives partially come from users who are more than happy to sign-up for a website someone threw together in a month without any thought about whether it's secure.
CurrentC is ramping up and isn't even taking real customers yet. There target user doesn't read Hacker news. This doesn't affect their business at all except for the slow down of trying to figure out the attack.
Security is one of those things you can't just toss in at the very end. In order to do it right, you really have to include security in your design from the ground up.
It seems like bullshit at first. The model of "secure software development" tends to culminate in notably different software designs. For instance, a proper payments service would have security at its forefront. A naive one might process all requests that come its way; OTOH, a secure payments service might choose to process only those requests that seem trustworthy (does the request look suspicious? does the requester have a history of abuse? etc.).
Security is something that will fundamentally shape the architecture and design of your system. You can't just go back and make these types of gigantic changes.
I guess it all comes down to whether you are willing to accrue technical debt by not designing securely from day 1. If you get funded, you can go back and change things, but (in practice) you can only change so much.
Writing a blog post about "fixing security problems" will not attract new customers for 99.99% of startups, unless security is a core value prop for your product (Stripe, for example).
Your average Airbnb user does not read Hacker News, waiting to signup for security conscious services.
More so, writing a blog post about how you spent all day preventing XSS, SQLIs and similar vectors wouldn't even get to the top of Hacker News because these are mundane and basic problems with simple fixes. The reaction by a technical audience like HN would a simple "congrats...?" pat on the back.
There is also the consideration that you will never know your security was insufficient until the day you do.
You can take reasonable efforts to secure your site. You can follow the best practices that you find. You may even have the best programmers money can buy.
But, in the end, until you are caught with your pants down, you may have no idea that you are actually vulnerable.
The startup problem is that they need a good product to attract users. If they have no users, poor security doesn't affect many people and can be tolerated. So all their efforts go into improving the product from an end-user standpoint, and security is left for a time when there are enough users to justify.
This is true, and you can easily view this as a form of abuse against userbases: your data will be exploited and not properly secured while a company profits and you suffer the consequences.
Worse than stupid web vulnerabilities of the sort you mention, but many startups don't even practice a modicum of best practices.
My coworkers recently tried a new New York-based food delivery startup and found that their auth wasn't even HTTPS. Forget XSS or SQLI, this is basically propping your front door wide open with a sign "please take whatever you want".
Worst part is when we emailed them they tried defending the use of HTTP for auth. Took a bit of convincing to get them to take us seriously.
There are a lot of startups out there whose security practices aren't just deficient, they're straight up amateur hour.
I think I know the food delivery service you're talking about (free delivery, no tips). They use Stripe as their processing backend, and they said that their connection to Stripe is over HTTPS, however, I gave up trying to explain that of the initial transmission to their servers is unencrypted, it doesn't matter.
I thought about reporting this to Stripe, but I don't know if that is an appropriate thing to do.
I still gave them a try, but I generated a virtual card number to use.
I had the same discussion with a new parking management company at my apartment complex. I told them I wasn't going to put confidential information on a site that doesn't use https, and they tried to tell me that they used a third party for authentication so my data wasn't stored there... I don't even know how to explain to them.
"You're telling me that once you have my information you throw it away immediately. That's great, but you are still forcing me to give you my information in the first place by standing in the middle of the street yelling it through a loud hailer".
If the form is POSTed directly to stripe (which is the recommended usage), your info is never seen by a third party. The site in question would only potentially store a token. Are you sure this wasn't the case?
If the form itself was delivered over http then it doesn't matter. An attacker could easily change the POST address to something else. And how could you even tell? Browsers don't display the URL that a submit button is going to POST to...
Of course if an attacker can MitM any HTTP web page on a site (ie. if a site is not all SSL) then it really doesn't matter if they serve the form over HTTPS because the attacker can set up another form over HTTP and the victim will be none the wiser.
And then there's the possibility of XSS in which case neither lack of MitM access or use of HTTPS will be sufficient protection.
This is true. You'd have to look for a script tag with src of https://checkout.stripe.com/checkout.js. Alternatively, you could try to follow the onclick handler for the button (Event Listeners in Chrome).
The reason it's amateur hour is security is an expertise and it's so easy for everyone else to screw it up that that's basically the default.
I hope one day tptacek or someone will distill web application security down to a really simple checklist that even the dumbest of developers can refer to so that at least we make less of the stupid mistakes.
I do like that link but it leaves it to us, the people who don't know or care deeply about this stuff, to study the problems further and come up with our own solutions. Ideally we'd be given answers instead of just a starting point for additional research.
It's hard to invest yourself in something you're not interested in.
It's also difficult to know where to begin when there are so many "unknown-unknowns."
That in mind: Don't try to be an expert. Start with awareness.
1. Don't roll your own security solutions. Leave it to the experts (i.e. a mature web framework).
2. Learn the best practices for your web framework of choice.[^1]
3. Have a basic understanding of the attacks.
You'll find security to be a far less daunting challenge when you chip away at the "unknown-unknowns."
Even if they just become "known-unknowns," you'll then know where to focus your attention and be better able to ask the right questions.
Why should we treat security like it's something we can google our way through in an afternoon? That's why sites and servers are compromised in record numbers every week.
Perhaps you should be less defensive about the incredibly low amount of knowledge/talent/intelligence required to put together many web or mobile apps?
If you read the rest of that sentence I included myself in that group since when it comes to security I've not many clues.
Well, it's arguably rational, if perhaps unethical.
Any time not spent working on security can be spent working on the startup, and presumably increasing the chances they get used. Most startups die because they don't get used, not because they weren't secure enough.
Because they're a VC-funded startup that seems to have a pretty good grasp of marketing and will no doubt attract users even if their security apparatus is a cruel joke.
Is there a reason you're not naming them? You disclosed it responsibly, and presumably they have now fixed it. I don't understand the rationale for _not_ naming them.
No particular reason - I hadn't decided if I wanted to name and shame them directly (though if you really wanted to find out, there aren't that many food delivery startups in NYC...), and in the absence of intent to name and shame, my default inclination is to not.
The issue was reported a while back, and after convincing them that, no, HTTP auth is a terrible idea, they did switch to HTTPS. This is not an open vulnerability.
Hint: tcas seems to be referring to the same company.
For all we know, he disclosed it 4 days ago. Merely disclosing a vuln doesn't mean an appropriate amount of time has passed where it could be patched. Remember, real users' info is at stake.
Fair point. I got the impression it had been fixed, but that may have been wrong. Hopefully, once it is fixed, they will be named, otherwise I don't see how things can ever get better.
While I totally agree this is important to know, CurrentC isn't a startup, it's a new program from an established company. These guys have made themselves a target, and it is very likely that no amount of good security would leave them totally invulnerable. The community's desire to make CurrentC look foolish is very high.
I suspect the point was that this was this program comes from established companies that have no place making the same mistakes that startups make, or for the same reasons.
I'm reminded of this quote from Steve Yegge's platform rant[1]
... I'll argue that Accessibility is actually more
important than Security because dialing Accessibility
to zero means you have no product at all, whereas dialing
Security to zero can still get you a reasonably
successful product such as the Playstation Network.
Granting one understands, generally, how these vulnerabilities work (read up on that site) - what would then be a good next step? Oftentimes these small companies are focused on getting the data-flow to work and have not coded in all the edge cases. What are reasonable (easy would be nice too) steps one can take to help mitigate the most vulnerable edge cases? Or is it something that should just immediately be hired out just before you want to go live?
Best advice I could provide if the devs aren't too knowledgeable on application security, is use a framework where possible, know where it's likely to fail you and focus there and then make sure you stay on top of patching all your framework components to catch vulns in that layer
So for example rails handles basic things like SQL injection, XSS in standard forms fine, then you can use devise or similar for authentication and get a reasonable level of security. What you're left with are areas like authorisation which tends to be app. specific so still requires work, but you probably have less to focus on.
Also watch out for what I'd call "dangerous" functionality, things like file uploads or user generated content where you want users to enter HTML tags but still avoid XSS. Things like that need specific consideration to avoid common security issues.
Of course if you're doing something that will attract real bad guys (anything to do with payments, anything to do with bitcoin, anything to do with Intellectual property management etc) then I'd strongly recommend getting an app security person on staff as soon as you can 'cause you will get attacked probably sooner rather than later...
This is doubly true for PHP. Upgrading an (already likely secure) database class in a framework that uses PDO is a lot easier than changing a thousand calls to mysql_query after the fact. You don't have to worry about wrapping every echoed variable in htmlspecialchars() when you're already using twig. PHP developers keep running afoul of what are already mostly solved problems. Imposing a bit of structure and modularity now will make responses to issues easier later.
Although the downsides of this are the possible vulnerabilities in the framework itself (as well as the potential learning curve and lock-in) there are likely to be more people using, and finding, those vulnerabilities than would be in your quick-and-dirty handrolled quasiframework. Even if the latter is more fun.
And if you're on shared hosting... umm... you should probably reconsider that. If that's not likely to happen soon, then database-driven sessions, regular backups and SSL are a must.
I think OWASP does a good job explaining this stuff if you know how to build a web-app, you should be able to understand the vulns (they give PoC code and examples).
OWASP could be doing a lot more but their PoC and descriptions are pretty good.
Your next step is to think about how you will be preventing them. An example, If you are writing a PHP site without a framework, how will you generate, validate, and store CSRF tokens? How will you filter output? How will you architect your web-app to prevent SQLi?
Security consulting is ridiculously expensive and I've seen companies pay a lot to get told very little. If you want to run security concerns by me, I am free to contact.
The big problem with tech startups is that they are by and large technologically clueless. Security is just one of the more obvious symptoms.
It's always been the case that a lot of tech startups are started by "idea people" who just may or may not get lucky with their choice of technical co-founder or first hire, but I get the feeling it's been getting a lot worse the past few years. You can go to startup meetups and have a hard time finding anyone with half a clue about the actual technology.
I've reported so many serious web vulnerabilities to startups it isn't even funny (4-5 S14 YC batch alone). Account hijacks, XSS, SQLi. Everywhere.
If you are starting a startup (or writing any web software software), PLEASE read OWASP to at least get an idea of what types of issues can exist in Web Applications. Their top 10 is a good place to start (https://www.owasp.org/index.php/Top_10_2013-Top_10)