From web-based email to online shopping and banking, organizations are bringing their businesses directly to customers' web browsers every day, circumventing the need for complex installations or update rollouts. Additionally, organizations are rolling out internal web applications for finance, marketing automation, and even internal communication that are often homegrown, or at least fine-tuned for their particular needs.
While web applications offer convenience to businesses and customers alike, their ubiquity makes them a popular attack target for cybercriminals. As a result, web application security testing, or scanning and testing web applications for risk, is essential.
As the 2018 Verizon Data Breach Report shows, web applications are a popular attack target in confirmed data breaches, and in some industries up to 41% of data breaches are web application-related. The report also found that about half of web application-related breaches took several months or longer for security teams to discover. The longer an attacker has access to systems, the more damage they can cause. Attackers must be discovered and removed as quickly as possible, but that’s often easier said than done.
As attackers increasingly target web applications, they are able to refine and battle-test their methods, increasing their sophistication. Even if a company follows best practices to protect itself against common web application attacks (like the OWASP Top Ten), this may not be enough. Breaking into web applications can be lucrative for criminals—they are motivated to use the latest and greatest in attack methods and tools, and they may have the resources of organized crime behind them. This kind of muscle can be hard for a business to combat alone.
Web applications can also be so complex that they confuse systems designed to automatically detect an attacker's intrusion. That is why common tools like intrusion detection alone aren’t sufficient; web application security testing can fill the gaps.
Dynamic Application Security Testing (DAST): A DAST approach involves looking for vulnerabilities in a web app that an attacker could try to exploit. This testing method works to find which vulnerabilities an attacker could target and how they could break into the system from the outside. Dynamic application security testing tools don’t require access to the application's original source code, so testing with DAST can be done quickly and frequently.
Static Application Security Testing (SAST): SAST has a more inside-out approach, meaning that unlike DAST, it looks for vulnerabilities in the web application's source code. Since it requires access to the application's source code, SAST can offer a snapshot in real time of the web application's security.
Application Penetration Testing: Application penetration testing involves the human element. A security professional will try to imitate how an attacker might break into a web app using both their personal security know-how and a variety of penetration testing tools to find exploitable flaws. You can also outsource web application penetration testing services to a third party if you do not have the resources in-house.
1) If a system is business-critical, it should be tested often: Any system that stores customer data—including credit card numbers, personally identifiable information (PII), or any other sensitive information—should be tested for security vulnerabilities; in fact, it's often a requirement of many government- or industry-mandated compliance guidelines. Keep this in mind when looking at the potential scope of web application security testing in your organization.
2) The earlier security is tested in software's design lifecycle, the better: You do not want to leave security testing as a last step in software development—inevitably, vulnerabilities will be found and this can throw a big wrench into the development and maintenance processes. Bring security into the process early in the development lifecycle, preferably with the full involvement of your development operation (DevOps) team, to streamline response, minimize risk, and minimize any costs or time spent on remediation.
3) Keep development teams on track by prioritizing remediation and bug fixes: The output of web application security testing will often be a list of items that development will need to address at some point. Security calls them vulnerabilities, but development calls them bugs. The key is to not simply drop a list of these issues into a DevOps team’s lap; instead, be sure to prioritize the vulnerabilities and fully integrate with the bug tracking system in place, in order to maximize time to remediation.