Critical Tests You Must Perform For Your Application's Security
In the current cybersecurity landscape, it is crucial to test your applications for security vulnerabilities. This task can be daunting if this is your first time trying to do so. Unfortunately, there is no ‘One Size Fits All’ approach to this.
So, where do you start? Before going out and hiring an expensive security consultant, you should understand the different types of tests that can be performed for assessing your application’s security and what‘s right for your application. The types of application security tests vary according to the degree of access to the tester's internal mechanisms. Let’s take a look at them:
White-Box Testing
In a white-box test, the tester is given full access to the application, including its source code. Most white-box testing focuses on reviewing source code to analyze the application’s data flow, information flow, control flow, and exception and error handling.
This can be done manually or through the use of automated tools. Tools that aid the review of source code to identify vulnerabilities are known as Static Application Security Tools (SAST). SAST tools can help you identify vulnerabilities that are caused due to use of insecure functions, insecure coding practices, aka taint analysis, or the use of vulnerable dependencies in your code.
Here are some examples so that you can better understand SAST and white-box testing.
Insecure Functions
Consider the following piece of C code:
#include<stdio.h>
void main() {
char str[50];
printf("Enter your string: ");
gets(str);
printf("The string you entered is: %s", str);
}
This simple program takes an input string from the user and echoes it back. This program may look simple, but it introduces a dangerous vulnerability to the application: Stack Buffer Overflow.
The root cause of this vulnerability is the use of the insecure function gets(). This function does not check user input size before putting it on the stack, which could lead to arbitrary code execution. SAST tools can help you identify such instances in your code.
Taint Analysis
Consider the following Javascript code from a web application:
router.get('/search', (req, res) => {
let searchParam = req.query.s;
searchResults = search(searchParam);
res.header('Content-Type','text/html');
if(!searchResults) {
res.send(`<html>
<body>
<p> Your search for ${searchParam} returned no results. </p>
</body>
`);
} else {
res.send(`<html>
<body>
<p> Your search results for ${searchParam}: </p>
${searchResults}
</body>
`);
}
}
The above code extracts the URL query parameter ‘s’ and sends the search results to the user's response. Notably, the parameter ‘s’ is sent back as-is in the HTTP response. This is a bad coding practice and gives rise to a Cross-Site Scripting (XSS) vulnerability.
Here, the URL query parameter ‘s’ is the tainted source because it is completely under user control. The function responsible for sending the response back to the user res.send() is where the tainted user input ends up in code. SAST tools identify such instances where unsanitized user input could compromise the security of application users.
The primary advantage of White-Box Testing over other methods is that this assessment can be performed even before the application is completely built.
Black-Box Testing
A black-box test is completely opposite to a white-box test, in terms of the knowledge shared with the tester about the application. In a black-box test, the security tester is not provided with any information about the application’s internal workings.
At most, the tester may be given an IP address or URL where the application is hosted for testing. It is the tester’s job to get into the application by exploiting security weaknesses in the application or the underlying infrastructure where the application is hosted.
A black-box test alone may not provide a good assessment of your application’s security as developers will tend to implement security through obscurity. It is a poor security practice and is less likely to be uncovered in a Black-Box test.
Examples of vulnerabilities that can be identified through a black-box test:
- Unauthenticated Administration Console
- XSS
- SQL Injection
- Unrestricted access to application logs
A middle ground exists between white-box and black-box testing, that is, grey-box testing.
Grey-Box Testing
In a grey-box test, the tester is provided enough information about the application that would allow them to make a comprehensive assessment of the application’s security.
Typically, in a grey-box test, the tester is not provided access to the application source code. However, the tester is provided with multiple user accounts on the application with varying privileges. This allows the tester to test multiple attack scenarios and test the application holistically.
The tester can use application features like any other application user and think about how they can abuse these features to either compromise the application or other application users.
Which Testing Approach is Right For You?
As an application owner, you must test your application in all possible attack scenarios. You can’t ignore black-box testing just because you have done a comprehensive white-box test, and vice versa as well. Every test strategy fulfills its own purpose. However, if your application has never undergone a security test, prioritizing the right test strategy is important.
A white-box test is recommended for applications that have never undergone security tests before. The reasons are:
- It does not require a complete working application.
- It helps the developers learn to write secure code.
- It provides a better root-cause analysis for easier fixing.
Multiple rounds of white-box tests can be performed while the application is still under development. Once a working version of the application is ready, a grey-box test can identify security vulnerabilities not picked up by a white-box test or vulnerabilities introduced during your application’s deployment. After multiple rounds of grey-box tests, a black-box test can be executed in an environment closely identical to your production environment.