We have been performing Source Code Review (SCR) of multiple Java/JavaEE based Web Applications during the recent past. The results have convinced us and the customers that SCR is a valuable exercise that must be performed for business critical applications in addition to Penetration Testing. In terms of vulnerabilities, SCR has the potential to find some of the vulnerability classes that an Application Penetration Test will usually miss out. In this article we will provide a brief overview of some of the vulnerability classes which we frequently discover during an SCR that are missed out or very difficult to identify during Penetration Testing.
Additionally we hope we will be able to provide answers for the following commonly asked questions:
- I have already performed an Application Penetration Test. Do I still need to conduct a Source Code Review for the same application?
- What are the vulnerabilities found during Source Code Review that are often missed by Application Penetration Test?
Read More: Web Application Penetration Testing Service
Approach for Source Code Review
The approach for SCR is fundamentally different from an Application Penetration Test. While an Application Penetration Test is driven by apparently visible use-cases and functionalities, the maximum possible view of the application in terms of its source code and configuration is usually available during an SCR. Apart from auditing important use-cases following standard practices, our approach consists of two broad steps:
Finding Security Weaknesses (Insecure/Risky Code Blocks) (Sinks)
A security weakness is an insecure practice or a dangerous API call or an insecure design. Some examples of weaknesses are:
- Dynamic SQL Query: string query = "SELECT * FROM items WHERE owner = '" + userName + "' AND itemname = '" + ItemName.Text + "'";
- Dangerous or risky API call such as RunTime.exec, Statement.execute
- Insecure Design such as using only MD5 hashing of passwords without any salt.
Correlation between Security Weakness and Dynamic Input
Dynamic construction of an SQL Query without the necessary validation or sanitization is definitely a security weakness, however it may not lead to security vulnerability if the SQL query does not involve any untrusted data. Hence it is required to identify code paths that start with an user input and reaches a possibly weak or risky code block. The absence of this phase will leave huge number of false positive in the results.
This step generally involves enumerating sources and finding a path between source to sink. A source in this case is any user controlled and untrusted input e.g. HTTP request parameters, cookies, uploaded file contents etc.
Five Vulnerabilities Source Code Review should Find
1. Insecure or Weak Cryptographic Implementation
SCR is a valuable exercise to discover weak or below standard cryptography techniques used in applications such as:
- Use of MD5 or SHA1 without salt for password hashing.
- Use of Java Random instead of SecureRandom.
- Use of weak DES encryption.
- Use of weak mode of otherwise strong encryption such as AES with ECB.
- Susceptibility to Padding Oracle Attack.
2. Known Vulnerable Components
For a small-medium scale JavaEE based application, 80% of the code that is executed at runtime comes from libraries. The actual percentage for a given application can be identified by referencing Maven POM file, IVY dependency file or looking into the lib directory. It is a very common possibility for dependent libraries and framework components to have known vulnerabilities especially if the application is developed over considerable time frame. As an example, during 2011, following two vulnerable components were downloaded 22 million times:
- Apache CXF with Authentication Bypass Vulnerability
- Spring Framework with Remote Code Execution Vulnerability
During an SCR, known vulnerable components are easier to detect due to source code access and knowledge of exact version number of various libraries and framework components used, something that is lacking during an Application Penetration Testing.
3. Sensitive Information Disclosure
An SCR should discover if an application in binary (jar/war) or source code form may disclose sensitive information that may compromise the security of the production environment. Some of the commonly seen cases are:
- Logs: Application logs sensitive information such as credentials or access keys in log files.
- Configuration Files: Application discloses sensitive information such as shared secret or passwords in plain text configuration files.
- Hardcoded Passwords and Keys: Many applications depend on encryption keys that are hardcoded within the source code. If an attacker manages to obtain even a binary copy of the application, it is possible to extract the key and hence compromise the security of the sensitive data.
- Email address of Developers in Comments: A minor issue, but hardcoded email addresses and names of developers can provide valuable information to attackers to launch social engineering or spear phishing attacks.
4. Insecure Functionalities
An enterprise application usually goes through various transformations and releases. The application might have legacy functionality with security implications. An SCR should be able to find such legacy functionality and identify its security implications. Some of the examples of legacy functionalities with known security issues are given below:
- RMI calls over insecure channel.
- Kerberos implementation that are vulnerable to replay attack.
- Legacy authentication & authorization technique with known weaknesses.
- J2EE bad practices such as direct management of database/resource connection that may lead to a Denial of Service.
- Race condition bugs.
5. Security Misconfiguration
SCR should be able to find common security misconfiguration in application and its deployed environment related to database configuration, frameworks, application containers etc. Some of the commonly discovered issues include:
- Application containers and database servers are running with highest (unnecessary) privilege.
- Default accounts with password enabled and unchanged.
- Insecure local file storage.
Additional Notes
An in-depth Source Code Review exercise is a valuable activity that has significant additional benefits apart from those mentioned above.
It is possible to conduct an in-depth review of implementation of security controls such as Cross-site Request Forgery (CSRF) prevention, Cross-site Scripting (XSS) prevention, SQL Injection prevention etc. It is not uncommon to find codes that lack or misuse such controls in a vulnerable manner resulting in bypass of protection.
There are multiple APIs that are considered to be risky or insecure as per various secure coding guidelines. It is possible to discover usage of such API in a given application easily and quickly during an SCR process.
SCR has the added benefit of being non-disruptive i.e. this activity does not require access to production environment and will not cause any service disruption.
Source Code Review (SCR) is a valuable technique to discover vulnerabilities in your Enterprise Application. It discovers certain class of vulnerabilities, which are difficult to find by conventional Application Penetration Testing. However, it must be noted that Application Penetration Testing and Source Code Review are complementary in many ways and both independently contribute in enhancing overall security of application and infrastructure.
No comments:
Post a Comment