# tx.origin Phishing Attack

## tx.origin phishing vulnerability

tx.origin and msg.sender can be used to get the address of the account making the call, however there is extra context that is vital to keep in mind.

We have 3 components in our example

1. Alice, the address of Alice's wallet in our example is 0x01 (The Depositor).
2. Bob, Bob has deployed a malicious contract in our example at address 0x02
3. The vulnerable contract, Pool, this is deployed in our example at address 0x03\
   \
   In each scenario the Depositor address should be `0x01` to be able to withdraw funds from the Pool contract.\ <br>

Here is the Vulnerable contract, note the check for access control in the `withdrawfunds()` function uses `tx.origin`\
\
![Pool](/files/JNlHxZk1u5uqdML4bKu9)\ <br>

Below is Bob's malicious contract.\
\
![Mal](/files/UeQgtPaRleZ3WXil4JWr)

Let's first look at the path from Alice to the Pool contract where no malicious actions happen. Alice calls `widrawfunds()` at 0x03, in this instance Alice's wallet address will be both the `msg.sender` and the `tx.origin`, and therefore the funds are sent to the correct caller.\ <br>

If Bob's contract calls the Pool contract in the similar way the code at the line `require(tx.origin == pool.depositer, "Must be the depositer");` will receive 0x02, and the call will revert.\ <br>

Now let's take a closer look at the vulnerability, if Bob can get Alice to call the malicious contract at 0x02, and then pass the call through to the Pool contract deployed at 0x03.

* 0x01 -> calls the `donate()` function at 0x02
* 0x02 passes on the call to Pool function `widrawfunds()` at 0x03\ <br>

At this stage the `msg.sender` is 0x02, which should fail as it's not the original depositor, however the `tx.origin` is still 0x01 as the account that started the transaction will always be Alice's.\ <br>

The check that the `tx.origin` is the depositor will therefore pass and Bob's contract will be able to claim all the funds due to Alice.\ <br>

## Resolution

It is recommended not to use `tx.origin` for access control.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://lab.guardianaudits.com/encyclopedia-of-solidity-attack-vectors/tx.origin-phishing-attack.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.