feat: add redirect param

[luizstacio]

• Add a redirect=true query param, to redirect the user to the previous page referrer once faucet is complete.
• Add a documentation section on the README with available query params.

[bvrooman]

There are potential security concerns related to unvalidated redirects that are made client side.

If I understand correctly, the flow is something like this:

1. The user enters dApp URL into the browser and arrives at dApp page
2. The user needs tokens, so the dApp brings the user to the faucet, storing the dApp URL in the param
3. The user receives their tokens and the faucet redirects back to the dApp using the given URL param

This is a potential vector for phishing attacks. If the user were to arrive at the faucet through a compromised link, they could be redirected back to a malicious dApp. This could also happen if a user's browser is compromised in some way that allows an attacker to modify URL params, such as a compromised browser extension.

When it comes to redirects, some protocols (e.g., OAuth2) mitigate this by requiring that the URL be registered by the application server side beforehand. They validate a request by comparing the URL param against the registered URL(s), effectively acting as a whitelist. The OWASP link talks more about this and possible mitigations.

[luizstacio]

There are potential security concerns related to unvalidated redirects that are made client side.

If I understand correctly, the flow is something like this:

1. The user enters dApp URL into the browser and arrives at dApp page
2. The user needs tokens, so the dApp brings the user to the faucet, storing the dApp URL in the param
3. The user receives their tokens and the faucet redirects back to the dApp using the given URL param

This is a potential vector for phishing attacks. If the user were to arrive at the faucet through a compromised link, they could be redirected back to a malicious dApp. This could also happen if a user's browser is compromised in some way that allows an attacker to modify URL params, such as a compromised browser extension.

When it comes to redirects, some protocols (e.g., OAuth2) mitigate this by requiring that the URL be registered by the application server side beforehand. They validate a request by comparing the URL param against the registered URL(s), effectively acting as a whitelist. The OWASP link talks more about this and possible mitigations.

I remove the redirectUrl param and implement a solution that only redirects the user back from the referrer page, this removes the vector attack of having a shared link with fuel.network directly. But yet is possible to create a redirect page that once clicked redirects to the faucet page in this way the referrer will be the previous page.

The solution I propose on Slack also was to add a hardcoded list inside the repo, this means that any DApp that wants the redirect would need to open a PR, this is the better way to control to who we allow redirects.

cc: @bvrooman @Voxelot