Application Code Reviews

We often find hidden vulnerabilities lurking in application code. With tight deadlines and evolving requirements, it can be challenging to ensure robust security coverage, especially without dedicated in-house experts.

Our experienced auditors focus on the most critical paths of your code, ensuring each security measure is rock solid. The outcome is a robust and dependable product, providing you with assurance.

 What is it?

Code review testing reviews an application’s source code to ensure security consideration in its critical paths. This includes steps to trace the path of user-controlled input through the application and verifying it is correctly handled, checking that encryption is performed appropriately, ensuring authorisation is effective, and looking for memory manipulation.

Source code review

This class of testing is aimed at reviewing an application’s source code to ensure that it considers security in its critical paths. This includes several  steps, such as tracing the path of user-controlled input through the application and verifying it is correctly handled, checking that any encryption is performed appropriately, ensuring authorisation is effective and looking for memory manipulation (buffer under- and overflows, heap overflows, integer overflows, format string manipulation).

This is important, particularly where such information is used in privileged operations, for example, whether OS command injection or buffer overflows are possible to trigger from a client perspective.

Common vulnerabilities can include:

Input validation

The correct use of input validation is particularly important in applications written with older frameworks, such as C, C++, VB and PHP; as these tend to have fewer built-in safeguards against such problems as SQL injection or OS command injection. Java and .NET based applications tend to exhibit fewer of these sorts of issues, partly because of superior library support for safe ways of carrying out such operations. However, robust input validation is required in any language.

Timing attacks and buffer overflows

Information disclosure issues will also be checked for, to ensure that no data is accidentally leaked via timing  attacks, such as where a password is rejected in different amounts of time, depending on how many initial characters are correct. Checking for leaked data in the slack space of packets or unallocated data will also be checked for.

Race conditions

Where applications are multi-threaded, it is important to consider race conditions, where two threads may be contending for the same resource – if this is not handled appropriately, security vulnerabilities can result. An example might be where an application checks a file’s permissions and then writes to the file. If an attacker can swap the file for another one in between the check and the operation, they may be able to cause unintended side effects. 

Logic errors

Another class of errors is semantic, or application logic errors, for example, where a low memory condition might cause certain checks to abort and leave the application in an inconsistent state. A further example would be failing to check for negative numbers properly when performing a financial transaction, both in a classic sense (-1) and also for integer overflow/underflow  conditions, as the maximum representable integer, plus one, can often end up as being a negative number. Some special cases can also cause a buffer to be freed twice if the particular logic path has not been examined fully – this can lead to arbitrary code execution in certain circumstances.

Cryptography

The use of cryptography will also be examined to check for errors, such as padding oracles where too much information is leaked back to an  attacker, revealing whether a particular packet is correctly or incorrectly constructed. All encryption should make use of an HMAC in addition to the encryption itself to prevent chosen ciphertext attacks. 

The correct use of Pseudo Random Number Generators (PRNGs) is also extremely important to make sure they are properly seeded and of a sufficient quality for cryptographic applications. Where  initialisation vectors are used in CBC ciphers, these must also be treated carefully so they are not repeated. Electronic Code Book mode ciphers are generally suboptimal, unless being used to encrypt data with extremely high entropy such as other encryption keys; otherwise, their use may reveal structure in messages by XORing two distinct messages. Any application code updates must always have their signatures checked to make sure an attacker is not trying to introduce their own code into the application.

Front end presentation

Web applications will need to be checked for all these issues, plus some web-specific problems such as Cross-Site Request  Forgery, which arises when a web application cannot easily tell whether a request is client-initiated or has been spoofed by JavaScript. The safest way to reliably prevent this is to include an unpredictable token on each  page, which is then checked upon submission – which in theory means the attacker cannot spoof such requests.

Approach / Tools

Depending on the language and platform in use, various static code analysis tools may be used to pick up the more obvious problems. These are usually customised towards the language, but include generic SAST tools, such as sonarqube. These sorts of tools can be incorporated into the development lifecycle to cut down on the number of security-related issues. DAST checking will depend on the framework and language in use and will be performed during the assessment.

Manual assessment of the code will also be performed; this will be mainly on the critical paths of the code and concentrate on security-critical areas of the application. All our code reviewers have worked in development and have experience with both programming in general and specialisations in specific languages.

The reverse engineering of existing libraries through the use of decompilers and disassemblers may also be performed, using tools such as Ghidra, IDA, jadx and dnspy. This is generally suboptimal for assessment and source code is more efficient.

Device independent

Previous  code  reviews carried out have included embedded C/C++ devices, iPhone and Android  applications, and web applications written in a variety of languages, including PHP, JavaScript, Java and C#.

Native application reviews have been carried out for applications written in languages from R to Delphi to Python to Scala.

Code assisted testing

An effective alternative to a pure code review is to assess an application with access to the code at the same time. This allows for a concentration of effort for both the application and code review. This process will normally include running SAST on the code and manual investigation of hot points within the code whilst using the application to understand how this could be impacted.

This can reduce the number of theoretical vulnerabilities in both the application and code review tests.