Request manual penetration testing

You can request Manual Penetration Testing (MPT) to have Veracode perform real-world attacks on your application in a runtime environment. Each MPT test identifies security findings (flaws and vulnerabilities) in your applications and publishes the results to the Veracode Platform.

About MPT

Penetration testing provides the following benefits:

• Identifies design flaws.
• Exploits vulnerabilities.
• Leverages combinations of lower impact flaws into higher impact vulnerabilities.
• Determines if identified flaws affect the confidentiality, integrity, or availability of the application.

The objectives of a web-focused penetration assessment include testing using proprietary or public tools to:

• Assess how vulnerabilities might be exploited against a target while establishing a running profile of attack methods discovered.
• Execute test cases to confirm the vulnerability and attempt to determine the impact to business.
• Customize and expand attack payloads, accounting for the specifics of the implementation of the target and environment.
• Analyze captured data for vulnerability patterns, interpreting the results, and developing remediation recommendations.

Human testers identify unorthodox ways of attacking applications and infrastructures to understand the design and functionality, complex authorization processes, and business logic requirements that might not be possible for computing systems to replicate today. These insights enable developers to secure their applications and infrastructure against a broader range of attacks.

Veracode recommends that your organization use Veracode Manual Penetration Testing in conjunction with other automated security assessments such as Veracode Static Analysis, Dynamic Analysis, and SCA to ensure maximum coverage from your security program.

Veracode uses industry standards for classifying and reporting manual penetration test vulnerabilities, including:

• Common Vulnerability Scoring System (CVSS) v3
• Common Weakness Enumeration (CWE)
• Common Attack Pattern Enumeration and Classification (CAPEC)

Details of Veracode Manual Penetration Testing are available in the methodology section of the Veracode Detailed PDF Report and Customizable PDF Report.

Veracode performs all Manual Penetration Testing according to industry-standard testing methodologies where applicable. The following table describes testing types, methodologies, and vulnerability types that form the foundation of Veracode MPT.

Test type	Methodology	Vulnerabilities
Web application/API	PTES (Penetration Testing Execution Standard), OWASP Testing Guide	OWASP Top 10 and CWE Top 25
Mobile application	PTES (Penetration Testing Execution Standard), OWASP Mobile Security Testing Guide	OWASP Mobile Top 10
Desktop or thick-client applications	PTES (Penetration Testing Execution Standard), OWASP recommended testing guidance and best practices	Application Logic Code Injection Local Storage Binary Exploitation and Reverse Engineering Excessive Privileges Unencrypted Storage of Sensitive Information Unencrypted Transmission of Sensitive Information Weak Encryption Implementations Weak Assembly Controls Weak GUI Controls Weak or Default Passwords
Internet of things (IoT) and embedded systems	PTES (Penetration Testing Execution Standard), OWASP IoT Testing Guide and other industry best practices	OWASP IoT Top 10
Infrastructure and Operations (DevOps Penetration Testing)	PTES (Penetration Testing Execution Standard), NIST SP 800-115, PCI DSS 11.3 (for PCI engagements)	Can vary depending on scope and rules of engagement

Request MPT

To request Manual Penetration Testing (MPT), contact your Veracode account manager or sales team.

Access MPT results

Veracode MPT test results provide the findings identified in your applications and are available from the Veracode Platform. We publish the results after each test.

To access MPT test results for an application, go to the Applications explore in Veracode Analytics or use the Reporting API.

MPT tests involve an initial test of your application to identify the first set of MPT findings, followed by retests to identify newly introduced findings and to update the status of findings from previous tests.

Review MPT results

The Veracode Platform can generate a report that includes manual assessment results, usually from MPT scans or code reviews. These results differ from the results of automated scans in several important ways, including objectives, attack values, and common attack patterns.

You perform a manual penetration assessment to observe the application code in a runtime environment and to simulate real-world attack scenarios. Manual testing can identify design flaws, evaluate environmental conditions, compound multiple lower-risk flaws into higher-risk vulnerabilities, and determine if identified flaws affect the confidentiality, integrity, or availability (CIA) of the application.

Objectives

The stated objectives of a manual penetration assessment are:

• Perform testing, using proprietary and/or public tools, to determine whether it is possible for an attacker to:
  • Circumvent authentication and authorization mechanisms
  • Escalate application user privileges
  • Hijack accounts belonging to other users
  • Violate access controls placed by the site administrator
  • Alter data or data presentation
  • Corrupt application and data integrity, functionality, and performance
  • Circumvent application business logic
  • Circumvent application session management
  • Break or analyze use of cryptography within user-accessible components
• Determine possible extent access or impact to the system by attempting to exploit vulnerabilities
• Score vulnerabilities using the Common Vulnerability Scoring System (CVSS)
• Provide tactical recommendations to address security issues of immediate consequence
• Provide strategic recommendations to enhance security by leveraging industry best practices

Attack values

To achieve the stated objectives, Veracode performs these tests as part of the manual penetration assessment, when applicable to the platforms and technologies in use:

• Cross Site Scripting (XSS)
• SQL Injection
• Command Injection
• Cross Site Request Forgery (CSRF)
• Authentication/Authorization Bypass
• Session Management testing, including token analysis, session expiration, and logout effectiveness
• Account Management testing, including password strength, password reset, account lockout, etc.
• Directory Traversal
• Response Splitting
• Stack/Heap Overflows
• Format String Attacks
• Cookie Analysis
• Server Side Includes Injection
• Remote File Inclusion
• LDAP Injection
• XPATH Injection
• Internationalization attacks
• Denial of Service testing at the application layer only
• AJAX Endpoint Analysis
• Web Services Endpoint Analysis
• HTTP Method Analysis
• SSL Certificate and Cipher Strength Analysis
• Forced Browsing

CAPEC attack pattern classification

These attack pattern classifications are used to group similar application flaws discovered during manual penetration testing. Attack patterns describe the general methods employed to access and exploit the specific weaknesses that exist within an application. CAPEC (Common Attack Pattern Enumeration and Classification) is an effort led by Cigital, Inc. and is sponsored by the United States Department of Homeland Security's National Cyber Security Division.

Abuse of functionality

Exploitation of business logic errors or misappropriation of programmatic resources. Application functions are developed to specifications with particular intentions, and these types of attacks serve to undermine those intentions.

Examples:

• Exploiting password recovery mechanisms
• Accessing unpublished or test APIs
• Cache poisoning

Spoofing

Impersonation of entities or trusted resources. A successful attack will present itself to a verifying entity with an acceptable level of authenticity.

Examples:

• Man in the middle attacks
• Checksum spoofing
• Phishing attacks

Probabilistic techniques

Using predictive capabilities or exhaustive search techniques in order to derive or manipulate sensitive information. Attacks capitalize on the availability of computing resources or the lack of entropy within targeted components.

Examples:

• Password brute forcing
• Cryptanalysis
• Manipulation of authentication tokens

Exploitation of authentication

Circumventing authentication requirements to access protected resources. Design or implementation flaws may allow authentication checks to be ignored, delegated, or bypassed.

Examples:

• Cross-site request forgery
• Reuse of session identifiers
• Flawed authentication protocol

Resource depletion

Affecting the availability of application components or resources through symmetric or asymmetric consumption. Unrestricted access to computationally expensive functions or implementation flaws that affect the stability of the application can be targeted by an attacker in order to cause denial of service conditions.

Examples:

• Flooding attacks
• Unlimited file upload size
• Memory leaks

Exploitation of privilege/trust

Undermining the application's trust model in order to gain access to protected resources or gain additional levels of access as defined by the application. Application that implicitly extend trust to resources or entities outside of their direct control are susceptible to attack.

Examples:

• Insufficient access control lists
• Circumvention of client side protections
• Manipulation of role identification information

Injection

Inserting unexpected inputs to manipulate control flow or alter normal business processing. Applications must contain sufficient data validation checks in order to sanitize tainted data and prevent malicious, external control over internal processing.

Examples:

• SQL Injection
• Cross-site scripting
• XML Injection

Data structure attacks

Supplying unexpected or excessive data that results in more data being written to a buffer than it is capable of holding. Successful attacks of this class can result in arbitrary command execution or denial of service conditions.

Examples:

• Buffer overflow
• Integer overflow
• Format string overflow

Data leakage attacks

Recovering information exposed by the application that may itself be confidential or may be useful to an attacker in discovering or exploiting other weaknesses. A successful attack may be conducted passive observation or active interception methods. This attack pattern often manifests itself in the form of applications that expose sensitive information within error messages.

Examples:

• Sniffing clear-text communication protocols
• Stack traces returned to end users
• Sensitive information in HTML comments

Resource manipulation

Manipulating application dependencies or accessed resources in order to undermine security controls and gain unauthorized access to protected resources. Applications may use tainted data when constructing paths to local resources or when constructing processing environments.

Examples:

• Carriage Return Line Feed log file injection
• File retrieval via path manipulation
• User specification of configuration files

Time and state attacks

Undermining state condition assumptions made by the application or capitalizing on time delays between security checks and performed operations. An application that does not enforce a required processing sequence or does not handle concurrency adequately will be susceptible to these attack patterns.

Examples:

• Bypassing intermediate form processing steps
• Time-of-check and time-of-use race conditions
• Deadlock triggering to cause a denial of service

MPT Flaw Matching

The MPT Flaw Matching feature evaluates findings from successive MPT tests of the same application. It identifies recurring findings across multiple tests and links the matched instances together. This link ensures that all instances of the same finding across successive tests trace back to the original test in which it was first identified.

MPT Flaw Matching adds the following information to findings:

• A status, such as New or Fixed.
• Consistent flaw IDs for each finding across test results. When we identify the same MPT finding in multiple tests of the same application, all instances inherit the flaw ID from the first time we found it.
• First found dates that display the publication date of the test in which we first identified the finding.

First found date

The first found date indicates when a finding was first identified during a test. The value is the publication date of the test results from the test in which we found the finding. For example, if we run tests in January, February, and March, and the January test found two findings that remain open, those findings appear in the March test results with a first found date of January.

Any findings identified before the release of MPT Flaw Matching might have inaccurate first found dates.

Because MPT findings retain their first found dates, you can include them in the remediation grace periods of any security policies applied to your applications. Grace periods provide teams flexibility in meeting security compliance goals before certain findings impact the application’s policy score.

MPT finding statuses

In the results, each MPT finding shows one of the following status values.

• New: findings identified for the first time in the latest test. All findings from the initial test show a New status.
• Open: unresolved findings that were identified in a previous test and again in the latest test. Open findings retain their original flaw IDs (assigned the first time they were identified) and their first found dates. Any New findings identified during an initial or subsequent test that we also identify in the latest test change to Open status.
• Fixed: resolved findings identified in a previous test but not in the latest test. Fixed findings retain their original flaw IDs (assigned the first time they were identified) and their first found dates.
• Closed: findings that we did not identify during two successive tests. When a finding is Closed, we remove it from the results in the Veracode Platform Analytics and reports.

About historical MPT findings

MPT Flaw Matching does not support any findings identified in a given application before the release of the flaw matching feature. These findings continue to show an Open status, and results from the latest test replace the results from the previous test.

To start using the benefits of MPT Flaw Matching on an application that you tested previously, you must run a new test on the given application. When we publish the results of the first new test, all findings will have a New status.