8

I just join a project, and while browsing the code, I realize that some links redirect to another web page, in HTTP instead of HTTPS.

The linked website has an https version, and there was no reason to not use it so I fix the issue.

However, the first website is on production, so we should avoid rebuilding the whole server for minor correction but rather wait to regroup several minor fixes.

I'm just wondering if this is a minor fix, or if leading users to an HTTP website is a major problem.

The linked website is a showcase website belonging to the company I work for, and there is no interaction such as logging into an account, so I guess while man in the middle attack is still possible, there is no sensible content/data to steal. Besides that, the link is in the footer of the first website, and the website itself doesn't have major traffic, so the number of people clicking it shouldn't be that high

How critical is it? Can such issue wait several days, or should it be fixed as soon as possible?

  • I don't think this is answerable in the general case, but in your specific case it doesn't seem remotely important. Between the low user volume and the lack of sensitive data, a MITM attack hardly seems likely or useful. I can't see any reason to rush a fix out, outside of whatever regular deployment cadence the company uses. – meagar Mar 15 at 16:49
  • Incidentally, I think the more useful fix is to have the destination website stop allowing HTTP connections. It should redirect HTTP connections to HTTPS. – meagar Mar 15 at 16:51
  • @meagar Not allowing HTTP connections is generally a usability concern, and it doesn't actually do anything to prevent MitM anyway (at least for active MitM). – AndrolGenhald Mar 15 at 19:18
  • @AndrolGenhald What is the usability concern? The majority of the Internet is moving in this direction. – meagar Mar 15 at 19:28
  • 1
    @meagar Most people still type google.com rather than https://google.com. Redirecting from HTTP to HTTPS is going to be the recommended behavior for a good while yet (reading your comment again I see you actually mention redirecting, but redirecting and disabling HTTP are two very different things, you have to establish an HTTP connection before the redirection is possible). – AndrolGenhald Mar 15 at 19:41
5

In general, the risk is low, as other answers here indicate. However, there is a scenario where risk is introduced:

  • You have session tokens being passed as cookie data
  • The cookies are scoped in such a way that the other (non-https) site has access to them
  • The cookies do not have the secure flag set

In the case that all of those are present, the session tokens may be intercepted via man-in-the-middle (MiTM) attack; since the browser will send them to the other site automatically, and they will be sent in plain text rather than over the encrypted HTTPS stream.

That's a fairly specific set of criteria, and MiTM attack is semi-tough to pull off, so how much real risk this presents should be decided based on 1) whether your site has all 3 of those criteria present, and 2) how sensitive the information in your application is.

5

If your website is purely static and doesn't contain any login or sensitive data, then the risk on a technical level is likely low, and may not warrant an out of cycle fix.

On the other hand there's a risk to reputation. If your business relies on a reputation of being "secure" then it may look bad to potential customers/clients that you aren't following best practices (https everywhere).

EDIT: As per Jason Ross' answer I should also mention that leaking credentials through cookies is possible when a user visits the insecure website, and has logged into a web app on the same domain and the cookies were also improperly set (missing SECURE bit)

-1

In many modern enterprise deployment scenarios application developers do not worry about https at all as this is a concern of the infrastructure team. In these cases SSL is terminated on the Load Balancer, and the certs are managed by the infrastructure team. The Load Balancer also would serve the http -> https redirect by default.

With this view of the world, where the app redirects to does not really matter that much. For consistency it's better to use the current protocol and not http or https specifically, so your application works equally well in dev (without tls) or in prod (with tls).

  • As Jason Ross pointed out, if cookies don't have the secure flag then passive MitM is a concern even if it redirects. To prevent active MitM links must be to HTTPS and not HTTP (HSTS mostly mitigates this, but not entirely). It also shouldn't be terribly difficult to use TLS in a development environment anyway. – AndrolGenhald Mar 15 at 22:34
  • @AndrolGenhald yep, true. Assume that cookies does have the secure flag as per best practices. As for "terribly difficult" it's subjective. Not difficult at all for you and me, but from my experience more than a couple of people needed help with that. In a working environment when any friction during development should be minimized, this is not an unreasonable thing to ask to take this off developers shoulders. – Andrew Savinykh Mar 15 at 23:08

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.