The Web AppSec How-To: The Defender's Toolbox

The Web AppSec How-to: The Defenders’ Toolbox
Source Code Analysis Made Easy
Web application security has made headline news in the past few years.
Incidents such as the targeting of specic 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
aect 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 ve 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 ve widespread security measures.

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 benets 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 ndings.
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 signies 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 trac is re-routed to the cloud service
which performs the request ltering.

The WAF benets:
•
• Provides visibility into actual threats. There are two benets to this:
1.
2.
•
•
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 dierent
computers to pile up the queue of requests from legitimate users - eectively, 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 insucient rule denition, 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-congured. In fast-paced development environments such as Agile and DevOps -
where new features and app enhancements are released continuously -delaying releases due to the
conguration 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 dierent 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-dened list of vulnerabilities.
DAST’s benets:
•
•
Exposes vulnerabilities that manifest themselves only in real-time. For example, it can present production
mis-congurations or vulnerabilities that are based on dynamic reection.
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.

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-reective attacks).
Limited app coverage. The DAST crawls the application in order to dene 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.
Static Application Security Testing
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 dierent code ows that
an attacker might be able to exploit.
The SAST benets:
•
•
•
•
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 oer best-x locations to eectively 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 oer “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

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 benets:
•
IAST enjoys the same benets as DAST tools, with two additional capabilities: the
reporting of non-reective 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 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 predened set of attack scenarios may suer from missed
results.
Building a Layered Approach
To summarize, you cannot aord 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.

The Web AppSec How-To: The Defender's Toolbox

More Related Content

What's hot

Similar to The Web AppSec How-To: The Defender's Toolbox

More from Checkmarx

Recently uploaded

The Web AppSec How-To: The Defender's Toolbox