Web2 PoC guidelines

Summary

As a security researcher, it’s inevitable that you will need to provide a PoC (Proof of Concept) for your bug report. Almost all bug bounty projects on Immunefi require it in some form, especially for high and critical bounties. 

PoCs are meant to be minimally or zero-invasive. In general, it’s important not to engage in unauthorized disclosure, make changes, or access sensitive information beyond what is necessary to submit the report. Violation of any of these rules will, in almost all cases, result in an immediate and permanent ban from the Immunefi platform. 

Are PoCs for web2 bugs the same as for web3 bugs?

No. Web2 PoCs are not necessarily runnable code. A video showcasing the attack is acceptable as a PoC, as long as it comes with a brief text explanation in the bug report about what is occurring in the video. For video PoCs, a HTTP request must also be provided. Whitehats can upload their PoCs on YouTube as an unlisted video (only accessible via link) and share it in the bug report.

Additional examples of acceptable web2 PoCs: 

• Screenshots showcasing the final attack
• HTTP requests
• A command line or any programmable runnable code
• Taking over a subdomain and showing proof within the Web2 PoC Rules.
• Taking over the external links within the in-scope assets and showing proof within the Web2 PoC Rules.

Can I perform blackbox testing on a website/application for the purpose of finding a bug?

In general, all blackbox testing is allowed unless it takes down the application/website. In case of such, you must ask for permission from the project in the Immunefi dashboard first if the attack would take down the application/website. If the project does not provide explicit consent, you may not conduct the attack, period. 

A project asked me for more information about my PoC for verification purposes. Can I choose not to provide it?

If the project requests more information about the PoC for verification purposes and it’s possible to provide that information, then you must provide it, or else the PoC may be considered invalid. For example, they may ask for:

1. Technical details about the vulnerability.
2. Steps to reproduce the vulnerability.
3. Relevant code snippets or configurations.
4. Visual evidence such as screenshots or log files.
5. Details about the environment used to discover the vulnerability.

What other requirements are necessary to follow for submitting a PoC?

You must comply with any additional guidelines specified by the bug bounty program you are submitting a bug report to. If there is any unreasonable requirement by the project, use the request help feature to ask for assistance.

What are the guidelines for inserting a JavaScript code payload into a website for the purpose of testing/finding a bug?

Do not insert a malicious JavaScript payload into a website. Instead, you must only insert harmless JavaScript code that doesn’t affect other users and any other functionality of the application. The insertion must also be done in a way that doesn’t disrupt the functionality of the website. It should be as minimally invasive as possible and not easily visible to regular website visitors. Otherwise, it may be considered as a malicious attack, which could result in a permanent ban from Immunefi and no payout.

Can I make changes to a project’s website to show that a vulnerability is real?
If you need to make an edit to a website to show that a vulnerability is real, make the most minimal edit possible, such as HTML comments (which are not visible to others), so as not to be invasive. Your PoC shouldn’t affect the state of the website and disclose to the public that a vulnerability exists.

Can I upload webshells to a project’s website to test/confirm a vulnerability?

Do not upload or attempt to upload webshells for any purpose. If you need to upload a file for your PoC, upload an empty or non-executable text file.

Can I run a DoS (Denial of Service) attack for the purpose of proving a bug?

If you want to run a DoS attack to prove a vulnerability, you must ask for and receive explicit permission from the project in the Dashboard before doing so. If the project does not respond, that does not count as the project giving permission. Again, the project must give explicit written consent in the Dashboard that it is okay to run a DoS attack for the purpose of proving a bug. 

Can I submit a partial PoC first, and then update/complete it after submission?

Your PoC must be complete/functional at the time of submission. Do not submit a partial or incomplete PoC, or your bug report is likely to get closed.