Web/App Self Triaging

We recommend proceeding through each section outlined in text below with questions for your review to help navigate you through the Web/App self triaging process.

The end result of each stage of the self triage assessment should be either:

• valid (proceed to next stage)
• invalid (provide rationale in reply to whitehat + close submission)
• needs more information (reply to whitehat with questions)

If at any time you are in doubt, you are entitled and strongly suggested to contact the whitehat using the dashboard for answering your doubts.

Assess the target

Evaluate if the asset domain/subdomain or Github repository is in scope.

If the domain or GitHub repository is not listed as in-scope for your bug bounty program, close the bug report as out-of-scope.

Assess the vulnerability type

Immunefi provides a list of priority web vulnerabilities in scope. However, we do accept any vulnerability which may result in an acceptable impact on the in-scope assets. (i.e. if you could perform an acceptable impact on the in-scope asset using out of scope XYZ vulnerability type, this will be considered as valid.).

If the vulnerability type is listed as excluded or out-of-scope for your bug bounty program, close the bug report.

Example: If there's a vulnerability in your analytics provider, which leaks access to analytics data, but doesn't provide any access to data stored by any in-scope asset, the bug report should be closed and not paid.

Assess the impact

The general question we are trying to answer in this assessment is:

What could the attacker achieve by exploiting the vulnerability?

In web impact assessment, the possibility of impacts are endless. This is not the complete list of impacts every submission could lead to, but instead, is a suggestion guide of how to assess impacts that could lead to the validity of the report.

To assess the base impact, consider the following questions:

• Does this achieve arbitrary code execution on the victim’s hardware?
• Does this vulnerability expose any confidential data?
• Is this vulnerability associated with CVE (Common Vulnerabilities and Exposures) on a third-party service/vendor that the client is hosting?
• What is the impact on cross users and integrity of the application?
• Does this vulnerability entice the victim to take a malicious action?

Also consider the following questions which could potentially decrease impact:

• Does this have an effect only on a single user?
• Does this only affect staging?

Your answer to these questions can be referenced against the Immunefi Severity System to establish an initial severity. If the initial severity is not listed with a reward in your bug bounty program, close the report.

Assess the difficulty of exploitation

At this stage of self triage, you might upgrade or downgrade the severity level of the vulnerability. If the new severity is now out of scope, once adequate rationale is provided to the whitehat, the report can be invalidated and closed.

Questions to consider:

1. Is the attack authenticated or non-authenticated?
2. Does the attack require any physical [or] local [or] network [or] adjacent requirement?
3. Does the attack require any user interaction for the exploit? (phishing)
4. Is the attack usable only by privileged users?

The attributes above may result in downgrading the severity of the bug report. If the new severity is not listed with a reward in your bug bounty program, close the report.

Read the report and validate the existence of the vulnerability

If the vulnerability simply does not exist, you can close it. (i.e. PoC depends on an unusual browser extension, effective mitigations are already in place, can only be deployed by the user itself). In some cases, you might agree with the severity, but the vulnerability actually doesn't exist.

Checklist to review:

• Review the information, screenshots, source snippets provided by the whitehat.
• Follow the mentioned steps to reproduce and manually validate the vulnerability.
• Identifying the root cause of the vulnerability.

Assess the severity level

Immunefi classifies (5) levels of severity:

• Critical
• High
• Medium
• Low
• None

The potential impact of a successful exploit informs the initial severity of a bug. However, this severity may be downgraded for various reasons. Initially, the whitehat will select their identified severity level.

If you wish to reassess the severity level, use any of the reasons on this list. Reasons not on this list will invite additional scrutiny:

• uncommon or incorrect action must be taken by the victim
• uncommon or incorrect action must be taken by an user with escalated privileges
• attacker needs escalated/admin privileges
• attacker needs key compromise
• no funds at risk
• attack requires repeated interaction over a long period of time (project may notice)
• attack requires adjacent network access or MITM network access
• attack requires physical access to the victim's computer
• attack requires brute-force complexity of over 40 bits

We also provide a non-exhaustive list of reasons for downgrading the severity of the bug that are not acceptable:

• no reason
• my dev said
• this is just a trading strategy
• we don't care about web bugs (then why were they in scope)

If at any time you are in doubt, you are entitled and strongly suggested to contact the whitehat using the dashboard for answering your doubts.

Example: Attacker could achieve arbitrary code execution on victim’s hardware without any requirement of user-interaction from the victim. This example has a critical impact and no user-interaction requirement hence (complexity of exploitation: easy, Impact: critical)