Secret Vault on Aptos

Description

The get_secret() function uses an address parameter instead of &signer, allowing any caller to pass the owner's address and retrieve secrets without authentication. This violates the core security principle that "only the owner should be able to retrieve their secret."

Root Cause

The function accepts an address parameter which can be provided by any caller, rather than requiring a &signer which proves transaction authorization. The current implementation only checks if the provided address matches @owner, but doesn't verify that the caller actually controls that address.

Key issues:

1. Uses address parameter instead of &signer for authentication

2. Any attacker can simply pass @owner as the parameter to bypass the check

3. The #[view] decorator prevents using &signer, creating a design conflict

Risk

Likelihood: High - Trivial to exploit by passing the owner's address as parameter

Impact: High - Complete exposure of secret data to any unauthorized caller

Impact

High severity because:

• Completely breaks confidentiality of stored secrets

• Allows any account to read the owner's secret without authorization

• Defeats the entire purpose of a "secret" vault

Proof of Concept

With the vulnerable #[view] function using address parameter, any attacker can read the owner's secret:

Test Result - Attacker succeeds:

The attacker successfully reads the owner's secret!

Recommended Mitigation

Change the function to use &signer for proper authentication and remove the #[view] decorator:

Test After Mitigation:

After removing #[view] and changing to &signer:

Test Result - Attacker fails:

But the owner can still access their secret:

Test Result - Owner succeeds:

This ensures only the actual owner (who can provide a valid &signer) can retrieve their secret, properly enforcing authentication.