22

Does HTTPS have any unique mechanisms that protect web servers from exploits run by a malicious client (eg. SQL injection, specific browser exploits etc.)?

My current understanding is that HTTPS is simply a HTTP session run over a TLS 1.2/1.3 tunnel (ideally), and wouldn't protect against any vulnerabilities of the client/server applications running on either end.

Is it correct that TLS only protects against MiTM and that browsers/web servers must be regularly patched to protect against all other exploits?

Improve this question
3
  • 4
    HTTP/HTTPS are at the wrong layer - they're below the application layer, and generally most modern web application frameworks don't directly expose it to user code anyways. If your client is actively malicious, though, nothing you do can (completely) protect the client side of the application.
    – Clockwork-Muse
    Feb 7, 2022 at 1:33
  • @Clockwork-Muse Thank you for your answer. "Generally most modern web application frameworks don't directly expose it to user code anyways" so, as you clarified, because HTTP/HTTPS is just the session.. whether the session is encapsulated by TLS will not have any baring on the application-layer exploits a client can run, is that correct?
    – Inquisitive
    Feb 7, 2022 at 5:24
  • 2
    While HTTPS can't protect the system (and users) from malicious code operating on the client, it does partly protect the client from being compromised in the first place. If the site uses any third-party scripts (e.g. a library from a CDN), HTTPS ensures that these scripts are fetched only from verified servers. This is really just another protection against MiTM really, but on another connection (one you have no control over whatsoever), so I think it is worth pointing out as a benefit.
    – Frax
    Feb 8, 2022 at 20:00

4 Answers 4

Reset to default
59

You are correct; TLS provides no protection at all against malicious clients. You can think of TLS as providing a tunnel between the client and server. What's going through the tunnel is protected against attack from outside the tunnel, but it doesn't control what goes through the tunnel at all. Therefore, it doesn't protect against attacks launched through the tunnel (in either direction).

Improve this answer
6
  • 3
    While this is technically correct, modern browsers offer several client security options, which are only available on pages served via https. So if your user is using a modern browser you will get added security benefits of using https!
    – Falco
    Feb 8, 2022 at 12:21
  • 7
    @Falco but also only against attackers against the browser. Those also do nothing if the client is intentionally malicious
    – Hobbamok
    Feb 9, 2022 at 10:02
  • 3
    @Hobbamok Of course, a malicious client does not need to use a secure browser. But several attacks (like XSS) target friendly users with valid credentials, and if they use a browser, https can protect them.
    – Falco
    Feb 9, 2022 at 13:21
  • 3
    @Falco my bad I had misremembered the question, instead of "client-run exploits" I was thinking about malicious clients, which is why I dismissed your comment. You are absolutely right though
    – Hobbamok
    Feb 9, 2022 at 13:39
  • mTLS my be an exception. It prevents untrusted clients from connecting to your server in the first place, regardless of how buggy your webapp may be.
    – Arctic Kona
    Feb 13, 2022 at 20:24
10

In the HTTPS extension, the communication protocol is encrypted using Transport Layer Security (TLS) that provides security for the transport layer. The web server, web application and web browser vulnerabilities are all application layer problems. Therefore, web browsers, web servers and web application all require regular security updates despite the utilization of HTTPS.

A web application firewall (WAF) on the server may help filtering malicious content transmitted over HTTPS. That might help protecting your web application from attacks against 0-day vulnerabilities. However, the request must look malicious in general (particularly most SQL injections and XSS vulnerabilities are easy to detect).

Additionally, TLS and its predecessor Secure Sockets Layer (SSL) have had vulnerabilities, too. Some have been weaknesses in the protocol itself (weak cipher suites, POODLE, BEAST, CRIME & BREACH) and some on the implementation (e.g. Heartbleed CVE-2014-0160). For this reason, you have to keep your TLS implementation up-to-date, too, and disable outdated versions of the protocol.

Improve this answer
1
  • Thank you for taking the time to provide more information/context with your answer.
    – Inquisitive
    Feb 8, 2022 at 6:39
2

Is it correct that TLS only protects against MiTM ... ?

No, that is not correct. Here are also some other aspects:

  • TLS provides confidentiality
  • TLS provides integrity
  • TLS provides protection against replay attacks
  • TLS provides forward secrecy
Improve this answer
6
  • Thank you for your answer. Three of those I knew already, except: "TLS provides protection against replay attacks" So this feature is provided by the MAC. Is there no feature inherent in HTTP that protects against replay attacks?
    – Inquisitive
    Feb 7, 2022 at 5:17
  • 7
    You are right that the goal of TLS is to protect against all of those attacks. But unless I am badly mistaken, all of them do rely on traffic interception so on something that is related to MiTM.
    – Serge Ballesta
    Feb 7, 2022 at 8:24
  • @Inquisitive: "So this feature is provided by the MAC" - No. MAC provides integrity. Protection against replay attacks is based on nonce.
    – mentallurg
    Feb 7, 2022 at 12:42
  • @SergeBallesta: No. MiTM has to do with authentication, when you cannot authenticate the other side. In case of replay attack the receiver obtains valid messages from the sender. Protection against MiTM hast nothing to do with protection against replay. Also if you would not use encryption and just sign messages, the traffic would be readable for everyone, but still it would be impossible to modify it. Thus, protection against MiTM hast nothing to do with confidentiality.
    – mentallurg
    Feb 7, 2022 at 13:00
  • 1
    @A.Hersean: We speak about MITM only if there is relay. Where as for replay attack there don't have to be any relay. If messages can be recorded and replayed at some other time, this is replay. At this time there can be no communication between 2 parties, so there is no relay. Thus the replaying attacker is not in the middle. Thus, protection from MITM does not mean protection from replaying.
    – mentallurg
    Feb 7, 2022 at 20:38
-2

Using HTTPS, the server is usually MORE vulnerable.

You still have the whole HTTP stack with its potential vulnerabilities exposed AND you now have all the TLS stack vulnerabilities for the attacker to pick from.

TLS vulnerabilities can be impressively bad - see e.g. the OpenSSL Hearthbleed.

On the other hand, HTTPS in some sense reduces the probability of the attack success by making it harder to obtain valid user credentials and/or to inject malicious code into the HTTP interaction.

(A lot of attacks are of "privilege escalation" type and require authentication, even if the authenticated user nominally has low privileges in the system.)

This is especially effective if the HTTPS server uses TLS authentication with client certificates. In this case, an attacker without a valid client certificate can only poke the TLS frontend. They will have to break the TLS code or obtain a valid cert + its private key by other means in order to get to the HTTP stack in the first place.

A well-maintained policy of issuing client certs only on hardware tokens may force the potential attacker well into the social engineering domain even if the system has gross HTTP or higher level vulnerabilities.

Improve this answer
6
  • 6
    The first part of your answer is misleading. While TLS implementation can introduce some bugs and vulnerabilities, it prevents a whole range of attacks by providing an authentication of the communication channel, confidentiality of its content, and better reliability (detection of errors) than the poor checksums of HTTP over TCP. Overall, despite a few vulnerability, HTTPS offer better security than HTTP.
    – A. Hersean
    Feb 7, 2022 at 12:50
  • The first part of the answer is in the same answer with the second part.
    – fraxinus
    Feb 7, 2022 at 13:24
  • 1
    @A.Hersean They offer different kinds of security. SSL provides security and privacy/confidentiality to connections between clients and servers, but has a risk of worsening the security and privacy of the server. I suppose the rarely-used client authentication could be used to prevent illegitimate clients from interacting with the backend running on the webserver.
    – Solomon Ucko
    Feb 8, 2022 at 4:00
  • That's awfully false, for instance it is far easier to exploit a non encrypted HTTP connection by intercepting any cookie involving classic ID Session system than finding a new HeartBleed in TLS and be able to succesffuly exploit it. The cause for that is not only the HTTP protocol but also the average competence/budget of developing web site. Also lot of stuff just now assume you will use HTTPS by default (SESSIONID Cookie over https is fine enough, over HTTP you're more in trouble).
    – Walfrat
    Feb 8, 2022 at 15:14
  • You mean ‘usually has a larger attack surface’, not ’is usually more vulnerable’. There is a big difference there, and it actually does matter in this case.
    – Austin Hemmelgarn
    Feb 8, 2022 at 22:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .