Hacker News Reader

Comment by jackowayed | Hacker News Reader

The demo app is not served over HTTPS, nor do the instructions tell users to use HTTPS. This is bad.

Yes, in its normal (unattacked) operation, the connection to Stripe will be safe HTTPS. But if someone does a man-in-the-middle attack, then there will be no connection to Stripe, just a connection to an evil website that steals the card (or both to be sneakier; it doesn't matter).

If you're not serving your site over HTTPS, then an attacker can arbitrarily rewrite the content of your site, so no one can trust it.

View on HN

This is a fantastic point. Someone should make a pull request so that the app requires some CERTIFICATE_PATH variable set and won't work without it. HTTPS or equal security is absolutely required for anything to do with online payments.

It is, although Stripe does only use https. When you post that form stripe.js captures the form submission and submits to its server, returning instead some tokens to identify the charge, so what is submitted through http is actually just a mostly worthless token (assuming that the credentials for the app are secure).

I'm not disagreeing with you, but the site running on https only is important in the context of the user not being thrown away by the lack of https, sensitive information is only transmitted through https.

There's more to it than that, re-read jackowayed's comment. Man-in-the-middle attacks are a real threat that should be considered.

You don't know (as a normal user) that the submission is going to go to Stripe with any high degree of certainty. Someone MITMs the plain http form and changes it to direct the cc info to a malicious server.

What stops anyone doing that on most e-commerce sites? If I go to Amazon.co.uk, my basket is served over HTTP. A man in the middle attack could rewrite that and get me to log into a fake site that looks legit.

Of course, the obvious answer is to run everything over HTTPS, but I'm not sure I understand the difference in what Amazon do and this demo page.

Yeah, even displaying a login form on a non-https page is a big hole for mitm attacks, but most of the web can't be bothered.

Even displaying any page over non-HTTPS and linking to a login page is a big hole for MITM attacks. Who's to say the login page is really on the correct server? As long at the little lock looks green (does Joe Public even pay attention?), it's safe ... right?

The idea is that hopefully the page where you enter cc and other personal info is https. This way, the user can look at the url and see, is this https to the site that I think it should be? If yes, enter personal info, else leave. That methodology works even if the main site is not https. An attacker can only at best replicate the page without https.

I would like to believe that everyone follows that methodology, but I have more experience that that. So for now, I like to believe that at least people who visit hn follow that methodology.

I'm a big proponent of SSL-everywhere, but paying Heroku $20 / month to have a custom endpoint seems absolutely obscene (especially for a small shop worried about simple once-off payments). I guess you could forward non-encrypted requests from your custom domain name to the Heroku-branded endpoint, but that is awfully ugly (and potentially scary to the end user).

Almost best to roll with a cheap $5 plan from Digital Ocean - except then you lose all of the ease of use this project is meant to solve.

At the very least he should probably highlight the possibility of MITM attacks when not serving the original page over HTTPS, but I'm not sure how to solve the SSL issue in a way that's as simple as what Heroku offers without dropping a lot of money in monthly fees.

Reply on news.ycombinator.com