Software Audit
Static Code Review
To find the security posture of the application that can characterized from the perspective of the effect, such as number of
vulnerabilities and their locations in the subject; excluding the risk rating of the vulnerabilities and the cause or origin, such
as coding errors, architectural flaws, and configuration issues.
Developing the thread model
Decomposing the application use a process of manual inspection to understand how the application works,
its assets, functionality, and connectivity.
Defining and classifying the assets classify the assets into tangible and intangible assets and rank them
according to business importance.
Exploring potential vulnerabilities - whether technical, operational or management.
Exploring potential threats develop a realistic view of potential attack vectors from an attackers
perspective, by using threat scenarios or attack trees.
Creating mitigation strategies develop mitigating controls for each of the threats deemed to be realistic.
The output from a threat model itself can vary but is typically a collection of lists and diagrams.
The OWASP Code Review Guide outlines an Application Threat Modeling methodology that can be used as a
reference for the testing applications for potential security flaws in the design of the application.
The attack surface
Exploring the attack surface includes dynamic and static data flow analysis: Where and when are variables set and how the variables are used
throughout the workflow, how attributes of objects and parameters might affect other data within the program
Firstly, all input to the code needs to be identified for All transactions within the application need to be identified and
determining if the parameters, method calls, and data analyzed along with the relevant security functions they invoke. The
exchange mechanisms implement the required security. areas that are covered during transaction analysis are:
Input, for example, can be:
Data/Input Validation of data from all untrusted sources.
Browser input
Authentication
Cookies
Session Management
Property files
Authorization
External processes
Cryptography (Data at rest and in transit)
Data feeds
Error Handling /Information Leakage
Service responses
Logging /Auditing
Flat files
Secure Code Environment.
Command line parameters
Environment variables
.
Proposed thread categorization
Type Example
Spoofing Threat action aimed to illegally access and use another user's credentials, such as
username and password
Tampering Threat action aimed to maliciously change/modify persistent data, such as
persistent data in a database, and the alteration of data in transit between two
computers over an open network, such as the Internet
Repudiation Threat action aimed to perform illegal operation in a system that lacks the ability
to trace the prohibited operations.
Information Threat action to read a file that they were not granted access to, or to read data in
disclosure transit
Denial of Threat aimed to deny access to valid users such as by making a web server
service temporarily unavailable or unusable.
Elevation of Threat aimed to gain privileged access to resources for gaining unauthorized
privilege access to information or to compromise a system
Method
Standard Thorough
PCI?
Requirement 6.3.7 mandates a code review of custom code:
6.3.7 - Review of custom code prior to release to production or customers in order to identify any potential
coding vulnerability. This requirement could be interpreted to mean that the code review must consider
other PCI requirements, namely:
6.5 - Develop all web applications based on secure coding guidelines such as the Open Web Application
Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover
prevention of common coding vulnerabilities in software development processes, to include the following:
6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session cookies)
6.5.4 Cross-site scripting (XSS) attacks
6.5.5 Buffer overflows
6.5.6 Injection flaws (for example, structured query language (SQL) injection)
6.5.7 Improper error handling
6.5.8 Insecure storage
6.5.9 Denial of service
6.5.10 Insecure configuration management
Common Weakness Enumeration (CWE)
ID Name
CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CWE-306 Missing Authentication for Critical Function
CWE-862 Missing Authorization
CWE-798 Use of Hard-coded Credentials
CWE-311 Missing Encryption of Sensitive Data
CWE-434 Unrestricted Upload of File with Dangerous Type
CWE-807 Reliance on Untrusted Inputs in a Security Decision
CWE-250 Execution with Unnecessary Privileges
CWE-352 Cross-Site Request Forgery (CSRF)
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
CWE-494 Download of Code Without Integrity Check
CWE-863 Incorrect Authorization
CWE-829 Inclusion of Functionality from Untrusted Control Sphere
CWE-732 Incorrect Permission Assignment for Critical Resource
CWE-676 Use of Potentially Dangerous Function
CWE-327 Use of a Broken or Risky Cryptographic Algorithm
CWE-131 Incorrect Calculation of Buffer Size
CWE-307 Improper Restriction of Excessive Authentication Attempts
CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
CWE-134 Uncontrolled Format String
CWE-190 Integer Overflow or Wraparound
CWE-759 Use of a One-Way Hash without a Salt
Vulnerabilities to focus
SQL Injection (SQLi)
LDAP Injection
Cross Site Scripting (XSS)
OS Command Injection
Cross Site Request Forgery (CSRF)
Privacy Violation
Cross Frame Scripting (XFS)
Session Hijacking
Path Traversal
Session Fixation
Reporting Requirements
Vulnerabilities can be classified according to different criteria. The most
commonly used vulnerability severity metric is the Forum of Incident
Response and Security Teams (FIRST) Common Vulnerability Scoring System
(CVSS)
When reporting the findings below is considered to be included the
following information:
The categorization of each vulnerability by type
The security threat that the issue is exposed to
The testing technique used to find the issue
The severity rating of the vulnerability (High, Medium, Low and/or CVSS score)
The root cause of security issues (e.g., security bugs, security flaw)
The remediation of the vulnerability (e.g., the countermeasure)