Scope and Rules of Engagement

Rules of Engagement

  • No Denial of Service testing
  • No Physical or Social Engineering
  • No testing of Third-party Services
  • No uploading of any vulnerability or client-related content to third-party utilities (e.g. Github, DropBox, YouTube)
  • All attack payload data must use professional language
  • If able to gain access to a system, accounts, users, or user data, stop at point of recognition and report. Do not dive deeper to determine how much more is accessible.
  • When documenting a vulnerability, if a vulnerability is public, please make sure it is discreet and doesn't identify the client.

Low Impact Vulnerabilities - Out of Scope

The following vulnerabilities are considered too low of an impact to the client and would be marked as Out of Scope if submitted:

  • Account/e-mail enumeration using brute-force attacks
    • Valid user account/email enumeration not requiring brute-force will be considered
  • Any low impact issues related to session management (i.e. concurrent sessions, session expiration, password reset/change log out, etc.)
  • Bypassing content restrictions in uploading a file without proving the file was received
  • Clickjacking/UI redressing
  • Client-side application/browser autocomplete or saved password/credentials
  • Descriptive or verbose error pages without proof of exploitability or obtaining sensitive information
  • Directory structure enumeration (unless the fact reveals exceptionally useful information)
  • Incomplete or missing SPF/DMARC/DKIM records
  • Issues related to password/credential strength, length, lockouts, or lack of brute-force/rate-limiting protections
    • Account compromises (especially admin) as a result of these issues will likely be considered VALID
  • Lack of SSL or Mixed content
    • Leaking Session Cookies, User Credentials, or other sensitive data will be reviewed on a case by case basis
    • If leaking of sensitive data requires MiTM positioning to exploit, it will be considered out of scope
  • Login/Logout/Unauthenticated/Low-impact CSRF
    • CSRF Vulnerabilities may be acceptable if they are of higher impact. Examples of low impact CSRF include: Add/Delete from Cart, Add/remove wishlist/favorites, Nonsevere preference options, etc.
  • Low impact Information disclosures (including Software version disclosure)
  • Missing Cookie flags
  • Missing/Enabled HTTP Headers/Methods which do not lead directly to a security vulnerability
  • Reflected file download attacks (RFD)
  • Self-exploitation (i.e. password reset links or cookie reuse)
  • SSL/TLS best practices that do not contain a fully functional proof of concept
  • URL/Open Redirection
  • Use of a known-vulnerable library which leads to a low-impact vulnerability (i.e. jQuery outdated version leads to low impact XSS)
  • Valid bugs or best practice issues that are not directly related to the security posture of the client
  • Vulnerabilities affecting users of outdated browsers, plugins or platforms
  • Vulnerabilities that allow for the injection of arbitrary text without allowing for hyperlinks, HTML, or JavaScript code to be injected
  • Vulnerabilities that require the user/victim to perform extremely unlikely actions (i.e. Self-XSS)
    • Self-XSS for a Persistent/Stored XSS will be considered. Please review the Self-XSS article for more information.
    • Any type of XSS that requires a victim to press an unlikely key combination is NOT in scope (i.e. alt+shift+x for payload execution)

Additional specific vulnerability types considered out of scope due to low impact:

  • IIS Tilde File and Directory Disclosure
  • SSH Username Enumeration
  • Wordpress Username Enumeration
  • SSL Weak Ciphers/ POODLE / Heartbleed
  • CSV Injection
  • PHP Info
  • Server-Status if it does not reveal sensitive information
  • Snoop Info Disclosures