Bypass by piggybacking any local web server

[dortau]

On today’s PCs there are likely to be several local web servers installed by different applications such as: Steam client, JetBrains' IDEs, NVIDIA Web Helper, Folding@Home client, Arduino Create agent, and until recently, Spotify as well. These servers open the door to several different vulnerabilities, such as XSSs and RCEs. Many of these servers are likely to approve the preflight from their respective public website.

Thus a vulnerability in any of these local web servers that may be activated from the respective public website, would circumvent the RFC mitigation method.

Activating the vulnerability from the public website is almost always possible with an XSS vulnerability, but even posting a link on the allowed website that points to the local address and phishing the victim to click it is enough, as the request’s initiator is allowed.

Example:

• Step 1: User (victim) is tricked to visit https://evil.com/.
• Step 2: The server at evil.com redirects the victim to https://allowed.com/redirect.php?page=http://localhost:1234/?name= (assuming that this URL is an open redirect in the allowed.com website, which has a corresponding local web server).
• Step 3: The server at https://allowed.com/ redirects the victim to the local web server on http://localhost:1234/?name= (assuming that this URL is an XSS in the local web server).
• Step 4: The local web server executes the attacker’s controlled JavaScript.
• Step 5: Then, because the RFC was written with the notion that local is more secure than private, the malicious code from the example above can make a request to any local, private or public endpoint without the new preflight header! For example: https://my-front-door-lock.local/?action=open.

I believe the issue is the extra hop from the local web server to another local or private web server, E.g. my-front-door-lock.local web server.

A possible mitigation against this piggybacking attack (in step 5) is to always initiate a preflight when the initiator is local. This seems not harmful as local and private web servers (on the LAN) are usually approached directly by the user (like Jupyter Notebook), or by its public web counterpart (like Steam client) or by another program (out the RFC scope), but not by other local origins. Obviously this does not prevent an abled attacker from running code on the vulnerable local web server (Step 4), but it does prevent them from putting other local servers or IoT devices at risk.

Although, as stated in the RFC, the above is not a problem claimed to be solved by the RFC, leaving it open makes the RFC somewhat ineffective.

[letitz]

Thanks for filing an issue!

This is indeed a problem we would like to tackle eventually - see #1, which discussed extending the restrictions not only to local -> private but indeed anything -> non-public.

Fixing this problem is not as high priority however, since it is significantly less easy to exploit - one needs at the very least a vulnerable local service. That may not be necessarily hard to find, but carrying out this attack is still more effort and less likely to succeed on every machine than a drive-by attack from evil.com.

Although, as stated in the RFC, the above is not a problem claimed to be solved by the RFC, leaving it open makes the RFC somewhat ineffective.

I disagree. Fixing this problem would improve things security-wise, but leaving it unsolved for now while concentrating on shipping CORS-RFC1918 for public -> non-public seems like a reasonable course of action that mitigates the largest class of attacks first.