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)
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.
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.
Both are bad. You can maybe prevent yourself from having to make this decision by being security aware from day0
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.
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.
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.
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.
Your average web startup that's providing jazzy ringtones and a new poke app, sure, should leave security for last.
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.
We make mistakes. Some of them are stupid.
Option 3) Spend the day fixing the security problem, then write a transparent post about it thus improving revenue/traction with new/existing users.
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.
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.
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.
Security and moving fast are often at odds.
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.
In other words, for their users, not them.
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.
And then there's the possibility of XSS in which case neither lack of MitM access or use of HTTPS will be sufficient protection.
Just checked again and when I go to the card number screen it is now HTTPS.
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.
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.
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.
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.
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.
[1]: For example, http://guides.rubyonrails.org/security.html
Imagine if we asked doctors for hints.
Don't you think it's time to get off your high horse?
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.
Building things from scratch means you end up having to worry about how your code is organized to make good secure programming decisions.
I have no desire to make CurrentC look foolish, only to help people write better software which they currently aren't doing
... 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.
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.
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...
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.
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.
Feels like we are regressing back to 1999.