In the modern times of digital technology, this information age we find ourselves in, we are getting more reliant as a species on the various applications that make life easier or more efficient. There are several millions of users using Paypal each day to process their transactions quickly and safely, vast numbers of people getting their entertainment through YouTube or Twitch, and the number of people who use Facebook, Instagram and Whatsapp to contact others rises more and more each minute. But how do we know that all of these applications are secure enough to be used day to day by so many people?
The answer is through application security testing. There are many methods employed for security testing that ensure the application is safe from external attacks or subsequent damages, both reputational and financial. These tools and methods must be considered by developers to make sure that their application is as safe and secure as possible before being released to the general public for all to see. This article will touch on some of the many different methods and tools that can be found and utilised, but it is important for any developer to familiarise themselves with as many methods as they can to ensure they have a healthy understanding of how to test their system’s security.
SAST – Static Application Security Testing
Static application security testing, or SAST for short, is a white-box form of testing that focuses on the actual code of the application whilst the application is at rest. SAST puts a large focus on shifting security left, or tying security checks into the development process. So, throughout the development timeline there will be moments of pause where the code is scanned through SAST whilst the code is not active. This is achieved by integrating SAST at the coding and testing phases, though some organisations and developers have even integrated it into the IDEs that the programmers use moment to moment.
SAST scans are based on a set of rules that are determined beforehand by the programmers. These rules define the coding errors in the source code that must be addressed and assessed. SAST scans tend to be designed to check for the most common security vulnerabilities known, such as SQL injection, input validation and stack buffer overflows. The pros of this system are that security is a top level priority and is constantly being checked over and over again, meaning that any slip-ups the programmers make will be caught immediately and won’t be continued into later versions of the application. However, SAST doesn’t cover all vulnerabilities, rather just the most common ones, as the more advanced ones are often found in run-time. Checking code whilst it is static means that it also cannot detect runtime errors. This is where DAST comes in.
DAST – Dynamic Application Security Testing
Dynamic application security testing, or DAST, is almost the opposite of SAST, as it is a black-box form of security testing. This means that the testers do not know the underlying architecture of the application that they are testing, unlike SAST where the scans can look at all of the code and compare it. DAST is performed by external testers, and is labelled with “dynamic” as it is performed during the runtime of the application. It looks for security vulnerabilities by simulating external attacks, attempting to penetrate the application by checking the exposed interfaces for flaws. Being able to run whilst the application itself is running gives DAST the advantage over SAST as it can pick up runtime errors that SAST cannot find, however it cannot find any internal errors.
DAST is extremely good at finding externally visible issues in the application it is testing. Examples of these are cross-site scripting, command injection, path traversal issues and insecure server configurations. It is the configuration issues it can find that makes it such a positive to use, as attacking from the outside makes it perfect to find configuration errors missed by internal tools. Sadly, as the tool cannot see the code, it cannot identify any issues internally that could lead to a breach or leak, and DAST scans can take a long time as there are so many checks to go through. Overall, it is best to combine DAST and SAST for a highly secure application.
What Else?
There is always the option of attempting manual tests, such as a manual penetration test. Penetration testing is one of the most common practises for web application security as most attacks against webpages are done manually. Whilst this option may not be elegant nor particularly effective, it is a great way to employ ideas you think scans may not always catch. Another tool to use could be correlation tools, as false positives in application testing can pose a constant challenge. Using correlation tools, a tester can reduce the noise by creating a central repository of findings from other security testing tools, then comparing results and letting developers prioritise the positives that are most likely needing attention.
It is clear that security testing is necessary, and though this article goes in depth about a few options, it’s important to make sure any developer uses a combination of all the tools present and usable to make sure their application is fully safe for all users.
