How to prevent browser from rendering malicious content if request or response is hacked?

Question

We are currently working on OWASP security fixes and we identified one attack scenario for which we are trying to figure out a possible solution:

1. User hits a valid HTTPRequest to our application. The URL in user's browser is set to our application url e.g. https//www.abc.com/request

2. Either of these:

   • A: Attacker intercepts the request and forwards it to some malicious site instead of our application. The URL in user's browser is set to application URL e.g. https://www.abc.com/request but the content will be that of malicious site.
   • B: Application processes the request and dispatches the response through Apache. While the response is en-route, an attacker intercepts the response and replaces the content of entire response with some malicious site or message like 'You Are Hacked!!'
3. In either case, the response gets rendered in user's browser, with the URL still pointing to https://www.abc.com/request in the browser but the content being malicious. This makes the user believe that it is still in our application.

We could replicate this scenario through our proxy tool. Being HTTPS, may be the attacker cannot decipher the response, but can certainly change the response content or redirect to some malicious site. Is there any way to identify and prevent rendering such responses in the browser through Apache or custom HTTP headers?

What if in scenario (2A), the user is routed from a valid HTTPS site to a malicious HTTP site?

Answer 1

If the request to your domain is HTTPS (e.g. https://example.com) this is effectively immune to a MITM attacker (corporate proxy issues aside). If an attacker redirected example.com to the IP of their own site then their own site would not have a trusted certificate installed for example.com so the user would get browser warnings and would be strongly discouraged from accepting the ceritificate and browsing to the site.

The only way round this for the attacker would be to gain a copy of your certificate with the private key, or somehow have their own trusted certificate for the domain which would be very difficult to do. And if they can do this by breaking into your server, then they win anyway. Bottom line - have trust in the Public Key Infrastructure of X.509. Read up there for more information on how this works.

Answer 2

HTTPS is a defense against the man in the middle (MITM) attack you describe

Being https, may be the attacker cannot decipher the response, but can certainly change the response content or redirect to some malicious site

I don't see how a MITM could modify the response when the browser is expecting a https response. If you are worried about the attacker downgrading to http then you should consider HSTS (HTTP Strict Transport Security). You may also want to get added to the HSTS preload list to prevent the first connection from being downgraded.

You may want to read up on sslstrip attacks or this related answer

Answer 3

The accepted answer already covers the important point, but it looks like you have some other misunderstandings that I'd like to help you clear up.

We could replicate this scenario through our proxy tool.

If you can modify HTTPS responses via a prozy (such as Fiddler, Burp, or ZAP), you must have either installed the browser's root certificate on your computer, or overridden your browser's objections to the untrusted HTTPS certificate for the site. No potential victim would do the first, and it's unlikely they'd do the second.

Being HTTPS, may be the attacker cannot decipher the response, but can certainly change the response content or redirect to some malicious site.

No, TLS (the security protocol that distinguishes HTTP from HTTPS) also prevents that. TLS provides a lot more than just encryption (confidentiality of the request and response). In particular, it also provides:

• Authentication (verifying that you're talking to the server you think you're talking to, and optionally also allowing the server to verify the client's identity although that's rarely used with HTTPS in particular).
• Integrity (preventing an attacker from modifying either the request or the response; a modified request or response - even just appending additional data or flipping a single bit - will invalidate the cryptographic authenticity tag that all TLS messages have, and the recipient of the modified message will discard it).

Is there any way to identify and prevent rendering such responses in the browser through Apache or custom HTTP headers?

Any special content in the header or body of a particular response would obviously not work, because the attacker would simply omit, delete, or modify that content. After all, we're supposing that the attacker controls what the browser receives, so you obviously can't set an "evil bit" on the message to prevent the browser from rendering it, as by the time the response reached the browser it would have no such mark anymore. However, there are some security-related headers that you can use to reduce the risk of man-in-the-middle attacks:

• HSTS (HTTP Strict Transport Security, the actual header is Strict-Transport-Security) is the big one. It specifies a lifetime and some optional flags, and the idea is that you set it on every response, usually with a long lifetime (I recommend a minimum of one year). You can also "preload" it, so that the user is protected before the first time they even visit the site. For the lifetime it has two main effects:
  • The site will never be loaded over insecure HTTP, even if another web page or the user explicitly tries to navigate to an http:// version of the site's URL.
  • The user will not be permitted to override HTTPS errors (such as due to an invalid certificate) for that site; this means even if you have a user who foolishly ignores security errors and tries to visit the page while being subjected to a man-in-the-middle attack, the browser just won't let them do that anyhow.
• HTTP Public Key Pinning (HPKP) is much less-well-supported than HSTS, but some browsers do respect it. HPKP works like HSTS (and should be used in combination with HSTS), in that the header includes a lifetime for the directive to last. HPKP also includes a mandatory field in which you specify the thumbprint of a certificate's public key information. For the specified lifetime (updated every time the browser sees that header over a trusted connection), the browser will require that, for the HTTPS certificate or one of its issued-by ancestors (the certificate authority that signed the certificate, or one of its ancestors), the thumbprint in the header matches the hash of the public key info in the certificate. This prevents your site from being compromised with a man-in-the-middle attack even if the attacker manages to obtain a valid but fraudulently-issued certificate for your domain, which normally would be accepted and considered trustworthy. Basically, the site says "hey browser, if in the future you see a cert that uses some other key, don't trust it even if it is otherwise valid". Since not all CAs are equally trustworthy, and there's no (other) way to limit which CAs are allowed to issue certificates for your domain, HSTS can provide some security against even uncommon threat of a compromised or malicious CA.