4 ms·

In the example image, why is ftp.bank.com:990 responding with CORS HTTP headers allowing attacker.com to establish a cross origin connection? The whole thing s

by ejcx 5y ago

In the example image, why is ftp.bank.com:990 responding with CORS HTTP headers allowing attacker.com to establish a cross origin connection? The whole thing seems a bit impractical to me.

geofft 5y ago
It's not - you're allowed to send requests to arbitrary sites. CORS just controls whether you can see the response. The reason for this is that you've been allowed to do things like <img src="https://unrelated-website https://unrelated-website"> and even <form action="https://unrelated-website https://unrelated-website" method="POST"> from basically the earliest days of the web. So you can send arbitrary GETs (automatically, no JS required) and POSTs (via getting the user to hit Submit, or using JS) to other websites, you just can't really see the response. For forms it navigates you to the new site (but you can do this in an iframe or something); for images, CSS, etc. the end user can potentially see the response but your website can't programmatically access it via JS. In fact you can also do things like <script src="https://unrelated-website https://unrelated-website">, <link rel="stylesheet" href="https://unrelated-website https://unrelated-website">, etc. and evaluate the result of the page hoping it's JavaScript/CSS/etc., but you can't see it. Back before CORS, a common way to do opt-in cross-website data sharing was "JSONP", where you'd pass the name of a callback function in an argument, a website would return a script consisting of your_function({...JSON response...}), and just trust the other website to not be malicious. (Web browsers now do a little bit of content sniffing and heuristics to try to prevent evaluating non-JS as JS, but that happens once the response has come back. You can still send the request.) CORS applies to using XMLHttpRequest/fetch/etc. to actually access the data. And even with CORS, browsers send (most) GET/POST requests straight through, and they check the CORS header on the response, because for the reasons above you could send GET/POST requests anyway. Only for other methods, custom headers, etc. does CORS preflight the request with OPTIONS. So, for some of the forms of this attack (e.g. tricking an FTP server into accepting an upload), you don't need to see the response. For some forms of this attack (e.g., tricking an FTP server into sending user-provided JS), the web model allows you to evaluate cross-origin content. No CORS is involved in either case.
- ejcx 5y ago
  Yes, you do in fact need CORS to set the arbitrary header in the example if it's even possible to send from a browser. I suppose it might be possible to send as `HELP xss:` which is close Like you said, you can send requests, but not the one listed in the example and you're severely limited in cross protocol interactions to valid http where you don't need to receive a response... (which some of the example attacks require btw) I think this is an interesting issue to consider, but the examples are based on wildly different threat models that include TLS being hijacked, maybe DNS if it was performed with rebinding, the FTP server being hijacked for one of the attacks. It is not at all concrete. Interesting, but not really worth worrying about. The interesting cross protocol attacks that I've seen involved SSRF talking to memcached, as a classic example. Something private. In practice I think they would struggle to find a single real world instance where they can pull off an attack enabled by this behavior. Which is fine, it's academic. Just not what I expected given the coverage.
  - geofft 5y ago
    In the example given, there's no arbitrary header. "HELP" is part of the POST data, which is controlled by the application. And example attacks 2 and 3 do not require seeing the response, only executing it, which you're permitted to do via a <script> tag.

by ejcx 5y ago

In the example image, why is ftp.bank.com:990 responding with CORS HTTP headers allowing attacker.com to establish a cross origin connection? The whole thing seems a bit impractical to me.

geofft 5y ago

It's not - you're allowed to send requests to arbitrary sites. CORS just controls whether you can see the response. The reason for this is that you've been allowed to do things like <img src="https://unrelated-website https://unrelated-website"> and even <form action="https://unrelated-website https://unrelated-website" method="POST"> from basically the earliest days of the web. So you can send arbitrary GETs (automatically, no JS required) and POSTs (via getting the user to hit Submit, or using JS) to other websites, you just can't really see the response. For forms it navigates you to the new site (but you can do this in an iframe or something); for images, CSS, etc. the end user can potentially see the response but your website can't programmatically access it via JS. In fact you can also do things like <script src="https://unrelated-website https://unrelated-website">, <link rel="stylesheet" href="https://unrelated-website https://unrelated-website">, etc. and evaluate the result of the page hoping it's JavaScript/CSS/etc., but you can't see it. Back before CORS, a common way to do opt-in cross-website data sharing was "JSONP", where you'd pass the name of a callback function in an argument, a website would return a script consisting of your_function({...JSON response...}), and just trust the other website to not be malicious. (Web browsers now do a little bit of content sniffing and heuristics to try to prevent evaluating non-JS as JS, but that happens once the response has come back. You can still send the request.) CORS applies to using XMLHttpRequest/fetch/etc. to actually access the data. And even with CORS, browsers send (most) GET/POST requests straight through, and they check the CORS header on the response, because for the reasons above you could send GET/POST requests anyway. Only for other methods, custom headers, etc. does CORS preflight the request with OPTIONS. So, for some of the forms of this attack (e.g. tricking an FTP server into accepting an upload), you don't need to see the response. For some forms of this attack (e.g., tricking an FTP server into sending user-provided JS), the web model allows you to evaluate cross-origin content. No CORS is involved in either case.

ejcx 5y ago
Yes, you do in fact need CORS to set the arbitrary header in the example if it's even possible to send from a browser. I suppose it might be possible to send as `HELP xss:` which is close Like you said, you can send requests, but not the one listed in the example and you're severely limited in cross protocol interactions to valid http where you don't need to receive a response... (which some of the example attacks require btw) I think this is an interesting issue to consider, but the examples are based on wildly different threat models that include TLS being hijacked, maybe DNS if it was performed with rebinding, the FTP server being hijacked for one of the attacks. It is not at all concrete. Interesting, but not really worth worrying about. The interesting cross protocol attacks that I've seen involved SSRF talking to memcached, as a classic example. Something private. In practice I think they would struggle to find a single real world instance where they can pull off an attack enabled by this behavior. Which is fine, it's academic. Just not what I expected given the coverage.
- geofft 5y ago
  In the example given, there's no arbitrary header. "HELP" is part of the POST data, which is controlled by the application. And example attacks 2 and 3 do not require seeing the response, only executing it, which you're permitted to do via a <script> tag.