Application Security Testing Best Practices – Part I
With cyber attacks increasing exponentially, security testing has become a necessity for organizations across the globe. Even if an organization has developed an application by properly following secure coding principles, the application still requires significant and rigorous testing before it is finally deployed. After deployment, security testing activities have to be regularly performed to ensure that just in case if a vulnerability, loophole, or weakness is found, it can be addressed immediately before being exploited by an attacker. For this article, our experts have compiled a list of best practices while performing security testing activities for applications.
Figure 1: Application Security Testing Best Practices
Perform Static Analysis
To start with, the application developers should perform static analysis. In static analysis, the code is inspected while it is in rest, i.e., without executing the program. This, in turn, allows the application developers to carry out a thorough and in-depth investigation of the source code. The developers should identify any loopholes, flaws, or backdoors, which can render the application vulnerable to attacks. In addition, Static analysis tools should be used which are capable of pointing out the vulnerabilities which might have been missed by the developers.
Perform Dynamic Analysis
Now that the code at rest has been examined, the application developers should test the application when it is being run. Dynamic analysis is often considered a natural follow-on process from static analysis. Here, the testing activities are performed in the run time environment. Unlike static analysis, dynamic application security testing (DAST) can assist in finding the vulnerabilities which are either too subtle or too complicated to be found out by static analysis. Various hidden problems like file access, memory manipulation, etc. do not appear in code reviews or static analysis and hence, dynamic analysis becomes highly relevant. You can check the benefits of DAST for application security testing here. In addition, you can check prominent open-source DAST tools here.
Look out for things which are not there
The difference between security testing activities and general application testing is quite simple – one looks out for making sure whether or not the code is doing what it is supposed to do, while in application security testing, the testers are concerned with finding the functionalities which are not supposed to be there in an application. While testing an application, the testers should be on the lookout for any unexpected outcomes or behaviors which are not specified in the application’s design document. It will help the testers in the identification of vulnerabilities that could be easily exploited by anyone who is trying to get access to your application’s data.
Test outside of public interfaces
At times, application security testing involves entering as many inputs as possible through an application or its APIs, wherever there is an input field. However, it must be noted by the testers as well as the developers that the number of inputs which are received by an application via its API and other such public interfaces is significantly outnumbered by the inputs coming from the file system and the network. Hence, it is way more important to test inputs which are not coming from the public interfaces as this will be essentially the first place wherein the attackers will look for to get access to your organization’s sensitive data.
Testing the deployment environment
In our experience of performing application security tests, we have found that even the smallest of errors in configuration can result in an application becoming vulnerable to attacks. So, it is vital that the testers or the application development team checks for configuration errors in the application before it is finally deployed. For example, if an application is being deployed to a server, the team will need to do activities such as –
- Perform port scanning on the server for finding open ports,
- Review server configuration files,
- Check whether the application is prone to directory traversal attack, etc.
Testing incident response procedures
When it comes to security, it is often stated that an organization must be proactive. Instead of waiting for a breach to happen, the team must check the efficacy of an organization’s incident response procedure. A breach simulation exercise can be undertaken by exploiting any high priority vulnerabilities during static or dynamic testing. Following the incident response procedure will ensure that all the members of the development team are familiar with the incident response procedure and if a breach or an information security incident actually occurs after deployment, the internal team is already prepared to mitigate and remediate the incident.
In the next part of this article, we will discuss more such best practices compiled by our security experts.
- Application Security Testing10
- AWS Penetration Testing5
- Cloud Penetration Testing5
- DAST-Dynamic Application Security Testing10
- network penetration test1
- OSINT Penetration Testing1
- PCI DSS Compliance5
- Penetration Testing as a Service10
- Phishing as a Service5
- Service Organization Control(SOC)1
- web application security10
Automated Retest for DAST29 Jun, 2020
Automated Retest for External Infrastructure26 Jun, 2020