ICANN looks forward to working with the community to find security vulnerabilities in order to keep our businesses and customers safe.
SLA
ICANN will make a best effort to meet the following SLAs for hackers participating in our program:
- Time to first response (from report submit) - 5 business days
- Time to triage (from report submit) - 10 business days
We’ll try to keep you informed about our progress throughout the process.
Disclosure Policy
- As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization
- Follow HackerOne's disclosure guidelines
Program Rules
- Please provide detailed reports with reproducible steps
- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact
- Social engineering (e.g. phishing, vishing, smishing) is prohibited
- Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service
- Only interact with accounts you own or with explicit permission of the account holder.
Prohibited Actions
- Uploading files that allow arbitrary commands ( e.g., a webshell)
- Modifying any files or data, including permissions
- Creating and maintaining a persistent connection to the server
- Intentionally viewing any files or data beyond what is needed to prove the vulnerability
- Failing to disclose any actions taken or applicable required information
Out of Scope Assets
- ICANN has numerous assets which are out of scope due to the hosting provider
- Verify the asset is in scope by checking the DNS records, as ICANN may have a redirect to an out of scope IP
Out of Scope Vulnerabilities
When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:
- Clickjacking on pages with no sensitive actions
- Unauthenticated/logout/login CSRF
- Attacks requiring MITM or physical access to a user's device
- Previously known vulnerable libraries without a working Proof of Concept
- Comma Separated Values (CSV) injection without demonstrating a vulnerability
- Missing best practices in SSL/TLS configuration
- Missing best practices in SPF/DMARC/DKIM configuration
- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
- Any activity that could lead to the disruption/denial of our service (DoS)
- Except those that can be described as "CWE-20: Improper Input Validation" type
Availability and Denial of Service Bugs
The Availability environment score modifier has been set to “Low” for all in scope systems. Impact to Availability will not elevate a bug to a Critical level, only the scores for Confidentiality and/or Integrity can elevate a bug to the Critical rating.
If a bug were to achieve a Critical rating due to the Availability score being Low or High, the impact will be noted but it will not raise the total score to a Critical rating.
Valid bug submissions which center around Availability and fall under CWE-20 may have their severity manually adjusted to reflect compensating controls or processes that are not visible to the submitter.
This represents the organizations compensating controls and risk tolerance for Availability of services.
Safe Harbor
Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.
Failure to meet the above conditions and requirements may be considered a breach of responsible disclosure guidelines and eliminate any potential recognition of the submitted research contribution.
Thank you for helping keep ICANN and our users safe!
