Hacker News Reader

Comment by potatolicious | Hacker News Reader

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.

View on HN

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...

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).

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.

At the time I had to enter my card number it wasn't the case.

Just checked again and when I go to the card number screen it is now HTTPS.

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.

That's one of the goals of owasp linked in the above post.

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.

[1]: For example, http://guides.rubyonrails.org/security.html

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.

Imagine if we asked doctors for hints.

Unfortunately the OWASP website is a mess... took me a while to even find the relevant articles on web app security from the landing page.

> even the dumbest of developers

Don't you think it's time to get off your high horse?

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.

Why even waste your time with them if they won't listen?

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.

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.

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.

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.

Reply on news.ycombinator.com