[SEC] Implement Authorization Signatures for Admin Actions

[Queenode]

🔴 Priority: Critical
Difficulty: Hard
Estimated Effort: 2-3 days
Relevant Files: contracts/src/lib.rs
Labels: security, priority:critical, auth

Requirements

1. Explicit Auth Verification

   • The current contract uses admin.require_auth(); for sensitive actions. While Soroban's auth framework handles the signature verification, it's best practice to explicitly verify that the auth covers the exact arguments passed to the function to prevent replay or argument spoofing if the contract is used as a sub-call.

2. Refactor Write Operations

   • For add_member: ensure the auth signature specifically covers (env.current_contract_address(), Symbol::new(&env, "add_member"), (new_member,)).
   • For payout: ensure auth covers the recipient argument.
   • For reset_cycle: ensure auth covers the cycle reset action.
   • For remove_member (from Issue [Deployment] Create Scripts for Testnet Deployment #2): ensure auth covers the specific member being removed.

3. Multi-Sig Preparation

   • Ensure the contract does not assume the Admin is a single ed25519 keypair. The Admin address might be a multisig account or another smart contract.
   • Use env.authorize_as_curr_contract() where applicable if the contract needs to perform cross-contract calls on behalf of the admin.

4. Testing

   • Utilize env.mock_auths() in tests to strictly define the expected authorization payload.
   • Test that calling payout(recipient_A) with an authorization signature meant for payout(recipient_B) fails.
   • Target: Strict auth checks verified in all state-modifying tests.

---

[OpensrcLord]

Hello @maintainer, I understand the expected outcome and would love to work on this. I'll provide a solution that satisfies the acceptance criteria.

[aristotle224]

I'd like to work on this issue because authorization is one of the most security-critical aspects of a Soroban contract. While require_auth() verifies that the caller has authorized the invocation, binding that authorization to the exact operation and arguments provides stronger guarantees against misuse in more complex invocation chains and prepares the contract for future multisig or contract-account administrators.

My approach would be to audit every privileged entry point and ensure the authorization payload explicitly matches the operation being performed. For actions such as add_member, payout, reset_cycle, and remove_member, I'd structure the authorization so it is tied to the current contract, the invoked function, and the specific arguments involved. This ensures that an authorization intended for one action or recipient cannot be reused for another.

I'd also review the contract with multisig compatibility in mind, avoiding assumptions that the admin is a single keypair. Where cross-contract authorization is required, I'd use the appropriate Soroban authorization APIs so the implementation remains compatible with contract accounts and more advanced account abstractions without changing the public interface.

Finally, I'd strengthen the test suite by using env.mock_auths() to verify the expected authorization payloads for every privileged operation. In particular, I'd add regression tests confirming that authorizations cannot be replayed with different arguments—for example, attempting to execute payout(recipient_A) using an authorization intended for payout(recipient_B) should fail. After implementing the changes, I'd run the full contract test suite to ensure all state-modifying operations enforce strict authorization while maintaining existing functionality.

[shepherd-001]

Hello, I've reviewed the issue and am confident in resolving it. I'm experienced with authentication services. Please assign the task to me.