While secure coding practices are vital for web application security, there will invariably be areas of the code that still have security issues. The best way to find those is through testing the web application both statically (non-running) and dynamically (running or runtime) so that developers can fix the issues during the development lifecycle. Let’s discuss the strengths and weaknesses of these two modes, as well as explore the variations of each for the second tip of this 5-part series.
Testing Your Web Applications
Static Testing
First, let’s look at static application security testing, otherwise known as SAST. When testing an application statically, you are doing so from the perspective of the developer of the application. This means you have full access to the source code and documentation of the application, effectively giving you full knowledge of the how the application works, how data flows through the application, and where there might be a security flaw in the code (that is why this method of testing is also called white-box or transparent box testing).
Testing statically is important in the software development lifecycle (SDLC) because it catches flaws before the code has been fully written and deployed into a running environment. That translates to cost savings due to bug fixing becoming more expensive the further you are in development. But how you statically test the code is really the important question, and the answer is dependent on your needs.
The most accurate method of static testing is to have a web application security expert with knowledge of secure coding practices run through the code manually (this is usually called a code review) to look for potential problems. Getting the expertise to do that is often difficult and expensive. Also, while this method of review is often done in development shops as code is written, performing a full code review to look for security issues is hardly feasible with modern applications that often run into the millions of lines of code. Essentially, this method of static review is just not very efficient for the DevOps-y world we live in.
In order to speed that process up, many companies use automated static code analyzers. These tools analyze the static code to determine if a security flaw exists and (typically) create a report that shows where issues exist down to the line of code. The higher-end tools also give advice on how to remediate the flaws and integrate into the development lifecycle (automated scanning and bug tracking take a huge load off of developers and web application security teams).
Automated analyzers do have a down side: their propensity for false positives. Because of this, the results require review by a person highly trained in secure coding and web application security in general. So, while the tool does a lot of the heavy lifting, the same expertise is needed to review results as is needed to do a manual review. It’s not the same level of effort as in code review, but it is highly recommended to perform the review of the results so that developers don’t have to chase down false positives themselves and take away cycles from actual development.
Dynamic Testing
Dynamic application security testing (DAST) is an entirely different animal than SAST. Where SAST is called white box testing because of the tester has the same view as the developer, dynamic testing is called black box testing because the tester has the view of the cyber attacker. This means two things: 1) the web application is in its running state; and 2) there is typically little to no detail of the inner workings of the web application available to the tester (it is possible to glean details of the web app via various nefarious practices, but that is beyond the scope of this discussion).
These distinctions between static and dynamic testing are important. If a tester finds a flaw with a web application in its running state, it is typically much easier to verify than with static testing. The tester simply has to run through the same steps again to make sure the flaw appears again. Essentially, the false positive rate is lower (especially when using automated tools) in dynamic testing than with static testing. So, let’s look at some of the methods of dynamically testing web applications.
Similar to the manual effort involved in the static code review mentioned above, dynamic testing can be performed using a manual methodology by an individual. This involves someone with expertise in web application security running through the application page by page looking for potential flaws in web forms, authentication mechanisms, session management, and others. This type of testing, while more accurate, can be time-consuming and expensive. Modern development timelines may cause this level of testing to become untenable to an organization.
Again, in a similar fashion as static testing, automated dynamic web application analyzers were created to cut down the time needed for a full dynamic test of an app. Typically, the analyzer is setup and ran by an individual (who does not need to be as proficient in dynamic testing) to perform and automated analysis of the website structure (called “spidering”) to find all the potential vulnerable elements of the web app. These are recorded and tested according to the configuration of the analyzer, and the results are provided when testing is completed (these results also need to be reviewed by an expert).
Outsourcing SAST and DAST
SAST and DAST testing obviously require expertise. Organizations often don’t have the resources and/or inclination to bring in that level of expertise, which means that outsourcing comes into play. There a lot of companies that perform application testing. Some focus on the more manual efforts like code review or manual dynamic testing. These are typically firms or business groups in a larger company that are highly specialized. There are other companies that use a mix of manual and automated testing, and others that almost strictly perform automated assessments.
Another more recent development in the dynamic testing world is the bug bounty program. A bug bounty program is essentially a crowdsourcing effort for finding software bugs (in this case, the bugs are focused on security). Individuals participate in the program by signing up as a tester and performing dynamic testing against the web application. If that individual finds and reports a unique and qualified flaw, the company running the program gives that person an award (typically monetary). There are also companies that plan and run the bug bounty for you. While somewhat controversial, bug bounties have the benefit of a high number of individuals with potentially different techniques testing a web application.
The approach your company takes to testing its web applications depend highly on its business goals and any resource restrictions that may be in place. But no matter what path is taken, it is highly recommended that both static and dynamic testing be performed on your web applications. Both have their strengths as weaknesses, but they can bolster each other when both are used in an effective web application security testing program.
Next up, we will discuss how web application firewalls (WAF) and intrusion detection systems (IDS) provide a valuable layer of security to defend your SQL-based cloud environment.
