APPLICATION SECURITY

HCSC801

BE EXTC, SEM-VII
Honours/ Minor degree Program in
CYBER SECURITY

Mrs. Arti Sawant

 COURSE OBJECTIVES

🞆 The terms and concepts of application Security,

Threats, and Attacks
🞆 The countermeasures for the threats wrt Application
security.
🞆 The Secure Coding Practices
🞆 The Secure Application Design and Architecture
🞆 The different Security Scanning and testing
techniques
🞆 The threat modeling approaches

2
COURSE OUTCOMES
🞆 Enumerate the terms of application Security,
Threats, and Attacks
🞆 Describe the countermeasures for the threats with
respect to Application security.
🞆 Discuss the Secure Coding Practices.
🞆 Explain the Secure Application Design and
Architecture
🞆 Review the different Security Scanning and testing
techniques.
🞆 Discuss the threat modeling approaches.

3
4
5
6
7
8
CA (20 MARKS)

[Link]. Rubrics Marks

1 Class Tutorial 10 marks

2 Quiz 10 marks
(Quiz 1 & 2) (5 marks each)

3 Content beyond syllabus 10 marks

presentation

9
WEB APPLICATION RECONNAISSANCE
🞆 It refers to the explorative data-gathering phase
that generally occurs prior to hacking a web
application
🞆 Performed by hackers, pen testers, or bug bounty
hunters
🞆 It can also be an effective way for security
engineers to find weakly secured mechanisms in a
web application and patch them before a malicious
actor find them
🞆 This process involves various techniques and tools
designed to uncover potential weaknesses and map
10
out the application’s structure
WEB APPLICATION RECONNAISSANCE
PROCESS

Subdomain Subdomain Gathering Bug

Finding Filtering Urls Hunting

11
1. Subdomain finding: Subdomain finding is the
process of discovering all subdomains
associated with a domain name. Website
owners can use subdomains to create separate
sections of their website for different purposes,
such as a blog, online store, or support portal.
Hackers can use unmonitored subdomains to
steal data and engage in malicious activities

2. Subdomain filtering: It refers to the process of

selectively allowing or blocking access to
specific subdomains within a larger domain,
essentially acting as a way to control which
parts of a website can be accessed based on
their subdomain name, often used in network
12
security to manage access to different sections
of a website or to prevent access to potentially
3. Gathering Urls: to gather Urls ,one can use tools
like crawlers, command-line utilities, or
information-gathering tools. [Link] can
detect closed and open ports of networks.
URLextractor is one of the easiest and useful tools
for performing reconnaissance on websites and
web apps. URLetractor provides a command-line
interface that you can run on Kali Linux. Mainly
URLextractor is used to find IP-address, DNS
information, Target servers, region of the server,
city, ASN number etc.

4. Bug hunting is the process executed by

highly-skilled hackers who detect security
vulnerabilities . Unlike malicious hackers, these
professionals report their findings to 13

organizations, helping them patch

vulnerabilities and enhance their defenses
API ANALYSIS
🞆 API analysis is the process of collecting and
analyzing data from an application
programming interface (API) to gain insights
🞆 Process:
📫 API analytics integrates with an organization's API
infrastructure to collect data from every API
communication
📫 The data collected includes request and response
headers, payloads, authentication methods, and the
frequency of API calls
📫 The data is then analyzed to provide actionable
14
insights
BENEFITS OF API ANALYSIS

🞆 API analysis helps organizations understand

how APIs are being used
🞆 It helps identify issues or bottlenecks
🞆 It helps organizations make informed
decisions to optimize API performance
🞆 It helps organizations improve their overall
API strategy

• Tools for API Analysis:

1. Katalon Studio · 2. Postman · 3. Apigee · 4. JMeter · 5.
REST-assured · 6. Assertible · 7. Soap UI etc. 15
IDENTIFYING WEAK POINTS IN
APPLICATION ARCHITECTURE
● Talking about vulnerabilities in web applications – about
issues that occur at the code level, or as a result of
improperly written code
● The architectural design of an application leads to either an
abundant number of security bugs or a relatively low
number of security bugs based on how the application’s
defenses are designed and distributed throughout the
codebase
● Identifying weak points in application architecture is a
useful reconnaissance technique.
● Hence, poor architecture of an application can lead into
easy access or handy reconnaissance
16
POINTS FOR WEB APPLICATION
RECONNAISSANCE TEST
● Technology used in the web application
● List of API endpoints by HTTP
● List of API endpoint shapes (where available)
● Functionality included in the web application (e.g.,
comments, auth, notifications,etc.)
● Domains used by the web application
● Configurations found (e.g., Content Security Policy or CSP)
● Authentication/session management systems

17
CONTD.
● After compiling this list, use it to prioritize any attempts at
hacking the application or finding vulnerabilities
● Most vulnerabilities in a web application are from
improperly designed application architecture and poorly
written methods
● A method that writes user-provided HTML directly to the
DOM may allow a user to upload a script and execute that
script on another user’s machine (XSS)

[*DOM stands for Document Object Model. It is a programming

interface that allows us to create, change, or remove elements
18
from the HTML document]
SECURE VS INSECURE ARCHITECTURE
SIGNALS
● A single XSS vulnerability may be the result of a poorly written
method. But multiple vulnerabilities are the sign of weak
application architecture
● Consider two simple applications that allow users to send direct
messages (texts) to other users. One of these applications is
vulnerable to XSS, while the other is not.
● The insecure application might not reject a script when a request
to store a comment is made to an API endpoint; its database
might not reject the script, and it might not perform proper
filtration and sanitization against the string representing the
message
● Ultimately, it is loaded into the DOM and evaluated as DOM test
Message script, hence resulting in script execution.
● Where as, secure application likely has one or many of the
19
preceding protections.
CONTD.
➢ Hence each of the IM systems should include the following
functionality:
• UI to write a message
• API endpoint to receive a message just written and submitted
• A database table to store a message
• An API endpoint to retrieve one or more messages
• UI code to display one or more messages
➢ The security mechanisms needed to secure this simple application
should, be abstracted into the application architecture rather than
implemented on a case-by-case basis
➢ Multiple layers where XSS risk could occur are
• API POST
• Database Write
• Database Read
• API GET 20

• Client Read
ADOPTION AND REINVENTION
● An organizational problem, which is reflected and visible in the
application architecture
● Reinventing tools or features comes with a number of benefits
from a development perspective including:
1. Avoiding complicated licenses
2. Adding additional functionality to the feature
3. Creating publicity via marketing the new tool or feature
technology
● But Reinvention is risky from a security point of view
● The risk waxes and wanes based on the particular functionality
being reinvented, but can span anywhere from a moderate
security risk all the way to an extreme security risk.
21
CA CLASS TUTORIAL 30/01/2025
1. What are different types of Web application
architectures? Define
[Link] are different service architectures?
Discuss its suitable cases.

22
OFFENCES RELATED TO APP
SECURITY
● Cross site scripting (XSS)
● Cross site request forgery (CSRF)
● XML external entity (XXE) injection
● Injection attacks
● Denial of service
● Cross origin resource sharing vulnerability

23
[Link] SITE SCRIPTING (XSS)
● XSS attack functions by taking advantage of the fact
that web applications execute scripts on users’
browsers
● XSS attacks are categorized a number of ways, with the
big three being:
i. Stored (the code is stored on a database prior to
execution)
ii. Reflected (the code is not stored in a database, but
reflected by a server)
iii. DOM-based (code is both stored and executed in
the browser)
24
1. STORED XSS
● Stored XSS is a type of XSS that stores malicious
code on the application server.
● Using stored XSS is only possible if your application is
designed to store user input—a classic example is a
message board or social media website.
● Steps of execution:
i. An attacker injects malicious code in a request to
submit content to the application.
ii. The application believes the request is innocent,
processes the user input and stores it in the database
iii. From this point onwards, every time the submitted
content is displayed to users, the malicious code
executes on their browsers. 25
● Depending on the type of payload and the
vulnerabilities present in the user’s browser, stored
XSS attacks can allow attackers to:

- Hijack the user’s session and perform actions on their

behalf
- Steal the user’s credentials
- Hijacking the user’s browser or delivering browser-
based exploits
- Obtain sensitive information stored in the user’s
account or in their browser
- Port scanning of hosts the web application can connect
to
- Website defacement

26
 EXAMPLE
Consider an attacker browsing a retail website. The attacker notices a
vulnerability that allows HTML tags to be included in the comments section,
including the <script> tag. Embedded tags become a permanent feature of
the page, and each time the page is opened, the browser parses the tags
along with the rest of the source code.

The attacker can then submit a comment like this:

<p>I highly recommend this product!</p>

<script src=”[Link] </script>

The comment is published on the page and every time the page loads for a
visitor, the malicious script runs. In this case, the script is designed to steal a
visitor’s session cookie, meaning the attacker can take over a user’s
account. This gives them access to credit card and other personal data, and
27
also lets them make purchases on behalf of the user.
2. REFLECTED XSS
● Reflected XSS involves injecting malicious executable
code into an HTTP response.
● The malicious script does not reside in the application
and does not persist.
● The victim’s browser executes the attack only if the
user opens a web page or link set up by the attacker.
● They are also known as Type 1, first-order, or non-
persistent XSS.
● A single browser request and response delivers and
executes the attack payload.

28
 EXAMPLE
Consider a social media site that requires users to authenticate to send and view messages. The
website has a search function which displays the search string in the URL, like this:
[Link]

An attacker notices this and tries the following string as their search: <script
type=’text/javascript’>alert(‘test’);</script>

If the website does not properly sanitize inputs, this test script will appear in the URL, like this:
[Link]
type=’text/javascript’>alert(‘test’);</script>

And the script will execute, showing an alert box in the browser. This means the website is
vulnerable to an XSS attack.

Now the attacker can craft a URL that executes a malicious script from their own domain:

[Link]
[Link]”

The attacker embeds this link into a phishing email, and sends it to individuals who are users of
the social media site, and are likely to be logged into it. Some users might be hesitant to click
29 on a
link from an unknown sender, but it’s enough that only a few of them are tricked into [Link]
user who clicks the link, will cause the malicious script to execute.
3. DOM BASED XSS ATTACK
● DOM-based XSS vulnerabilities usually arise when
JavaScript takes data from an attacker-controllable
source, such as the URL, and passes it to a sink that
supports dynamic code execution
● This enables attackers to execute malicious
JavaScript, which typically allows them to hijack other
users' accounts.
● The most common source for DOM XSS is the URL,
which is typically accessed with the
[Link] object.
● An attacker can construct a link to send a victim to a
vulnerable page with a payload in the query string and
fragment portions of the URL. 30
2. CROSS SITE REQUEST
FORGERY (CSRF)
● Cross-site request forgery (CSRF) is a technique that enables
attackers to impersonate a legitimate, trusted user.
● CSRF attacks can be used to change firewall settings, post
malicious data to forums, or conduct fraudulent transactions.
● In many cases, affected users and website owners are unaware
that an attack occurred, and become aware of it only after the
damage is done and recovery is not possible.
● CSRF attacks exploit a mechanism that makes the sign-in
process more convenient.
● Browsers often automatically include credentials in the request
when a user tries to access a site. These credentials can include
the user’s session cookies, basic authentication credentials, IP
address, and Windows domain credentials
31
EXAMPLE
Consider a user who wants to transfer an amount of $5,000 to a
family member via the web application of Acme Bank, which has
a CSRF vulnerability. An attacker identifies this vulnerability and
wants to intercept this transaction so that the funds are
transferred to their bank account instead of to the intended
recipient.

The attacker can construct two types of URLs to perform the

illicit funds transfer, depending on whether the application was
designed using GET or POST requests.

32
 CONTD.. TYPE 1-FORGED GET REQUEST
The original request would look like something like this, transferring the amount to
account #344344: GET [Link]
acct=344344&amount=5000 HTTP/1.1

The attacker’s forged request might look like this. The attacker changes the account
number to their own account (#224224 in this example) and increases the transfer
amount to $50,000: [Link]
acct=224224&amount=50000

Now the attacker needs to trick the victim into visiting this forged URL while signed
into the banking application. The attacker might draft an email like :

33
 CONTD.. TYPE 2- FORGED POST REQUEST
If the banking application uses POST requests, the user’s original operation would
look like this:

POST [Link] HTTP/1.1

acct=344344&amount=5000

In this case, the attacker would need to craft a <form> element with the forged
request:

<form action="[Link] method="POST">

<input type="hidden" name="acct" value="224224"/>
<input type="hidden" name="amount" value="50000"/>
<input type="submit" value="Click to get your free gift!"/>
</form>

When the user submits the form, believing they will receive a gift, the post request is
executed and, if the user is currently signed into the application, the illicit transfer is
carried out.
34
3. XML EXTERNAL ENTITY

● 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.
35
HOW DOES THIS ATTACK ARISES?
● 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.
36
 TYPES OF XXE ATTACKS:

● Exploiting XXE to retrieve files, where an external entity is defined

containing the contents of a file, and returned in the application's
response.
● Exploiting XXE to perform SSRF attacks, where an external entity is
defined based on a URL to a back-end system.
● Exploiting blind XXE exfiltrate data out-of-band, where sensitive
data is transmitted from the application server to a system that the
attacker controls.
● Exploiting blind XXE to retrieve data via error messages, where the
attacker can trigger a parsing error message containing sensitive 37

data.
[Link] ORIGIN RESOURCE
SHARING VULNERABILITY
● Cross-origin resource sharing (CORS) is a mechanism for
integrating applications.
● CORS defines a way for client web applications that are loaded
in one domain to interact with resources in a different domain.
● This is useful because complex applications often reference
third-party APIs and resources in their client-side code.
● For example, your application may use your browser to pull
videos from a video platform API, use fonts from a public font
library, or display weather data from a national weather database.
● CORS allows the client browser to check with the third-party
servers if the request is authorized before any data transfers.

38
 IMPORTANCE OF CORS
● In the past, when internet technologies were still new, cross-site
request forgery (CSRF) issues happened. These issues sent fake
client requests from the victim's browser to another application.
For example, the victim logged into their bank's application. Then they
were tricked into loading an external website on a new browser tab. The
external website then used the victim's cookie credentials and relayed
data to the bank application while pretending to be the victim.
Unauthorized users then had unintended access to the bank application.
To prevent such CSRF issues, all browsers now implement the same-
origin policy.

● Same-origin policy
Today, browsers enforce that clients can only send requests to a resource
with the same origin as the client's URL. The protocol, port, and
39
hostname of the client's URL should all match the server it requests.
HOW DOES IT WORK?
In standard internet communication, your browser sends an HTTP
request to the application server, receives data as an HTTP response,
and displays it. In browser terminology, the current browser URL is
called the current origin and the third-party URL is cross-origin.
When you make a cross-origin request, this is the request-response
process:
1. The browser adds an origin header to the request with information
about the current origin's protocol, host, and port
2. The server checks the current origin header and responds with the
requested data and an Access-Control-Allow-Origin header
3. The browser sees the access control request headers and shares
the returned data with the client application
Alternatively, if the server doesn’t want to allow cross-origin access, it40
responds with an error message.
 CORS VULNERABILITY
● It occur when a web application allows cross-domain requests
without proper validation of the origin. This can lead to an attacker
being able to perform unauthorized actions, such as stealing
sensitive information, through malicious JavaScript code executed on
the victim's browser. The root cause of this vulnerability lies in the
permissive access control policies implemented by the web
application.

● For instance, imagine that an application is designed to allow cross-

domain requests from any domain. A malicious actor could craft a
script to send a request to the application and then execute it from
their own domain. If the application doesn't properly validate the
origin of the request, it will allow the attacker's domain to access its
41
resources. This allows the attacker to exploit vulnerabilities and
potentially gain access to sensitive data.
 EXAMPLE
Let’s consider an example of a web application that uses cookies to authenticate
users. The application allows users to log in and access their profile information.
The profile information is stored on a different domain than the one hosting the login
page.

Assume that the login page is hosted on [Link] and the user’s
profile is hosted on [Link] The profile data is only accessible
after the user logs in and authenticates with the application.

Now, suppose that the application is configured to allow cross-origin requests from
any domain. An attacker can use a malicious website to exploit this vulnerability.
The malicious website can run a script that sends a request to the profile page,
passing the user’s cookies in the request. If the application doesn’t properly validate
the origin of the request, it will allow the attacker’s domain to access the user’s
profile data. This allows the attacker to steal sensitive data, such as session tokens
or user credentials 42
43
44
45
46
47
48
49
50