Potential XSS in FileBrowser leads to Admin account takeover in Filebrowser

[febinrev]

Description

A Cross-Site Scripting vulnerability is discovered in FileBrowser in which an attacker with a non-admin user account inside the FileBrowser instance can create malicious HTML & JS files, craft them in a specific way and send the HTML file's link to the Admin to achieve Account takeover via XSS bypassing the Content-Security-Policy.
Proof of Concept

// xss.js

alert(document.cookie);

// xss.htm

<script src="/api/raw/poc/xss.js?auth=[jwt_token of the Low Privileged user]"></script>"

1. Create a folder named "poc" as the non-admin user.
2. Create the 2 files as above (xss.htm and xss.js) under the poc folder.
3. Craft the XSS URL as below and open it as the Admin user to verify the XSS.

http://your_filebrowser_ip:port//api/raw/poc/xss.htm?auth=[non-admin user's jwt token]&inline=true

It will trigger an alert pop-up with Admin's Cookie.

Explanation

• The parameter "?auth=[non-admin token]" is added in the URL so that when the Admin opens the URL it will fetch those html/js files that are created by the non-admin user, otherwise FileBrowser will use the Admin's original jwt token that's been stored as Cookie thus leading to a "404 Not Found" Error. This is because those files are created by the non-admin user, so if the API tries to fetch them with Admin's token it will lead to an error, the API also accepts the jwt token inside a URL get parameter "?auth=". So, the non-admin user can deliberately supply his own JWT token in the malicious URL for a successful exploitation

• The "?inline=true" parameter is included in the crafted URL because without that parameter FileBrowser will treat the HTML file as an attachment and will download it as a file, so by having "inline=true" the HTML file will be treated as a webpage, and execute the javascript.

• Content-Security-Policy(CSP) is bypassed because of the fact that FileBrowser sets CSP "default-src" to 'self'. As the malicious JS is also loaded from the same site, it will get executed.

Impact

This vulnerability is capable of Admin account takeover. Admin can even run system shell commands and access filesystem, thus leads to Arbitrary Command execution.

[IceWreck]

Huh, shouldn't this be reported in private ?

[febinrev]

Huh, shouldn't this be reported in private ?

1. I did, i did report it through huntr.dev and also created a github issue with the huntr.dev link to the private report without disclosing anything publicly, I even tried mentioning the devs in comments, they didn't even notice.

2. This Attack has a slightly high complexity, certain conditions has to be met in order for a successful attack. Those conditions include: Attacker with a low privileged user account, a user-interaction is required from the Admin i.e., admin needs to click a crafted URL/link. So, this is not a critical vulnerability, this is a Medium one.
   By keeping this in mind, I thought to create a public issue so that the devs will fix it immediately and also the users of Filebrowser can be aware of such attacks and never click on links without examining.

I am sorry and I had no other way to report this privately.

[IceWreck]

I was able to reproduce and fix it, will submit an MR for the fix ASAP.

[febinrev]

I was able to reproduce and fix it, will submit an MR for the fix ASAP.

That's appreciated. Thanks.