The Web AppSec How-to: The Defenders’ Toolbox

Web application security has made headline news in the past few years. Incidents such as the targeting of speci�c sites as a channel to distribute malware to a particular audience (aka “watering hole attacks”), Web hacks by political activists such as the Anonymous Collective, and mass attacks aimed at CMS systems have become all too common.

While all these Web attacks focus on the application layer, many organizations continue to prioritize their resources and security spending on network-layer solutions such as IDS and network �rewalls. Although network-layer solutions sift out the illegitimate connections and can even defend against common DDoS attacks – these solutions still expose the application layer to attacks coming from so-called legitimate sessions. For instance, a SQL injection (SQLi) attack manipulates the backend database to spurt out sensitive data. However, the query itself seems to come from a legitimate source. A Cross-Site Scripting (XSS) attack, which enables an attacker to execute a script such as the theft of a session cookie or performing a transaction on behalf of an unknowing user, is not recognized by an IPS which views the XSS request as a legit connection. Consider the popular security analogy of the organization’s servers to an all-open party club. The bouncer might prevent rowdy folks from entering the party (i.e. network-layer security solutions). However, heavy protection should be placed against those that were able to enter the party - having passed that �rst line of defense - and may potentially misbehave from within. Similarly, application layer solutions attempt to protect the Web servers.

A sound security strategy must also include Web application layer defenses. Fortunately, there are a few existing technologies that aim to protect this layer. These solutions are not intended just for a static website. Rather, they consider the dynamic nature of today’s Web applications where each addition and change can a�ect the security state of the whole application.

In this article we review the various Web application security tools and highlight important decision factors to help you choose the application security technology best suited for your environment.

Source Code Analysis Made Easy

The Five Measures of Web App Sec

The Web application security defender’s toolbox contains �ve mature solutions:

1.Penetration testing2.Web Application Firewall (WAF)3.Dynamic Application Security Testing (DAST)4.Static Application Security Testing (SAST)5.Interactive Application Security Testing (IAST)

We’d like to note that there are other alternatives which are slowly gaining popularity. However, they have yet to receive the maturity to be adopted by large enterprises. As such, we focus on these �ve widespread security measures.

Penetration Testing (aka Pen-Testing)

Source Code Analysis Made Easy

Penetration testing is a process which assesses the security posture of the organization. It does this by emulating hacker activity in order to gain access to the organization’s systems and processes. Penetration testing includes manual and automated processes – across all layers of the organization. Looking at Web applications, pen-testers test the security robustness of the application from remote by stealing session cookies, attempting to upload malware on the site, responding to authentication security questions and other such attack simulations. Many of the simulations are performed automatically, with necessary manual enhancements for increased accuracy.Organization’s may employ a pen-testing team in-house or use a consulting service. Whatever the case, pen-testing is performed on a periodic basis.

The bene�ts of penetration testing:

•

•

Penetration testing’s shortcomings:

•

•

•

•

Web Application Firewall (WAF)

A Web Application Firewall is placed in front of the application and in real-time inspects the content of Web request. If the request signi�es an attack then it is blocked, otherwise the request proceeds as usual to the application. The WAF can be an appliance or a SaaS solution where the tra�c is re-routed to the cloud service which performs the request �ltering.

It’s comprehensive and provides a good health check security report of the application. A good pen-tester will also provide recommendations and remediation solutions.Testing is performed by a human being. This means not just following a checklist of activities, but rather “thinking outside of the box”. Particular skills include developing and understanding the development process as well as thinking like a hacker to undermine the developers’ work, understanding multiple platforms, building new tools and communicating �ndings.

Pen-testing provides the security state at a particular point in time, namely, when the process was conducted. As Web apps continuously grow and change over time, pen-testing cannot cover these code changes and additions on a constant basis.

Pen-testers are limited in their capabilities and cannot cover all security aspects. They cannot cover all processes, platforms and cases within a reasonable timeframe. For this reason, many pen-testers enhance their process with automated tools. It’s a lengthy process. Pen-testers work against an existing application. The complete testing process and later reviewing the results takes quite a lot of time. Furthermore, since pen-testing also involves a lot of manual testing, the human element comes into play here. A pen-tester for an average of 20 resource-heavy Web pages may take about 3 weeks of work.

Combine the particular expertise, the time it takes to perform a project, and a recurring process that needs to be done on a periodic basis – and pen-testing amounts to an expensive process.

Source Code Analysis Made Easy

•

• Provides visibility into actual threats. There are two bene�ts to this:1.

2.

•

•

The WAF shortcomings:

•

•

•

•

Dynamic Application Security Testing

Dynamic Application Security Testing (DAST) runs di�erent inputs against the Web app to check whether the app is exploitable to certain vulnerabilities. The DAST product crawls the Web app and tries to exploit the application according to a pre-de�ned list of vulnerabilities.

DAST’s bene�ts: •

•

The WAF protects the organization in real-time, when operating in ‘block’ mode. This means that even if a vulnerability escaped into production, the WAF would be able to protect against exploit attempts.

Prioritizing vulnerability �xing. Since organizations can actually see the requests that mostly try to attack the app, they can better decide to place resources on defending against that type of attack. Delivering real-time threat intelligence. Insight into the attack requests assists the WAF in blocking attacks at an earlier stage. For example, if a WAF detected a SQLi attempt originating from a certain source, the WAF can automatically �ag all subsequent requests originating from that source as malicious.

Blocks Business Logic Attacks (BLAs) such as app-layer Denial of Service (DoS), and even fraud cases. For example, consider online ticketing queues. An attacker can place an order for a certain venue from di�erent computers to pile up the queue of requests from legitimate users - e�ectively, causing a DDoS. Developer acceptance. Developers want to develop, not to hinder their progress by security testing as required by application security testing tools (as described below). WAF alleviates the secure coding struggle between the security and development teams.

The WAF bene�ts:

WAFs don’t rectify the problem. Even if the WAF blocks attacks – it’s not remediating the issue, only patching it for a certain time period. In case of a mode change, an insu�cient rule de�nition, or a simple WAF failure, the vulnerability will still be exposed to attack. WAFs are customized to the application they’re protecting. This means that every time that the app changes, the WAF needs to be re-con�gured. In fast-paced development environments such as Agile and DevOps - where new features and app enhancements are released continuously -delaying releases due to the con�guration of security settings is not viable. WAFs may block also legitimate requests. Due to false reportings, it may be that legitimate requests do not get to be processed by the application. WAFs, as their name implies, are good only for Web apps. But what happens if you’re developing a real-time system? How about mobile apps? Embedded devices? Cars?

Exposes vulnerabilities that manifest themselves only in real-time. For example, it can present production mis-con�gurations or vulnerabilities that are based on dynamic re�ection.Integration with 3rd party code. Many times an app is based on an external compiled package or library. A magnifying glass into the source code of the app to “read” its behavior is impossible in these cases. However, testing the app’s functionalities based on varying input allows the user to gain an understanding of what the app does and how it does it.

Static Application Security Testing

Source Code Analysis Made Easy

The shortcomings of DAST:•

• •

Static Application Security Testing (SAST) reviews the source code of the app to identify vulnerabilities, rather than tests the �nalized application. Some SAST solutions operate on the binary code, while others analyze the actual un-compiled source code. Inherently, the SAST provides more visibility into the di�erent code �ows that an attacker might be able to exploit.

The SAST bene�ts: •

•

•

•

The shortcomings of SAST: •

•

•

It is much easier to �x a problem earlier in the development process, than later. As in the case of generic bugs, the same goes with security bugs – i.e. vulnerabilities: the sooner they get �xed in the development process, the less expensive it is to �x. Most SAST tools integrate with development environments so while the developers are writing their code, it can be tested for security. SAST tools which perform source code analysis enable developers to test their code for security vulnerabilities even before that code is compiled. The vulnerability is �xed right from its source – i.e. the code. The SAST tools’ results pinpoint to the actual faulty code. Some tools even o�er best-�x locations to e�ectively obliterate issues arising from particular vulnerabilities stemming from dependent code �ows. Covers all type of code. SAST can be applied to all code - not only at Web apps - but also at embedded systems, PC-code, etc. To recognize the importance of secure development across all systems, consider as an example malware infection. Many times, a �rst stage in malware distribution is by exploiting a user’s vulnerable browser. Another way for malware to infect systems is by exploiting vulnerabilities in common apps such as Adobe. An obvious malware prevention measure that vendors can provide their customers is not having vulnerabilities in the browser and apps in the �rst place. There is also a clear immediate �nancial advantage to building secure development code in such systems: many companies today such as Google, Facebook, Yahoo and others o�er “Bug Bounties”. These are sums of money that security researchers are compensated for revealing app vulnerabilities. The more secure the code – the less bug bounties to pay out.SAST �ts into any sort of development environments and models, including Waterfall, Agile and DevOps.

False reportings. SAST tools might falsely �ag secure code as vulnerability �ndings, leading to the “crying wolf” syndrome. For this reason, it is important that your SAST tool has a high accuracy rate (say, 5% or less) and an easy management system to quickly sift out those stray �ndings.Reports �ndings that cannot be exploited. Even if the application does contain vulnerable code, it does not mean that the vulnerability itself can be exploited.It is risk-based. You don’t necessarily know that the vulnerability is one that attackers are after, so your prioritization is focused on potential risk rather than on actual risk

Limited vulnerability coverage. The DAST tool analyzes only requests and responses. As a result, DAST cannot surface hidden vulnerabilities such as design issues, or vulnerabilities that do not generate feedback when triggered (aka non-re�ective attacks).

Limited app coverage. The DAST crawls the application in order to de�ne its points of entry. However, some DAST tools are known to miss smaller or less visited pages and thus the security of these pages are not tested. Every code change requires a new scan. The point is that DAST runs on the executable – the complete Web app. Consequently, if the app changes it needs to be re-packaged as an application in order to perform a dynamic scan. In an environment with constant new releases, no security program has the privilege to delay a release to follow the DAST cycle: packaging an app for scanning, returning the app to development for �xing, and once again re-packaging to re-scan.

Source Code Analysis Made Easy

Integrated/ Intrinsic/ Interactive Application Security Testing

Integrated/ Intrinsic/ Interactive Application Security Testing (IAST) is a combination of SAST techniques and DAST techniques. As the variety of names implies, there are a few technology approaches, not necessarily similar, to IAST. Some IAST tools provide visibility into the code �ow on the runtime context, while others test the success of attack simulations. Regardless of the approach, IAST requires instrumentation of the application or the runtime environment, meaning the addition of various reporting monitors within the code. These monitors are triggered according to a predetermined set of requests.

The IAST bene�ts: •

The shortcoming of IAST:•

•

•

Building a Layered Approach

To summarize, you cannot a�ord the one alternative not mentioned above – and that’s to sit back and do nothing. It is also important to recognize that there is no one solution that will provide you with a 100% protection. An ideal application security strategy should include securing the apps already from the development stage, placing a WAF on main functions, performing periodic pen-testing and executing a code review on code changes. We recognize that in most environments, issues such as money, false reportings as well as time and resources play a role in building the ideal strategy. For this reason, we suggest choosing two or more technologies and then choose the particular tools that align best with your particular environment and business needs.

IAST enjoys the same bene�ts as DAST tools, with two additional capabilities: the reporting of non-re�ective attacks and pinpointing the vulnerable line of code.

Requires an agent installation. The instrumentation of the application requires the planting of agents (i.e. monitors) in the actual code slowing down the tool’s setup time and the testing process. Lack of automation. Some implementations require the manual generation of requests in order to map out the code �ow hence limiting the scope of the tested app to human nature. Additionally, the lack of automation results in inconsistent �ndings.Accuracy/ Low Vulnerability Coverage. According to the IAST implementation, the tool might lead to false reportings or missed results. IAST tools that look at the code �ow might falsely report on a �nding. On the other hand, IAST tools that work against a prede�ned set of attack scenarios may su�er from missed results.