5 ms·

It would be a good idea for Chrome to display an alert similar to the non-HTTPS resource loading if integrity checks are not present for externally loaded scrip

It would be a good idea for Chrome to display an alert similar to the non-HTTPS resource loading if integrity checks are not present for externally loaded scripts. The danger of serving external JS without integrity check its is very similar to having non-HTTPS connections in your website.

Cthulhu_ 8y ago
Yeah, especially if it's detecting a payment information form, just like they do with passwords atm. They can detect CC forms just fine (with their autocomplete functionality). I'd also like browsers to do automatic integrity checking - they should be able to have an internal list of signatures, tracking releases of well known libraries.
dchest 8y ago
> It would be a good idea for Chrome to display an alert similar to the non-HTTPS resource loading if integrity checks are not present for externally loaded scripts. It would just teach users to ignore warnings. > The danger of serving external JS without integrity check its is very similar to having non-HTTPS connections in your website. No, it's not similar at all.
interfixus 8y ago
Why particularly for Chrome?
- helloguillecl 8y ago
  Sorry, I wanted to fix that after I posted the comment.
- josteink 8y ago
  Are you implying there are other browsers? /s The wonderful web as we used to know it has devolved into a pretty sad thing (and web-developers with it).
deleted 8y ago
[deleted]
danShumway 8y ago
> is very similar to having non-HTTPS connections in your website I am very into the idea of doing integrity checks on web pages, I think that it's an important direction for the web to move (for multiple reasons) and will improve security a ton. I'd love for browsers to start adding 1st party support for stuff like that; I've even thought about trying to build an extension or something for my own personal use. 100% on board. But... nah, I don't think these risks are comparable. Removing HTTPS is much more dangerous than shipping code without an integrity check. With an integrity check, you're just checking to see if the code has been changed. Without HTTPS, it's not just the code that could be changed -- anything on the page including your actual requests can be captured and changed. Plus all of your data can be read as well. With HTTPS, the only fear is that the website itself is compromised. That's a valid fear, but it's so much smaller than the fear that anyone along the entire chain of you to your router to anyone between you and the website server could be compromised.
- helloguillecl 8y ago
  I think you are missing that, if any external script is compromised, anything in the page can be changed, including the destination of the data you send. Correct if I'm wrong, but the "action" attribute for a <form> element could be changed to an external location, without having to bypass any cross-origin policy?
  - danShumway 8y ago
    Even in that situation though, the only way for an external script to get compromised is for the website serving it to get compromised. With HTTP, it's not just the site that's vulnerable. Maybe you're connecting to an open access point, and someone sitting next to you in the coffee shop is reading your credentials out of thin air. Maybe the router itself is serving malware. Maybe your ISP is compromised, or a random proxy someplace. Imagine you had a Google doc or a Github repo where 4 or 5 people had access to it. That's potentially a vulnerability, any of those people could change the doc behind your back. And if you don't trust them to keep their accounts secure, maybe someone uses them to sneak something in. It's a very valid concern. Now imagine you had a Google doc or Github repo with open editing that anyone could connect to at any time and change, without logging any information about their change, or even running a 3rd-party server. That's the difference between being required to trust 3rd-party scripts and connecting to a site without HTTPS. In your example about bypassing the cross-origin policy, POST requests in general are allowed to be cross-origin by default, so unless you're explicitly blocking that using something like an iFrame, a 3rd-party script can already just send requests directly. Again, valid vulnerability that's worth being concerned about. But unencrypted web traffic is on a whole nother level. Without HTTPS there's just no mitigation for that vulnerability. Putting the 3rd-party code in an iFrame? I'll just move it out. Setting more restrictive CORS headers? I'll just change them. The difference is that if you're including 3rd-party scripts from sites that you don't trust, there are things you can do to limit their impact. There's nothing you can do to limit what an attacker can do to an unencrypted connection.

Cthulhu_ 8y ago

Yeah, especially if it's detecting a payment information form, just like they do with passwords atm. They can detect CC forms just fine (with their autocomplete functionality). I'd also like browsers to do automatic integrity checking - they should be able to have an internal list of signatures, tracking releases of well known libraries.

dchest 8y ago

> It would be a good idea for Chrome to display an alert similar to the non-HTTPS resource loading if integrity checks are not present for externally loaded scripts. It would just teach users to ignore warnings. > The danger of serving external JS without integrity check its is very similar to having non-HTTPS connections in your website. No, it's not similar at all.

interfixus 8y ago

Why particularly for Chrome?

helloguillecl 8y ago
Sorry, I wanted to fix that after I posted the comment.
josteink 8y ago
Are you implying there are other browsers? /s The wonderful web as we used to know it has devolved into a pretty sad thing (and web-developers with it).

deleted 8y ago

[deleted]

danShumway 8y ago

> is very similar to having non-HTTPS connections in your website I am very into the idea of doing integrity checks on web pages, I think that it's an important direction for the web to move (for multiple reasons) and will improve security a ton. I'd love for browsers to start adding 1st party support for stuff like that; I've even thought about trying to build an extension or something for my own personal use. 100% on board. But... nah, I don't think these risks are comparable. Removing HTTPS is much more dangerous than shipping code without an integrity check. With an integrity check, you're just checking to see if the code has been changed. Without HTTPS, it's not just the code that could be changed -- anything on the page including your actual requests can be captured and changed. Plus all of your data can be read as well. With HTTPS, the only fear is that the website itself is compromised. That's a valid fear, but it's so much smaller than the fear that anyone along the entire chain of you to your router to anyone between you and the website server could be compromised.

helloguillecl 8y ago
I think you are missing that, if any external script is compromised, anything in the page can be changed, including the destination of the data you send. Correct if I'm wrong, but the "action" attribute for a <form> element could be changed to an external location, without having to bypass any cross-origin policy?
- danShumway 8y ago
  Even in that situation though, the only way for an external script to get compromised is for the website serving it to get compromised. With HTTP, it's not just the site that's vulnerable. Maybe you're connecting to an open access point, and someone sitting next to you in the coffee shop is reading your credentials out of thin air. Maybe the router itself is serving malware. Maybe your ISP is compromised, or a random proxy someplace. Imagine you had a Google doc or a Github repo where 4 or 5 people had access to it. That's potentially a vulnerability, any of those people could change the doc behind your back. And if you don't trust them to keep their accounts secure, maybe someone uses them to sneak something in. It's a very valid concern. Now imagine you had a Google doc or Github repo with open editing that anyone could connect to at any time and change, without logging any information about their change, or even running a 3rd-party server. That's the difference between being required to trust 3rd-party scripts and connecting to a site without HTTPS. In your example about bypassing the cross-origin policy, POST requests in general are allowed to be cross-origin by default, so unless you're explicitly blocking that using something like an iFrame, a 3rd-party script can already just send requests directly. Again, valid vulnerability that's worth being concerned about. But unencrypted web traffic is on a whole nother level. Without HTTPS there's just no mitigation for that vulnerability. Putting the 3rd-party code in an iFrame? I'll just move it out. Setting more restrictive CORS headers? I'll just change them. The difference is that if you're including 3rd-party scripts from sites that you don't trust, there are things you can do to limit their impact. There's nothing you can do to limit what an attacker can do to an unencrypted connection.