Enforce Strict Input Validation and Payload Bounds on Token Store Writes [MED]

[HayimShaul]

Description
Even after a delivery event has been authenticated, the finality listener must not blindly commit its content to the Token Store. Before invoking StoreToken or DeleteTokens, enforce explicit bounds and well-formedness checks on the incoming data: maximum payload size for raw token bytes (ledger, ledger_metadata), maximum number of token outputs per transaction, maximum batch size for bulk delete operations, and rejection of structurally invalid or oversized wallet_id / owner_raw / issuer_raw fields. These checks should be applied as a validation stage in the tokens.Service.Append call chain, before any SQL statement is issued, ensuring that even a legitimate but misbehaving peer cannot cause unbounded storage or CPU consumption in tokendb.

Short Summary
Resource exhaustion / DoS attack. Malicious users can create toxic transaction that tokenSDK will submit to the ledger and receive back finality events that cause this issue. A solution can be limiting the message size, metadata size, etc. and some validation checks.
To address this issue we need:
(1) To prevent the Ledger from sending large messages in finality we need to limit the protobuf messages. This needs to be updated in the documentation accordingly.
(2) When Alice transfers to Bob, bob needs to validate that Alice's token is not too big.

[SurbhiAgarwal1]

Hi @HayimShaul,

Thank you for the detailed write-up. I'd love to work on this issue. Here is my proposed approach:

Root Cause Understanding:
The core problem is that tokens.Service.Append currently trusts incoming finality event data without any bounds checking. Even a legitimate but misbehaving peer can send oversized or malformed payloads that get committed directly to tokendb, causing unbounded storage or CPU exhaustion.

Proposed Solution:

I'd introduce a dedicated validation stage inside tokens.Service.Append, before any SQL statement is issued:

1. Payload Size Limits

   • Cap ledger and ledger_metadata raw bytes to a configurable MaxTokenPayloadSize
   • Reject any token output exceeding this limit before StoreToken is called

2. Output Count Bounds

   • Enforce MaxTokenOutputsPerTx to prevent a single transaction from flooding the token store

3. Bulk Delete Bounds

   • Cap DeleteTokens batch size with MaxBulkDeleteSize

4. Field Well-formedness Checks

   • Validate wallet_id, owner_raw, and issuer_raw for:
     • Non-empty values
     • Maximum byte length
     • Structural validity

5. Protobuf Message Size Limits (as mentioned in the issue)

   • Add size constraints at the protobuf level to prevent large messages from even reaching the finality listener
   • Update documentation to reflect these limits

Implementation Plan:

• Add a ValidateTokenPayload(token) function in tokens.Service
• Make all limits configurable via a ValidationConfig struct
• Add unit tests covering oversized payloads, malformed fields, and bulk delete bounds

Could you please assign this issue to me? I'm happy to discuss the approach further before starting.

Thank you!

[HayimShaul]

Hi @SurbhiAgarwal1
Thank you for offering.
Sounds like a good plan. Let me know if you have any questions.

I see you asked to be assigned to more tasks, but please let's do it one at a time as to not block others.