Penetration Testing Standard
The Standard presents the general penetration tests methodology used by the Information Security Team performing internal penetration testing activities
Scope
The Standard standardize procedures, activities, documentation, and reporting during internal penetration testing activities.
Penetration tests execution
Information Security Team conducts penetration tests to check the security of a complete system or single system components. The tools, methods and techniques used falls into three categories:
Well known throughout both the computer security and “hacker” communities
In-house tools developed to extend the boundaries beyond the usual hacker’s toolkit
Specialist observation. Examining the site to look for vulnerabilities that may not be discovered directly using tools.
The penetration testing can be performed within 3 different levels of knowledge “boxes”:
BlackBox – no prior information is provided. All tests are performed from the external attacker’s perspective
GreyBox – some information is provided. Tests are performed with some information about systems, infrastructure, components, and configuration
WhiteBox – all information is provided, including source code
Coverage
Information Security Team performs penetration tests of the following categories:
Applications
Native applications (Client applications: Windows/MacOS/Linux)
Mobile applications (Client applications: Android/iOS)
Web applications
External infrastructure
Remote components (Servers, databases)
External networks
Internal systems
Internal web applications
Internal networks
Used tools
Information Security Team uses open-source tools for penetration tests, as well as closed source (commercial) tools. Open-source tools are individually inspected to test for potential external risks. Some of used tools are listed below:
Open-source tools
Kali Linux and included tools, some examples for reference:
Wfuzz
SQLMap
Zed Attack Proxy
MobSF mobile security testing framework
Commercial tools:
Burp Suite pro
Nessus pro
ThunderScan
Testing checklists
All penetration tests are performed using checklists and depends on platforms the target system is originated. There are 3 maintained checklists to do a penetration test:
Web Application testing checklist
Mobile Application testing checklist
Client Application testing checklist
The checklists are filled out during the penetration tests to help testers to follow procedures and cover as much of attack surface as possible. The checklist consists of the test name, testing status and status.
Sample values for field “Tested”:
Yes (tested for vulnerability)
No (not tested for vulnerability)
N/A (not applicable for target system/scope)
Possible values for field “Vulnerable”:
Yes (vulnerability exist)
No (vulnerability not identified)
This checklist is used during most of the penetration tests that involves Web applications and their components. This checklist is based on OWASP testing guide.
Web Application testing checklist
Information Gathering
Manually explore the site
Spider/crawl for missed or hidden content
Check for files that expose content, such as robots.txt, sitemap.xml, .DS_Store
Check the caches of major search engines for publicly accessible sites
Check for differences in content based on User Agent (e.g., Mobile sites, access as a Search engine Crawler)
Perform Web Application Fingerprinting
Identify technologies used
Identify user roles
Identify application entry points
Identify client-side code
Identify multiple versions/channels (e.g. web, mobile web, mobile app, web services)
Identify co-hosted and related applications
Identify all hostnames and ports
Identify third-party hosted content
Configuration Management
Check for commonly used application and administrative URLs
Check for old, backup, and unreferenced files
Check HTTP methods supported and Cross Site Tracing (XST)
Test file extensions handling
Test for security HTTP headers (e.g., CSP, X-Frame-Options, HSTS)
Test for policies (e.g., Flash, Silverlight, robots)
Test for non-production data in live environment, and vice-versa
Check for sensitive data in client-side code (e.g. API keys, credentials)
Secure Transmission
Check SSL Version, Algorithms, Key length
Check for Digital Certificate Validity (Duration, Signature and CN)
Check credentials only delivered over HTTPS
Check that the login form is delivered over HTTPS
Check session tokens only delivered over HTTPS
Check if HTTP Strict Transport Security (HSTS) in use
Authentication
Test for user enumeration
Test for authentication bypass
Test for bruteforce protection
Test password quality rules
Test remember me functionality
Test for autocomplete on password forms/input
Test password reset and/or recovery
Test password change process
Test CAPTCHA
Test multi factor authentication
Test for logout functionality presence
Test for cache management on HTTP (e.g., Pragma, Expires, Max-age)
Test for default logins
Test for user-accessible authentication history
Test for out of channel notification of account lockouts and successful password changes
Test for consistent authentication across applications with shared authentication schema / SSO
Session Management
Establish how session management is handled in the application (e.g., tokens in cookies, token in URL)
Check session tokens for cookie flags (httpOnly and secure)
Check session cookie scope (path and domain)
Check session cookie duration (expires and max-age)
Check session termination after a maximum lifetime
Check session termination after relative timeout
Check session termination after logout
Test to see if users can have multiple simultaneous sessions
Test session cookies for randomness
Confirm that new session tokens are issued on login, role change and logout
Test for consistent session management across applications with shared session management
Test for session puzzling
Test for CSRF and clickjacking
Authorization
Test for path traversal
Test for bypassing authorization schema
Test for vertical Access control problems (a.k.a. Privilege Escalation)
Test for horizontal Access control problems (between two users at the same privilege level)
Test for missing authorization
Data Validation
Test for Reflected Cross Site Scripting
Test for Stored Cross Site Scripting
Test for DOM based Cross Site Scripting
Test for Cross Site Flashing
Test for HTML Injection
Test for SQL Injection
Test for LDAP Injection
Test for ORM Injection
Test for XML Injection
Test for XXE Injection
Test for SSI Injection
Test for XPath Injection
Test for XQuery Injection
Test for IMAP/SMTP Injection
Test for Code Injection
Test for Expression Language Injection
Test for Command Injection
Test for Overflow (Stack, Heap, and Integer)
Test for Format String
Test for incubated vulnerabilities
Test for HTTP Splitting/Smuggling
Test for HTTP Verb Tampering
Test for Open Redirection
Test for Local File Inclusion
Test for Remote File Inclusion
Compare client-side and server-side validation rules
Test for NoSQL injection
Test for HTTP parameter pollution
Test for auto-binding
Test for Mass Assignment
Test for NULL/Invalid Session Cookie
Denial of Service
Test for anti-automation
Test for account lockout
Test for HTTP protocol DoS
Test for SQL wildcard DoS
Business Logic
Test for feature misuse
Test for lack of non-repudiation
Test for trust relationships
Test for integrity of data
Test segregation of duties
Cryptography
Check if data which should be encrypted is not
Check for wrong algorithms’ usage depending on context
Check for weak algorithms’ usage
Check for proper use of salting
Check for randomness functions
Risky Functionality - File Uploads
Test that acceptable file types are whitelisted
Test that file size limits, upload frequency and total file counts are defined and are enforced
Test that file contents match the defined file type
Test that all file uploads have Anti-Virus scanning in-place.
Test that unsafe filenames are sanitized
Test that uploaded files are not directly accessible within the web root
Test that uploaded files are not served on the same hostname/port
Test that files and other media are integrated with the authentication and authorization schemas
Risky Functionality - Card Payment
Test for known vulnerabilities and configuration issues on Web Server and Web Application
Test for default or guessable password
Test for non-production data in live environment, and vice-versa
Test for Injection vulnerabilities
Test for Buffer Overflows
Test for Insecure Cryptographic Storage
Test for Insufficient Transport Layer Protection
Test for Improper Error Handling
Test for all vulnerabilities with a CVSS v2 score > 4.0
Test for Authentication and Authorization issues
Test for CSRF
HTML5
Test Web Messaging
Test for Web Storage SQL injection
Check CORS implementation
Check Offline Web Application
Mobile applications checklists
Android penetration testing checklist
Information Gathering
Reverse Engineering the Application Code
Testing for Common Libraries and Fingerprinting
Enumeration of Application Known Controllers
Information Disclosure by Logcat
Application Local Storage Flaws
Hidden Secrets in the Code
Storing Sensitive Data on Shared Storage (exposed to all applications without any restrictions)
Cryptographic Based Storage Strength
Content Providers Access Permissions
Content Providers SQL Injection
Privacy and Metadata Leaks
IPC Security
User Propriety Data in Logcat
Technical Valuable Data in Logcat
Exposed Components and Cross Application Authorization
Permissions & Digital Signature Data Sharing Issues
Clipboard Separation
Public Intents and Unauthenticated Data Sources
Public Intents and Authorization Flaws
Code Puzzling and Abusing Application State
Race Conditions, Deadlocks and Concurrency Threats
In Device Denial of Service attacks
Privacy Breaches
Exposing Device Specific Identifiers in Attacker Visible Elements
Exposure of Private User Data to Attacker Visible Components
Tracking Application Installations in Insecure Means
UI Security
Tap Jacking
Client Side based Authorization Decisions
Business Logic Testing
Bypassing business logic
Execution of Untrusted Code
WebView Security
Exposing External Java Interfaces in WebViews DOM
JavaScript Execution Risks at WebViews
Code Signing
Loading Dynamic DEX onto Dalvik
Abusing Dynamic Code Execution Decisions
Stack Based Buffer Overflows
Heap Based Buffer Overflows
Object Lifetime Vulnerabilities (Use-after-free, double free’s)
Format Strings Vulnerabilities
NDK Exposed Code Secrets
Integer Overflows
Integer Underflows
Transport Layer Security
Insecure Transport Layer Protocols
TLS Authenticity Flaws
TLS Weak Encryption
Bypassing TLS Certificate Pinning
TLS Known Issues – CRIME, BREACH, BEAST, Lucky13, RC4, etc.
Disable certificate validation
Authentication Flaws
Using Insecure Authentication Vectors (IMEI, MAC, etc..)
Cross Application Authentication
Local Authentication Bypass Threats
Client Side Based Authentication Flaws
Client Side Authorization Breaches
Android Sandbox Security
Shared User Resources
Excessive Permissions
Disclosure of Privileged Data to Public Resources
iOS penetration testing checklist
Information Gathering
Information Disclosure by Apple System Log (ASL)
Testing for Common Libraries and Fingerprinting
Enumeration of Application Known Controllers
Application Local Storage Flaws
Hidden Secrets in the Code
Storing Sensitive Data on Shared Storage
Storing Sensitive Data in application Cache files
Cryptographic Based Storage Strength
Content Providers Access Permissions
Content Providers SQL Injection
Privacy and Metadata Leaks
IPC Security
User Propriety Data in ASL
Technical Valuable Data in ASL
Exposed Components and Cross Application Authorization
Permissions & Digital Signature Data Sharing Issues
Clipboard Separation
Code Puzzling and Abusing Application State
Race Conditions, Deadlocks and Concurrency Threats
In Device Denial of Service attacks
Privacy Breaches
Exposing Device Specific Identifiers in Attacker Visible Elements
Exposure of Private User Data to Attacker Visible Components
Tracking Application Installations in Insecure Means
UI Security
Tap Jacking
Client Side based Authorization Decisions
Business Logic Testing
Bypassing business logic
Bypassing controllers hierarchy
Execution of Untrusted Code
WebView Security
Exposing External Java Interfaces in WebViews DOM
JavaScript Execution Risks at WebViews
Code Signing
Abusing Dynamic Code Execution Decisions
Stack Based Buffer Overflows
Heap Based Buffer Overflows
Object Lifetime Vulnerabilities (Use-after-free, double free’s)
Format Strings Vulnerabilities
Integer Overflows
Integer Underflows
Exposing External Java Interfaces in WebViews DOM
Transport Layer Security
Insecure Transport Layer Protocols
TLS Authenticity Flaws
TLS Weak Encryption
Bypassing TLS Certificate Pinning
TLS Known Issues – CRIME, BREACH, BEAST, Lucky13, RC4, etc.
Disable certificate validation
Authentication Flaws
Using Insecure Authentication Vectors (IMEI, MAC, etc..)
Cross Application Authentication
Local Authentication Bypass Threats
Client Side Based Authentication Flaws
Client Side Authorization Breaches
Application Sandbox Security
Shared User Resources
Excessive Permissions
Disclosure of Privileged Data to Public Resources
Application Keychain Security
Keychain Resources
Misuse of keychain storage
Developer Group Keychain usage
Client Application testing (Windows/OSX/Linux)
Information Gathering
Information Disclosure in logs
Testing for Common Libraries and Fingerprinting
Application Local Storage Flaws
Hidden Secrets in the Code
Storing Sensitive Data on Shared Storage
Storing Sensitive Data in application Cache files
Cryptographic Based Storage Strength
Content Providers Access Permissions
Content Providers SQL Injection
Privacy and Metadata Leaks
IPC Security
Exposed Components and Cross Application Authorization
Permissions & Digital Signature Data Sharing Issues
Clipboard Separation
Code Puzzling and Abusing Application State
Race Conditions, Deadlocks and Concurrency Threats
In Device Denial of Service attacks
Privacy Breaches
Exposing Device Specific Identifiers in Attacker Visible Elements
Exposure of Private User Data to Attacker Visible Components
Tracking Application Installations in Insecure Means
UI Security
Click Jacking
Client Side based Authorization Decisions
Business Logic Testing
Bypassing business logic
Execution of Untrusted Code
WebView Security
Code Signing
Abusing Dynamic Code Execution Decisions
Stack Based Buffer Overflows
Heap Based Buffer Overflows
Object Lifetime Vulnerabilities (Use-after-free, double free’s)
Format Strings Vulnerabilities
Integer Overflows
Integer Underflows
Transport Layer Security
Insecure Transport Layer Protocols
TLS Authenticity Flaws
TLS Weak Encryption
Bypassing TLS Certificate Pinning
TLS Known Issues – CRIME, BREACH, BEAST, Lucky13, RC4, etc.
Disable certificate validation
Authentication Flaws
Using Insecure Authentication Vectors (IMEI, MAC, etc..)
Cross Application Authentication
Local Authentication Bypass Threats
Client Side Based Authentication Flaws
Client Side Authorization Breaches
Application Sandbox Security
Shared User Resources
Excessive Permissions
Disclosure of Privileged Data to Public Resources
Test Execution
Generally, the Penetration Tests for web applications are based on the OWASP Testing Guide, which offers a wide and efficient spectrum for the testing of these services.

Phases
Phase 1. Before the real tests and scans begin the legal terms and further requirements as well as the exact scope of the tests must be specified in phase 1. If all organizational frameworks are negotiated the start of phase 2 can begin.
Phase 2. In this part of the Penetration Test the test object will be analyzed by analysis like port-scans and fingerprinting. Furthermore, this phase will make use of automated scan tools, to gather as much information as possible about the test object and to execute first automated attacks on the systems. Based on the results of the applied tools it is possible to determine first potential weak points which by then the tools will exploit already. Based on this information and the analysis of phase 3 further manual attacks will be executed in phase 4.
Phase 3. The corresponding scan-results will be appraised and analyzed. Thereby on one hand the already executed attacks by the tools will be evident and on the other hand the gathered information of the scans will be used for the execution of manual attacks in phase 4.
Phase 4. Based on the scan results from phase 2 plus the more exact analysis in phase 3 further manual attacks will be executed on the test object. This phase will attempt to take advantage of these weak points, for example to execute attacks for the expansion of rights (privilege escalation) or for general testing of rights (access control). In addition, further attacks like XSS or SQL-Injection will be executed.
Phase 5. Closing the identified weak points and findings will be evaluated and documented based on the vulnerability measurement (either the risk matrix or CVSS). Thereby the probability of exploitation as well as the severity of the weak point and additional parameter will be used to generate a proper Risk Score.
Vulnerability scoring
This chapter explains different vulnerability scoring systems used in penetration tests. There are 2 main vulnerability scoring systems used.
Risk Matrix
This scoring method is based on risk matrix with 2 dimensions:
Probability and Impact.
Probability represents the ease of exploitation and effort required to exploit it.
It has a score of 1 to 5, 1 representing low probability and 5 - high probability. Impact represents potential damage if vulnerability was successfully exploited.
It has a score of Probability squared and has 1 to 25 points, 25 representing extreme impact.
1
Extremely low probability
2
Low probability
3
Medium probability
4
High probability
5
Extremely high probability
By multiplying both dimensions, risk matrix can be assembled

To make the risk assessment simpler, risk categories can be divided by their score
1-9
Low risk
12-32
Medium risk
36-75
High risk
80-125
Critical risk
Common Vulnerability Scoring System (CVSS)
This scoring system may be used for most penetration tests as it has been standardized and is compatible with most of the vulnerability management frameworks and tools. CVSSv3 is represented by the vulnerability vector string that can be represented using 3 levels that varies by given details:
Base score
Temporal Score
Environmental Score
In most of the tests, base and temporal vulnerability score is used.
More information about CVSS scoring system can be found here: Common Vulnerability Scoring System Version 3.1 Calculator
Depending on the requirements of the penetration test, either scoring methodology may be used. In some cases, both scoring systems are used.
Review and Update
This Standard must be maintained in accordance with the Information Security Policy.
Revision History
0.1
LŠ
GK
2023-05-20
2023-05-23
0.2
LŠ
DM
2023-11-02
2023-11-02
0.3
GK
DM
2024-09-10
2024-09-10
Last updated