🛡️ Insufficient Input Validation in Objectarium Bucket Instantiation

[ccamel]

Note

Severity: Low
target: v5.0.0 - Commit: cde785fbd2dad71608d53f8524e0ef8c8f8178af
Ref: OKP4 CosmWasm Audit Report v1.0 - 02-05-2024 - BlockApex

Description

The Objectarium contract's instantiate function lacks necessary validations on the bucket name parameter during the bucket creation process. This oversight allows for the creation of buckets with arbitrary lengths and potentially malicious content in their names. The absence of strict checks and sanitization on the bucket names could facilitate phishing attacks or cross-site scripting (XSS) vulnerabilities when these names are displayed in a frontend application.

Impact

If exploited, this vulnerability could lead to phishing attacks and execution of unauthorized scripts in the context of a user's session (XSS), compromising the security of the frontend application and the integrity of user interactions.

Recommendation

Implement a validation check to ensure all input conforms to the URL-safe alphabet as specified in RFC 4648, using the defined character set.

[ccamel]

My 2 cents:

Restricting the character sets for bucket names in our smart contract is irrelevant to me. Front-end applications typically sanitize input to mitigate security risks (such as XSS), making the risk of security issues from uncleaned names practically non-existent. Furthermore, imposing such restrictions could prevent users from using international characters or special symbols, which might be essential for their needs.

Additionally, in blockchains, the larger the data, the higher the cost, creating a natural deterrent against abuses such as entering extremely long strings. In my sense, this cost-based deterrent is an effective and direct way to discourage abuse without needing additional restrictions.

Important to note that if the security analysis recommendation were implemented, it would need to apply to all textual fields across all our smart contracts, including the cognitarium, making the implementation extremely significant and impactful.

[amimart]

I totally agree with you @ccamel, this would bring an opinionated API on matters that are in the scope of the network's token model & the client's responsibility.

I'd be in favour of closing this one.

[ccamel]

The team has reviewed this issue and agreed to decline it.