Code review verifies the security of the source code of your application to find security flaws that could have been overlooked during the development phase and could leave your application vulnerable to attacks. Source code review helps organizations identify risks in the eventuality of an attack or data breach. It helps to eliminate vulnerabilities by the software development team at an early stage thereby enhancing the code effectiveness to reduce application maintenance costs and overall development costs.
An insecure application could potentially allow an attacker to gain unauthorized access, compromise application functionality, or steal sensitive data thereby impacting the business not only in lost revenue and legal sanctions but also through reputational damage. Verifying source code prior to application deployment can help to reduce the time and resources that would otherwise take if vulnerabilities were found after the code has been deployed. Implementing source code reviews alongside secure coding best practices is important to provide assurance about the security of your application during the development process.
Secure Code Review
Our approach to the secure code review is to first understand the purpose of the whole application, then the purpose of each function, as it fits into the Customer Name environment. By establishing what is expected, our auditor can more effectively design attacks that are likely to succeed. This understanding is critical in ensuring not only are common vulnerabilities detected but attacks very specific to your application and the business process it supports can be crafted and tested.
The tester will use a comprehensive testing methodology that will identify security vulnerabilities from the OWASP Top 10 as well as security vulnerabilities that are specific to the application itself.
Below is a description of how we specifically perform Secure Code Review.
The first phase of the methodology covers the information-gathering activities needed in order to properly plan and carry out the code review. This includes the compilation of basic information about the code to be reviewed, an analysis of the applicable controls, and the preparation of the testing environment if any specific requirements are demanded by the particularities of the code.
To further organize this phase, three main activities have been defined:
Preparation: This activity comprises all the interviews, meetings, and information-gathering activities needed to properly define the scope, objectives, and needs of the code to be reviewed.
Test Design: once the scope, objectives, and custom needs of the code have been identified, the next logical step is to establish the test cases that are going to be considered in order to achieve the objectives that have been set. This is reflected in the checklist, indicating those cases that are not applicable.
Environment Preparation: Before starting the next phase, it is necessary to ensure that the testing environment is prepared to carry out the tests selected during the previous activity. This includes the installation and configuration of the tools.
The next phase covers the execution of the test cases selected for the code review in the previous phase, taking into consideration the scope, objectives, and constraints set. The execution process is divided into three sequential phases, each providing data as input for the next one. All of them are carried out by the code review team, using both automated and manual tools. To further organize this phase, three main activities are defined:
Managed mode: This activity covers the execution of the automated tools selected for the analysis of the code. The following categories are analyzed:
> Data/Input Management
> Authentication Controls
> Session Management
> Authorization Management
> Cryptography
> Error Handling/Information Leakage
> Software communications
> Logging/Auditing
> Secure Code Design
Defined Mode: Once the managed mode activity is finished, the code review team generates a set of results, by complementing these results with a full manual review of the applicable controls.
Optimized Mode: The final part of the execution phase focuses on those sections of the application found to be most at risk, alongside several more specific tests that require further evaluation.
Source Code Review – Scope & Approach
Hybrid Approach: By using both automated and manual testing methods, we actively set the industry benchmark in security testing. We collect large amounts of data with automated testing tools and then use that data to conduct manual testing methods to explore further. This hybrid approach ensures that your application and organization are thoroughly covered and secure against potential attacks.
We conduct manual code review & automated code review and follow the industry best practices and guidelines specified by OWASP Top Ten, OWASP Code Review Guide, ASVS, WASC, SANS, and NIST for security risks and provide recommendations according to industry-standard secure coding techniques for software development.
Our manual review team reviews the application security architecture and develops custom rules to identify security issues with the application code. We review the code, both manually and using automation tools, from a developer’s application development perspective to identify flaws in design and programming and vulnerable programming constructs and functions.
We assess the identified vulnerabilities and back doors thoroughly to eliminate false positives. We also prepare an in-depth report with the identified vulnerabilities and recommendations to fix the code, mitigate risks, and improve cybersecurity during the development phase to reduce your development costs. Security code review pricing depends on the approximate lines of code of the application.
Supported languages and platforms (commercial & open source) include Java, C#, ASP, VB.Net, VB, C++, Php, JS, Ruby, Apex, VBScript, Perl, Android, iOS, HTML5, PL SQL, Python, Scala, Go, Kotlin, Groovy & Cobol.
The vulnerabilities that are checked as part of the security test include Access Control, Arithmetic Operation On Boolean, Blind SQL Injections, Buffer Overflow, CGI Reflected XSS, CGI Stored XSS, Client-Side Only Validation, Code Injection, Command Injection, Connection String Injection, Cookie not Sent Over SSL, Cookies Scoping, Cross-Site History Manipulation, Dangerous File Upload, Dangerous Functions, Data Filter Injection, DB Parameter Tampering, Dead Code, Deprecated And Obsolete, DoS by Sleep, DoS by Unreleased Resources, Double Free, Environment Injection, Environment Manipulation, Files Canonicalization Problems, Files Manipulation, Frame Spoofing, Hardcoded Absolute Path, Hardcoded Password, Impersonation Issue, LDAP Injection, Password in Connection String, Process Control, Reflected XSS, Resource Injection, SQL injection, Stored XSS, UTF7 XSS, XPath Injection, etc.
The first phase of the Source Code Review methodology covers the information-gathering activities needed in order to properly plan and carry out the code review. This includes the compilation of basic information about the code to be reviewed, an analysis of the applicable controls, and the preparation of the testing environment if any specific requirements are demanded by the particularities of the code.
Code Review Methodology
Our code review covers OWASP Top 10 and WASC 27 classes. Additionally, we review for
Authentication and User Management
> User credentials are encrypted in the datastore
> Security policies are configurable (not hardcoded)
> Standard security frameworks are used (instead of custom code)
> SSL is used to protect user credentials and authentication tokens
> Authentication cookies do not persist
> Authentication cookies are encrypted
> Cookie names and paths are used
> The application handles user management events such as authentication failure, password reset, password change, account lockout, and cancel account
> The application handles suspicious events such as multiple failed login attempts, session replay, and attempted access to restricted resources
> Strong password policies are enforced
> Authentication credentials are not passed by HTTP GET
Authorization
> Authentication and authorization should be the first logic executed for each request
> Authorization checks are granular (page and directory level)
> Deny access to pages and data by default
> Re-authenticate for requests that have side-effects
> ACLs are configured for all files
> Authorization based on clearly defined roles
> Authorization works properly and cannot be circumvented by parameter manipulation
> Authorization cannot be bypassed by cookie manipulation
Session Management
> No session parameters passed in URLs
> Session cookies expire in a reasonably short time
> Session cookies are encrypted
> Session data is being validated
> Private data in cookies is kept to a minimum
> Application avoids excessive cookie use
> The session id is complex
> Session storage is secure
> Application properly handles invalid session IDs
> Session limits such as inactivity timeout are enforced
> Logout invalids the session
> Session resources are released when the session is invalidated
Input Validation
> All external input is validated without exception
Where possible input is restricted to known good chars
Data is validated server-side (security should not rely on client-side validations)
> The application validates numerical input and rejects unexpected input
> Application efficiently evaluates input length
> The strong separation between data and commands
> The strong separation between data and client-side scripts
> Data should be checked for special characters before being passed to SQL, LDAP, OS, and third-party commands
> HTTP headers are validated for each request (e.g. Referrer)
Cryptography
> Sensitive data has been secured in memory, storage, and transit
> Restricted areas require SSL
> Sensitive information not passed to/from non-SSL pages
> Proper SSL setup
> SSL provider supports only strong algorithms
> Web-based admin tools require SSL
> Decryption services protected by authentication/authorization
> Require SSL for the login page
> Securely storing cryptographic keys
Exception Handling
> When exceptions occur the application fails securely
> Error messages do not reveal sensitive information
> System errors are never shown to users
> Resources are released and transactions rolled back when there is an error
Auditing & Logging
> All user/system actions are logged
> Sensitive information is not logged (e.g. Passwords)
> Logging for user management events (e.g. Password reset)
> Unusual activity such as multiple login attempts is logged
> Logs have enough detail to reconstruct events for audit purposes
> Logging is highly configurable (logging levels)
General
> Proper configuration of frameworks
> Libraries are up-to-date
> System calls have their return status checked
> Efficient memory usage
> No exposures to buffer overruns
> Code, services, commands, and processes are executed using minimal privileges (least privileges)
> Code has no back doors
> Debugging code and test harnesses have been removed
Vulnerabilities Reviewed
The details of prominent vulnerabilities that are checked during the Source Code Review:
Injection Flaws:- Threats such as SQL injection, OS Command Injection, and LDAP injection, to verify the user data sent to an application as part of a command or query.
Cross-Site Scripting (XSS):- XSS vulnerabilities occur when a web application accepts user inputs on a web page without proper validation. Cross-site scripting allows an attacker to execute scripts in the victim’s browser that can hijack user sessions, deface websites, or redirect the user to malicious sites.
Data Exposure:- Many web apps and APIs do not properly protect sensitive information, and cybercriminals can steal or tamper with such data.
Broken Authentication:- Authentication and session management are frequently designed incorrectly, allowing cybercriminals to compromise user credentials, keys, or session tokens, or to exploit other flaws to steal other users’ identities.
Broken Access Control:- Restrictions on what authenticated users can do are often not properly enforced which can lead to horizontal and vertical privilege escalation vulnerabilities.
XML External Entities:- Numerous legacy or poorly configured XML parsers evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.
The following methods are used during the source code review process, based on customer requirements:
Manual Code Review:- Our experts manually identify security vulnerabilities line by line within source code that an automated tool would often miss. Such vulnerabilities typically exist within critical functionality, including business logic, encryption, network communications, and access controls.
Automated Code Review:- A fully automated approach can ensure breadth of coverage in the identification of some of the most commonly found vulnerabilities, using commercial code-scanning and our custom tools.
Source Code Review is generally conducted as part of the Penetration Testing (VAPT) exercise.
