11 ms·

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

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 https://www.owasp.org/index.php/Top_10_2013-Top_10)

wh-uws 12y ago
Mcx is a publicly traded company http://en.m.wikipedia.org/wiki/Multi_Commodity_Exchange http://en.m.wikipedia.org/wiki/Multi_Commodity_Exchange
- smackfu 12y ago
  Different MCX here: https://en.wikipedia.org/wiki/Merchant_Customer_Exchange https://en.wikipedia.org/wiki/Merchant_Customer_Exchange
LesZedCB 12y ago
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.
- steakejjs 12y ago
  I don't see it as any different than "it's own thing". CurrentC is a new product built from scratch essentially. 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
  - ska 12y ago
    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.
potatolicious 12y ago
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.
- onedev 12y ago
  Why even waste your time with them if they won't listen?
  - potatolicious 12y ago
    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. In other words, for their users, not them.
- tcas 12y ago
  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.
  - cortesoft 12y ago
    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.
toufka 12y ago
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?
- steakejjs 12y ago
  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.
- raesene4 12y ago
  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...
ProAm 12y ago
"Move fast and break things" then just look for an exit and it will be someone else's problem.
krapp 12y ago
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.
- king_jester 12y ago
  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.
- steakejjs 12y ago
  Considering AppSec harmful is ridiculous. 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.
  - fragsworth 12y ago
    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.
akincisor 12y ago
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. 1: https://plus.google.com/+RipRowan/posts/eVeouesvaVX https://plus.google.com/+RipRowan/posts/eVeouesvaVX
freshflowers 12y ago
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. Feels like we are regressing back to 1999.
borski 12y ago
We offer a free startup plan at https://www.tinfoilsecurity.com https://www.tinfoilsecurity.com to help with this exact problem.

wh-uws 12y ago

Mcx is a publicly traded company http://en.m.wikipedia.org/wiki/Multi_Commodity_Exchange http://en.m.wikipedia.org/wiki/Multi_Commodity_Exchange

smackfu 12y ago
Different MCX here: https://en.wikipedia.org/wiki/Merchant_Customer_Exchange https://en.wikipedia.org/wiki/Merchant_Customer_Exchange

LesZedCB 12y ago

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.

steakejjs 12y ago
I don't see it as any different than "it's own thing". CurrentC is a new product built from scratch essentially. 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
- ska 12y ago
  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.

potatolicious 12y ago

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.

onedev 12y ago
Why even waste your time with them if they won't listen?
- potatolicious 12y ago
  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. In other words, for their users, not them.
tcas 12y ago
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.
- cortesoft 12y ago
  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.

toufka 12y ago

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?

steakejjs 12y ago
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.
raesene4 12y ago
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...

ProAm 12y ago

"Move fast and break things" then just look for an exit and it will be someone else's problem.

krapp 12y ago

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.

king_jester 12y ago
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.
steakejjs 12y ago
Considering AppSec harmful is ridiculous. 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.
- fragsworth 12y ago
  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.

akincisor 12y ago

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. 1: https://plus.google.com/+RipRowan/posts/eVeouesvaVX https://plus.google.com/+RipRowan/posts/eVeouesvaVX

freshflowers 12y ago

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. Feels like we are regressing back to 1999.

borski 12y ago

We offer a free startup plan at https://www.tinfoilsecurity.com https://www.tinfoilsecurity.com to help with this exact problem.