Department of Computer Science and Engineering

AnjalaiAmmal-Mahalingam Engineering College

Kovilvenni-614 403

UNIT-V

HACKING TECHNIQUES AND TOOLS

Social Engineering, Injection, Cross-Site Scripting(XSS), Broken Authentication and Session Management, Cross-
Site Request Forgery, Security Misconfiguration, Insecure Cryptographic Storage, Failure to Restrict URL Access,
Tools: Comodo, OpenVAS, Nexpose, Nikto, Burp Suite,etc.

1. SOCIAL ENGINEERING
Definition

• Social engineering is a manipulation technique that exploits human error to gain

private information, access, or valuables. In cybercrime, these “human hacking”
scams tend to lure unsuspecting users into exposing data, spreading malware
infections, or giving access to restricted systems. Attacks can happen online, in-
person, and via other interactions.

• Scams based on social engineering are built around how people think and act. As
such, social engineering attacks are especially useful for manipulating a user’s
behavior. Once an attacker understands what motivates a user’s actions, they can
deceive and manipulate the user effectively.

• In addition, hackers try to exploit a user's lack of knowledge. Thanks to the speed of
technology, many consumers and employees aren’t aware of certain threats like drive-
by downloads. Users also may not realize the full value of personal data, like their
phone number. As a result, many users are unsure how to best protect themselves and
their information.

Generally, social engineering attackers have one of two goals:

1. Sabotage: Disrupting or corrupting data to cause harm or inconvenience.

2. Theft: Obtaining valuables like information, access, or money.

How Does Social Engineering Work?

• Most social engineering attacks rely on actual communication between attackers and
victims. The attacker tends to motivate the user into compromising themselves, rather
than using brute force methods to breach your data.
• The attack cycle gives these criminals a reliable process for deceiving you. Steps for
the social engineering attack cycle are usually as follows:
▪ Prepare by gathering background information on you or a larger group you
are a part of.
▪ Infiltrate by establishing a relationship or initiating an interaction, started
by building trust.
▪ Exploit the victim once trust and a weakness are established to advance the
attack.
▪ Disengage once the user has taken the desired action.
Traits of Social Engineering Attacks

• Social engineering attacks center around the attacker’s use of persuasion and
confidence. When exposed to these tactics, you are more likely to take actions you
otherwise wouldn’t.

Among most attacks, you’ll find yourself being misled into the following behaviors:

Heightened emotions: Emotional manipulation gives attackers the upper hand in an any
interaction. You are far more likely to take irrational or risky actions when in an enhanced
emotional state. The following emotions are all used in equal measure to convince you.
• Fear
• Excitement
• Curiosity
• Anger
• Guilt
• Sadness
Urgency: Time-sensitive opportunities or requests are another reliable tool in an attacker’s
arsenal. You may be motivated to compromise yourself under the guise of a serious problem
that needs immediate attention. Alternatively, you may be exposed to a prize or reward that
may disappear if you do not act quickly. Either approach overrides your critical thinking
ability.
Trust: Believability is invaluable and essential to a social engineering attack. Since the
attacker is ultimately lying to you, confidence plays an important role here. They’ve done
enough research on you to craft a narrative that’s easy to believe and unlikely to rouse
suspicion.
 Types of Social Engineering Attacks

Almost every type of cybersecurity attack contains some kind of social engineering.
For example, the classic email and virus scams are laden with social overtones.

Social engineering can impact you digitally through mobile attacks in addition to
desktop devices. However, you can just as easily be faced with a threat in-person. These
attacks can overlap and layer onto each other to create a scam.

Here are some common methods used by social engineering attackers:

1. Phishing Attacks

Phishing attackers pretend to be a trusted institution or individual in an attempt to persuade

you to expose personal data and other valuables.

Attacks using phishing are targeted in one of two ways:

1. Spam phishing, or mass phishing, is a widespread attack aimed at many users. These attacks
are non-personalized and try to catch any unsuspecting person.
2. Spear phishing and by extension, whaling , use personalized info to target particular users.
Whaling attacks specifically aim at high-value targets like celebrities, upper management,
and high government officials.
Examples of Social Engineering Attacks

2. Worm Attacks

The cybercriminal will aim to attract the user’s attention to the link or infected file – and
then get the user to click on it.

Examples of this type of attack include:

• The LoveLetter worm that overloaded many companies’ email servers in 2000. Victims
received an email that invited them to open the attached love letter. When they opened the
attached file, the worm copied itself to all of the contacts in the victim’s address book. This
worm is still regarded as one of the most devastating, in terms of the financial damage that it
inflicted.
• The Mydoom email worm — which appeared on the Internet in January 2004 — used texts
that imitated technical messages issued by the mail server.
• The Swen worm passed itself off as a message that had been sent from Microsoft. It claimed
that the attachment was a patch that would remove Windows vulnerabilities. It’s hardly
surprising that many people took the claim seriously and tried to install the bogus security
patch — even though it was really a worm.
2. INJECTION
• One of the most commonly known types of attacks against a web application is SQL
Injection. SQL injection is a type of injection attack that specifically targets SQL
databases, allowing a malicious user to either provide their own parameters to an
existing SQL query, or to escape an SQL query and provide their own query.
• Naturally, this typically results in a compromised database because of the escalated
permissions the SQL interpreter is given by default. SQL injection is the most
common form of injection, but not the only form. Injection attacks have two major
components: an interpreter and a payload from a user that is somehow read into the
interpreter. This means that injection attacks can occur against command-line utilities
like FFMPEG (a video compressor) as well as against databases (like the traditional
SQL injection case).
• Let’s take a look at several forms of injection attacks so that we can get a good
understanding of what type of application architecture is required for such an attack to
work, and how a payload against a vulnerable API could be formed and delivered.
SQL Injection
SQL injection is the most classically referenced form of injection (see Figure 13-1).
An SQL string is escaped in an HTTP payload, leading to custom SQL queries being
executed on behalf of the end user.

Figure 13-1. SQL injection

• Traditionally, many OSS packages were built using a combination of PHP and
SQL(often MySQL). Many of the most referenced SQL injection vulnerabilities
 throughout history occurred as a result of PHP’s relaxed view on interpolation among
view, logic, and data code.
• Old-school PHP developers would interweave a combination of SQL, HTML, and
PHP into their PHP files—an organizational model supported by PHP that would be
misused, resulting in an enormous amount of vulnerable PHP code.
Let’s look at an example of a PHP code block for an old-school forum software that
allows a user to log in:
<?php if ($_SERVER['REQUEST_METHOD'] != 'POST') {
echo'
<div class="row">
<div class="small-12 columns">
<form method="post" action="">
<fieldset class="panel">
<center>
<h1>Sign In</h1><br>
</center>
<label>
<input type="text" id="username" name="username"
placeholder="Username">
</label>
<label>
<input type="password" id="password" name="password"
placeholder="Password">
</label>
<center>
<input type="submit" class="button" value="Sign In">
</center>
</fieldset>
</form>
</div>
</div>';
} else {
// the user has already filled out the login form.
// pull in database info from config.php
$servername = getenv('IP');
$username = $mysqlUsername;
$password = $mysqlPassword;
$database = $mysqlDB;
$dbport = $mysqlPort;
$database = new mysqli($servername, $username, $password, $database,$dbport);
if ($database->connect_error) {
echo "ERROR: Failed to connect to MySQL";
die;
}
$sql = "SELECT userId, username, admin, moderator FROM users WHERE username =
'".$_POST['username']."' AND password = '".sha1($_POST['password'])."';";
$result = mysqli_query($database, $sql);
}
• As you can see in this login code, PHP, SQL, and HTML are all intermixed.
Furthermore, the SQL query is generated based off of concatenation of query params
with no sanitization occurring prior to the query string being generated.
Let’s consider another simple Node.js/Express.js server—this time one that communicates
with an SQL database:
const sql = require('mssql');
/*
* Recieve a POST request to /users, with a user_id param on the request body.
*
* An SQL lookup will be performed, attempting to find a user in the database
* with the `id` provided in the `user_id` param.
*
* The result of the database query is sent back in the response.
*/
app.post('/users', function(req, res) {
const user_id = req.params.user_id;
/*
* Connect to the SQL database (server side).
*/
await sql.connect('mssql://username:password@localhost/database');
/*
* Query the database, providing the `user_id` param from the HTTP
* request body.
*/
const result = await sql.query('SELECT * FROM users WHERE USER = ' + user_id);
/*
* Return the result of the SQL query to the requester in the
* HTTP response.
*/
return res.json(result);
});
• In this example, a developer used direct string concatenation to attach the query
param to the SQL query. This assumes the query param being sent over the network
has not been tampered with, which we know not to be a reliable metric for legitimacy.
In the case of a valid user_id, this query will return a user object to the requester.
 • In the case of a more malicious user_id string, many more objects could be returned
from the database. Let’s look at one example:
const user_id = '1=1'
• Ah, the old truthy evaluation. Now the query says SELECT * FROM users where
USER = true, which translates into “give all user objects back to the requester.”
What if we just started a new statement inside of our user_id object?
user_id = '123abc; DROP TABLE users;';
• Now our query looks like this: SELECT * FROM users WHERE USER = 123abd;
DROP TABLE users;. In other words, we appended another query on top of the
original query. Oops, now we need to rebuild our userbase.
A more stealthy example can be something like this:
const user_id = '123abc; UPDATE users SET credits = 10000 WHERE user = 123abd;'
Now, rather than requesting a list of all users, or dropping the user tables, we are
using the second query to update our own user account in the database
Code Injection
• In the injection world, SQL injection is just a subset of “injection"-style attacks. SQL
injection is categorized as injection because it involves an interpreter (the SQL interpreter)
being targeted by a payload that is read into the interpreter as a result of improper
sanitization, which should allow only specific parameters from the user to be read into the
interpreter.
• A command-line interface (CLI) called by an API endpoint is provided with
additional unexpected commands due to lack of sanitization
(see Figure 13-2). These commands are executed against the CLI.

Figure 13-2. CLI injection

• SQL injection is first an injection attack and second a code injection attack. This is
because the script that runs in an injection attack runs under an interpreter or CLI
rather than against the host operating system (command injection).
 • As mentioned earlier, there are many lesser-known styles of code injection that do not
rely on a database. These are less common for a number of reasons. First, almost
every complex web application today relies on a database for storing and retrieving
user data. So it’s much more likely you will find SQL or other database injection
instead of injection against a less common CLI running on the server.
• In addition, knowledge of exploiting SQL databases through injection is very
common, and SQL injection attacks are easy to research. You can perform a couple of
quick searches on the internet and find enough reading material on SQL injection to
last you for hours, if not days.
• Other forms of code injection are harder to research, not because they are less
common (they are, but I don’t believe that’s why there is less documentation), but
because often code injection is application specific. In other words, almost every web
application will make use of a database (typically some type of SQL), but not every
web application will make use of other CLI/interpreters that can be controlled via an
API endpoint.
• Let’s consider an image/video compression server that MegaBank has allocated for
use in its customer-facing marketing campaigns. This server is a collection of REST
APIs located at https://media.mega-bank.com. In particular, it consists of a few
interesting APIs:
• uploadImage (POST)
• uploadVideo (POST)
• getImage (GET)
• getVideo (GET)
The endpoint uploadImage() is a simple Node.js endpoint that looks something like
this:
const imagemin = require('imagemin');
const imageminJpegtran = require('imagemin-jpegtran');
const fs = require('fs');
/*
* Attempts to upload an image provided by a user to the server.
*
* Makes use of imagemin for image compression to reduce impact on server
drive space.
*/
app.post('/uploadImage', function(req, res) {
if (!session.isAuthenticated) { return res.sendStatus(401); }
/*
* Write the raw image to disk.
fs.writeFileSync(`/images/raw/${req.body.name}.png`, req.body.image);
/*
* Compresses a raw image, resulting in an optimized image with lower disk
* space required.
*/
const compressImage = async function() {
const res = await imagemin([`/images/raw/${req.body.name}.png`],
`/images/compressed/${req.body.name}.jpg`);
return res;
};
/*
* Compress the image provided by the requester, continue script
* expecution when compression is complete.
*/
const res = await compressImage();
/*
* Return a link to the compressed image to the client.
*/
return res.status(200)
.json({url: `https://media.mega-bank.com/images/${req.body.name}.jpg` });
});
• This is a pretty simple endpoint that converts a PNG image to a JPG. It makes use of
the imagemin library to do so, and does not take any params from the user to determine the
compression type, with the exception of the filename.
It may, however, be possible for one user to take advantage of filename duplication and
cause the image min library to overwrite existing images. Such is the nature of filenames
on most operating systems:
// on the front-page of https://www.mega-bank.com
<html>
<!-- other tags -->
<img src="https://media.mega-bank.com/images/main_logo.png">
<!-- other tags -->
</html>
const name = 'main_logo.png';
// uploadImage POST with req.body.name = main_logo.png
• This doesn’t look like an injection attack, because it’s just a JavaScript library that is
converting and saving an image. In fact, it just looks like a poorly written API endpoint that
did not consider a name conflict edge case.
• However, because the imagemin library invokes a CLI (imagemin-cli), this would
actually be an injection attack— making use of an improperly sanitized CLI attached
to an API to perform unintended actions.
Command Injection
• With command injection, an API endpoint generates Bash commands, including a
request from a client. A malicious user adds custom commands that modify the normal
operation of the API endpoint (see Figure 13-3).
 • My reasoning for introducing the CLI example using a video converter in the last
section was to ease into command injection. So far we have learned that code
injection involves taking advantage of an improperly written API to make an
interpreter or CLI perform actions that the developer did not intend. We have also
learned that command injection is an elevated form of code injection where rather
than performing unintended actions against a CLI or interpreter, we are performing
unintended actions against an OS.

Figure 13-3. Command injection

• Let’s step back for a second and consider the implications of an attack at this level.
First, the ability to execute commands (typically Bash) against a Unix-based OS (Macintosh
or Linux) has very serious risks attached to it. If we have direct access to the host Unix OS
(over 95% of servers are Unix-based), and our commands are interpreted as a super user, we
can do anything we want to that OS.
• A compromised OS gives the hacker access to a number of very integral files and
permissions, such as:
/etc/passwd
Keeps track of every user account on the OS
/etc/shadow
Contains encrypted passwords for users
~/.ssh
Contains SSH keys for communicating with other systems
/etc/apache2/httpd.conf
Configuration for Apache-based servers
/etc/nginx/nginx.conf
Configuration for Nginx-based servers
Furthermore, command injection could potentially give us write permissions against these
files in addition to read permissions.

3.Cross-Site Scripting(XSS)
• Cross-Site Scripting (XSS) vulnerabilities are some of the most common
vulnerabilities throughout the internet, and have appeared as a direct response to the
increasing amount of user interaction in today’s web applications.
• At its core, an XSS attack functions by taking advantage of the fact that web
applications execute scripts on users’ browsers. Any type of dynamically created
script that is executed puts a web application at risk if the script being executed can be
contaminated or modified in any way—in particular by an end user. XXS attacks are
categorized a number of ways, with the big three being:
1. Stored (the code is stored on a database prior to execution)
2. Reflected (the code is not stored in a database, but reflected by a server)
3. DOM-based (code is both stored and executed in the browser)
• There are indeed categorical variations beyond this, but these three encompass the
types of XSS that most modern web applications need to look out for on a regular
basis. These three types of XSS attacks have been designated by committees like the
Open Web Application Security Project (OWASP) as the most common XSS attack
vectors on the web.
XSS Discovery and Exploitation
• Imagine you are unhappy with the level of service provided by mega-bank.com.
Fortunately for you, mega-bank.com offers a customer support portal, support.
Megabank.Com, where you can write feedback and hopefully hear back from a
customer support representative.
You write a comment in the support portal, with the following text:
I am not happy with the service provided by your bank.
I have waited 12 hours for my deposit to show up in the web application.
Please improve your web application.
Other banks will show deposits instantly.
—Unhappy Customer, support.mega-bank.com
• Now, in order to emphasize how unhappy you are with this fictional bank, you decide
you want to bold a few words. Unfortunately the UI for submitting support requests
does not support bolding text.
Because you are a little bit tech savvy, you try to add in some HTML bold tags:
I am not happy with the service provided by your bank.
I have waited 12 hours for my deposit to show up in the web application.
<strong>Please improve your web application.</strong>
Other banks will show deposits instantly.
—Unhappy Customer, support.mega-bank.com
After you press Enter, your support request is shown to you. The text inside the
<strong></strong> tags has been bolded.
A customer support representative soon messages you back:
Hello, I am Sam with MegaBank support.
I am sorry you are unhappy with our application.
We have a scheduled update next month on the fourth that should increase the speed
at which deposits are reflected in our app.
By the way, how did you bold that text?
—Sam from Customer Support, support.mega-bank.com
What is happening here is actually pretty common in many web applications. Here we have a
very simple architectural mistake that can be deadly to a company if left alone until a hacker
finds it.
user submits comment via web form ->
user comment is stored in database ->
comment is requested via HTTP request by one or more users ->
comment is injected into the page ->
injected comment is interpreted as DOM rather than text
Usually this happens as a result of a developer literally applying the result of the
HTTP request to the DOM. Frequently this is done by a script like the following:
/*
* Create a DOM node of type 'div.
* Append to this div a string to be interpreted as DOM rather than text.
*/
const comment = 'my <strong>comment</strong>';
const div = document.createElement('div');
div.innerHTML = comment;
/*
* Append the div to the DOM, with it the innerHTML DOM from the comment.
* Because the comment is interpreted as DOM, it will be parsed
* and translated into DOM elements upon load.
*/
const wrapper = document.querySelector('#commentArea');
wrapper.appendChild(div);
Because the text is appended literally to the DOM, it is interpreted as DOM markup
rather than text. Our customer support request included a <strong></strong> tag in this case.
Stored XSS
• Stored XSS attacks are probably the most common type of XSS attack. Stored XSS
attacks are interesting because they are the easiest type of XSS to detect, but often one
of the most dangerous because many times they can affect the most users (see Figure
10-1).

Figure 10-1. Stored XSS—malicious script uploaded by a user that is stored in a

database and then later requested and viewed by other users, resulting in script
execution on their machines
• A stored database object can be viewed by many users. In some cases all of your users
could be exposed to a stored XSS attack if a global object is infected. If you operated
or maintained a video-hosting site and “featured” a video on the front page, a stored
XSS in the title of this video could potentially affect every visitor for the duration of
the video. For these reasons, stored XSS attacks can be extremely deadly to an
organization.
• On the other hand, the permanent nature of a stored XSS makes detection quite easy.
Although the script itself executes on the client (browser), the script is stored in a
database, aka server side.
Reflected XSS
• Most books and educational resources teach reflected XSS before introducing stored
XSS. I believe reflected XSS attacks are often much more difficult for newly minted
hackers to find and take advantage of than stored XSS attacks.
• A stored XSS attack is very simple to understand from a developer’s point of view.
The client sends a resource to the server, typically over HTTP. The server updates a
 database with the resource received from the client. Later on, that resource may be
accessed by other users, in which case the malicious script will execute unknowingly
inside of the requester’s internet browser.
• Reflected XSS attacks, on the other hand, operate identically to stored XSS attacks
but are not stored in a database, nor should they regularly hit a server. A reflected
XSS affects the code of the client in the browser directly without relying on a server
to relay a message to be rendered with a script to be executed (see Figure 10-2).

Figure 10-2. In reflected XSS, a user performs an action against the local web
application resulting in script execution of an unstored (linked) on their own device
• As a result of not being stored on the server, reflected XSS can be a bit hard to
understand compared to stored XSS. Let’s start out with an example. We are once
again a customer of a fictional bank with a web application located at mega-
bank.com.
• This time, we are trying to look up support documentation for how to open a new
savings account to complement our existing checking account. Fortunately, mega-
bank.com’s support portal, support.mega-bank.com, has a search bar we can use to
look up common support requests and their solutions.
• The first thing we try is a search for “open savings account.” This search redirects us
to a new URL at support.mega-bank.com/search?query=open+savings+account. On
this search results page we see the heading: 3 results for “open savings account.” Next
we try adjusting the URL to support.mega-bank.com/search?query=open+checking+
account. The heading on the results page now becomes: 4 results for “open checking
account.”
DOM-Based XSS
• The final major categorization for XSS attacks is DOM-based XSS, illustrated in
Figure 10-3. DOM XSS can be either reflected or stored, but makes use of browser
DOM sinks and sources for execution. Due to differences in browser DOM
implementation, some browsers might be vulnerable while others are not.
• These XSS attacks are much more difficult to find and take advantage of than
traditional reflected or stored XSS, as they require deep knowledge of the browser
DOM and JavaScript.

Figure 10-3. DOM-based XSS

• The major difference between for DOM XSS and other forms of XSS is that
DOMbased XSS attacks never require any interaction with a server. As a result, there
is a movement to start categorizing DOM XSS as a subset of a new category called
clientside XSS.
Mutation-Based XSS
• Several years ago, my friend and colleague Mario Heiderich published a paper called
“mXSS Attacks: Attacking well-secured Web-Applications by using inner HTML
Mutations.” This paper was one of the first introductions to a new and emerging
classification of XSS attacks that has been dubbed mutation-based XSS (mXSS).
• mXSS attacks are possible against all major browsers today. They rely on developing
a deep understanding of methods by which the browser performs optimizations and
conditionals when rendering DOM nodes.
4.Cross-Site Request Forgery

• CSRF attacks take advantage of the way browsers operate and the trust relationship
between a website and the browser. By finding API calls that rely on this relationship
to ensure security—but yield too much trust to the browser—we can craft links and
forms that with a little bit of effort can cause a user to make requests on his or her
own behalf—unknown to the user generating the request.
• Oftentimes CSRF attacks will go unnoticed by the user that is being attacked—as
requests in the browser occur behind the scenes.
Query Parameter Tampering
• Let’s consider the most basic form of CSRF attack—parameter tampering via a
hyperlink. Most forms of hyperlink on the web correspond with HTTP GET requests.
The most common of which is simply an <a href="https://my-site.com"></a>
embedded in an HTML snippet.
• The anatomy of an HTTP GET request is simple and consistent regardless of where it
is sent from, read from, or how it travels over the network. For an HTTP GET to be
valid, it must follow a supported version of the HTTP specification—so we can rest
assured that the structure of a GET request is the same across applications.

The anatomy of an HTTP GET request is as follows:

GET /resource-url?key=value HTTP/1.1
Host: www.mega-bank.com
• Every HTTP GET request includes the HTTP method (GET), followed by a resource
URL and then followed by an optional set of query parameters. The start of the query
params is denoted by ? and continues until whitespace is found. After this comes the
HTTP specification, and on the next line the host at which the resource URL can be
located.
• When a web server gets this request it will be routed to the appropriate handler
class,which will receive the query parameters alongside some additional information
to identify the user that made the request, the type of browser they requested from,
and what type of data format they expect in return.
Figure 11-1. CSRF GET—a malicious link is spread that causes state-changing HTTP
GET requests to be performed on behalf of the authenticated user when clicked

Let’s look at an example in order to make this concept more concrete.

The first example is a server-side routing class that is written on top of Express.js—
the most popular Node.js-based web server software:
/*
* An example route.
*
* Returns the query provided by the HTTP request back to the requester.
* Returns an error if a query is not provided.
*/
app.get('/account', function(req, res) {
if (!req.query) { return res.sendStatus(400); }
return res.json(req.query);
});
This is an extremely simple route that will do only a few things:
• Accept only HTTP GET request to /account
• Return an HTTP 400 error if no query params are provided
• Reflect query params to the sender in JSON format if they are provided
Let’s make a request to this endpoint from a web browser:
/*
* Generate a new HTTP GET request with no query attached.
* This will fail and an error will be returned.
*/
const xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
console.log(xhr.responseText);
}
xhr.open('GET', 'https://www.mega-bank.com/account', true);
xhr.send();
Here, from the browser we initiate an HTTP GET request to the server, which will
return a 400 error because we did not provide any query parameters.
We can add the query parameters to get a more interesting result:
/*
* Generate a new HTTP GET request with a query attached.
*
* This will succeed and the query will be reflected in the response.
*/
const xhr = new XMLHttpRequest();
const params = 'id=12345';
xhr.onreadystatechange = function() {
console.log(xhr.responseText);
}

xhr.open('GET', `https://www.mega-bank.com/account?${params}`, true);

xhr.send();
Shortly after making this request, a response will be returned with the content:
{
id: 12345
}
It will also include an HTTP 200 status code if you check out the network request in
your browser.
It is crucial to understand the flow of these requests in order to find and make use of
CSRF vulnerabilities. Let’s backtrack a bit and talk about CSRF again.
The two main identifiers of a CSRF attack are:
• Privilege escalation
• The user account that initiates the request typically does not know it occurred (it
is a stealthy attack)

Alternate GET Payloads

Because the default HTTP request in the browser is a GET request, many HTML tags that
accept a URL parameter will automatically make GET requests when interacted with or
when loaded into the DOM. As a result of this, GET requests are the easiest to attack via
CSRF.
In the prior examples, we used a hyperlink <a></a> tag in order to trick the user into
executing a GET request in their own browser. Alternatively, we could have crafted an
image to do the same thing:
<!--Unlike a link, an image performs an HTTP GET request right when it loads
into the DOM. This means it requires no interaction from the user loading the webpage.-->
<img src="https://www.mega-bank.com/transfer?
to_user=<hacker's account>&amount=10000" width="0" height="0" border="0">
When image tags are detected in the browser, the browser will initiate a GET request
to the src endpoint included in the <img> tag (see Figure 11-2). This is how the image
objects are loaded into the browser.
As such, an image tag (in this case an invisible 0 × 0 pixel image) can be used to initiate
a CSRF without any user interaction required.

Figure 11-2. CSRF IMG—inside of the target application, an <img> tag is posted that
forces an HTTP GET when loaded

Likewise, most other HTML tags that allow a URL parameter can also be used to
make malicious GET requests. Consider the HTML5 <video></video> tag:
<!-- Videos typically load into the DOM immediately, depending on the browser's
configuration. Some mobile browsers will not load until the element is interacted
with. -->
<video width="1280" height="720" controls>
<source src="https://www.mega-bank.com/transfer?
to_user=<hacker's account>&amount=10000" type="video/mp4">
</video>
• The preceding video functions identically to the image tag used. As such, it’s
important to be on the lookout for any type of tag that requests data from a server via
an src attribute. Most of these can be used to launch a CSRF attack against an
unsuspecting end user.
CSRF Against POST Endpoints
• Typically CSRF attacks take place against GET endpoints, as it is much easier to
distribute a CSRF via a hyperlink, image, or other HTML tag that initiates an HTTP
GET request automatically.
• However, it is still possible to deliver a CSRF payload that targets a POST, PUT, or
DELETE endpoint. Delivery of a POST payload just requires a bit more work as well
as some mandatory user interaction (see Figure 11-3).
Typically CSRF attacks delivered by POST requests are created via browser forms, as
the <form></form> object is one of the few HTML objects that can initiate a POST
request without any script required.
<form action="https://www.mega-bank.com/transfer" method="POST">
<input type="hidden" name="to_user" value="hacker">
<input type="hidden" name="amount" value="10000">
<input type="submit" value="Submit">
</form>
In the case of CSRF via POST form, we can make use of the “hidden” type attribute
on form inputs in order to seed data that will not be rendered inside of the browser.
Figure 11-3. CSRF POST—A form is submitted targeting another server that is not
accessible to the creator of the form but is to the submitter of the form

We can further manipulate the user by offering legitimate form fields in addition to
the hidden fields that are required to design the CSRF payload:
<form action="https://www.mega-bank.com/transfer" method="POST">
<input type="hidden" name="to_user" value="hacker">
<input type="hidden" name="amount" value="10000">
<input type="text" name="username" value="username">
<input type="password" name="password" value="password">
<input type="submit" value="Submit">
</form>
• In this example, the user will see a login form—perhaps to a legitimate website. But
when the form is filled out, a request will actually be made against MegaBank—no
login attempt to anything will be initiated.
• This is an example of how legitimate-looking HTML components can be used to send
requests taking advantage of the user’s current application state in the browser. In this
case, the user is signed into MegaBank, and although they are interacting with an
entirely different website, we are able to take advantage of their current session in
MegaBank to perform elevated operations on their behalf.
• This technique can also be used to make requests on behalf of a user who has access
to an internal network. The creator of a form cannot make requests to servers on an
internal network, but if a user who is on the internal network fills out and submits the
 form, the request will be made against the internal server as a result of the target
user’s elevated network access.
• Naturally, this type of CSRF (POST) is more complex than seeding a CSRF GET
request via an <a></a> tag—but sometimes you must make an elevated request
against a POST endpoint in which case forms are the easiest way of successfully
making an attack.
5. BROKEN AUTHENTICATION AND SESSION MANAGEMENT

Broken authentication is often the result of weaknesses in access controls and session
management. Some common weaknesses include weak password policies, unencrypted
traffic, and poor logout mechanisms and timeouts.

Factors of authentication

Before we can talk about weak passwords, we should mention factors of authentication. A
password, for example, is one kind of authentication factor.

• When an application tries to authenticate your identity, it usually uses a combination

of three factors: Knowledge, Possession, and Physical (Something you Know or You
have or You are). It can’t use just one factor because one isn’t strong enough on its
own.
 • The knowledge factor is something you know, like your password, but it can’t be
relied on to protect your account on its own because it can be guessed by someone
who knows you, or found if you wrote it down.
• The possession factor is something you have, like a key card or ID. These items can
be lost or stolen by someone who wants to impersonate you. And the physical factor
is what you are, like your fingerprints.
• This factor is expensive to use, can have problems with accuracy, and is difficult to
replace. Since your physical factors don’t typically change, and you can’t easily
replace them, this factor can be problematic.
• Let’s look at an example. ‘Vijay Kumar’ works at a company called CRCE Inc. that
forces all their employees to reset their passwords every 15 days. After years of
working at CRCE Inc., Vijay resets his password and jots it down in a notebook just
in case he forgets it.
• The next day, Vijay finds that someone has logged into his computer and changed his
background. Vijay’s co-worker, Emily, saw him write down his password and was
able to log into his account.

Weak password change control and practices

• Forgotten passwords can actually be a major risk for user account authentication.
Even though many users and businesses rely on this feature, it isn’t always secure.
Attackers can actually benefit from weak “forgot username” or “forgot password”
features on an otherwise secure website.
• In this example, an attacker uses a “Forgot Password” page and enters the username
of their target. The “Forgot Password” page then sends a 6-digit secret code to the
account owner that expires in 15 minutes.
• Even though the feature makes sure the secret code expires, there are no limits on the
number of attempts someone can enter the code. The attacker could easily brute force
the code by entering all possibilities for the 6 digits within those 15 minutes.

About HTTP and cookies

• HTTP is the language we use to talk on the web and is important to understand before
we discuss session management. There are different versions of HTTP, but in general,
you can think of HTTP as working through requests and responses.
• HTTP requests contain a lot of information that helps applications track state and user
session management. Each HTTP request contains a goldmine of information that can
be traced like a trail of breadcrumbs if unprotected.
 • This information is stored in cookies on the client-side, and in session IDs, also called
session tokens, on the server-side. Session cookies, one of many types of cookies,
contain a session ID.
• Session cookies and session IDs have the same goal, and help to keep state. They
store information about your interaction with a web site, but cookies are stored in
your browser, whereas a session ID is a string of random numbers and letters that
must be sent on every request. Cookies don’t expire until you close the browser, but
session IDs can time out.
• Session IDs are a representation of the user and their actions on the web. For instance,
session IDs can have data about whether a user is logged in, has items in a shopping
cart, or has timed-out their session. In fact, the only defining feature of what identifies
a user on the web is their session ID.

Insecure Session Management

• This brings us to insecure session management. As we mentioned, when you log in to

a web site, you’re assigned a session ID. This becomes associated with your browser
and allows you to navigate the web site without having to enter your password on
each page. Your session ID identifies and represents you on the web.
• Unfortunately, many sites only securely protect a user’s credentials, and not the
session ID. If a hacker were able to get someone’s session ID, they would be able to
log in and impersonate that user before the session timed out.
• Hackers could guess or predict Which session IDs are active to impersonate another
user by using their assigned ID. They could even steal IDs if the server were sending
out session IDs under unencrypted traffic.
Session hijacking

• Unencrypted or clear-text traffic is any web traffic sent through an insecure channel
that isn’t encrypted. Clear-text traffic is highly vulnerable to man-in-the-middle
attacks because it isn’t protected and can be read by anyone who intercepts it using
various techniques.
• If a hacker comes along and intercepts unencrypted web traffic, then they could steal
session ID and impersonate a user. Remember, the session ID is the only thing that
identifies users, so if a hacker steals this, the webserver can no longer tell the
difference between a legitimate user and the hacker.
• We all know about insecure WiFi and using an unsecured public WiFi connection,
Let’s look at an example of how session hijacking can work.
• ‘Vijay Kumar’ is a sales executive and browsing his recent sales transactions on a
local coffee shop’s free wireless connection. Vijay’s connection on the public WiFi is
over HTTP, which doesn’t use encryption.
• Meanwhile, a mischievous computer expert is also sitting at the coffee shop and
intercept Vijay’s network traffic using special tools and successfully retrieve its
session ID from unencrypted network traffic.
• The hacker simply copies the session ID into his/her own browser, and since Vijay
has already authenticated, he is able to log in. Since, they are both using the same
session ID, as long as Vijay doesn’t log out, the hacker will have access using the
same session ID.

Session fixation

• Sessions can also be vulnerable to session fixation attacks. This happens when an
attacker fixes, or forces, a session they already know onto an unsuspecting user. If the
user authenticates with the fixed session, the attacker can then use it with all of the
same privileges as that user.
• For example, rather than attempting to hijack a user’s session, an attacker can
purposely expose a link with their session identifier to a known administrator. When
the administrator logs in, the session becomes active with administrator privileges.
• However, the attacker also has access to the fixed session ID, so the attacker’s session
is also active.
Countermeasures against Broken Authentication

Use 2 factors of authentication

• As we learned about factors of authentication in the above sections of this article and
by combining different factors of authentication, the web application can overcome
from unique weaknesses.
• For example, the Administrator can combine knowledge with possession-based
authentication to overcome a weakness in a password being guessed or a token being
lost.
• Using two different factors of authentication together is called 2-factor authentication,
and many organizations are improving their security by using two or more factors for
their authentication.

Strengthen forgot password controls

• While implementing the forgot password feature, considering some of the above-
mentioned countermeasures can help by adding layers of defense against hackers.
• Treat the forgot password feature with the same importance as authentication by
adding aspects such as complexity to any secret challenges or even 2 Factor
Authentication.

Session timeout

• Setting a reasonable session timeout can help ensure that attackers who steal session
IDs have a limited timeframe to use them in.
• A session timeout can depend on the security profile of the application. 5-10 minutes
may be reasonable, but the organization should decide based on risk.
• Another option is to implement an absolute timeout so that even if a session is stolen,
forcing a logoff after a fixed time ensures that all sessions eventually expire.
• Finally, before any new user session is authorized, any existing session IDs should be
invalidated. This prevents session fixation.

Network encryption

• Encrypting traffic using SSLJTLS is another way to protect user information and is
becoming more common. In a previous example, we saw how a hacker could
intercept web traffic and steal session data, but if traffic is encrypted, this is no longer
possible, or at least very difficult.
Encryption is a good first defense against session hijacking.

Account lockout

• Finally, account lockout is a good defense against password attacks. Limiting the
number of attempts users have to enter their passwords can help ensure that hackers
can’t use brute force techniques by trying passwords until they gain access.
• However, the account lockout can cause problems. Attackers cause a denial of service
if they try to lock out all of the accounts of a system. In this case, consider using a
policy that increasingly delays the time between password attempts each time they fail
to enter incorrectly, rather than locking out the account.

Key Takeaway from this article

• SessionlDs are how users are identified in web applications and so disclosing this
session ID is dangerous as users can be impersonated.
• Encryption is a good first defense against traffic sniffing and can help protect clear-
text traffic on the Internet. Account lockouts or increasing time delays can help deter
hackers from automated attacks against your web application.
• Implementing session timeouts can also help ensure that if a session is stolen, by the
time it is used it has already expired.

6.Security Misconfiguration

What Is Security Misconfiguration?

• Security misconfiguration is any error or vulnerability present in the configuration

of code that allows attackers access to sensitive data. There are many types of
security misconfiguration, but most present the same danger: vulnerability to data
breach and attackers gaining unauthorized access to data.

Security Misconfigurations and Their Dangers

• Security misconfiguration, because it involves flaws in security configuration, can

lead to a data breach and even complete system compromise. Depending on the
value of the data compromised, this can have a significant negative impact on a
business.
• Attackers may be able to exploit or even modify parts of applications by taking
advantage of security misconfigurations. These security misconfiguration
vulnerabilities leave a business exposed to potential attack.
Examples of Security Misconfigurations

• Some concrete examples of security misconfigurations include AD

misconfigurations, vulnerabilities within the Active Directory domain. These
common security misconfigurations range from attackers gaining administrative
privileges to issues arising from services running on hosts with multiple
administrators.
• Another example is a security misconfiguration that was discovered in JIRA, a
collaboration tool. One misconfiguration exposed many companies to the
vulnerability of releasing corporate and personal data. In this case, it was an
authorization misconfiguration in Global Permissions that caused the security
risk. These are only two of the many kinds of security misconfiguration that can
affect a business.

How Security Misconfigurations Occur

• Security misconfiguration occurs when security settings are put in place poorly, or
not implemented at all. Cloud misconfiguration and identity service
misconfiguration both stem from improper security configuration.

Types of Security Misconfiguration

There are several types of security misconfiguration that can affect a business.

• AD misconfiguration, which exposes administrator and domain credentials.

• Identity access misconfiguration, which provides attackers easy access to
applications.
• API security misconfiguration, which leaves unrestricted endpoints and unprotected
files.
• Network security misconfiguration, which is incorrect configuration of an information
system.
• Cloud security misconfiguration, which leaves gaps in the cloud environment that
may lead to security breach.
• Web server misconfiguration, which often includes unnecessary default and sample
files.

Any aspect of an application or code that should have security measures is susceptible to
security misconfiguration.

Causes of Security Misconfiguration

Security misconfiguration can occur in many ways. Some of the common causes include:
 • Using default credentials or default passwords provided by a vendor
• Installing unused features
• Directory traversal
• Accidental security-lax coding

The Impact of Security Misconfiguration

• Security misconfiguration can expose a business to higher risk of attack, and

when attackers gain access, it can lead to major impact on the business. The risks
of security misconfiguration vary depending on the data that is exposed.
• Big or small, security misconfiguration can cause a business to lose money,
customers and reputation.

Risks of Security Misconfiguration

• The overarching risk of security misconfiguration is exposing systems, services or

data to attackers. Different types of attacks pose different levels of risk. In a
directory traversal attack, adversaries gain unauthorized access to browse file
structure and discover vulnerabilities.
• They can potentially modify parts of an application, and in some cases reverse
engineer it, causing significant loss for a business.
• Other misconfigurations, such as those present in firewalls or unused
administration ports, expose a business to vulnerability of a remote attack. Cloud
misconfiguration can lead to application access for attackers and poses other
security risks depending on what data a business stores in the cloud. Security
misconfiguration exposes a business to risks which have immediate and lasting
impact.

How Security Misconfiguration Impacts Businesses

• When sensitive data is leaked or stolen by an attacker, the result can mean
potential loss of customers, regulatory fines for failing to meet required security
measures, and harm to finances and reputation.
• In addition, any business-critical information gained by an attacker can put a
business at further risk. The access gained via security misconfiguration flaws can
also lead to complete system compromise.
• Any breach of data or applications can slow down a business and, in some cases,
bring production to a halt. The greater the protection needs of an application or
data that is exposed, the worse the impact on a business. That’s why preventing
security misconfiguration is vital.
Preventing Security Misconfiguration

• Preventing security misconfiguration requires implementing necessary security

measures and ensuring a firm grip on access control, typically with an identity and
access management (IAM) framework. It is also important to have a way to
diagnose any security misconfigurations quickly and accurately as they arise.

How to Diagnose Security Misconfigurations

• Finding security misconfigurations that already exist is just as important as

preventing them. First, a business should improve visibility across its ecosystem.
Using network diagrams and security scanning can provide insight on expected
performance of applications.
• Improved visibility and real-time insights can provide a business with the ability
to spot security misconfigurations before they become a problem.
• Along with scanning, internal testing and external application security testing can
give a business insight into its vulnerability. The testing stage is where discovered
security misconfigurations can be diagnosed. If this is done prior to deployment,
the risk can be prevented before an attacker has a chance.

7.Insecure Cryptographic Storage

• When you sign up for a mobile banking or any online account, you trust that the
application securely stores your username, password, bank account number, and all
other sensitive information.

• You may imagine your data getting encrypted or turned into random strings of
characters while stored in the company’s database. The only way to make sense of
them is by having the encryption key.

• Even if hackers manage to log in to the financial application’s database, they still
can’t decipher the data if they don’t have the key. But when the application has
insecure cryptographic storage, they may be able to crack the encryption and see the
actual user data. The video below shows how insecure cryptographic storage works.
How Can Insecure Cryptographic Storage Be Exploited?

• Malicious insiders like disgruntled employees may take advantage of insecure

cryptographic storage and steal sensitive data. It may take a while to detect this
malicious activity, especially if the employee has access to the data.

• Outside attackers may exploit other vulnerabilities to gain unauthorized access to the
database. For instance, they can use brute force, a trial-and-error tactic to guess login
information.

What Causes Insecure Cryptographic Storage?

There are several reasons behind insecure cryptographic storage, including:

• Failure to encrypt data: Companies usually encrypt data while in transit or traveling
from one user to another. However, some may fail to implement encryption
algorithms while the data is at rest or stored. When this happens, it only takes a hacker
to successfully access the company’s database to expose all sensitive data.

• Failure to encrypt the correct data: If your bank’s application security is designed to
encrypt usernames and passwords but not bank account details and phone numbers,
this is already a type of insecure cryptographic storage. Threat actors can perform a
social engineering attack by contacting the account owners over the phone.

• Using DIY encryption algorithms: Some developers may be brilliant enough to create
their encryption algorithm. While the process could be fun, it’s not very secure. For
one, the algorithm may not completely follow industry requirements.
 • Using obsolete encryption algorithms: At present, Advanced Encryption Standard
(AES) is the algorithm standard used by large companies and government agencies. It
is one of the recommended algorithms, and using outdated ones may be risky.

What Are the Effects of Insecure Cryptographic Storage?

• The most obvious repercussion of having insecure cryptographic storage is the

increased vulnerability to data breaches. When cryptographic storage is done
correctly, hackers won’t be able to use any of the data even if they can access the
database.

• The data will remain gibberish and invaluable. However, if one type of sensitive data
is not encrypted, if the encryption used is weak, or if the encryption key is not stored
correctly, hackers may have a huge payday.

• The resulting data breach can have less quantifiable effects, such as loss of customer
trust and reputational damage to the company.

How Can Insecure Cryptographic Storage Be Prevented?

• To avoid exposing data to insecure cryptographic storage, it’s important to define data
security during the software development process. This process includes discussing
what data to encrypt, what encryption algorithm to use, and all other pertinent details
in securing sensitive information.

• Regularly scanning the application or software for vulnerabilities is also vital in early
insecure cryptographic storage detection and prevention.
8.Failure to Restrict URL Access

• Failure to Restrict URL Access (FTRE) is a security vulnerability that occurs when a
web application does not properly enforce restrictions on access to sensitive pages or
functionality by unauthenticated or unauthorized users.
• This can lead to the exposure of confidential data or the execution of unauthorized
actions by attackers. FTRE can arise due to a variety of reasons such as improper
access control mechanisms, insufficient authentication and authorization checks, or
incorrect configuration of server-side security controls.

Example of vulnerable code on different programming languages:

• in Python:

@app.route('/admin')

def admin_panel():

if request.args.get('auth_token') == 'SECRET_TOKEN':

# Display admin panel

return render_template('admin.html')

else:

# Redirect to login page

return redirect('/login')

• In this example, the web application checks for the presence of an “auth_token” query
parameter to determine if the user is authenticated to access the admin panel.
However, this code does not enforce any restrictions on who can access the admin
panel. An attacker could simply guess or brute-force the auth token and gain access to
sensitive functionality.

in PHP:

if ($_SESSION['authenticated'] === true) {

// Display sensitive content

} else {
 header('Location: /login.php');

exit();

• This PHP code checks for a session variable called “authenticated” to determine if the
user is authenticated. However, if the web application fails to properly destroy
sessions on logout or if an attacker can steal a valid session cookie, they can bypass
this check and access the sensitive content without being authenticated.

• in Java:

@RequestMapping("/admin")

public ModelAndView adminPanel(@RequestParam(value = "auth_token") String

authToken) {

if (authToken.equals("SECRET_TOKEN")) {

// Display admin panel

return new ModelAndView("admin");

} else {

// Redirect to login page

return new ModelAndView("redirect:/login");

• This Java code uses the Spring Framework to check for the presence of an
“auth_token” query parameter to determine if the user is authenticated to access the
admin panel. However, this code does not enforce any restrictions on who can access
the admin panel. An attacker could simply guess or brute-force the auth token and
gain access to sensitive functionality.

Examples of exploitation Failure to Restrict URL Access

Unrestricted access to sensitive data:

• An attacker could guess or brute-force a valid URL or query parameter that grants
access to sensitive data, such as customer data or confidential business information.
For example, if a web application has a URL like “example.com/customer/123” to
display customer information, an attacker could try guessing different customer IDs
until they find a valid one that grants access to sensitive data.

Unauthorized access to functionality:

• An attacker could guess or brute-force a valid URL or query parameter that grants
access to sensitive functionality, such as an administrative panel or a payment
processing page.
• For example, if a web application has an admin panel at “example.com/admin” with
no authentication checks, an attacker could simply guess or brute-force the URL and
gain access to the admin panel.

Bypassing authentication and authorization checks:

• An attacker could manipulate URLs or query parameters to bypass authentication or

authorization checks and gain access to sensitive functionality or data. For example, if
a web application checks for an “auth_token” query parameter to determine if a user
is authenticated, an attacker could try modifying the parameter or injecting their own
to bypass the check and gain access to sensitive functionality.

Session hijacking:

• An attacker could steal a valid session cookie from a logged-in user and use it to
bypass authentication checks and gain access to sensitive functionality or data. For
example, if a web application uses session cookies to authenticate users, an attacker
could steal a valid session cookie using techniques such as XSS or CSRF attacks and
use it to access sensitive functionality or data without needing to provide valid
authentication credentials.

Privilege escalation techniques for Failure to Restrict URL Access

URL parameter manipulation:

• An attacker could manipulate the URL or query parameters to gain access to higher
levels of functionality or data. For example, if a web application has a URL like
“example.com/customer/123” that displays customer information, an attacker could
 modify the URL to “example.com/customer/123/admin” to try and gain access to
administrative functionality related to the customer.

Session fixation:

An attacker could use session fixation to set a valid session ID for a victim user,
allowing the attacker to access the victim’s account and privileges. For example, if a web
application uses session cookies to authenticate users, an attacker could set a valid session ID
for a victim user using a URL that includes the session ID, and then wait for the victim to log
in with the same session ID.

Cross-site scripting (XSS):

An attacker could use an XSS vulnerability to inject malicious JavaScript into a web
page, allowing them to steal session cookies or other sensitive information. This could allow
the attacker to bypass authentication and gain higher levels of access to the system or
application.

Cross-site request forgery (CSRF):

An attacker could use a CSRF attack to force a victim user to perform actions on their
behalf, such as changing the victim’s password or making unauthorized purchases. This
could allow the attacker to gain higher levels of access to the system or application by
performing actions that are not authorized for their own account.

General methodology and checklist for Failure to Restrict URL Access

Methodology:

Identify the application’s functionality: Understand the web application’s

functionality and identify any areas where user authentication and authorization checks are
required.

Identify the URLs and parameters: Identify the URLs and parameters associated with
the identified functionality.

Attempt to access the functionality without authentication: Attempt to access the

functionality by accessing the URLs and parameters associated with it, without providing
any authentication credentials. This can be done manually or through automated tools.
 Attempt to access the functionality with incorrect or invalid authentication
credentials: Attempt to access the functionality by providing incorrect or invalid
authentication credentials, such as a wrong username or password.

Checklist:

Understand the web application’s functionality and identify the different user roles, such as
regular users, administrators, or moderators

• Identify the URLs and query parameters associated with the identified functionality,
and determine if they are properly restricted based on user roles.
• Test each URL and query parameter associated with the identified functionality to
determine if it can be accessed without proper authentication and authorization.
• Test each URL and query parameter associated with the identified functionality with
incorrect or invalid credentials to determine if it is possible to gain unauthorized
access.
• Test each URL and query parameter associated with the identified functionality with
valid credentials for different user roles, such as a regular user account or an
administrative account, to determine if proper authorization checks are in place.
• Attempt to bypass authentication and authorization checks by manipulating URLs or
query parameters, or by using other techniques such as session fixation, XSS or CSRF
attacks.
• If any vulnerabilities are found, test for privilege escalation techniques to gain higher
levels of access to the system or application.
• Document any vulnerabilities found, including the steps to reproduce them, and report
them to the development team for remediation.
• Verify that any reported vulnerabilities have been properly remediated before
considering the testing complete.

Tools set for exploiting Failure to Restrict URL Access

Manual Tools:

• Burp Suite – A comprehensive web application security testing tool that includes
features for intercepting and modifying HTTP/S traffic, testing for various
vulnerabilities, and reporting findings.
• ZAP (Zed Attack Proxy) – A free, open-source web application security testing tool
that includes features for actively testing for various vulnerabilities, such as FTRE,
and reporting findings.
 • Postman – A popular tool for testing and debugging RESTful APIs, which can also be
used to manually test web applications for vulnerabilities such as FTRE.

Automated Tools:

• OWASP ZAP – A powerful automated security testing tool that includes features for
scanning web applications for various vulnerabilities, including FTRE.
• Nikto – An open-source web server scanner that can also be used to test web
applications for vulnerabilities, including FTRE.
• Arachni – A modular, open-source web application security testing tool that includes
features for scanning web applications for various vulnerabilities, including FTRE.
• Vega – An open-source web application security testing tool that includes features for
scanning web applications for various vulnerabilities, including FTRE.

OpenVAS
• OpenVAS, short for Open Vulnerability Assessment System, is an open-source
vulnerability scanning and vulnerability management tool designed to help
organizations identify security vulnerabilities in their networks, systems, and
applications. OpenVAS is similar in purpose to commercial vulnerability assessment
tools like Nessus.

Top 10 use cases of OpenVAS?

Here are the top 10 use cases of OpenVAS:

1. Vulnerability Scanning: OpenVAS scans networks, hosts, and applications to identify known
vulnerabilities, misconfigurations, and potential security weaknesses.
2. Plugin-Based Architecture: OpenVAS utilizes a plugin-based system that allows it to support
a wide range of vulnerability checks and security tests. New plugins can be added and
updated to keep up with the latest vulnerabilities.
3. Compliance Auditing: It can be used to assess compliance with various security standards
and regulatory requirements, such as PCI DSS, HIPAA, and CIS benchmarks.
4. Network Discovery: OpenVAS helps organizations identify and catalog all devices and
systems connected to their network, helping maintain an up-to-date inventory.
5. Web Application Scanning: OpenVAS can scan web applications for common
vulnerabilities, including SQL injection, cross-site scripting (XSS), and insecure
authentication.
 What are the feature of OpenVAS?

The following are the key features of OpenVAS:

1. Vulnerability Scanning: OpenVAS performs scans to identify vulnerabilities,

misconfigurations, and security weaknesses in hosts, systems, and applications.
2. Plugin-Based Architecture: OpenVAS uses a plugin-based system that allows it to support a
wide range of vulnerability checks and security tests. New plugins can be added and updated
to keep up with the latest vulnerabilities.
3. Compliance Auditing: OpenVAS can assess compliance with various security standards and
regulatory requirements, such as PCI DSS, HIPAA, and CIS benchmarks.
4. Network Discovery: It helps organizations identify all devices and systems connected to their
network, assisting in maintaining an accurate inventory.
5. Web Application Scanning: OpenVAS can scan web applications for common
vulnerabilities, including SQL injection, cross-site scripting (XSS), and insecure
authentication.
6. Customizable Scans: Users can configure OpenVAS scans by specifying target hosts, scan
policies, and other parameters to tailor scans to their specific needs.

How OpenVAS works and Architecture?

OpenVAS works by conducting scans on target systems and analyzing the results to identify
vulnerabilities and potential security issues. Here’s a simplified overview of how OpenVAS
works:
1. Scan Configuration: Users configure OpenVAS scans by defining target hosts, specifying
scan policies (e.g., which types of vulnerabilities to check), and setting other scan
parameters.
2. Scanning: OpenVAS performs scans on the target systems based on the configured policies.
It sends various probes and checks to detect vulnerabilities, misconfigurations, and potential
security risks.
3. Vulnerability Detection: During the scan, OpenVAS identifies vulnerabilities by comparing
its findings with a constantly updated database of vulnerability checks (plugins).
4. Data Analysis: OpenVAS analyzes the scan results and assigns severity levels to each
identified vulnerability, helping organizations prioritize remediation efforts.
5. Reporting: OpenVAS generates detailed reports that include a list of vulnerabilities, their
descriptions, severity ratings, and recommendations for mitigation.
OpenVAS Architecture:
OpenVAS typically consists of several components that work together to provide
vulnerability scanning and management capabilities:

1. OpenVAS Scanner: This component conducts the actual scanning of target hosts and collects
scan results. It communicates with the OpenVAS Manager to fetch scan configurations and
report results.
2. OpenVAS Manager: The manager coordinates the scanning process, manages scan policies,
and stores scan results. It acts as the central control point for managing and scheduling scans.
3. OpenVAS CLI and GUI: These are the user interfaces for interacting with OpenVAS. The
CLI provides a command-line interface, while the GUI offers a graphical user interface for
configuring scans, viewing results, and generating reports.
4. OpenVAS Greenbone Security Assistant (GSA): GSA is a web-based interface that allows
users to manage and configure OpenVAS scans through a web browser.
5. OpenVAS Knowledge Base (NVTs): The knowledge base contains a vast collection of
Network Vulnerability Tests (NVTs), which are plugins used to detect vulnerabilities.
6. OpenVAS OpenVAS Transfer Protocol (OTP): OTP is used for communication between
various components of OpenVAS.
OpenVAS can be deployed on a single server or in a distributed architecture for scalability.
Communication between these components is secured to protect sensitive scan data.

OpenVAS is a powerful tool for vulnerability assessment and management and is

particularly valuable for organizations looking for an open-source solution to identify and
address security vulnerabilities in their infrastructure.
Nexpose

• Nexpose is a vulnerability scanning tool. It is sold as a virtual machine, private cloud

deployment, standalone software, managed service, or appliance. The user can
interact with nexpose using the web browser. The editions of nexpose are paid except
for the free program that is Nexpose community edition.
• Nexpose is used to scan the vulnerability of a network. Nexpose finds the active
services which are running on the machine-like open ports, services and running
applications. Using the services, applications, it tries to find the existing vulnerability
on the network;
• It supports vulnerability management's lifecycle, including verification, impacts
analysis, discovery, risk classification, detection, reporting and mitigation. The result
of nexpose will be shown in the scan report. With the help of the result, we can
prioritize vulnerabilities on the basis of the risk factor. After that, we can find the
most effective solution for vulnerability.
• Metasploit pro and nexpose integrate with each other to provide validation tools and
vulnerability assessments that help us verify vulnerabilities, eliminate false positives,
and test remediation measures. There are various ways through which we can use
nexpose with Metasploit pro. Metasploit pro provides us a connector that is used to
add a Nexpose console. Using this addition, we can directly run a vulnerability scan
from the web interface and then we can automatically import the result of the scan
into a project. In the other method, we can run scans from nexpose and import the
result of the scan into Metasploit pro to perform vulnerability analysis and validation.
We will select the method according to our situation.

Features of Nexpose

• Nexpose works in mobile, virtual, physical and cloud environments to find assets and
scan for vulnerabilities within an organization's environment and then prioritize risk
according to the exploitability of those vulnerabilities.
• It also priorities vulnerability patching and schedule scan by enabling administrators
and configure security alerts. Nexpose has a special feature known as Live
monitoring, which collects the available data and then converts that data into action
plans. Vulnerabilities that are exploited first are found and prioritized by the advanced
exposure analytics feature of nexpose.
• Because of this, the security managers save from getting bogged down with too many
security alerts. The Liveboards feature is used to replace the result of a static
dashboard with visual reporting that is constantly updated. Rapid 7 introduces a new
feature for nexpose named as remediation workflow feature, which is used to track
and manage the security staff of the organization and analyze the progress of
addressing those vulnerabilities.
Product Version

Nexpose has various editions with different deployment options as follows:

Ultimate: It offers hardware appliances, managed services, virtual appliances, private cloud,
or software products. All features have a scan engine and an unlimited number of IP
addresses.

Enterprise: It offers hardware appliances, managed services, virtual appliances, private

cloud, or software products. Medium to large organizations uses it with the security team. It
supports scan engine, users and various number of IPs.

Consultant: It offers a virtual application or software product. It is used in the organization,

which gives IT security consulting. We can install it only on one laptop. It can scan upto
1,024 IPs and support one scan engine.

Express: It offers as a private cloud, virtual application or Software product. It can support
two scan engines and only one user. It is used only in small organizations. It can scan up to
1,024 IPs.

Nikto

• Nikto is an Open Source software written in Perl language that is used to scan a
web-server for the vulnerability that can be exploited and can compromise the
server. It can also check for outdated version details of 1200 server and can detect
problems with specific version details of over 200 servers.
• It can also fingerprint server using favicon.ico files present in the server. It is not
designed to be a particularly a stealth tool rather than it is designed to be fast and
time-efficient to achieve the task in very little time. Because of this, a web admin
can easily detect that its server is being scanned by looking into the log files.
It can also show some items that do not have security problem but are info only
which shows how to take full use of it to secure the web-server more properly.
Features:
• Full support for SSL
• Finds sub-domain
• Supports full HTTP Proxy
• Outdated component report
• Result saved in multiple format (xml, csv etc)
• Username guessing
• Gives details of installed software
• Takes Nmap file as input to scan port in a web-server.
• Able to perform dictionary attack.
• Updated easily
BURP SUITE

• Burp Suite software is the best toolbox for web security testing. In web security
testing, the incursion also protects engineer grace. Used to find and exploit search
flaws. Burp Suite is therefore designed to be used by point-and-click. Understanding
how systems are attacked is essential for everyone working in security, whether they
are developers or security professionals.
• Burp Suite is a platform and graphical tool that work together to do security testing on
online applications. It supports the whole testing process, from the initial mapping and
analysis of an application's attack surface through the discovery and exploitation of
security flaws.

What is Burp Suite?

• Burp Suite is a proxy program that enables us to track, examine, and alter requests
made by our browsers before they are forwarded to a distant server.
• Burp Suite is a prominent web application security solution. It gives us the ability to
manually test for vulnerabilities, intercepts HTTP messages, and change a message's
body and header.
• It was created by a business with the alias Portswigger, whose creator Dafydd
Stuttard also works there. BurpSuite is designed to be an all-in-one toolkit, and
BApps are add-ons that may be installed to expand its functionality.
• It is the most widely used tool among experts in online app security and bug bounty
hunters. It is a better option than free substitutes like OWASP ZAP because of how
simple it is to use. The community edition of Burp Suite is accessible for free,
whereas the professional edition and the enterprise edition need payment.

Why is Burp Suite Used in Cybersecurity

Burp Suite is a comprehensive framework that may be used to carry out several activities,
including:

• Web crawling.
• Web application testing, both manually and automatically.
• Analysis of web applications.
• Vulnerability detection

Burpsuite also has the advantage of being built into the Chrome browser.

Features and Tools Offered by Burp Suite

BurpSuite provides the following tools:

1. Spider

• A web crawler or spider is employed to map the target web application. The
mapping's goal is to compile a list of endpoints so that their capabilities may be
examined and possible vulnerabilities can be discovered. Spidering is carried out
for the straightforward reason that more attack surfaces are available during real
testing if you collect more endpoints during recon.

• It is a web spider/crawler that is used to map the target web application. The
objective of the mapping is to get a list of endpoints so that their functionality
can be observed and potential vulnerabilities can be found.
• Spidering is done for a simple reason that the more endpoints you gather during
your recon process, the more attack surfaces you possess during your actual
testing

2. Proxy:
 • BurpSuite contains an intercepting proxy that lets the user see and modify the
contents of requests and responses while they are in transit. It also lets the
user send the request/response under monitoring to another relevant tool in
BurpSuite, removing the burden of copy-paste.
• The proxy server can be adjusted to run on a specific loop-back ip and a port.
The proxy can also be configured to filter out specific types of request-
response pairs.

3. Intruder:

• It is a fuzzer. This is used to run a set of values through an input point. The values
are run and the output is observed for success/failure and content length. Usually, an
anomaly results in a change in response code or content length of the response.
BurpSuite allows brute-force, dictionary file and single values for its payload
position.
The intruder is used for:
• Brute-force attacks on password forms, pin forms, and other such forms.
• The dictionary attack on password forms, fields that are suspected of being
vulnerable to XSS or SQL injection.
• Testing and attacking rate limiting on the web-app.
4. Repeater:

Repeater lets a user send requests repeatedly with manual modifications.

It is used for:
• Verifying whether the user-supplied values are being verified.
• If user-supplied values are being verified, how well is it being done?
• What values is the server expecting in an input parameter/request header?
• How does the server handle unexpected values?
• Is input sanitation being applied by the server?
• How well the server sanitizes the user-supplied inputs?
• What is the sanitation style being used by the server?
• Among all the cookies present, which one is the actual session cookie?
• How is CSRF protection being implemented and if there is a way to bypass it?