XSS via SVG generates the on-chain SVG for an ERC-721 token ID

[code423n4]

Lines of code

https://github.com/rabbitholegg/quest-protocol/blob/8c4c1f71221570b14a0479c216583342bd652d8d/contracts/ReceiptRenderer.sol#L40

Vulnerability details

Impact

SVG is a unique type of image file format that is often susceptible to Cross-site scripting. If a malicious user is able to inject malicious Javascript into an SVG file, then any user who views the SVG on a website will be susceptible to XSS. This can lead to stolen cookies, Denial of Service attacks, and more.
In the ReceiptRenderer contract, the user can use the function generateSVG to generate an SVG. One of the arguments used by this function is questId_.
When generating an ERC20 contract, a malicious user can set malicious XSS as the questId. This set of circumstances leads to XSS when the SVG is loaded on any website.

Proof of Concept

Creating a SVG file inside of a Solidity contract is novel and thus requires the entity creating a SVG file to sanitize any potential user-input that goes into generating the SVG file.

https://github.com/rabbitholegg/quest-protocol/blob/8c4c1f71221570b14a0479c216583342bd652d8d/contracts/ReceiptRenderer.sol#L29
https://github.com/rabbitholegg/quest-protocol/blob/8c4c1f71221570b14a0479c216583342bd652d8d/contracts/ReceiptRenderer.sol#L63
https://github.com/rabbitholegg/quest-protocol/blob/8c4c1f71221570b14a0479c216583342bd652d8d/contracts/ReceiptRenderer.sol#L100

The same has happened:
code-423n4/2022-01-timeswap-findings#131

Tools Used

Manually

Recommended Mitigation Steps

The easiest solution is to remove all user-input data from the SVG file.

[c4-judge]

kirk-baird marked the issue as duplicate of #177

[c4-judge]

kirk-baird marked the issue as satisfactory

[c4-judge]

kirk-baird changed the severity to QA (Quality Assurance)

[c4-judge]

kirk-baird marked the issue as grade-b