Security Testing With JMeter - Learn

How
While the main purpose of Apache JMeter™ is load testing, its functionality
enables it to be used for security and automation testing as well. Security testing
intends to uncover vulnerabilities of the system and determine that its data and
resources are protected from possible intruders. In this article, we will explore the
different areas of security testing where the tool can be applied. We will cover
three different types of security testing: Site Spidering, Fuzzing and Distributed
Denial of Service (DDOS), and how they can be implemented in JMeter. We will
finish with things to notice when security testing your APIs.

Why JMeter? There are specialized security testing software, like, Burp
Suite or Acunetix. But most of them are commercial and cost hundreds or
thousands of dollars. Compared to them, JMeter seems like a more accessible
and attractive option.

Site Spidering

When testing the security of your software, the most important phase is
information gathering. Site Spider allows you to draw a map of the site's visible
places (places that you can access using only the interface of the website). The
data is shown per each website URL. You can use the information to draw
conclusions about the size of the tested space, its functionality and, possibly, the
tools used in development. This information enables us to determine the most
obvious attack vectors and choose the appropriate test data.

Let’s look briefly at the order of actions that the Spider carries out, which the
JMeter script should perform too:
• Go to the start page
• Read all the URLs on the page
• Follow each link and analyze the responses
• Repeat steps 2 and 3 for each URL

While we can build a JMeter script that will perform this function, it’s important to
understand that JMeter is not a browser, but rather works at protocol level.
Therefore, JMeter does not perform all the actions supported by browsers. In
particular, JMeter does not execute Javascript found in HTML pages. So
Javascript and unusual objects, such as Flash, will be skipped. A similar problem
occurs with most Spiders. Just keep these drawbacks in mind.
Let’s build our JMeter script. You can learn more from this blog post “How to
Spider a Site with JMeter - A Tutorial”.

1. After adding a Thread Group, you can use the HTTP Request Sampler (Right
Click on Thread Group -> Add -> Sampler -> HTTP Request), which allows you
to send various HTTP Requests.

2. To extract URL links, we can use several elements:

The Regular Expression Extractor

Right Click on HTTP Request Sampler -> Add -> Post Processors -> Regular
Expression Extractor

The Regular Expression Extractor enables applying a regular expression to the

response body of the HTTP Request Sampler. For example, a regular expression
for extracting a link from a tag looks as follows: -
“<a\s+(?:[^>]*?\s+)?href=(["'])(.*?)\1”. The configuration of the element for this
case is shown below. You can use this, or create your own.
XPath Extractor

Right Click on HTTP Request Sampler -> Add -> Post Processors -> XPath
Extractor

You can also extract the URL using the XPath query. To do this, we will use
the XPath Extractor element. The XPath query for this case looks as follows:
//a/@href, and the configuration of the element for this case is shown below. You
can use this, or create your own.

CSS/JQuery Extractor
Right Click on HTTP Request Sampler -> Add -> Post Processors ->
CSS/JQuery Extractor

CSS/JQuery is more convenient and readable than Regex and XPath. It allows
you to easily select HTML DOM elements that might otherwise have been difficult
to write a regular expression for. For example, in the screenshot below, there is
this configuration to extract a link from a tag. You can use this, or create your
own.

HTML Link Parser

This post processor does not have any settings. It extracts absolutely all the
links, which makes it somewhat unsuitable for our task, because it does not
distinguish between GET links and POST links, but we only need GET requests
for creating a website map.
A great JMeter advantage when building a spider is the wide configuration
variability. With the help of the elements covered above, we can gather additional
information from the pages viewed. For example, you can check a page for input
forms, and then write the page data into a separate file.

3. Now, you can write to the file and work with the URL by using the BeanShell
PostProcessor. Below is the code for the BeanShell PostProcessor, which writes
all the received URLs to a file and performs the initial processing of the URL. For
example, some internal URLs have a dot and no slash at the beginning of the
line. The script addresses the issue.

File yourFile = new File("urls.csv");

yourFile.createNewFile();
f = new FileOutputStream(yourFile, true);
p = new PrintStream(f);
this.interpreter.setOut(p);
int matches = Integer.parseInt(vars.get("number_matchNr"));
for (int i=1; i<=matches; i++) {
url = vars.get("number_" + i);
if (url.indexOf(".")==0){url =
url.substring(1,url.length());}
if (url.indexOf("/")!=0 && url.indexOf(".")!=0 &&
!url.contains("mailto") && !url.contains("http")){url = "/"
+ url;}
if (url.length()!=1) {print(url);}
}
f.close()

Fuzzing

Fuzzing is a way of testing applications, which is based on the transfer of

incorrect, random or unforeseen by program logic data and seeing how the
system responds. Fuzzing is connected to the phase of information gathering
and is an integral part of the black box security testing, which means we just
focus on inputs and output of the software system, without bothering about
internal knowledge of the software program. By using Fuzzing, you can find
coding errors and security gaps. For example, you might find web application
directories that are inaccessible from its interface or untypical errors when
processing the input data. Fuzzing can also be easily automated, because, for
instance, with the help of JMeter, we can generate various types of requests with
different test data.
Fuzz testing is similar to functional testing, with the main difference being the test
data. If you need ideas, this repository contains a lot of test data for fuzzing, both
field validation and directory fuzzing. For Fuzz testing, we need an element that
sends requests. For a website, that would be a HTTP Request Sampler.

Click here to see an example of data that we can pass as parameters.

Let’s look at this case example, aimed at identifying SQL injections allowing you
to bypass the login phase. Below is the POST authorization request for this
example. You should always check POST requests when Fuzz testing. The
csv_line is a variable from the CSV Data Config, where there is a file with
injections. You can also use CSV files for other kinds of bad data that can lead to
unexpected consequences, like here.

Now, responses can be analyzed with the help of the Response Assertion. This
element analyzes the response according to the pattern that you can specify in
the configuration of the sampler, and ends successfully if the response matches
the pattern. Since we need to check whether the login will be performed or not,
Assertion settings should be such that it checks for successful login. Below is a
screenshot with an example of the settings.
It is also important to check access to obvious directories and files. This is called
Directory Traversal. As we wrote above, with certain tools used during
development, a project can contain obvious paths and files and we can try to find
them.

The Internet contains a lot of information about such paths. Let us take the
following document and connect it to the script and run it. This document
contains obvious paths common for the PHP language.The script goes through
all these paths.
As you can see, we have found some interesting paths and files. For example,
the first link is a page with information about the version of PHP that is used on
the server. This is a huge source of information about the services used on the
server. This is not very good for the owner of the resource, whose sensitive data
is exposed. The second link is the panel to work with the resource database, a
real catch.

As you might have noticed, Fuzzing files are specifically focused. For example, in
the first case we used injections for the MySQLDB, and the paths for PHP. Our
spider helped us select the information for fuzzing, as well as draw conclusions
about the environment under testing. We were also able to find the page for the
POST request using it.

Distributed Denial of Service

DDOS is a type of network attack based on the limited resources of the service
under attack. Multiple requests are sent to the service, which it will obviously not
cope with, and then it will have to refuse to service (or will make them wait
unacceptably long). As a rule, requests are sent from different points. Otherwise,
if you want to call DOS with mass requests using only one machine, it must have
an extremely wide Internet channel and large processing power. DDOS is
possible at each level of the OSI model. We will look at DDOS at level 7 using
HTTP requests. Arranging such an attack during the testing phase allows you to
check how much the server can resist such attacks.

Almost DDOS: just add one HTTP Request Sampler that will access the main
application page. After that set a large number of users in the thread.

Now we can launch it. This is still not DDOS, rather it is just an attempt to call
DOS loading the website with regular Get requests to the main page. But even
such a simple attempt is sufficient to ensure the inaccessibility of the resource.

Besides, if you look at the results of the script, you will notice that some of the
requests failed.
This, unfortunately, will be enough for some sites on the Internet. So, please, do
not check this on the site where you usually watch films or read articles.

But what if our application server has high performance and is able to process
the load from one machine? Then, JMeter enables distributing load generation
between several machines.
The logic of load distribution is quite simple: the client (the machine where we run
the script) sends the specified set of tests to each of the servers (machines
running JMeter as a server), the servers in their turn perform these tests and
send the collected results back to the client.

The Apache website has a comprehensive step-by-step guide for setting up the
distributed load, where all the pitfalls are described, as well as the advantages
and disadvantages of this technique.

Some more use cases:

If the server prohibits sending more than 1 request per second from one IP
address, use IP spoofing. For example, if you press F5 several times on the
website vk.com, you will receive a notification that the request will not be
processed. Learn more from this blog post: IP Spoofing and JMeter.

To simulate attacks at multiple selected addresses, and not just one, use the file
that was obtained with the help of the spider. Connect it using CSV Data Config
and then send requests at the addresses specified in the CSV.

Does your server still process all requests? Try out a slow HTTP POST Attack!
This attack involves sending a large HTTP POST request in small pieces to the
server. By standard, the HTTP server must wait for the full data transfer and can
close the connection only by timeout. Thus, the attacked server opens a huge
number of connections, catastrophically spending its resources.

To conduct this attack, you need to edit the users.properties file that is located in
the /bin folder.

Open this file and add these strings:

httpclient.socket.http.cps=1
httpclient.socket.https.cps=1

This is necessary for emulating a slow Internet connection. This means that one
character per second will be sent, it's slow enough.
 What about the DDOS of the other levels? We can also do this, for example, to
replace the HTTP Request sampler with the UDP Request server and send a lot
of UDP packets to the server that is working with this protocol, whether it is a
DNS server or some other. Working with UDP Request Sampler has been
covered in this article. This will be DDOS of level 4 of OSI model.

Security Testing Your APIs - Things to Notice

As mentioned above, JMeter is also well suited for functional testing automation,
making APIs one of the first clients to automate this kind testing. To test
REST/SOAP API, you can use the same HTTP Request sampler as shown
above. You can also use various plugins from Plugin Manager, for example the
Custom SOAP Sampler or XML Plugins.

A whole section in the BlazeMeter blog is devoted to API testing. Therefore, we

will not focus on this, but I just want to draw your attention to a few practical
aspects.

• Have you noticed that some websites have a login attempt restriction? The
account or IP is blocked for a while or forever. But sometimes there is no
restriction when a request is sent through API. This is a very big omission, which
was found even in the applications of famous banks.
• Underprotected API ranked 10th in the Top Ten Owasp. Even if you do not speak
publicly about the general availability and openness of your API, it does not
mean it is protected.
• Access control - You have a website and all the data is being perfectly
processed. You provide an API for users, which allows them to carry out various
actions, like writing messages on your website. But suddenly John writes a
message on behalf of Mary. Where is the problem? John replaced the author's id
in the message sent through the API. Something similar happened once on
Facebook.

That’s it! You now have tools to run security tests on your website, app or API,
with JMeter. If you need to keep your data secure, BlazeMeter also
provides Private Cloud abilities. To learn more, request a demo or just put your
URL or JMX file in the box below, and your test will start in minutes.