Unit 5 – Hacking Techniques and Tools

5.1 – Social Engineering

Social networks are websites and apps that allow users and organizations to connect,
communicate, share information and form relationships. People can connect with others in
the same area, families, friends, and those with the same interests. Social networks are one of
the most important uses of the internet today.

Popular social networking sites -- such as Facebook, Yelp, Twitter, Instagram and TikTok --
enable individuals to maintain social connections, stay informed and access, as well as share
a wealth of information. These sites also enable marketers to reach their target audiences.

Social networking sites have come a long way since the first social networking site,
SixDegrees.com, was launched in 1997. Today, the world is rapidly adopting newer social
networking platforms. According to DataReportal, a Kepios analysis from January 2022
indicated that there are more than 4.74 billion social network users worldwide.

Social networking work

The term social networking entails having connections in both the real and the digital worlds.
Today, this term is mainly used to reference online social communications. The internet has
made it possible for people to find and connect with others who they may never have met
otherwise.

Online social networking is dependent on technology and internet connectivity. Users can
access social networking sites using their PCs, tablets or smartphones. Most social
networking sites run on a back end of searchable databases that use advanced programming
languages, such as Python, to organize, store and retrieve data in an easy-to-understand
format. For example, Tumblr uses such products and services in its daily operations as
Google Analytics, Google Workspace and WordPress.

Social networks
With the broad spectrum of websites, apps and services that exist online, there is no single
exact definition of a social network. Generally, though, social networks have a few common
attributes that set them apart.

 A social network will focus on user-generated content. Users primarily view and
interact with content made by other users. They are encouraged to post text, status
updates or pictures for viewing by others.
 Social networks allow the user or organization to create a profile. The profile contains
information about the person and a centralized page with the content posted by them.
Their profile may be associated with their real name.
 A social network has a way to form a lasting connection with other users. These
connections are commonly called friending or following the other user. They allow
the users to find other users and form webs of relationships. Often an algorithm will
recommend other users and organizations they may want to form a connection with.
Although often used interchangeably, social network is different than social media. A social
network focuses on the connections and relationships between individuals. Social media is
more focused on an individual sharing with a large audience. In this case, media is used in the
same sense as in mass media. Most social networks can also be used as social media sites.

Purpose of social networking

Social networking fulfills the following four main objectives:

 Sharing. Friends or family members who are geographically dispersed can connect
remotely and share information, updates, photos and videos. Social networking also
enables individuals to meet other people with similar interests or to expand their
current social networks.
 Learning. Social networks serve as great learning platforms. Consumers can instantly
receive breaking news, get updates regarding friends and family, or learn about what's
happening in their community.
 Interacting. Social networking enhances user interactions by breaking the barriers of
time and distance. With cloud-based video communication technologies such as
WhatsApp or Instagram Live, people can talk face to face with anyone in the world.
 Marketing. Companies may tap into social networking services to enhance brand
awareness with the platform's users, improve customer retention and conversion rates,
and promote brand and voice identity.

Different types of social networking

While there are various categories of social networking sites, the six most common types are
the following:

 Social connections. This is a type of social network where people stay in touch with
friends, family members, acquaintances or brands through online profiles and updates,
or find new friends through similar interests. Some examples are Facebook, Myspace
and Instagram.
 Professional connections. Geared toward professionals, these social networks are
designed for business relationships. These sites can be used to make new professional
contacts, enhance existing business connections and explore job opportunities, for
example. They may include a general forum where professionals can connect with co-
workers or offer an exclusive platform based on specific occupations or interest
levels. Some examples are LinkedIn, Microsoft Yammer and Microsoft Viva.
 Sharing of multimedia. Various social networks provide video- and photography-
sharing services, including YouTube and Flickr.
 News or informational. This type of social networking allow users to post news
stories, informational or how-to content and can be general purpose or dedicated to a
single topic. These social networks include communities of people who are looking
for answers to everyday problems and they have much in common with web forums.
Fostering a sense of helping others, members provide answers to questions, conduct
discussion forums or teach others how to perform various tasks and projects. Popular
examples include Reddit, Stack Overflow or Digg.
 Communication. Here, social networks focus on allowing the user to communicate
directly with each other in one-on-one or group chats. They have less focus on posts
 or updates and are like instant messaging apps. Some examples are WhatsApp,
WeChat and Snapchat.
 Educational. Educational social networks offer remote learning, enabling students and
teachers to collaborate on school projects, conduct research, and interact through
blogs and forums. Google Classroom, LinkedIn Learning and ePals are popular
examples.

Advantages and Disadvantages of social networking

Social networking can be a double-edged sword. On one end, it provides unsurpassed social
benefits, yet it can also make people more vulnerable to the spread of misinformation, as well
as privacy and security threats.

Social networking offers the following benefits to consumers and businesses:

 Brand awareness. Social networking enables companies to reach out to new and
existing clients. This helps to make brands more relatable and promotes brand
awareness.
 Instant reachability. By erasing the physical and spatial boundaries between people,
social networking websites can provide instant reachability.
 Builds a following. Organizations and businesses can use social networking to build a
following and expand their reach globally.
 Business success. Positive reviews and comments generated by customers on social
networking platforms can help improve business sales and profitability.
 Increased website traffic. Businesses can use social networking profiles to boost and
direct inbound traffic to their websites. They can achieve this, for example, by adding
inspiring visuals, using plugins and shareable social media buttons, or encouraging
inbound linking.

Social networking also has the following downsides:

 Rumors and misinformation. Incorrect information can slip through the cracks of
social networking platforms, causing havoc and uncertainty among consumers. Often,
people take anything posted on social networking sites at face value instead of
verifying the sources.
 Negative reviews and comments. A single negative review can adversely affect an
established business, especially if the comments are posted on a platform with a large
following. A tarnished business reputation can often cause irreparable damage.
 Data security and privacy concerns. Social networking sites can inadvertently put
consumer data at risk. For instance, if a social networking site experiences a data
breach, the users of that platform automatically fall under the radar as well. According
to Business Insider, a data breach in April 2021 leaked the personal data of more than
500 million Facebook users.
 Time-consuming process. Promoting a business on social media requires constant
upkeep and maintenance. Creating, updating, preparing and scheduling regular posts
can take a considerable amount of time. This can be especially cumbersome for small
businesses that may not have the extra staff and resources to dedicate to social media
marketing.
Social networks in business
There are many ways a business or organization can use social networks. Globally, the
average person spends over two hours a day using social networks. This represents a great
opportunity and market.

Most social networks are run as for-profit companies. They make most of their revenue from
selling ads or promoted content. Facebook's parent company Meta has an almost $300 billion
market cap.

Social networks can be used for customer research, engagement and marketing. They offer a
way to directly connect businesses and customers. Brands can build a community around
themselves. Social networks collect information about users' likes and dislikes, allowing for
extremely targeted advertising. Social media listening allows an organization to learn what
people are saying about their company.

Some businesses are implementing internal social networks. In very large organizations this
can increase employee engagement and satisfaction. Also, as teams become more
geographically diverse or have members working from home, private social networks can
promote collaboration and information sharing.

Some business are beginning to use social networks in their recruitment strategies.

5.2 – Injection
Injection attacks refer to any type of attack that targets injection vulnerabilities—a broad
category of cybersecurity weaknesses that includes several of the most serious application
security risks.

Despite the wide variety of attack vectors, the common denominator for injection attacks is
that attackers are able to insert payloads into executed application code via unvalidated user
input. Depending on the specific vulnerability and the attack target, injection may involve
database queries, JavaScript code, native application code, operating system commands, and
so on. When successful, injection attacks can have a wide variety of consequences, from
revealing less sensitive information to more serious data breaches, denial of service, privilege
elevation, authentication bypass, or even remote code execution and potentially full
compromise of a target system.

1 Injection attack: SQL injection (SQLi)

Most web applications are backed by databases of some sort, with many relying
on standard relational database management systems that use SQL as their data
access and query language. SQL injection attacks are performed by including an
SQL statement in data sent via a web form, comment field, query string,
parameter, or another input channel accessible to external users. The malicious
code can be an SQL query designed to extract sensitive data or an SQL
statement aimed at modifying database content by adding or deleting records or
even entire database tables. Malicious hackers often target user records to add a
privileged user or elevate privileges for an existing account.

An application that has an SQL injection vulnerability incorporates user-

controllable input in the SQL statements it builds. The resulting query is sent to
the database server without sufficient validation or encoding and executed,
including any malicious SQL statements injected by the attacker. When the
vulnerable application doesn’t return data directly, attackers may use blind SQL
injection to discover information indirectly.

SQL injection vulnerabilities correspond to CWE-89: Improper Neutralization

of Special Elements used in an SQL Command in the Common Weakness
Enumeration, with SQL injection listed at #3 on the CWE Top 25 for 2023.
Invicti’s DAST tools can automatically detect many types of SQL injection
vulnerabilities, from typical in-band SQL injection (including UNION
injections) to blind SQL injection (including Boolean-based) and out-of-band
SQL injection.

2 Injection attack: Cross-site scripting (XSS)

While it doesn’t have “injection” in the name, cross-site scripting (XSS) is all
about exploiting script injection vulnerabilities. If a web application fails to
sanitize user-supplied inputs that include script code (usually JavaScript), it may
be vulnerable to XSS. To exploit an XSS vulnerability, the attacker supplies a
string that contains malicious code, typically by including it as a request
parameter value. Instead of processing that value as expected by application
logic, a vulnerable application executes the provided script payload in the
victim’s browser.

Though sometimes dismissed as low-risk and limited to a single user session,

XSS attacks can have serious consequences, especially when used in a longer
attack chain. What’s more, with full-stack JavaScript applications now also
running on the server side with Node.js, the impact of XSS no longer has to be
limited to the browser. User input filtering alone is not enough to prevent XSS,
as there are many ways of evading XSS filters, so following secure coding
practices and restricting script sources using Content Security Policy are
recommended to prevent XSS.

XSS is listed as CWE-79: Improper Neutralization of Input During Web Page

Generation in the CWE classification and was ranked the second most
dangerous software weakness in the CWE Top 25 for 2023. Invicti DAST can
detect and automatically confirm many types of XSS vulnerabilities,
including reflected XSS, stored (persistent) XSS, and DOM-based XSS.
3 Injection attack: OS command injection

Web applications may sometimes need to execute operating system commands,

for instance to read or write files on the web server. For an application with
an OS command injection vulnerability, attackers can hide malicious system
commands in user inputs and have the application execute them on the server.
Successful command injection (also called shell injection) can be extremely
dangerous, allowing attackers to obtain information about system and server
configuration, escalate user permissions, or execute arbitrary system commands
to fully compromise the system.

Because the consequences can be so serious, it’s good practice to avoid calling
system commands that include user-controllable data in your web applications.
When executing a system command is necessary, be sure to carefully validate
all its inputs and restrict them to specific permitted values.

OS command injection was ranked at #5 in the CWE Top 25 list as CWE-78:

Improper Neutralization of Special Elements Used in an OS Command. Invicti
DAST scanners can detect several variants of command injection
vulnerabilities, including blind and out-of-band command injection.

4 Injection attack: Code injection (remote code execution)

Your application has a code injection vulnerability (aka remote code

execution or RCE) if an attacker can include application code in user input and
get your app to execute it. The difference compared to OS command injection is
that you are injecting application code, not system commands (though the two
can occur together if an application accepts malicious code that then calls a
system command). For example, code injection into a vulnerable application
written in PHP will involve PHP code, while a vulnerable Java app would be
injected with Java code.

While most code injection vulnerabilities are only exploitable as part of a longer
attack chain, RCE is considered the holy grail of application security testing
because if an attacker manages to get remote code execution, they can do more
or less anything they want, so the target system is considered fully
compromised. While the specific severity rating depends on the ease of
exploitation, RCE vulnerabilities are nearly always critical.

Code injection is officially classified as CWE-94: Improper Control of

Generation of Code. Invicti’s vulnerability scanner can detect and often
automatically confirm dozens of code execution and code evaluation
vulnerabilities across a variety of programming languages and frameworks.
5 Injection attack: XXE injection

To round out this top five, let’s look at something slightly different: XML
external entity (XXE) injection. XML documents are used in all sorts of web
application requests and if an app that accepts XML inputs is configured to
support legacy document type definitions (DTDs) with weak XML parser
security, attackers can use specially crafted XML documents to perform XXE
injection. This breaks the XML parser and can be used for further cyberattacks
ranging from directory traversal to server-side request forgery (SSRF) or even
remote code execution.

While the first four injection attacks discussed here rely on failures in user input
validation, XXE takes advantage of inherently unsafe legacy functionality in
XML parsers. Because this is more a case of insecure configuration than
insecure code, XXE can sometimes evade detection, making it particularly
dangerous. If your application processes XML documents, the only way to
avoid XXE vulnerabilities is to disable support for DTDs or (if you have to use
them) at the very least disallow the use of external entities.

Attack vectors related to XML external entities fall under CWE-611: Improper
Restriction of XML External Entity Reference. XXE injection used to have its
own spot at #4 in the OWASP Top Ten for 2017 but was merged into the
Security Misconfiguration category for the 2021 edition. Invicti’s web
vulnerability scanner detects many XXE injection vulnerabilities, including out-
of-band XXE injection.

Other common injection attacks

The top five above represents the most common injection vulnerabilities found
in applications and APIs today, but several less frequent injection attacks also
deserve a mention:

 NoSQL injection attacks follow the same principle as SQL injection but
target databases that don’t use SQL queries, such as MongoDB,
Cassandra, or Elasticsearch. Because there is no standard query language
for NoSQL databases, NoSQL injection payloads are different for each
type of database server.
 JSON injection attacks are closely related to XSS but instead of injecting
script code, attackers attempt to insert or modify JSON data sent or
received by the application. This injection technique is especially useful
when attacking REST APIs, where JSON is the dominant data format.
 Server-side template injection (SSTI) attacks target server-side template
engines used to dynamically generate web page code. If attackers are able
to inject expressions in the relevant template language, their malicious
 code will be included in the page HTML. Expression language
injection is a related risk, this time injecting expressions specific to a web
framework rather than a template engine.
 HTTP header injection (CRLF injection) is possible when an application
accepts newline characters in input that then goes directly into an HTTP
header. HTTP requests use a newline to separate the request header and
body, so injecting newline characters may allow an attacker to replace the
legitimate response body with HTML data that includes malicious code
such as an XSS payload.

Preventing injection vulnerabilities and attacks

Apart from XXE, all the injection attacks listed here rely on the web application
accepting and executing unsensitized user inputs. The underlying security issue
is improper input validation and its own place in the CWE Top 25 list, right up at #4.
By properly sanitizing, filtering, and encoding all user-controlled inputs to your app,
you can prevent the vast majority of trivial injection vulnerabilities. Setting the
right HTTP security headers and CSP rules will also block many avenues of external
attack right out of the gate.

Developers should know and use secure input processing features in modern web
frameworks and languages. Most SQL injection attacks can be prevented by using
parameterized queries or server-side prepared statements (aka stored procedures),
while application frameworks such as React provide built-in constructs that make it
all but impossible to write code vulnerable to XSS (unless you deliberately bypass all
the built-in safeguards).

Vulnerabilities can always crop up both in new and updated code, and new ones
discovered on code previously considered safe, so it’s vital to consistently test your
entire exploitable attack surface. The recommended practice is to regularly and
automatically scan all your web applications and APIs with a high-quality dynamic
application security testing solution that is integrated both into your development
lifecycle and your security operations.
 5.3 – Cross-site scripting XSS

Cross Site Scripting (XSS) is a vulnerability in a web application that allows a

third party to execute a script in the user’s browser on behalf of the web
application.

Cross-site Scripting is one of the most prevalent vulnerabilities present on the

web today. The exploitation of XSS against a user can lead to various
consequences such as account compromise, account deletion, privilege
escalation, malware infection and many more.

In its initial days, it was called CSS and it was not exactly what it is today.
Initially, it was discovered that a malicious website could utilize JavaScript to
read data from other website’s responses by embedding them in an iframe, run
scripts and modify page contents. It was called CSS (Cross Site Scripting) then.
The definition changed when Netscape introduced the Same Origin Policy and
cross-site scripting was restricted from enabling cross-origin response reading.
Soon it was recommended to call this vulnerability as XSS to avoid confusion
with Cascading Style Sheets(CSS). The possibility of getting XSSed arises
when a website does not properly handle the input provided to it from a user
before inserting it into the response. In such a case, a crafted input can be given
that when embedded in the response acts as a JS code block and is executed by
the browser. Depending on the context, there are two types of XSS –

Reflected XSS: If the input has to be provided each time to execute, such XSS
is called reflected. These attacks are mostly carried out by delivering a payload
directly to the victim. Victim requests a page with a request containing the
payload and the payload comes embedded in the response as a script. An
example of reflected XSS is XSS in the search field.

Stored XSS: When the response containing the payload is stored on the server
in such a way that the script gets executed on every visit without submission of
payload, then it is identified as stored XSS. An example of stored XSS is XSS
in the comment thread.

There is another type of XSS called DOM based XSS and its instances are either
reflected or stored. DOM-based XSS arises when user-supplied data is provided
to the DOM objects without proper sanitizing. An example of code vulnerable
to XSS is below, notice the variables firstname and lastname :
<?php

if(isset($_GET["firstname"]) && isset($_GET["lastname"]))

$firstname = $_GET["firstname"];

$lastname = $_GET["lastname"];

if($firstname == "" or $lastname == "")

echo "<font color=\"red\">Please enter both fields...</font>";

else

echo "Welcome " . $firstname. " " . $lastname;

?>
 There are two aspects of XSS (and any security issue) –

1. Developer: If you are a developer, the focus would be secure

development to avoid having any security holes in the product. You do
not need to dive very deep into the exploitation aspect, just have to use
tools and libraries while applying the best practices for secure code
development as prescribed by security researchers. Some resources for
developers are – a). OWASP Encoding Project : It is a library written in
Java that is developed by the Open Web Application Security
Project(OWASP). It is free, open source and easy to use. b). The “X-
XSS-Protection” Header : This header instructs the browser to activate
the inbuilt XSS auditor to identify and block any XSS attempts against
the user. c). The XSS Protection Cheat Sheet by OWASP : This resource
enlists rules to be followed during development with proper examples.
The rules cover a large variety of cases where a developer can miss
something that can lead to the website being vulnerable to XSS. d).
Content Security Policy : It is a stand-alone solution for XSS like
problems, it instructs the browser about “safe” sources apart from which
no script should be executed from any origin.

2. Security researchers: Security researchers, on the other hand, would like

similar resources to help them hunt down instances where the developer
became lousy and left an entry point. Researchers can make use of – a).
CheatSheets – 1. XSS filter evasion cheat sheet by OWASP. 2. XSS cheat
sheet by Rodolfo Assis. 3. XSS cheat sheet by Veracode. b). Practice
Labs – 1. bWAPP 2. DVWA(Damn vulnerable Web Application) 3.
prompt.ml 4. CTFs c). Reports – 1. Hackerone Hacktivity 2. Personal
blogs of eminent security researchers like Jason Haddix, Geekboy,
Prakhar Prasad, Dafydd Stuttard(Portswigger) etc.

5.4 – Broken Authentication and Session Management

Simply stated, broken authentication and session management allows a

cybercriminal to steal a user's login data or forge session data, such as cookies,
to gain access to websites.

Did you know a whopping 113 million websites contain a security

vulnerability? That’s approximately six percent of all websites globally.
A website vulnerability is a weakness in website code that cybercriminals can
exploit to gain unauthorized access to a site—and a mere one vulnerability has
the power to impact over 1,000 pages on a single website.

Let’s talk about one of the most common types of vulnerabilities on the
OWASP Top 10: broken authentication and session management. Simply
stated, broken authentication and session management allows a cybercriminal to
steal a user’s login data or forge session data, such as cookies, to gain access to
websites.

What is the OWASP Top 10?

The OWASP Top 10, short for Open Web Application Security Project, is a list
of the ten most dangerous web application security flaws today (including
broken authentication and session management). According to owasp.org, its
purpose is to drive visibility and evolution in the safety and security of the
world’s software. As of 2021, broken authentication is now referred to
as identification and authentication failures by OWASP.

Broken authentication and session management:

Many websites require users to log in to access their accounts, make a purchase,
etc. More often than not, this is done using a username and password. With this
information, a site will assign and send each logged-in visitor a unique session
ID that serves as a key to the user’s identity on the server.

If not properly secured, a cybercriminal can impersonate a valid user and access
that user’s account, resulting in a broken authentication and session
management attack.

Authentication process be exploited:

When a user logs onto a website, the site uses a proprietary algorithm to
generate a unique session ID. Their device then uses that session ID as a key to
their identity for the remainder of their user session.

All of this information has to be sent back and forth between the user and the
server. If that information is not encrypted and is sent as plain text instead, it
becomes an attack vector. Hackers can then intercept user credentials or session
IDs to impersonate that person. This is especially true when operating on a
public network (e.g. coffee shop wifi) or a public computer that anyone else can
access. The following are some broken authentication and session management
attack examples.
Credential stuffing

The stealing of usernames and passwords to gain unauthorized access to user

accounts across multiple websites and services is known as credential stuffing.
This technique relies on the fact that many people reuse the same login
credentials across different online platforms. Attackers typically obtain these
credentials from breaches of other websites and then use automated tools to test
them on various websites in hopes of finding matches. Credential stuffing
exploits the widespread issue of password reuse and can lead to unauthorized
access to user accounts, compromising sensitive information, and leading to
financial or reputational damage.

Brute force attacks

Another approach a cybercriminal could take is attempting a brute-force

attack wherein they repeatedly try common weak passwords to guess a user’s
correct password. It is also possible for attackers to forge session IDs if they are
not randomly generated. For example, if an attacker intercepts several legitimate
session IDs that are enumerated, it is possible to guess the next legitimate
session ID and access the site fraudulently. These are commonly referred to as
man-in-the-middle attacks.

Password spraying attacks

This type of cyberattack uses a single password against many user accounts
before moving on to another password to avoid triggering account lockouts.
This technique contrasts with brute force attacks, which try many passwords
against a single user account. Password spraying targets the common use of
weak passwords across multiple accounts and takes advantage of the fact that
many users opt for simplicity over security. By exploiting the likelihood that at
least some accounts will use common passwords, attackers can gain
unauthorized access without alerting the authentication mechanisms designed to
lock accounts after a few unsuccessful login attempts.

How to prevent broken authentication attacks

Explore below broken authentication best practices to protect user credentials

and authentication processes from exploitation by bad actors.

Use an SSL certificate

To prevent man-in-the-middle type attacks on your site’s sessions, it is

important to encrypt this data in transit using an SSL certificate. As the name
implies, an SSL (secure socket layer) is a digital certificate that encrypts
information sent between a web server and a web browser.

Enforce strong passwords

Regarding brute force attacks, mentioned earlier in this article, it’s a good
practice to have access control and password policies for any and all registered
users on a site (this includes admin accounts, especially!).

Strong passwords do not have complete words; instead, they consist of a

combination of random letters (both uppercase and lowercase), numbers, and
symbols to prevent users' passwords from being easily guessed. Minimum
password lengths should also be required, and users should be required to
update their passwords after multiple failed login attempts are detected.

Use a session manager

Implement a secure, server-side session management system that creates a new,

random session ID with high complexity each time someone logs in. Ensure the
session ID is not visible in the web page's URL, is kept safe, and is properly
discarded following a user's logout, periods of inactivity, or after session
timeouts.

Conduct regular website security audits

Make sure you are on top of any website vulnerabilities or issues by conducting
security audits on a regular basis. An automated website security plan is also
helpful in that it continuously monitors the site for issues.

Prevent data breaches with Site Lock

In short, broken authentication and session management is a major security risk.

It can allow a hacker to steal a user’s sensitive data or forge session data, such
as cookies, to gain unauthorized access to websites. However, there are simple
and easy solutions to prevent your site from being affected by this vulnerability.
Learn more about protecting your site with our website security solutions. If
your site has already been hacked, discover how SiteLock's website hack repair
service can help.

5.5 – Cross - Site Request Forgery

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to

execute unwanted actions on a web application in which they’re currently
authenticated. With a little help of social engineering (such as sending a link via
email or chat), an attacker may trick the users of a web application into
executing actions of the attacker’s choosing. If the victim is a normal user, a
successful CSRF attack can force the user to perform state changing requests
like transferring funds, changing their email address, and so forth. If the victim
is an administrative account, CSRF can compromise the entire web application.

CSRF is an attack that tricks the victim into submitting a malicious request. It
inherits the identity and privileges of the victim to perform an undesired
function on the victim’s behalf (though note that this is not true of login CSRF,
a special form of the attack described below). For most sites, browser requests
automatically include any credentials associated with the site, such as the user’s
session cookie, IP address, Windows domain credentials, and so forth.
Therefore, if the user is currently authenticated to the site, the site will have no
way to distinguish between the forged request sent by the victim and a
legitimate request sent by the victim.

CSRF attacks target functionality that causes a state change on the server, such
as changing the victim’s email address or password, or purchasing something.
Forcing the victim to retrieve data doesn’t benefit an attacker because the
attacker doesn’t receive the response, the victim does. As such, CSRF attacks
target state-changing requests.

An attacker can use CSRF to obtain the victim’s private data via a special form
of the attack, known as login CSRF. The attacker forces a non-authenticated
user to log in to an account the attacker controls. If the victim does not realize
this, they may add personal data—such as credit card information—to the
account. The attacker can then log back into the account to view this data, along
with the victim’s activity history on the web application.

It’s sometimes possible to store the CSRF attack on the vulnerable site itself.
Such vulnerabilities are called “stored CSRF flaws”. This can be accomplished
by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a
more complex cross-site scripting attack. If the attack can store a CSRF attack
in the site, the severity of the attack is amplified. In particular, the likelihood is
increased because the victim is more likely to view the page containing the
attack than some random page on the Internet. The likelihood is also increased
because the victim is sure to be authenticated to the site already.

Synonyms

CSRF attacks are also known by a number of other names, including XSRF,
“Sea Surf”, Session Riding, Cross-Site Reference Forgery, and Hostile Linking.
Microsoft refers to this type of attack as a One-Click attack in their threat
modeling process and many places in their online documentation.

Prevention measures that do NOT work

A number of flawed ideas for defending against CSRF attacks have been
developed over time. Here are a few that we recommend you avoid.

Using a secret cookie

Remember that all cookies, even the secret ones, will be submitted with every
request. All authentication tokens will be submitted regardless of whether or not
the end-user was tricked into submitting the request. Furthermore, session
identifiers are simply used by the application container to associate the request
with a specific session object. The session identifier does not verify that the
end-user intended to submit the request.

Only accepting POST requests

Applications can be developed to only accept POST requests for the execution
of business logic. The misconception is that since the attacker cannot construct
a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is
incorrect. There are numerous methods in which an attacker can trick a victim
into submitting a forged POST request, such as a simple form hosted in an
attacker’s Website with hidden values. This form can be triggered automatically
by JavaScript or can be triggered by the victim who thinks the form will do
something else.

Multi-Step Transactions

Multi-Step transactions are not an adequate prevention of CSRF. As long as an

attacker can predict or deduce each step of the completed transaction, then
CSRF is possible.

URL Rewriting

This might be seen as a useful CSRF prevention technique as the attacker

cannot guess the victim’s session ID. However, the user’s session ID is exposed
in the URL. We don’t recommend fixing one security flaw by introducing
another.

HTTPS

HTTPS by itself does nothing to defend against CSRF.

However, HTTPS should be considered a prerequisite for any preventative

measures to be trustworthy.

Validating the Referrer Header

This doesn’t work in practice because the referrer header can be easily spoofed
by an attacker. Additionally, some users or browsers might not send the referrer
header due to privacy settings or policies, leading to false positives. Moreover,
there are situations where the referrer can be null, such as when a user navigates
to a site from a bookmark or any other resource without a traditional url. In
these scenarios, legitimate requests could be mistaken as potential CSRF
attacks, which would result in more potential false positive flags.

Examples

How does the attack work?

There are numerous ways in which an end user can be tricked into loading
information from or submitting information to a web application. In order to
execute an attack, we must first understand how to generate a valid malicious
request for our victim to execute. Let us consider the following example: Alice
wishes to transfer $100 to Bob using the bank.com web application that is
vulnerable to CSRF. Maria, an attacker, wants to trick Alice into sending the
money to Maria instead. The attack will comprise the following steps:

1. Building an exploit URL or script

2. Tricking Alice into executing the action with Social Engineering

GET scenario

If the application was designed to primarily use GET requests to transfer

parameters and execute actions, the money transfer operation might be reduced
to a request like:

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

Maria now decides to exploit this web application vulnerability using Alice as
the victim. Maria first constructs the following exploit URL which will transfer
$100,000 from Alice’s account to Maria’s account. Maria takes the original
command URL and replaces the beneficiary name with herself, raising the
transfer amount significantly at the same time:

http://bank.com/transfer.do?acct=MARIA&amount=100000

The social engineering aspect of the attack tricks Alice into loading this URL
when Alice is logged into the bank application. This is usually done with one of
the following techniques:

 sending an unsolicited email with HTML content

  planting an exploit URL or script on pages that are likely to be visited by
the victim while they are also doing online banking

The exploit URL can be disguised as an ordinary link, encouraging the victim to
click it:

<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View
my Pictures!</a>

Or as a 0x0 fake image:

<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000"
width="0" height="0" border="0">

If this image tag were included in the email, Alice wouldn’t see anything.
However, the browser will still submit the request to bank.com without any
visual indication that the transfer has taken place.

A real life example of CSRF attack on an application using GET was a uTorrent
exploit from 2008 that was used on a mass scale to download malware.

POST scenario

The only difference between GET and POST attacks is how the attack is being
executed by the victim. Let’s assume the bank now uses POST and the
vulnerable request looks like this:

POST http://bank.com/transfer.do HTTP/1.1

acct=BOB&amount=100

Such a request cannot be delivered using standard A or IMG tags, but can be
delivered using a FORM tags:

<form action="http://bank.com/transfer.do" method="POST">

<input type="hidden" name="acct" value="MARIA"/>

<input type="hidden" name="amount" value="100000"/>

<input type="submit" value="View my pictures"/>

</form>

This form will require the user to click on the submit button, but this can be also
executed automatically using JavaScript:

<body onload="document.forms[0].submit()">

<form...

Other HTTP methods

Modern web application APIs frequently use other HTTP methods, such as PUT
or DELETE. Let’s assume the vulnerable bank uses PUT that takes a JSON
block as an argument:

PUT http://bank.com/transfer.do HTTP/1.1

{ "acct":"BOB", "amount":100 }

Such requests can be executed with JavaScript embedded into an exploit page:

<script>

function put() {

var x = new XMLHttpRequest();

x.open("PUT","http://bank.com/transfer.do",true);

x.setRequestHeader("Content-Type", "application/json");

x.send(JSON.stringify({"acct":"BOB", "amount":100}));

</script>

<body onload="put()">
Fortunately, this request will not be executed by modern web browsers thanks
to same-origin policy restrictions. This restriction is enabled by default unless
the target web site explicitly opens up cross-origin requests from the attacker’s
(or everyone’s) origin by using CORS with the following header:

Access-Control-Allow-Origin: *

Related Attacks

 Cross-site Scripting (XSS)

 Cross Site History Manipulation (XSHM)

5.6 – Security Misconfiguration

Misconfigurations are a major avenue for web application attacks. No matter

how secure your code is, a misconfigured runtime environment can still render
your app vulnerable. This Cybersecurity Awareness Month, here are the top five
categories of application security misconfigurations.

As part of Cybersecurity Awareness Month, CISA has published a list of the top
10 network security misconfigurations found during red and blue team
assessments and in actual incident responses. To make sure application security
doesn’t get left out, we’ve decided to follow up with our own list of common
application security misconfigurations – but since top 10 lists have received
some bad press for being little more than clickbait, we’ll stick to just five of the
most important categories.

In broad terms, an application security misconfiguration is any security flaw

directly caused by the way an application or its environment is set up, not by
any vulnerability in the application itself. For example, if an application is not
vulnerable in a development environment but becomes vulnerable once
deployed to production, you most likely have a security misconfiguration on
your hands. With that definition in place and keeping in mind there is plenty of
overlap between the categories, let’s dive into the top 5 application security
misconfigurations.

Misconfiguration #1: Vulnerable tech stack components

Any web application is merely the outermost layer of a technology stack that
goes right down to the operating system. Depending on its vintage and
architecture, a web tech stack may include a web server, application server,
database server, web framework, dynamic dependencies, and more. Unless all
the runtime components are properly maintained, a missing patch or security
update may provide attackers with an opening to exploit a known vulnerable
product version and potentially compromise your system without touching the
application itself (for instance, via remote code execution by the application
server).

Misconfiguration #2: Missing or insufficient access controls

Many data breaches happen not because an attacker broke in but because they
found something out in the open – exposed cloud storage buckets, sensitive
files, and forgotten APIs are all fair game. While ensuring proper access control
at multiple levels is a major requirement for secure application development, it
must also be a part of deployment and operations, especially as application
components become more and more distributed. For example, a misconfigured
web server may allow attackers to download the application source code,
revealing intellectual property and making it easier to find vulnerabilities by
directly analyzing the code.

Misconfiguration #3: Default or development configurations

Development environments have very different requirements compared to

production. Getting as much error information as possible is crucial, and
security measures will often be disabled for debugging (or they simply won’t
exist yet). With this in mind, many components default to less secure but more
verbose settings intended to ease development, and locking them down should
be a routine part of the deployment process. Unless properly hardened to
minimize the attack surface and data exposure, components may leak excessive
information to attackers or expose resources or user accounts that shouldn’t be
accessible at all.

Misconfiguration #4: Missing or incorrect HTTP security headers

We’ve written a lot about HTTP security headers in the past, and with good
reason, as they are one of the easiest ways to stop entire classes of web attacks
without touching a single line of application code. Among several common
headers, the two definite must-haves are Content Security Policy (CSP) headers
to minimize exposure to cross-site scripting and the HTTP Strict Transport
Security (HSTS) header to enforce encrypted communications and thus prevent
man-in-the-middle attacks. While setting them is a fundamental best practice,
misconfiguring your security headers can be a risk in itself – from a false sense
of security when your CSP rules don’t do what you expected, to making your
entire domain inaccessible due to a bad HSTS header.

Read our technical white paper about HTTP security headers

Misconfiguration #5: Excessive process privileges

Privilege escalation is usually the first goal of any attacker who manages to gain
an initial foothold on your server. In order to minimize the options available to
malicious actors, application hardening should include making sure that all the
processes in your stack are running with the minimum necessary privileges and
(if possible and appropriate) are separated to reduce the risk of lateral
movement. For example, for development on a local machine, it might be quick
and easy to run all your servers as root with full file system access – but if done
in a production environment, it would allow total system compromise from a
single successful command injection.

5.7 – Cryptographic Storage

This article provides a simple model to follow when implementing solutions to

protect data at rest.

Passwords should not be stored using reversible encryption - secure password

hashing algorithms should be used instead. The Password Storage Cheat
Sheet contains further guidance on storing passwords.

Architectural Design

The first step in designing any application is to consider the overall architecture
of the system, as this will have a huge impact on the technical implementation.

This process should begin with considering the threat model of the application
(i.e, who you are trying to protect that data against).

The use of dedicated secret or key management systems can provide an

additional layer of security protection, as well as making the management of
secrets significantly easier - however it comes at the cost of additional
complexity and administrative overhead - so may not be feasible for all
applications. Note that many cloud environments provide these services, so
these should be taken advantage of where possible. The Secrets Management
Cheat Sheet contains further guidance on this topic.

Where to Perform Encryption

Encryption can be performed on a number of levels in the application stack,

such as:

 At the application level.

 At the database level (e.g, SQL Server TDE)
  At the filesystem level (e.g, BitLocker or LUKS)
 At the hardware level (e.g, encrypted RAID cards or SSDs)

Which layer(s) are most appropriate will depend on the threat model. For
example, hardware level encryption is effective at protecting against the
physical theft of the server, but will provide no protection if an attacker is able
to compromise the server remotely.

Minimise the Storage of Sensitive Information

The best way to protect sensitive information is to not store it in the first place.
Although this applies to all kinds of information, it is most often applicable to
credit card details, as they are highly desirable for attackers, and PCI DSS has
such stringent requirements for how they must be stored. Wherever possible, the
storage of sensitive information should be avoided.

Algorithms

For symmetric encryption AES with a key that's at least 128 bits (ideally 256
bits) and a secure mode should be used as the preferred algorithm.

For asymmetric encryption, use elliptical curve cryptography (ECC) with a

secure curve such as Curve25519 as a preferred algorithm. If ECC is not
available and RSA must be used, then ensure that the key is at least 2048 bits.

Many other symmetric and asymmetric algorithms are available which have
their own pros and cons, and they may be better or worse than AES or
Curve25519 in specific use cases. When considering these, a number of factors
should be taken into account, including:

 Key size.
 Known attacks and weaknesses of the algorithm.
 Maturity of the algorithm.
 Approval by third parties such as NIST's algorithmic validation program.
 Performance (both for encryption and decryption).
 Quality of the libraries available.
 Portability of the algorithm (i.e, how widely supported is it).

In some cases there may be regulatory requirements that limit the algorithms
that can be used, such as FIPS 140-2 or PCI DSS.

Custom Algorithms

Don't do this.
Cipher Modes

There are various modes that can be used to allow block ciphers (such as AES)
to encrypt arbitrary amounts of data, in the same way that a stream cipher
would. These modes have different security and performance characteristics,
and a full discussion of them is outside the scope of this cheat sheet. Some of
the modes have requirements to generate secure initialisation vectors (IVs) and
other attributes, but these should be handled automatically by the library.

Where available, authenticated modes should always be used. These provide

guarantees of the integrity and authenticity of the data, as well as
confidentiality. The most commonly used authenticated modes
are GCM and CCM, which should be used as a first preference.

If GCM or CCM are not available, then CTR mode or CBC mode should be
used. As these do not provide any guarantees about the authenticity of the data,
separate authentication should be implemented, such as using the Encrypt-then-
MAC technique. Care needs to be taken when using this method with variable
length messages

ECB should not be used outside of very specific circumstances.

Random Padding

For RSA, it is essential to enable Random Padding. Random Padding is also

known as OAEP or Optimal Asymmetric Encryption Padding. This class of
defense protects against Known Plain Text Attacks by adding randomness at the
beginning of the payload.

The Padding Schema of PKCS#1 is typically used in this case.

Secure Random Number Generation

Random numbers (or strings) are needed for various security critical
functionality, such as generating encryption keys, IVs, session IDs, CSRF
tokens or password reset tokens. As such, it is important that these are generated
securely, and that it is not possible for an attacker to guess and predict them.

It is generally not possible for computers to generate truly random numbers

(without special hardware), so most systems and languages provide two
different types of randomness.

Pseudo-Random Number Generators (PRNG) provide low-quality randomness

that are much faster, and can be used for non-security related functionality (such
as ordering results on a page, or randomising UI elements). However, they must
not be used for anything security critical, as it is often possible for attackers to
guess or predict the output.

Cryptographically Secure Pseudo-Random Number Generators (CSPRNG) are

designed to produce a much higher quality of randomness (more strictly, a
greater amount of entropy), making them safe to use for security-sensitive
functionality. However, they are slower and more CPU intensive, can end up
blocking in some circumstances when large amounts of random data are
requested. As such, if large amounts of non-security related randomness are
needed, they may not be appropriate.

The table below shows the recommended algorithms for each language, as well
as insecure functions that should not be used.

L Unsafe Functions Cryptographically Secu

a Functions
n
g
u
a
g
e

C random(), rand() getrandom(2)

Ja Math.random(), StrictMath.random(), java.util.Rando java.security.SecureRa

v m, java.util.SplittableRandom, java.util.concurrent.Thr m, java.util.UUID.rand
a eadLocalRandom UUID()

P array_rand(), lcg_value(), mt_rand(), rand(), uniqid() random_bytes(), Rando

H Engine\Secure in PHP
P 8, random_int() in PHP
7, openssl_random_pse
_bytes() in PHP 5

. Random() RandomNumberGener
N
E
T
L Unsafe Functions Cryptographically Secu
a Functions
n
g
u
a
g
e

/
C
#

O arc4random()/arc4random_uniform() (Uses RC4 SecRandomCopyBytes

bj Cipher), subclasses ofGKRandomSource, rand(),
e random()
ct
iv
e-
C

P random() secrets()
yt
h
o
n

R rand(), Random SecureRandom

u
b
y

G rand using math/rand package crypto.rand package

o

R rand::prng::XorShiftRng rand::prng::chacha::Ch
u aRng and the rest of th
st Rust library CSPRNGs
 L Unsafe Functions Cryptographically Secu
a Functions
n
g
u
a
g
e

N Math.random() crypto.randomBytes(),
o to.randomInt(), crypto.
d omUUID()
e.
js

UUIDs and GUIDs

Universally unique identifiers (UUIDs or GUIDs) are sometimes used as a

quick way to generate random strings. Although they can provide a reasonable
source of randomness, this will depend on the type or version of the UUID that
is created.

Specifically, version 1 UUIDs are comprised of a high precision timestamp and

the MAC address of the system that generated them, so are not
random (although they may be hard to guess, given the timestamp is to the
nearest 100ns). Type 4 UUIDs are randomly generated, although whether this is
done using a CSPRNG will depend on the implementation. Unless this is known
to be secure in the specific language or framework, the randomness of UUIDs
should not be relied upon.

Defence in Depth

Applications should be designed to still be secure even if cryptographic controls

fail. Any information that is stored in an encrypted form should also be
protected by additional layers of security. Application should also not rely on
the security of encrypted URL parameters, and should enforce strong access
control to prevent unauthorised access to information.

Key Management

Processes
Formal processes should be implemented (and tested) to cover all aspects of key
management, including:

 Generating and storing new keys.

 Distributing keys to the required parties.
 Deploying keys to application servers.
 Rotating and decommissioning old keys

Key Generation

Keys should be randomly generated using a cryptographically secure function,

such as those discussed in the Secure Random Number Generation section.
Keys should not be based on common words or phrases, or on "random"
characters generated by mashing the keyboard.

Where multiple keys are used (such as data separate data-encrypting and key-
encrypting keys), they should be fully independent from each other.

Key Lifetimes and Rotation

Encryption keys should be changed (or rotated) based on a number of different

criteria:

 If the previous key is known (or suspected) to have been compromised.

 This could also be caused by a someone who had access to the key
leaving the organisation.
 After a specified period of time has elapsed (known as the cryptoperiod).
 There are many factors that could affect what an appropriate
cryptoperiod is, including the size of the key, the sensitivity of the
data, and the threat model of the system. See section 5.3 of NIST
SP 800-57 for further guidance.
 After the key has been used to encrypt a specific amount of data.
 This would typically be 2^35 bytes (~34GB) for 64-bit keys
and 2^68 bytes (~295 exabytes) for 128-bit block size.
 If there is a significant change to the security provided by the algorithm
(such as a new attack being announced).

Once one of these criteria have been met, a new key should be generated and
used for encrypting any new data. There are two main approaches for how
existing data that was encrypted with the old key(s) should be handled:

1. Decrypting it and re-encrypting it with the new key.

2. Marking each item with the ID of the key that was used to encrypt it, and
storing multiple keys to allow the old data to be decrypted.
The first option should generally be preferred, as it greatly simplifies both the
application code and key management processes; however, it may not always be
feasible. Note that old keys should generally be stored for a certain period after
they have been retired, in case old backups of copies of the data need to be
decrypted.

It is important that the code and processes required to rotate a key are in
place before they are required, so that keys can be quickly rotated in the event
of a compromise. Additionally, processes should also be implemented to allow
the encryption algorithm or library to be changed, in case a new vulnerability is
found in the algorithm or implementation.

Key Storage

Securely storing cryptographic keys is one of the hardest problems to solve, as

the application always needs to have some level of access to the keys in order to
decrypt the data. While it may not be possible to fully protect the keys from an
attacker who has fully compromised the application, a number of steps can be
taken to make it harder for them to obtain the keys.

Where available, the secure storage mechanisms provided by the operating

system, framework or cloud service provider should be used. These include:

 A physical Hardware Security Module (HSM).

 A virtual HSM.
 Key vaults such as Amazon KMS or Azure Key Vault.
 An external secrets management service such as Conjur or HashiCorp
Vault.
 Secure storage APIs provided by the ProtectedData class in the .NET
framework.

There are many advantages to using these types of secure storage over simply
putting keys in configuration files. The specifics of these will vary depending
on the solution used, but they include:

 Central management of keys, especially in containerised environments.

 Easy key rotation and replacement.
 Secure key generation.
 Simplifying compliance with regulatory standards such as FIPS 140 or
PCI DSS.
 Making it harder for an attacker to export or steal keys.

In some cases none of these will be available, such as in a shared hosting

environment, meaning that it is not possible to obtain a high degree of
protection for any encryption keys. However, the following basic rules can still
be followed:

 Do not hard-code keys into the application source code.

 Do not check keys into version control systems.
 Protect the configuration files containing the keys with restrictive
permissions.
 Avoid storing keys in environment variables, as these can be accidentally
exposed through functions such as phpinfo() or through
the /proc/self/environ file.

The Secrets Management Cheat Sheet provides more details on securely storing
secrets.

Separation of Keys and Data

Where possible, encryption keys should be stored in a separate location from

encrypted data. For example, if the data is stored in a database, the keys should
be stored in the filesystem. This means that if an attacker only has access to one
of these (for example through directory traversal or SQL injection), they cannot
access both the keys and the data.

Depending on the architecture of the environment, it may be possible to store

the keys and data on separate systems, which would provide a greater degree of
isolation.

Encrypting Stored Keys

Where possible, encryption keys should themselves be stored in an encrypted

form. At least two separate keys are required for this:

 The Data Encryption Key (DEK) is used to encrypt the data.

 The Key Encryption Key (KEK) is used to encrypt the DEK.

For this to be effective, the KEK must be stored separately from the DEK. The
encrypted DEK can be stored with the data, but will only be usable if an
attacker is able to also obtain the KEK, which is stored on another system.

The KEK should also be at least as strong as the DEK. The envelope
encryption guidance from Google contains further details on how to manage
DEKs and KEKs.

In simpler application architectures (such as shared hosting environments)

where the KEK and DEK cannot be stored separately, there is limited value to
this approach, as an attacker is likely to be able to obtain both of the keys at the
same time. However, it can provide an additional barrier to unskilled attackers.

A key derivation function (KDF) could be used to generate a KEK from user-
supplied input (such a passphrase), which would then be used to encrypt a
randomly generated DEK. This allows the KEK to be easily changed (when the
user changes their passphrase), without needing to re-encrypt the data (as the
DEK remains the same).

5.8 – Failure to Restrict URL Access

Hacking is a term used to describe the process of gaining remote access to other
computers, most commonly through the internet. Ethical hacking refers to the
process of hacking with simply the intention of uncovering vulnerabilities that
may exist and then reporting them in order to help protect against future
incidents. This can be done by researching a vulnerability or by performing
penetration testing.

Main Content:

 It is important for organizations, such as businesses and governmental

entities, to understand that not all hackers are unethical – there are those
who use their skills for good purposes.
 Ethical hackers take on roles such as network administrator or
information assurance specialist, and they are vital in helping an
organization stay secure against attacks from Cyber criminals or
malicious insiders.
 Computer systems are becoming more and more complicated, so it is
becoming increasingly essential to have ethical hacking professionals on
your team to help prevent major network breaches and other such
dangers.
 An example of a strong security measure is the principle of least
privilege, which requires users to have access only to the information
they need. This gives a greater level of protection against security
breaches. An attacker requires more ‘privilege’ before they can gain
access to restricted areas of a system, making it harder for them to
infiltrate the system and make changes that could create further problems.
 In regard to ethical hacking, this means that those who should be able to
see data or use an application should only ever be able to access
information authorized for them.

The phrase ‘failure to restrict URL access’ appears in the ethical hacking
glossary. The definition of failure to restrict URL access in Ethical hacking is
“A type of mistake in which a user can access data in a system that they do not
have permission to view, possibly resulting in data loss, fraud, or other
violations of security policies”.

The Scenario:

Jack has been hired by a company as an ethical hacker. The company has
provided him with a login and password, so he can test the strength of their
systems and see if there are any security flaws that need fixing. He is allowed to
access everything except for billing records, which he cannot access due to
company policy. Jack creates a program that creates fields within the billing
records and then submits them. He is, therefore, able to view all the company’s
customer credit card numbers, much to his delight. This is not something he
should have been able to do, but when the client told him not to go into the
billing section, they also did not tell him specifically that he could not modify
any data once he got there.

Drawbacks:

 The company can lose a lot of money if its customer’s credit card
numbers are stolen.
 Any negative publicity surrounding the incident may affect the company
to such an extent that they may suffer financially as a result.
 Any penalties imposed will be costly and could cause the loss of
customers and staff, both of whom could be vital to the success of any
organization.
 Professional hackers will use techniques like this without informing their
employer in order to gain privileged status.
 They will use this in order to access areas of a network for which they
should not have permission, possibly gaining full access to all parts of a
system.
 The company may be at risk of breaching the laws that are put in place to
protect people’s information, resulting in them being processed.
 This is why it is so important to make sure that these steps are taken
correctly. If they are not, you could suffer many severe consequences and
end up doing more damage than good.

Conclusion:

While in some situations people may use this in order to look at private
information, it is significant to note that there are a lot of ways that this can be
used by hackers that are not malicious. Most don’t intentionally look for ways
to gain access without permission, but it is still a risky thing to do. In order to
carry out ethical hacking tasks effectively, you will typically need to perform
one or more of the following activities: penetration testing, vulnerability
scanning, and web application testing.

5.9 - Tools: Comodo, OpenVAS, Nexpose, Nikto, Burp Suite

Comodo Antivirus with Premium Internet Security Software can prevent most
of the cyber attacks and malware which steal private data stored on your
computer, give hackers unauthorized access to your computer, and in turn,
your financial and personal information.

Malware arising from the internet can hold your system hostage and demand
money, secretly gather sensitive information about your computing habits,
internet activity, and keystrokes, etc.

You can protect yourself from all of these threats with the latest version
of Comodo Internet Security Software.

Comodo Internet Security (CIS) is developed and distributed by Comodo

Group, a freemium Internet security suite that includes an antivirus program,
personal firewall, sandbox, host-based intrusion prevention system (HIPS) and
website filtering.

Comodo is a strong antivirus solution that offers many features like anti-
malware protection, full scans, quick scans, a firewall, gaming mode, and more.
Since it's been around for 25 years, you can expect Comodo to be sophisticated
enough to have seen changing cybersecurity needs.

OpenVAS:

OpenVAS is an open-source vulnerability scanning and management tool that

helps to identify security issues like misconfigurations, outdated software, and
weak passwords that could be exploited by attackers. OpenVAS is widely used
by security professionals to assess and improve the security posture of their
networks and is known for its effectiveness and flexibility. This article explores
how OpenVAS works, its features, and how it can be used to enhance
cybersecurity. forms the Greenbone Community Edition together with other
open-source modules.

Open Vulnerability Assessment System (OpenVAS) is free software that is used

to detect and manage vulnerabilities in computer systems and networks. It
provides various services and tools for vulnerability assessment such as
identifying and analyzing security issues such as misconfigurations, outdated
software, and weak passwords that could be exploited by attackers.

Working of OpenVAS

OpenVAS consists of a server and various client-side tools for scanning and
reporting. It uses a regularly updated database of known vulnerabilities and
checks systems against these to detect potential weaknesses. The tool
performs a comprehensive scan of the specified targets, identifying potential
vulnerabilities such as outdated software, misconfigurations, and weak
passwords and generates comprehensive reports detailing the identified
vulnerabilities and provide recommendations for remediation.

A vulnerability assessment tool works in the following way as follows.

1. Classifies the system resources.

2. Allocates the enumerable values to the classified resources.

3. Detects the possible threats (vulnerabilities) in each resource.

4. Eliminates the vulnerabilities on a priority basis.

Components of OpenVAS architecture

 OpenVAS Scanner:

o The primary engine that performs the actual scanning of target

systems. It uses Network Vulnerability Tests (NVTs) to detect
security vulnerabilities.

 OpenVAS Manager:

o Manages scan configurations, schedules, and stores scan results. It

acts as an intermediary between the scanner and the user
interfaces, handling scan requests and processing results.
  Greenbone Security Assistant (GSA):

o A web-based graphical user interface (GUI) that allows users to

manage scans, configure settings, and view scan results. It
provides an easy-to-use platform for interacting with OpenVAS.

 OpenVAS CLI:

o A command-line interface for users who prefer scripting and

command-line operations. It enables management of scans,
targets, and results through commands and scripts.

3. Detects the possible threats (vulnerabilities) in each resource.

4. Eliminates the vulnerabilities on a priority basis.

Components of OpenVAS architecture

 OpenVAS Scanner:

o The primary engine that performs the actual scanning of target

systems. It uses Network Vulnerability Tests (NVTs) to detect
security vulnerabilities.

 OpenVAS Manager:

o Manages scan configurations, schedules, and stores scan results. It

acts as an intermediary between the scanner and the user
interfaces, handling scan requests and processing results.

 Greenbone Security Assistant (GSA):

o A web-based graphical user interface (GUI) that allows users to

manage scans, configure settings, and view scan results. It
provides an easy-to-use platform for interacting with OpenVAS.

 OpenVAS CLI:

o A command-line interface for users who prefer scripting and

command-line operations. It enables management of scans,
targets, and results through commands and scripts.

 Greenbone Security Feed (GSF):

 o A continuously updated feed that provides the latest Network
Vulnerability Tests (NVTs) and security information. It ensures
OpenVAS can detect the most recent vulnerabilities.

 OpenVAS Libraries:

o These libraries provide essential functionalities required by the

scanner and manager, such as network communication, data
storage, and cryptographic operations.

 Database:

o The database stores scan results, configurations, and other

essential data. It ensures data persistence and retrieval for
analysis and reporting purposes.

Nexpose

In the realm of cybersecurity, ensuring the integrity and security of systems is

paramount. With the continuous evolution of threats, it's imperative for
professionals to utilize robust tools for vulnerability analysis. Among the
myriad options available, Nexpose stands out as a powerful vulnerability
assessment solution. When integrated with the renowned Kali Linux
distribution, it becomes a formidable combination for identifying and
mitigating security risks. This article delves into the intricacies of Nexpose
vulnerability analysis tools on Kali Linux, covering its features, installation,
configuration, and practical usage.

Understanding Nexpose Vulnerability Analysis Tools

Nexpose, developed by Rapid7, is a widely acclaimed vulnerability

management solution designed to help organizations identify, assess, and
remediate security weaknesses across their IT infrastructure. It employs
advanced scanning techniques to uncover vulnerabilities, misconfigurations,
and potential threats within networks, applications, and endpoints. With its
comprehensive database of vulnerabilities and intuitive interface, Nexpose
empowers security professionals to prioritize and address critical issues
efficiently.

Key Features of Nexpose

  Extensive Vulnerability Coverage: Nexpose boasts a vast database of
vulnerabilities, encompassing operating systems, applications, network
devices, and more. It leverages industry-standard feeds and threat
intelligence to stay current with emerging threats.

 Prioritization and Risk Scoring: Nexpose helps you prioritize remediation

efforts by assigning risk scores to identified vulnerabilities. These scores
consider exploitability, potential impact, and asset criticality, guiding you
toward the most pressing issues.

 Compliance Reporting: Nexpose generates reports aligned with various

compliance frameworks, such as PCI DSS, HIPAA, and GDPR, simplifying
regulatory adherence.

 Automation and Scheduling: Nexpose can be automated to run regular

scans, ensuring continuous vulnerability assessment and reducing
manual intervention.

 Integrations: Nexpose integrates with numerous security tools and

frameworks, including Metasploit and Tenable.io, streamlining your
workflows.

 Intuitive Interface: Nexpose presents a user-friendly interface, making it

accessible to users with varying levels of technical expertise.

Nexpose Vulnerability Analysis Tools

Below, we will explain the step-by-step Installation Installation Process &

Implementation of nexpose vulnerability analysis tools.

Step 1: Setting Permissions Using chmod

To make a file work, you need to do a few things in Linux. Use a command
called chmod to change the file's permissions to make it executable. Just type
in "chmod +x" and then the file name, which in this case is Rapid7Setup-
Linux64.bin.

chmod +x Rapid7Setup-Linux64.bin
Step 2: Installation Steps

Follow these steps:

 Click on "Next" as shown in the picture above.

 It will then ask you to agree to the terms. Click "Accept" and then click
"Next."

 This will allow you to continue with the installation process.

Step 3: Configuring Database Port (Default (5432))

 The setup will prompt you to specify the port for the database that
Nexpose will utilize.
  The default port is set to 5432. If you do not need to modify it, proceed
by clicking on "Next."

Step 4: User Information Setup

 Fill in the required information, including First Name, Last Name,

Company, User Name, and Password.

 Once all necessary information is provided, click on "Next" to proceed

with the installation.
Step 5: Unchecking Installation Box to Avoid Issues

 A checkbox may be presented, usually labeled as "Start Nexpose

immediately after installation."

 Important: Do not check this box, as it may lead to potential issues

during installation.

 Leave the box unchecked and proceed with the installation

Step 6: Complete Installation

 Once the installation process is complete, a confirmation message will

be displayed.

 Click on "Finish" to finalize the installation process.

Advantages of Nexpose Vulnerability Analysis Tools

Below, we are discussing the uses of nexpose vulnerability analysis tools, those
are following.

 Vulnerability Identification

 Risk Prioritization

 Reporting and Remediation

Vulnerability Identification

Nexpose uses automated scans to find and list vulnerabilities in a company's IT

setup. This includes weaknesses in systems, networks, and applications.
Risk Prioritization

The solution assigns risk rankings to detected vulnerabilities, allowing security

teams to prioritize repair actions based on their severity and possible impact.

Reporting and Remediation

The program creates extensive vulnerability reports, which provide insights
into the environment's security posture. These reports are critical for making
decisions and communicating with stakeholders. Nexpose also makes
recommendations on appropriate remediation procedures.

Example:

Vulnerability Scanner Nexpose: To run any executable, type./ followed by the

filename nsc. sh. It may take some time to run this command for the first time.
The utility has successfully loaded, as shown in the screenshot below. It tells us
that we can get there by using the URL https://localhost:3780:

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

How to install Nikto in Linux:

Step 1: root@kali:~# git clone https://github.com/sullo/nikto.git

Step 2: root@kali:~# cd nikto/program

Step 3: root@kali:~/nikto/program# perl nikto.pl

Usages:-

 Help menu: root@kali:~/nikto/program# perl nikto.pl -H

  Scan a website: root@kali:~/nikto/program# perl nikto.pl -host
https://www.webscantest.com/

Want to be a Software Developer or a Working Professional looking to enhance

your Software Development Skills? Then, master the concepts of Full-Stack
Development. Our Full Stack Development - React and Node.js Course will help
you achieve this quickly. Learn everything from Front-End to Back-End
Development with hands-on Projects and real-world examples.

Burp Suite

Burp or Burp Suite is a set of tools used for penetration testing of web
applications. It is developed by the company named Portswigger, which is also
the alias of its founder Dafydd Stuttard. BurpSuite aims to be an all in one set
of tools and its capabilities can be enhanced by installing add-ons that are
called BApps.
It is the most popular tool among professional web app security researchers
and bug bounty hunters. Its ease of use makes it a more suitable choice over
free alternatives like OWASP ZAP. Burp Suite is available as a community
edition which is free, professional edition that costs $399/year and an
enterprise edition that costs $3999/Year. This article gives a brief introduction
to the tools offered by BurpSuite. If you are a complete beginner in Web
Application Pentest/Web App Hacking/Bug Bounty, we would recommend you
to just read through without thinking too much about a term.

The tools offered by BurpSuite are:

1. Spider:
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?

5. Sequencer:
The sequencer is an entropy checker that checks for the randomness of tokens
generated by the webserver. These tokens are generally used for
authentication in sensitive operations: cookies and anti-CSRF tokens are
examples of such tokens. Ideally, these tokens must be generated in a fully
random manner so that the probability of appearance of each possible
character at a position is distributed uniformly. This should be achieved both
bit-wise and character-wise. An entropy analyzer tests this hypothesis for
being true. It works like this: initially, it is assumed that the tokens are random.
Then the tokens are tested on certain parameters for certain characteristics. A
term significance level is defined as a minimum value of probability that the
token will exhibit for a characteristic, such that if the token has a
characteristics probability below significance level, the hypothesis that the
token is random will be rejected. This tool can be used to find out the weak
tokens and enumerate their construction.

6. Decoder:
Decoder lists the common encoding methods like URL, HTML, Base64, Hex, etc.
This tool comes handy when looking for chunks of data in values of parameters
or headers. It is also used for payload construction for various vulnerability
classes. It is used to uncover primary cases of IDOR and session hijacking.

7. Extender:
BurpSuite supports external components to be integrated into the tools suite
to enhance its capabilities. These external components are called BApps. These
work just like browser extensions. These can be viewed, modified, installed,
uninstalled in the Extender window. Some of them are supported on the
community version, but some require the paid professional version.

8. Scanner:

The scanner is not available in the community edition. It scans the website
automatically for many common vulnerabilities and lists them with information
on confidence over each finding and their complexity of exploitation. It is
updated regularly to include new and less known vulnerabilities.