The Web AppSec How-to: The Defenders Toolbox

Transcription

1 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 specific 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 firewalls. 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 first 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 affect 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. The Five Measures of Web App Sec The Web application security defender s toolbox contains five mature solutions: 1.Penetration testing 2.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 five widespread security measures.

2 Penetration Testing (aka Pen-Testing) 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 benefits of penetration testing: 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 findings. Penetration testing s shortcomings: 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. 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 signifies 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 traffic is re-routed to the cloud service which performs the request filtering.

3 The WAF benefits: Source Code Analysis Made Easy 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. Provides visibility into actual threats. There are two benefits to this: 1. Prioritizing vulnerability fixing. 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. 2. 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 flag 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 different computers to pile up the queue of requests from legitimate users - effectively, 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 shortcomings: 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 insufficient rule definition, 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-configured. In fast-paced development environments such as Agile and DevOps - where new features and app enhancements are released continuously -delaying releases due to the configuration 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? Dynamic Application Security Testing Dynamic Application Security Testing (DAST) runs different 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-defined list of vulnerabilities. DAST s benefits: Exposes vulnerabilities that manifest themselves only in real-time. For example, it can present production mis-configurations or vulnerabilities that are based on dynamic reflection. 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.

4 The shortcomings of DAST: 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-reflective attacks). Limited app coverage. The DAST crawls the application in order to define 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 fixing, and once again re-packaging to re-scan. Static Application Security Testing Static Application Security Testing (SAST) reviews the source code of the app to identify vulnerabilities, rather than tests the finalized 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 different code flows that an attacker might be able to exploit. The SAST benefits: It is much easier to fix 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 fixed in the development process, the less expensive it is to fix. 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 fixed right from its source i.e. the code. The SAST tools results pinpoint to the actual faulty code. Some tools even offer best-fix locations to effectively obliterate issues arising from particular vulnerabilities stemming from dependent code flows. 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 first 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 first place. There is also a clear immediate financial advantage to building secure development code in such systems: many companies today such as Google, Facebook, Yahoo and others offer 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 fits into any sort of development environments and models, including Waterfall, Agile and DevOps. The shortcomings of SAST: False reportings. SAST tools might falsely flag secure code as vulnerability findings, 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 findings. Reports findings 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

5 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 flow 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 benefits: IAST enjoys the same benefits as DAST tools, with two additional capabilities: the reporting of non-reflective attacks and pinpointing the vulnerable line of code. The shortcoming of IAST: 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 flow hence limiting the scope of the tested app to human nature. Additionally, the lack of automation results in inconsistent findings. 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 flow might falsely report on a finding. On the other hand, IAST tools that work against a predefined set of attack scenarios may suffer from missed results. Building a Layered Approach To summarize, you cannot afford 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.