18

I have an application. Which works on http, http://normal.bank.com. But for log-in, performing any action, etc. I am rediecting user to https://secure.bank.com, where user can login and perform action. Is this is still vulnerable to MIM attack? What are the precautions?

user960567
  • 2,461
  • 4
  • 16
  • 16
  • Possible dupe: http://security.stackexchange.com/questions/14246/can-a-session-be-hijacked-if-the-user-is-redirected-from-https-to-http-after-log – sleske Nov 03 '13 at 10:03
  • 5
    @sleske No, this is a different case. Here, after login, the user is still in HTTPS. – Adi Nov 03 '13 at 10:44
  • 1
    @Adnan: Oh yes, you're right. – sleske Nov 03 '13 at 14:34
  • 2
    Just out of curiosity though, is there ever a time where you would want to have an `http://normal.bank.com`? From what I understand, it should be standard protocol to always have banks and important information in https (and http disabled). – krikara Nov 04 '13 at 06:41
  • Most banks have marketing sites that are http and typically these have links to "login to online banking" – paj28 Nov 04 '13 at 07:36
  • 2-3 years ago, I was on a team that demonstrated a MiM attack that works in *exactly* this situation on one of the largest banks in the US. They spent several months after that denying that they had a problem, but then fixed it "accidentally" when they redesigned their web site. – Moshe Katz Nov 06 '13 at 00:58
  • @MosheKatz, is they are using https every ehere – user960567 Nov 06 '13 at 05:25
  • 1
    @user960567 Yes, they are now using HTTPS everywhere. Now we need to convince them to use [HSTS](https://www.owasp.org/index.php/HTTP_Strict_Transport_Security). – Moshe Katz Nov 06 '13 at 05:38
  • Possible duplicate of [Security of an initial redirection from http://example.com to https://example.com](https://security.stackexchange.com/questions/44849/security-of-an-initial-redirection-from-http-example-com-to-https-example-co) – Michael Dec 04 '17 at 14:34
  • As this concerns different subdomains for redirection, this is not exactly a dupe. – Tobi Nary Dec 04 '17 at 15:47

6 Answers6

17

Is this is still vulnerable to MIM attack?

Yes, it is, because you'd probably go with session-cookies that might be sniffed through a browser-plugin like firesheep or man-in-the-middle'd easily.

What are the precautions?

Best practice nowadays is to have your whole application run over HTTPS because:

  • secure cookies don't work in a mixed environment
  • MITM-attacks do work in a mixed environment
  • ensuring the authenticity of your website to its users doesn't work in a mixed environment
  • no need to think about HTTP-resources in a HTTPS-page and ugly browser-alerts

To ensure HTTPS throughout the whole site:

  • create 2 virtualhost-configs, one for http: and one for https:
  • in your http config, use a redirect from http://site/resource to https://site/resource as the only pattern in this config, so if someone types in http://site/somepath it will always get redirected to the secure site
  • in your https config, use a HTST header to help ensure (browser-based) that your user visits your site always via HTTPS

Everything else, like login-page-encryption-only is out-of-date; search for "firesheep"

Thanatos
  • 1,016
  • 2
  • 10
  • 16
that guy from over there
  • 3,476
  • 17
  • 26
14

Yes, you are vulnerable to MITM attacks due to the fact that you are starting out with an unencrypted web application. This is where the attack takes place, as the attacker would be able to modify any references to https://secure.bank.com and replace them with http://secure.bank.com. The attacker would then intercept your data, and relay the contents to the actual secure connection at https://secure.bank.com

It is highly suggested to force SSL from the very beginning of the session, and you should make sure to only advertise the secure URL.

David Houde
  • 5,464
  • 1
  • 27
  • 22
  • But the site https://secure.bank.com is not available on http. Is still I am vulnerable? – user960567 Nov 03 '13 at 09:39
  • Can you explain a more in simple terms? Thanks – user960567 Nov 03 '13 at 09:42
  • I've edited the answer to better explain how the attack might take place. – David Houde Nov 03 '13 at 10:16
  • See the above answer – user960567 Nov 03 '13 at 11:03
  • 1
    @user960567 The attacker can choose to redirect to secure.hisserver.com, where 'hisserver' looks similarly enough to 'bank' for the user not to notice. My bank does this and I hate them for it. The login is `https://secure.bank.com/very/long/uri` and the only way to get there is via `http://bank.com/login`. Horrible. – Jan Nov 03 '13 at 12:36
  • I just want to add clarification that closing port 80 does not protect you against MITM in case client initiates HTTP request. _How_ that is possible is described in the answer but still this is something I see many people confused about. – Pijusn Nov 08 '17 at 07:39
11

After visiting http://normal.bank.com, an attacker can replace all links to https://secure.bank.com with links to http://secure.bank.com. When the user clicks on http://secure.bank.com, the MITM will happily connect to the server via HTTPS and serve the contents back to the client via HTTP. No matter what redirection precautions used here, the whole redirection can prevented by the MITM.

In conclusion, yes, you're still vulnerable to MITM attacks.

Adi
  • 43,808
  • 16
  • 135
  • 167
  • 1
    Yes they have different cookies, secure and HttpOnly. – user960567 Nov 03 '13 at 11:01
  • @Adnan You didn't take things like sslstrip into account, which work by MITMing the client, showing the client only HTTP links while establishing an HTTPS connection to the server when the client tries to open such a link. – heinrich5991 Nov 03 '13 at 15:44
  • @heinrich5991 Incorrect. Please reread the part of the answer starting with "Even if the references to..." – Adi Nov 03 '13 at 15:46
  • 1
    @Adnan To be clear: Client requests `http://bank.com/`, server returns page with link to `https://secure.bank.com/` for login, the MITM replaces that link with `http://secure.bank.com/` and saves the link for HTTPS requests. The client clicks on login and requests `http://secure.bank.com/`, MITM changes this to a request to `https://secure.bank.com/`, server happily returns data, MITM decrypts it and sends it back to the client. Client logs in and MITM is able to intercept login data. – heinrich5991 Nov 03 '13 at 15:48
  • 1
    @heinrich5991 Please note the part of the answer where I mention "Secure cookies". Secure cookies are flagged with the "Secure" flag, which means that the cookie will ONLY be passed with an HTTPS request. – Adi Nov 03 '13 at 15:52
  • @heinrich5991 You are indeed correct. I've edited my answer to reflect that fact. Apparently, I've originally missed the whole point. – Adi Nov 03 '13 at 16:21
5

I'm going to buck the trend here and say it is acceptable to redirect like this.

It is true that a user is vulnerable to MITM if they go to http://secure.bank.com/ and continue to use the site without further checks on certificates, URLs, etc.

However, this is an issue of user behaviour, and not something you can fix server-side.

Lets just think for a minute how you might try to fix this server-side. Rather than issue a redirect you could show an informational page, perhaps with a strongly worded warning "To access this site securely you must use https://secure.bank.com/" Or you could have the web server only listen on port 443 and reject port 80.

Now what happens if an attacker has full control of a user's network? When the user goes to http://secure.bank.com/ the attacker redirects them to https://secure.bank.com.attacker.com/ and presents a phishing page. Or perhaps they insert a phishing page directly into http://secure.bank.com/ Either way, an experienced and alert user could detect this, but many users will continue.

It doesn't make any difference how the real http://secure.bank.com/ behaves - the attacker can do whatever they like.

So ultimately this is a user training issue. And the behaviour of the site can influence this. The vast majority of times a user visits the site, they will visit the real site and not a MITM attack. If the site automatically redirects them, this does nothing to discourage them using the http URL in the future. If they get a warning message, or the site simply does not work, they will quickly learn to use the https by default.

But how responsible are you as a site operator to train your users like this? The reality is that the vast majority of sites do redirect from http to https like this. From a business point of view, why make your site more difficult to use than a competitors? If it's just you making this stand, are you really going to have an effect on general user behaviour?

For those reasons, on balance, I recommend that most sites do redirect from http to https in this way.

To lock this down as much as possible, I recommend you setup the redirect so that http://secure.bank.com/ redirects to https://secure.bank.com/ - stripping the rest of the URL.

paj28
  • 32,736
  • 8
  • 92
  • 130
  • "However, this is an issue of user behaviour, and not something you can fix server-side." yes, you can, and this is called HSTS. but you must ensure to run the while site in HTTPS. – that guy from over there Nov 06 '13 at 07:02
  • 1
    While HSTS is good, it's not supported on Safari or IE, so we really can't rely on a user having an HSTS-compliant browser. – paj28 Nov 06 '13 at 11:09
4

It wasn't explicitely mentioned so far, thus this late answer. Websites switching between HTTP and HTTPS are inevitably prone to SSL-strip. A good explanation you can find here:

SSL-strip presentation from Moxie Marlinspike

Some important points:

  • It is the first request that makes the difference. Whenever the user starts with HTTP as the first page, then SSL-strip can talk to the user with HTTP and to the site with HTTPS. A switching site will prevent the user from choosing HTTPS for the first request.
  • This is where the HSTS header jumps in. If you already visited the site earlier from a secure connection, the header will tell the browser to call the site with HTTPS only for future requests. If you visit the site for the first time, the HSTS header cannot help.
  • If the user cares, he can start with HTTPS (typing the url with https:// into the browser bar), this makes SSL-strip impossible on SSL-only sites.
martinstoeckli
  • 5,149
  • 2
  • 27
  • 32
2

I wrote a blog post about it a few months back. In my blog post I showed how redirecting traffic from http to https could potentially dangerous depending on the mechanism selected. I proposed HSTS (HTTP Strict Transport Security).

http://blog.michaelhidalgo.info/2013/09/redirecting-http-traffic-to-https-why.html

Michael Hidalgo
  • 71
  • 1
  • 6