4 ms·

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. Corre

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.
- wormhole11 8y ago
  >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. Not sure what you're trying to say here, as far as I know CORS is applicable to all HTTP methods except OPTIONS when using Ajax. If you're saying that it's allowed using Forms, then that's allowed for all HTTP methods as we're navigating away from the page.
  - danShumway 8y ago
    Agreed, I phrased that poorly. What I mean is that you can send a POST request to any server from a webpage unless the page you're on has taken specific steps to mitigate that attack. The remote server might have CORS headers set up so that the browser blocks the request. However, in this scenario (stealing payment information) we're talking about an attacker sending data to a remote domain that they control, so you really can't trust that they're going to block third-party AJAX requests to their own domain for their own attack. To block requests or form actions from your own page, you'd need to explicitly set a CSP header, which isn't something that's on by default. Note that a CSP header does not protect you if you're using HTTP, because I can just turn your CSP header off when I intercept the unencrypted page.

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.

wormhole11 8y ago
>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. Not sure what you're trying to say here, as far as I know CORS is applicable to all HTTP methods except OPTIONS when using Ajax. If you're saying that it's allowed using Forms, then that's allowed for all HTTP methods as we're navigating away from the page.
- danShumway 8y ago
  Agreed, I phrased that poorly. What I mean is that you can send a POST request to any server from a webpage unless the page you're on has taken specific steps to mitigate that attack. The remote server might have CORS headers set up so that the browser blocks the request. However, in this scenario (stealing payment information) we're talking about an attacker sending data to a remote domain that they control, so you really can't trust that they're going to block third-party AJAX requests to their own domain for their own attack. To block requests or form actions from your own page, you'd need to explicitly set a CSP header, which isn't something that's on by default. Note that a CSP header does not protect you if you're using HTTP, because I can just turn your CSP header off when I intercept the unencrypted page.