Unrestricted File Upload in Part Attachment in inventree/inventree
Reported on
Jun 11th 2022
Description
The application inventree allows users to upload any file in part attachment allowing attacker to render files such as HTML in the browser.
Proof of Concept
Video PoC Link: https://drive.google.com/file/d/1vurBkHegeYCwbXopE5Yhyb702rYgG9FM/view?usp=sharing
Impact
Authenticated user can upload dangerous file to anywhere in server (example: upload a file with .html extension lead to stored xss)
References
As of now, this is intended. Any file can be added by authorized users. I will discuss this with the team and then we will decide how to classify this.
Hi there @saharshtapi . The dev team decided this is expected behaviour. We will add notes to our docs and maybe the ui and thank you for your consideration. It is a core workflow to upload html test reports via the api so we can not cut this option.
I totally understand but a better practice would be do download the file on clicking the link rather than opening in the browser using the servers URL. Doing this will prevent any kind of XSS attack which can allow an attack to change privileges or other harmful scenarios, as the file will be getting downloaded.
@saharshtapi a very good point and I will issue a fix to ensure files are downloaded rather than opened directly in the browser.
@maintainer can you please valid this report as you can see my perspective now as many applications also face the similar issue and I think I can ask this much in return 😃🦾.
We are working on that - it seems to be a manual process to change that.
I've reopened the report for you ♥️ Feel free to proceed as you wish @maintainer!
@saharshtapi sorry for the delay and thank you for suggesting the fix we didn't think about before!
@maintainer great work on fixing all the bugs in such a short time. 🎉🍾
@sarahstapi we try to keep our users safe - if the community keeps reporting we will keep fixing ;-). All XSS reports were caused by the same error so the fix by @Oliver was released in under 1 day after we decided it was an issue.
Before we proceed with CVEs for each of the reports, we first require the permission of the maintainer 👍
@maintainer - are you happy for us to assign and publish CVEs for each of the recent valid reports?
All confirmed reports have now been patched and published here - https://github.com/inventree/InvenTree/security/advisories?state=published
So yes, we are happy for these to be made public now
That is great - shall I proceed with a CVE for each valid and public report? A CVE is good practice and allows users of your software to know about the vulnerability in a responsible way :)
CVE assigned: CVE-2022-2111
It should be published shortly too 👏 Feel free to update the relevant GitHub Security Advisory with the CVE number stated above.
Sorry if I am coming in late herebut all the XSS reportsare the exact same issue and fix - that should be only 1 CVE right?
Looking at other application’s reports and cve database the cve’s were assigned to all XSS.
Because I facilitated this manually, we have only allotted one CVE for all of the XSS issues, as they only required a single fix to address all of the issues 👍
@admin thank you for the response. I was not sure if this is automated and might lead to spam in the CVE database- which might not be good.