| summary |
HFS user adding a "web link" in HFS is vulnerable to "target=_blank" exploit
### Summary
When adding a "web link" to the HFS virtual filesystem, the frontend opens it with `target="_blank"` but without the `rel="noopener noreferrer"` attribute. This allows the opened page to use the `window.opener` property to change the location of the original HFS tab.
### Details
While most modern browsers have fixes already implemented for this `target="_blank"` exploit at the browser level, users on outdated browsers remain vulnerable. This means that if an admin of the HFS instance adds a link to an external third-party service (that they believe is safe at the time) and that service they added later becomes compromised, the malicious page could replace the original HFS tab's content with a phishing page. This does not require the admin account itself to be compromised, only that a legitimate linked site turns malicious.
### Impact
Affected users (people using old browsers without the browser level fix) could be misled into entering their HFS credentials or other sensitive information into a fake site controlled by an attacker. This vulnerability is fixed in most modern browsers, but adding `rel="noopener noreferrer"` remains a best practice to protect legacy environments.
### PoC
Firstly, in the HFS admin page, under the filesystem (/~/admin/#/fs) press "Add" then "web link" then set the link to take the user to to an HTML file that exploits this vulnerability, here is an example of a malicious HTML file's code:
```<html>
<body>
<script>
window.opener.location = "https://example.org";
</script>
<b>Error loading...</b>
</body>
</html>
```
Now, in the HFS folder you placed this web link in, open HFS and click the web link, if you aren't on a modern browser that fixed this vulnerability on the browser level, then switch back to the HFS tab that opened it, and you should be taken to "https://example.org" if you tried the code I provided, or whatever other page you tried. |