A Seminar Report On

CYBER SECURITY : ATTACKS & MITIGATIONS

submitted to
JAWAHARLAL NEHRU TECHNOLOGICAL UNIVERSITY,
ANANTHAPUR
in partial fulfilment of the requirements for the award of the degree of

BACHELOR OF TECHNOLOGY
IN
COMPUTER SCIENCE AND ENGINEERING
Submitted by
RAKESH DAMA
(17AK1A0586)
Under the esteemed guidance of
Dr. K. Nawaz
and
Dr. S. Jumlesha
Department of CSE.

ANNAMACHARYA INSTITUTE OF TECHNOLOGY AND SCIENCE,TIRUPATHI

(Affiliated to JNTUA, Anantapuramu)
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
Venkatapuram(V), Karkambadi Road, Renigunta (M), Tirupathi-517520
 Certificate

This is to certify that the Seminar report entitled

CYBER SECUIRTY: ATTACKS & MITIGATIONS

is the bonafide work carried out by

RAKESH DAMA
(17AK1A0586)

Submitted towards the Partial Fulfilment Of The Requirements For The Award Of
The Degree Of Bachelor of Technology In Computer Science And Engineering from
JNUTA, Anantapuramu during the year 2020 – 2021.

This Work has been Carried Out Under My guidance.

Guide: Head of the Department:

Dr. K. Nawaz and Mrs. B. Rupa Devi
Dr. S. Jumulesha Professor & HOD,
Dept. of. CSE. Dept. of. CSE.
 ABSTRACT
As we become increasingly connected through the Internet by access through the
computer, our phones, and even household devices, security has become a hot topic. Attacks
can happen from any corner. What happens if someone gains control of your computer or
phone? Or someone gains control of just your Google account?

On an enterprise level, attacks on computer systems can also breach millions of pieces of
personal data, including credit card information. Governments are also vulnerable to attacks that
expose sensitive data.

Cybersecurity involves everyone and every entity - from you and your neighbors, to
organizations, to companies, to governments.

The Internet has completely revolutionized the way we communicate with each other
and share information. Many of us spend hours on social media and online group chats. Nearly
all institutions have some sort of computer system administration to keep track of accounts, and
buying and selling things on the Internet is now the norm. One by one, even medical
equipment, transportation systems, and vacuums are connected to the web.
 CYBER SECURITY
INTRODUCTION
There’s no turning back, even as more connections to the Internet lead to more privacy
concerns and security risks. We don’t want strangers to access our accounts, or our credit card
numbers. Along with practicing personal security, organizations and businesses also need to do
their part to implement the right protections.

Cybersecurity is the field of study and practice that responds to these challenges as technology
evolves. In a formal definition by CISCO:

“Cybersecurity is the practice of protecting systems, networks, and programs from

digital attacks.”
Digital attacks can cover a whole range from fraudulent emails to a targeted shutdown of a
website’s traffic. Defenses against these attacks, then, must be learned and implemented at all
levels.

The CIA Triad

A basic, overarching model for cybersecurity, particularly as it relates to information, is

the CIA Triad. CIA stands for Confidentiality, Integrity, and Availability (not the US Central
Intelligence Agency). Nearly all information security policies trace back to this model. Let’s go
through each component of this triad.

Confidentiality

This pillar of the triad refers to protecting private information from eyes that shouldn’t
have access to it. Confidentiality is the need to enforce access - who can see this, and who
shouldn’t? For example, we don’t want to give our social security number to just anyone, but we
trust that the institutions we give them to - like tax services - implement the right security
measures to keep it secret. So what tools are used to guarantee the right access?

Some of the ways confidentiality is managed are:

 Keeping levels of access and setting permissions

 Encrypting data and files
 Requiring multi-factor authentication
Integrity

Integrity refers to data integrity here. We need security controls that protect data from
being changed or deleted. We must also ensure that the damage can be reversed if data was
changed accidentally or by the wrong person. Some techniques related to integrity are:

 Keeping backups of the data in its correct state, and logging versions
 Using cryptography to securely check for changes
 Keeping track of digital signatures to prove integrity of data
Availability

This last pillar refers to data being consistently, reliably available to those authorized. For
example, when you login to a social media account and want to set your privacy settings, you
expect all the correct settings you had set before to appear immediately. The social media
company ensures that even with high traffic, information gets to your screen. How is this
accomplished?

 Always monitoring servers and networks

 Maintaining hardware and software
 Having a plan for disaster recovery

WEB APPLICATION SECURITY

For Web Application Security most of hacker and security practitioners follow a guide
called OWASP TOP 10.
WHAT IS OWASP ?
The Open Web Application Security Project® (OWASP) is a nonprofit foundation that
works to improve the security of software. Through community-led open-source software
projects, hundreds of local chapters worldwide, tens of thousands of members, and leading
educational and training conferences, the OWASP Foundation is the source for developers and
technologists to secure the web.

 Tools and Resources

 Community and Networking
 Education & Training

The OWASP Top 10 is a standard awareness document for developers and web
application security. It represents a broad consensus about the most critical security risks to web
applications.

Top 10 Web Application Security Risks

A1:2017-Injection: Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur
when untrusted data is sent to an interpreter as part of a command or query. The attacker’s
hostile data can trick the interpreter into executing unintended commands or accessing data
without proper authorization.

A2:2017-Broken Authentication: Application functions related to authentication and

session management are often implemented incorrectly, allowing attackers to compromise
passwords, keys, or session tokens, or to exploit other implementation flaws to assume other
users’ identities temporarily or permanently.

A3:2017-Sensitive Data Exposure: Many web applications and APIs do not properly
protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify
such weakly protected data to conduct credit card fraud, identity theft, or other crimes.
Sensitive data may be compromised without extra protection, such as encryption at rest or in
transit, and requires special precautions when exchanged with the browser.

A4:2017-XML External Entities (XXE): Many older or poorly configured XML

processors evaluate external entity references within XML documents. External entities can
be used to disclose internal files using the file URI handler, internal file shares, internal port
scanning, remote code execution, and denial of service attacks.

A5:2017-Broken Access Control: Restrictions on what authenticated users are allowed to

do are often not properly enforced. Attackers can exploit these flaws to access unauthorized
functionality and/or data, such as access other users’ accounts, view sensitive files, modify
other users’ data, change access rights, etc.

A6:2017-Security Misconfiguration: Security misconfiguration is the most commonly

seen issue. This is commonly a result of insecure default configurations, incomplete or ad
hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error
messages containing sensitive information. Not only must all operating systems,
frameworks, libraries, and applications be securely configured, but they must be
patched/upgraded in a timely fashion.

A7:2017-Cross-Site Scripting XSS: XSS flaws occur whenever an application includes

untrusted data in a new web page without proper validation or escaping, or updates an
existing web page with user-supplied data using a browser API that can create HTML or
JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack
user sessions, deface web sites, or redirect the user to malicious sites.

A8:2017-Insecure Deserialization: Insecure deserialization often leads to remote code

execution. Even if deserialization flaws do not result in remote code execution, they can be
used to perform attacks, including replay attacks, injection attacks, and privilege escalation
attacks.

A9:2017-Using Components with Known Vulnerabilities: Components, such as libraries,

frameworks, and other software modules, run with the same privileges as the application. If
a vulnerable component is exploited, such an attack can facilitate serious data loss or server
takeover. Applications and APIs using components with known vulnerabilities may
undermine application defenses and enable various attacks and impacts.

A10:2017-Insufficient Logging & Monitoring: Insufficient logging and monitoring,

coupled with missing or ineffective integration with incident response, allows attackers to
further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or
destroy data. Most breach studies show time to detect a breach is over 200 days, typically
detected by external parties rather than internal processes or monitoring.

SQL INJECTION VULNERABILITY

What is SQL injection (SQLi)?

SQL injection is a web security vulnerability that allows an attacker to interfere with the
queries that an application makes to its database. It generally allows an attacker to view data
that they are not normally able to retrieve. This might include data belonging to other users, or
any other data that the application itself is able to access. In many cases, an attacker can modify
or delete this data, causing persistent changes to the application's content or behavior.

In some situations, an attacker can escalate an SQL injection attack to compromise the
underlying server or other back-end infrastructure, or perform a denial-of-service attack.
What is the impact of a successful SQL injection attack?

A successful SQL injection attack can result in unauthorized access to sensitive data,
such as passwords, credit card details, or personal user information. Many high-profile data
breaches in recent years have been the result of SQL injection attacks, leading to reputational
damage and regulatory fines. In some cases, an attacker can obtain a persistent backdoor into an
organization's systems, leading to a long-term compromise that can go unnoticed for an extended
period.

SQL Injection examples

There are a wide variety of SQL injection vulnerabilities, attacks, and techniques, which
arise in different situations. Some common SQL injection examples include:

 Retrieving hidden data, where you can modify an SQL query to return additional
results.
 Subverting application logic, where you can change a query to interfere with the
application's logic.
 UNION attacks, where you can retrieve data from different database tables.
  Examining the database, where you can extract information about the version and
structure of the database.
 Blind SQL injection, where the results of a query you control are not returned in the
application's responses.

How to prevent SQL injection

Most instances of SQL injection can be prevented by using parameterized queries (also known as
prepared statements) instead of string concatenation within the query.

The following code is vulnerable to SQL injection because the user input is concatenated directly
into the query:

String query = "SELECT * FROM products WHERE category = '"+ input

+ "'";

Statement statement = connection.createStatement();

ResultSet resultSet = statement.executeQuery(query);

This code can be easily rewritten in a way that prevents the user input from interfering with the
query structure:

PreparedStatement statement = connection.prepareStatement("SELECT

* FROM products WHERE category = ?");

statement.setString(1, input);

ResultSet resultSet = statement.executeQuery();

Parameterized queries can be used for any situation where untrusted input appears as data within
the query, including the WHERE clause and values in an INSERT or UPDATE statement. They
can't be used to handle untrusted input in other parts of the query, such as table or column names,
or the ORDER BY clause. Application functionality that places untrusted data into those parts of
the query will need to take a different approach, such as white-listing permitted input values, or
using different logic to deliver the required behavior.
For a parameterized query to be effective in preventing SQL injection, the string that is used in
the query must always be a hard-coded constant, and must never contain any variable data from
any origin. Do not be tempted to decide case-by-case whether an item of data is trusted, and
continue using string concatenation within the query for cases that are considered safe. It is all
too easy to make mistakes about the possible origin of data, or for changes in other code to
violate assumptions about what data is tainted.

BROKEN AUTHENTICATION

Conceptually at least, authentication vulnerabilities are some of the simplest issues to

understand. However, they can be among the most critical due to the obvious relationship
between authentication and security. As well as potentially allowing attackers direct access to
sensitive data and functionality, they also expose additional attack surface for further exploits.
For this reason, learning how to identify and exploit authentication vulnerabilities, including how
to bypass common protection measures, is a fundamental skill.

In this section, we'll look at some of the most common authentication mechanisms used
by websites and discuss potential vulnerabilities in them. We'll highlight both inherent
vulnerabilities in different authentication mechanisms, as well as some typical vulnerabilities that
are introduced by their improper implementation. Finally, we'll provide some basic guidance on
how you can ensure that your own authentication mechanisms are as robust as possible.
What is the impact of vulnerable authentication?

The impact of authentication vulnerabilities can be very severe. Once an attacker has
either bypassed authentication or has brute-forced their way into another user's account, they
have access to all the data and functionality that the compromised account has. If they are able to
compromise a high-privileged account, such as a system administrator, they could take full
control over the entire application and potentially gain access to internal infrastructure.

Even compromising a low-privileged account might still grant an attacker access to data
that they otherwise shouldn't have, such as commercially sensitive business information. Even if
the account does not have access to any sensitive data, it might still allow the attacker to access
additional pages, which provide a further attack surface. Often, certain high-severity attacks will
not be possible from publicly accessible pages, but they may be possible from an internal page.

ACCESS CONTROL VULNERABILITY

In this section, we will discuss what access control security is, describe privilege
escalation and the types of vulnerabilities that can arise with access control, and summarize how
to prevent these vulnerabilities.
What is access control?

Access control (or authorization) is the application of constraints on who (or what) can
perform attempted actions or access resources that they have requested. In the context of web
applications, access control is dependent on authentication and session management:

 Authentication identifies the user and confirms that they are who they say they are.
 Session management identifies which subsequent HTTP requests are being made by
that same user.
 Access control determines whether the user is allowed to carry out the action that they
are attempting to perform.

Broken access controls are a commonly encountered and often critical security
vulnerability. Design and management of access controls is a complex and dynamic problem that
applies business, organizational, and legal constraints to a technical implementation. Access
control design decisions have to be made by humans, not technology, and the potential for errors
is high.
Vertical access controls

Vertical access controls are mechanisms that restrict access to sensitive functionality that
is not available to other types of users.

With vertical access controls, different types of users have access to different application
functions. For example, an administrator might be able to modify or delete any user's account,
while an ordinary user has no access to these actions. Vertical access controls can be more fine-
grained implementations of security models designed to enforce business policies such as
separation of duties and least privilege.

Horizontal access controls

Horizontal access controls are mechanisms that restrict access to resources to the users
who are specifically allowed to access those resources.

With horizontal access controls, different users have access to a subset of resources of the
same type. For example, a banking application will allow a user to view transactions and make
payments from their own accounts, but not the accounts of any other user.
XML EXTERNAL ENTITY (XXE) INJECTION

In this section, we'll explain what XML external entity injection is, describe some
common examples, explain how to find and exploit various kinds of XXE injection, and
summarize how to prevent XXE injection attacks.

What is XML external entity injection?

XML external entity injection (also known as XXE) is a web security vulnerability that
allows an attacker to interfere with an application's processing of XML data. It often allows an
attacker to view files on the application server filesystem, and to interact with any back-end or
external systems that the application itself can access.

In some situations, an attacker can escalate an XXE attack to compromise the underlying
server or other back-end infrastructure, by leveraging the XXE vulnerability to perform server-
side request forgery (SSRF) attacks.
How do XXE vulnerabilities arise?

Some applications use the XML format to transmit data between the browser and the
server. Applications that do this virtually always use a standard library or platform API to
process the XML data on the server. XXE vulnerabilities arise because the XML specification
contains various potentially dangerous features, and standard parsers support these features even
if they are not normally used by the application.

XML external entities are a type of custom XML entity whose defined values are loaded
from outside of the DTD in which they are declared. External entities are particularly interesting
from a security perspective because they allow an entity to be defined based on the contents of a
file path or URL.

Exploiting XXE to retrieve files

To perform an XXE injection attack that retrieves an arbitrary file from the server's
filesystem, you need to modify the submitted XML in two ways:

 Introduce (or edit) a DOCTYPE element that defines an external entity containing the
path to the file.

 Edit a data value in the XML that is returned in the application's response, to make use
of the defined external entity.

For example, suppose a shopping application checks for the stock level of a product by
submitting the following XML to the server:

<?xml version="1.0" encoding="UTF-8"?>

<stockCheck><productId>381</productId></stockCheck>

The application performs no particular defenses against XXE attacks, so you can exploit
the XXE vulnerability to retrieve the /etc/passwd file by submitting the following XXE
payload:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<stockCheck><productId>&xxe;</productId></stockCheck>
This XXE payload defines an external entity &xxe; whose value is the contents of the
/etc/passwd file and uses the entity within the productId value. This causes the
application's response to include the contents of the file:

Invalid product ID: root:x:0:0:root:/root:/bin/bash

daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...

INFORMATION DISCLOSURE VULNERABILITY

In this section, we'll explain the basics of information disclosure vulnerabilities and
describe how you can find and exploit them. We'll also offer some guidance on how you can
prevent information disclosure vulnerabilities in your own websites.

Learning to find and exploit information disclosure is a vital skill for any tester. You are likely to
encounter it on a regular basis and, once you know how to exploit it effectively, it can help you
to improve your testing efficiency and enable you to find additional, high-severity bugs.
What is information disclosure?

Information disclosure, also known as information leakage, is when a website unintentionally

reveals sensitive information to its users. Depending on the context, websites may leak all kinds
of information to a potential attacker, including:

 Data about other users, such as usernames or financial information

  Sensitive commercial or business data
 Technical details about the website and its infrastructure

The dangers of leaking sensitive user or business data are fairly obvious, but disclosing technical
information can sometimes be just as serious. Although some of this information will be of
limited use, it can potentially be a starting point for exposing an additional attack surface, which
may contain other interesting vulnerabilities. The knowledge that you are able to gather could
even provide the missing piece of the puzzle when trying to construct complex, high-severity
attacks.

Occasionally, sensitive information might be carelessly leaked to users who are simply browsing
the website in a normal fashion. More commonly, however, an attacker needs to elicit the
information disclosure by interacting with the website in unexpected or malicious ways. They
will then carefully study the website's responses to try and identify interesting behavior.

What are some examples of information disclosure?

Some basic examples of information disclosure are as follows:

 Revealing the names of hidden directories, their structure, and their contents via a
robots.txt file or directory listing

 Providing access to source code files via temporary backups

 Explicitly mentioning database table or column names in error messages
 Unnecessarily exposing highly sensitive information, such as credit card details
 Hard-coding API keys, IP addresses, database credentials, and so on in the source code
 Hinting at the existence or absence of resources, usernames, and so on via subtle
differences in application behavior

How do information disclosure vulnerabilities arise?

Information disclosure vulnerabilities can arise in countless different ways, but these can broadly
be categorized as follows:

 Failure to remove internal content from public content. For example, developer
comments in markup are sometimes visible to users in the production environment.
  Insecure configuration of the website and related technologies. For example, failing to
disable debugging and diagnostic features can sometimes provide attackers with useful
tools to help them obtain sensitive information. Default configurations can also leave
websites vulnerable, for example, by displaying overly verbose error messages.
 Flawed design and behavior of the application. For example, if a website returns
distinct responses when different error states occur, this can also allow attackers to
enumerate sensitive data, such as valid user credentials.

What is the impact of information disclosure vulnerabilities?

Information disclosure vulnerabilities can have both a direct and indirect impact
depending on the purpose of the website and, therefore, what information an attacker is able to
obtain. In some cases, the act of disclosing sensitive information alone can have a high impact on
the affected parties. For example, an online shop leaking its customers' credit card details is
likely to have severe consequences.

On the other hand, leaking technical information, such as the directory structure or which
third-party frameworks are being used, may have little to no direct impact. However, in the
wrong hands, this could be the key information required to construct any number of other
exploits. The severity in this case depends on what the attacker is able to do with this
information.

CROSS-SITE SCRIPTING (XSS)

In this section, we'll explain what cross-site scripting is, describe the different varieties of cross-
site scripting vulnerabilities, and spell out how to find and prevent cross-site scripting.

What is cross-site scripting (XSS)?

Cross-site scripting (also known as XSS) is a web security vulnerability that allows an attacker to
compromise the interactions that users have with a vulnerable application. It allows an attacker
to circumvent the same origin policy, which is designed to segregate different websites from
each other. Cross-site scripting vulnerabilities normally allow an attacker to masquerade as a
victim user, to carry out any actions that the user is able to perform, and to access any of the
user's data. If the victim user has privileged access within the application, then the attacker might
be able to gain full control over all of the application's functionality and data.

How does XSS work?

Cross-site scripting works by manipulating a vulnerable web site so that it returns malicious
JavaScript to users. When the malicious code executes inside a victim's browser, the attacker can
fully compromise their interaction with the application.

What are the types of XSS attacks?

There are three main types of XSS attacks. These are:

Reflected XSS, where the malicious script comes from the current HTTP request.
Stored XSS, where the malicious script comes from the website's database.
DOM-based XSS, where the vulnerability exists in client-side code rather than server-
side code.
Reflected cross-site scripting
Reflected XSS is the simplest variety of cross-site scripting. It arises when an application
receives data in an HTTP request and includes that data within the immediate response in an
unsafe way.

Here is a simple example of a reflected XSS vulnerability:

https://insecure-website.com/status?message=All+is+well.

<p>Status: All is well.</p>

The application doesn't perform any other processing of the data, so an attacker can easily
construct an attack like this:

https://insecure-website.com/status?message=<script>/
*+Bad+stuff+here...+*/</script>

<p>Status: <script>/* Bad stuff here... */</script></p>

If the user visits the URL constructed by the attacker, then the attacker's script executes in the
user's browser, in the context of that user's session with the application. At that point, the script
can carry out any action, and retrieve any data, to which the user has access.

Stored cross-site scripting

Stored XSS (also known as persistent or second-order XSS) arises when an application receives
data from an untrusted source and includes that data within its later HTTP responses in an unsafe
way.

The data in question might be submitted to the application via HTTP requests; for example,
comments on a blog post, user nicknames in a chat room, or contact details on a customer order.
In other cases, the data might arrive from other untrusted sources; for example, a webmail
application displaying messages received over SMTP, a marketing application displaying social
media posts, or a network monitoring application displaying packet data from network traffic.

Here is a simple example of a stored XSS vulnerability. A message board application lets users
submit messages, which are displayed to other users:
<p>Hello, this is my message!</p>

The application doesn't perform any other processing of the data, so an attacker can easily send a
message that attacks other users:

<p><script>/* Bad stuff here... */</script></p>

DOM-based cross-site scripting

DOM-based XSS (also known as DOM XSS) arises when an application contains some client-
side JavaScript that processes data from an untrusted source in an unsafe way, usually by writing
the data back to the DOM.

In the following example, an application uses some JavaScript to read the value from an input
field and write that value to an element within the HTML:

var search = document.getElementById('search').value;

var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;

If the attacker can control the value of the input field, they can easily construct a malicious value
that causes their own script to execute:

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

In a typical case, the input field would be populated from part of the HTTP request, such as a
URL query string parameter, allowing the attacker to deliver an attack using a malicious URL, in
the same manner as reflected XSS.

What can XSS be used for?

An attacker who exploits a cross-site scripting vulnerability is typically able to:

Impersonate or masquerade as the victim user.

Carry out any action that the user is able to perform.
Read any data that the user is able to access.
Capture the user's login credentials.
 Perform virtual defacement of the web site.
Inject trojan functionality into the web site.

Impact of XSS vulnerabilities

The actual impact of an XSS attack generally depends on the nature of the application, its
functionality and data, and the status of the compromised user. For example:

In a brochureware application, where all users are anonymous and all information is
public, the impact will often be minimal.
In an application holding sensitive data, such as banking transactions, emails, or
healthcare records, the impact will usually be serious.
If the compromised user has elevated privileges within the application, then the impact
will generally be critical, allowing the attacker to take full control of the vulnerable
application and compromise all users and their data.

How to prevent XSS attacks

Preventing cross-site scripting is trivial in some cases but can be much harder depending on the
complexity of the application and the ways it handles user-controllable data.

In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the

following measures:

Filter input on arrival. At the point where user input is received, filter as strictly as
possible based on what is expected or valid input.
Encode data on output. At the point where user-controllable data is output in HTTP
responses, encode the output to prevent it from being interpreted as active content.
Depending on the output context, this might require applying combinations of HTML,
URL, JavaScript, and CSS encoding.
Use appropriate response headers. To prevent XSS in HTTP responses that aren't
intended to contain any HTML or JavaScript, you can use the Content-Type and X-
Content-Type-Options headers to ensure that browsers interpret the responses in
the way you intend.
 Content Security Policy. As a last line of defense, you can use Content Security Policy
(CSP) to reduce the severity of any XSS vulnerabilities that still occur.

Common questions about cross-site scripting

How common are XSS vulnerabilities? XSS vulnerabilities are very common, and XSS is
probably the most frequently occurring web security vulnerability.

How common are XSS attacks? It is difficult to get reliable data about real-world XSS attacks,
but it is probably less frequently exploited than other vulnerabilities.

What is the difference between XSS and CSRF? XSS involves causing a web site to return
malicious JavaScript, while CSRF involves inducing a victim user to perform actions they do not
intend to do.

What is the difference between XSS and SQL injection? XSS is a client-side vulnerability that
targets other application users, while SQL injection is a server-side vulnerability that targets the
application's database.

How do I prevent XSS in PHP? Filter your inputs with a whitelist of allowed characters and use
type hints or type casting. Escape your outputs with htmlentities and ENT_QUOTES for
HTML contexts, or JavaScript Unicode escapes for JavaScript contexts.

How do I prevent XSS in Java? Filter your inputs with a whitelist of allowed characters and use a
library such as Google Guava to HTML-encode your output for HTML contexts, or use
JavaScript Unicode escapes for JavaScript contexts.
INSECURE DESERAILIZATION
In this section, we'll cover what insecure deserialization is and describe how it can potentially
expose websites to high-severity attacks. We'll highlight typical scenarios and demonstrate some
widely applicable techniques using concrete examples of PHP, Ruby, and Java deserialization.
We'll also look at some ways that you can avoid insecure deserialization vulnerabilities in your
own websites.

Exploiting insecure deserialization has a reputation for being difficult. However, it can
sometimes be much simpler than you might think. If you're new to the topic of deserialization,
this section contains key background information that you should familiarize yourself with first.
If you already know the the basics of deserialization, you can skip straight to learning about how
to exploit it.

What is serialization?

Serialization is the process of converting complex data structures, such as objects and their
fields, into a "flatter" format that can be sent and received as a sequential stream of bytes.
Serializing data makes it much simpler to:

Write complex data to inter-process memory, a file, or a database

Send complex data, for example, over a network, between different components of an
application, or in an API call

Crucially, when serializing an object, its state is also persisted. In other words, the object's
attributes are preserved, along with their assigned values.

Serialization vs deserialization

Deserialization is the process of restoring this byte stream to a fully functional replica of the
original object, in the exact state as when it was serialized. The website's logic can then interact
with this deserialized object, just like it would with any other object.
Many programming languages offer native support for serialization. Exactly how objects are
serialized depends on the language. Some languages serialize objects into binary formats,
whereas others use different string formats, with varying degrees of human readability. Note that
all of the original object's attributes are stored in the serialized data stream, including any private
fields. To prevent a field from being serialized, it must be explicitly marked as "transient" in the
class declaration.

Be aware that when working with different programming languages, serialization may be
referred to as marshalling (Ruby) or pickling (Python). These terms are synonymous with
"serialization" in this context.

What is insecure deserialization?

Insecure deserialization is when user-controllable data is deserialized by a website. This

potentially enables an attacker to manipulate serialized objects in order to pass harmful data into
the application code.

It is even possible to replace a serialized object with an object of an entirely different class.
Alarmingly, objects of any class that is available to the website will be deserialized and
instantiated, regardless of which class was expected. For this reason, insecure deserialization is
sometimes known as an "object injection" vulnerability.
An object of an unexpected class might cause an exception. By this time, however, the damage
may already be done. Many deserialization-based attacks are completed before deserialization is
finished. This means that the deserialization process itself can initiate an attack, even if the
website's own functionality does not directly interact with the malicious object. For this reason,
websites whose logic is based on strongly typed languages can also be vulnerable to these
techniques.

How do insecure deserialization vulnerabilities arise?

Insecure deserialization typically arises because there is a general lack of understanding

of how dangerous deserializing user-controllable data can be. Ideally, user input should never be
deserialized at all.

However, sometimes website owners think they are safe because they implement some form of
additional check on the deserialized data. This approach is often ineffective because it is virtually
impossible to implement validation or sanitization to account for every eventuality. These checks
are also fundamentally flawed as they rely on checking the data after it has been deserialized,
which in many cases will be too late to prevent the attack.

Vulnerabilities may also arise because deserialized objects are often assumed to be trustworthy.
Especially when using languages with a binary serialization format, developers might think that
users cannot read or manipulate the data effectively. However, while it may require more effort,
it is just as possible for an attacker to exploit binary serialized objects as it is to exploit string-
based formats.

Deserialization-based attacks are also made possible due to the number of dependencies that
exist in modern websites. A typical site might implement many different libraries, which each
have their own dependencies as well. This creates a massive pool of classes and methods that is
difficult to manage securely. As an attacker can create instances of any of these classes, it is hard
to predict which methods can be invoked on the malicious data. This is especially true if an
attacker is able to chain together a long series of unexpected method invocations, passing data
into a sink that is completely unrelated to the initial source. It is, therefore, almost impossible to
anticipate the flow of malicious data and plug every potential hole.

In short, it can be argued that it is not possible to securely deserialize untrusted input.
What is the impact of insecure deserialization?

The impact of insecure deserialization can be very severe because it provides an entry
point to a massively increased attack surface. It allows an attacker to reuse existing application
code in harmful ways, resulting in numerous other vulnerabilities, often remote code execution.

Even in cases where remote code execution is not possible, insecure deserialization can lead to
privilege escalation, arbitrary file access, and denial-of-service attacks

How to prevent insecure deserialization vulnerabilities

Generally speaking, deserialization of user input should be avoided unless absolutely necessary.
The high severity of exploits that it potentially enables, and the difficulty in protecting against
them, outweigh the benefits in many cases.

If you do need to deserialize data from untrusted sources, incorporate robust measures to make
sure that the data has not been tampered with. For example, you could implement a digital
signature to check the integrity of the data. However, remember that any checks must take place
before beginning the deserialization process. Otherwise, they are of little use.

If possible, you should avoid using generic deserialization features altogether. Serialized data
from these methods contains all attributes of the original object, including private fields that
potentially contain sensitive information. Instead, you could create your own class-specific
serialization methods so that you can at least control which fields are exposed.

Finally, remember that the vulnerability is the deserialization of user input, not the presence of
gadget chains that subsequently handle the data. Don't rely on trying to eliminate gadget chains
that you identify during testing. It is impractical to try and plug them all due to the web of cross-
library dependencies that almost certainly exist on your website. At any given time, publicly
documented memory corruption exploits are also a factor, meaning that your application may be
vulnerable regardless.
CONCLUSION
Cybersecurity is important because it protects all categories of data from theft and
damage. This includes sensitive data, personally identifiable information (PII), protected health
information (PHI), personal information, intellectual property, data, and governmental and
industry information systems. The future of cybersecurity will in one sense be like the present:
hard to define and potentially unbounded as digital technologies interact with human beings
across virtually all aspects of politics, society, the economy, and beyond.

REFERENCES

1. https://www.bugbountyhunter.com/
2. https://owasp.org/www-project-top-ten/
3. https://portswigger.net/