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.
The whole thing seems a bit impractical to me.
The reason for this is that you've been allowed to do things like <img src="https://unrelated-website"> and even <form action="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">, <link rel="stylesheet" href="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.
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.
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.