A link redirect to http instead of https: how critical is it?
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?
tls http
asked 4 hours ago
KepotxKepotx
5071312
add a comment |
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?
tls http
asked 4 hours ago
KepotxKepotx
5071312
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
3 hours ago
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
3 hours ago
@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
1 hour ago
@AndrolGenhald What is the usability concern? The majority of the Internet is moving in this direction.
– meagar
52 mins ago
@meagar Most people still typegoogle.comrather thanhttps://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
39 mins ago
add a comment |
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?
tls http
asked 4 hours ago
KepotxKepotx
5071312
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?
tls http
tls http
asked 4 hours ago
KepotxKepotx
5071312
asked 4 hours ago
KepotxKepotx
5071312
asked 4 hours ago
KepotxKepotx
5071312
asked 4 hours ago
KepotxKepotx
5071312
asked 4 hours ago
KepotxKepotx
5071312
5071312
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
3 hours ago
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
3 hours ago
@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
1 hour ago
@AndrolGenhald What is the usability concern? The majority of the Internet is moving in this direction.
– meagar
52 mins ago
@meagar Most people still typegoogle.comrather thanhttps://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
39 mins ago
add a comment |
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
3 hours ago
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
3 hours ago
@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
1 hour ago
@AndrolGenhald What is the usability concern? The majority of the Internet is moving in this direction.
– meagar
52 mins ago
@meagar Most people still typegoogle.comrather thanhttps://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
39 mins ago
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
3 hours ago
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
3 hours ago
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
3 hours ago
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
3 hours ago
@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
1 hour ago
@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
1 hour ago
@AndrolGenhald What is the usability concern? The majority of the Internet is moving in this direction.
– meagar
52 mins ago
@AndrolGenhald What is the usability concern? The majority of the Internet is moving in this direction.
– meagar
52 mins ago
@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
39 mins ago
@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
39 mins ago
add a comment |
2 Answers
2
active
oldest
votes
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).
answered 2 hours ago
DaisetsuDaisetsu
4,12711021
add a comment |
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
secureflag 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.
answered 1 hour ago
Jason RossJason Ross
213
New contributor
Jason Ross is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f205446%2fa-link-redirect-to-http-instead-of-https-how-critical-is-it%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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).
answered 2 hours ago
DaisetsuDaisetsu
4,12711021
add a comment |
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).
answered 2 hours ago
DaisetsuDaisetsu
4,12711021
add a comment |
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).
answered 2 hours ago
DaisetsuDaisetsu
4,12711021
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).
answered 2 hours ago
DaisetsuDaisetsu
4,12711021
answered 2 hours ago
DaisetsuDaisetsu
4,12711021
answered 2 hours ago
DaisetsuDaisetsu
4,12711021
answered 2 hours ago
DaisetsuDaisetsu
4,12711021
4,12711021
add a comment |
add a comment |
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
secureflag 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.
answered 1 hour ago
Jason RossJason Ross
213
New contributor
Jason Ross is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
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
secureflag 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.
answered 1 hour ago
Jason RossJason Ross
213
New contributor
Jason Ross is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
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
secureflag 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.
answered 1 hour ago
Jason RossJason Ross
213
New contributor
Jason Ross is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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
secureflag 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.
answered 1 hour ago
Jason RossJason Ross
213
New contributor
Jason Ross is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 1 hour ago
Jason RossJason Ross
213
New contributor
Jason Ross is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 1 hour ago
Jason RossJason Ross
213
answered 1 hour ago
Jason RossJason Ross
213
213
New contributor
Jason Ross is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Jason Ross is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Jason Ross is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f205446%2fa-link-redirect-to-http-instead-of-https-how-critical-is-it%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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
3 hours ago
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
3 hours ago
@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
1 hour ago
@AndrolGenhald What is the usability concern? The majority of the Internet is moving in this direction.
– meagar
52 mins ago
@meagar Most people still type
google.comrather thanhttps://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
39 mins ago