Character limit for the "symbol" field #5398
Comments
Add maximum length check (11 characters) - Add validation for potentially dangerous characters - Fixes OpenZeppelin#5398
|
ERC-721 describes the optional It is important to note that the content of that string cannot attack the contract itself. Issues are on the front-ends that query these string (what is true of symbol also applies to name and tokenURI), and may not properly sanitize them before processing them. IMO, any issue related to XSS (or similar) attack from an unsanitized string should be fixed on the the consumer side, not here! Other implementations of ERC-721 (and ERC-20, and ERC-1155) will not have this kind of checks, and front ends that consume these values will have to protect themselves no matter what we do here. In the meantime, if someone wants to create a token with name = |
|
Your explanation regarding the lack of sanitization for certain characters is understandable. However, why not impose a limit on the number of characters for the symbol variable? Since it is merely a symbol, why allow the use of an unlimited number of characters? |
openzeppelin-contracts/contracts/token/ERC721/ERC721.sol
Line 41 in ba8b5cf
The "symbol" field, which is often accessible to any user of a smart contract when minting a new NFT, can be exploited for malicious purposes. A user could inject malicious JavaScript code via the "symbol" field, which might then be displayed in a web application, leading to an XSS attack—assuming the web application lacks output sanitization and a properly configured CSP (Content Security Policy).
In the field of cybersecurity, the principle of "Defense in Depth" applies, which emphasizes implementing mitigation mechanisms at every level of a system or application. Given that the "symbol" field is meant to represent only an abbreviated name for the NFT, it should not support an unlimited number of characters. Furthermore, careful consideration should be given to whether certain characters, such as < and >, should be permitted in this field.
Example of an attack:
https://solodit.cyfrin.io/issues/insufficient-input-validation-on-sablierv2nftdescriptorsafeassetsymbol-allows-an-attacker-to-obtain-stored-xss-codehawks-sablier-git
The text was updated successfully, but these errors were encountered: