0% found this document useful (0 votes)
31 views9 pages

Int 244 Ca 3

Uploaded by

bgmimrnani3110
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
31 views9 pages

Int 244 Ca 3

Uploaded by

bgmimrnani3110
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 9

2)CSRF Practical Report

Objective

The objective of this practical is to demonstrate how a Cross-Site Request Forgery (CSRF) attack
works and how to secure a web application against it. CSRF exploits the trust that a website has in
the user's browser, tricking the user into making an unintended request, such as changing a
password, without their consent.

Setup

1. Vulnerable Web Application: A basic web application is set up that allows a user to change
their password. However, the application is intentionally left vulnerable to CSRF because it
does not include a mechanism to verify the authenticity of requests made to it.

2. Malicious Attacker Page: A page is created that mimics the vulnerable application’s form.
This malicious page tricks the user into submitting a password change request by submitting
a form in the background when the user interacts with the page. The attacker can specify a
new password without the user's knowledge.

Step 1: Creating a Vulnerable Web Application

The vulnerable web application allows users to change their password via a simple form. This form
submits the new password to the server without any kind of authentication to verify that the request
is legitimate. This makes the web application vulnerable to CSRF attacks.

Step 2: Creating the Malicious CSRF Attack Page

The attacker creates a malicious web page containing a hidden form that submits a request to
change the user’s password. When the user visits this page, the attacker can trigger a password
change without the user knowing, simply by having them click a button or visit the page.

The attack works because the web application doesn't check whether the request is coming from the
legitimate user or from an external source. The attacker can craft a form on their page that silently
sends a request to change the password, exploiting the user's logged-in session on the vulnerable
website.

Step 3: Securing the Web Application with CSRF Protection

To prevent CSRF attacks, we implement a CSRF token in the web application. This token is a unique,
random string generated by the server each time a user loads the page. The token is embedded in
the form, and when the form is submitted, the server checks that the token sent with the request
matches the one generated and stored on the server side.

If the tokens don't match, the server knows the request is potentially malicious and denies it. This
ensures that only legitimate requests from the user, who initially loaded the form and was given the
token, can be processed.
Testing the CSRF Vulnerability and Protection

1. Test Vulnerability:

o When the vulnerable application is used without CSRF protection, the attacker’s
malicious page can successfully change the password without the user’s consent, as
it can submit a form on behalf of the user.

2. Test CSRF Protection:

o After implementing CSRF protection, the attacker’s page will be blocked from making
the request, as the token validation will fail. The server will reject any request that
doesn't contain a valid token, thus preventing the CSRF attack.

Conclusion

CSRF Attack:

 Vulnerability: The web application initially lacked any mechanism to authenticate requests,
making it vulnerable to CSRF.

 Exploit: The attacker created a page that could silently submit a password change form on
behalf of the logged-in user, changing the user's password without their consent.

Solution:

 CSRF Token: The application is protected by implementing a CSRF token, which is checked on
the server side with every form submission. This ensures that requests are coming from
legitimate users and not from malicious external sources.

Steps to Secure Against CSRF:

1. Generate a Unique Token: Generate a random token for every form or session.

2. Include the Token in Forms: Embed the token in the form as a hidden input field.

3. Verify the Token on Submission: The server should verify the token on each form submission
and reject any requests where the token doesn't match the expected value.

Implementing CSRF protection significantly enhances the security of web applications by ensuring
that only authorized actions are performed by the user.
Password Cracking with John the Ripper
Objective:
The objective of this practical is to demonstrate how to crack a password-protected file using John
the Ripper.

Setup:
A sample password-protected ZIP file is provided for this task. The file can be downloaded from the
given link.

Process Overview:

1. Download the ZIP File:


First, download the password-protected ZIP file from the shared Google Drive folder.

2. Extract Password Hash Using ZIP2John:


Use the ZIP2John utility (part of John the Ripper) to extract the password hash from the ZIP
file.

3. Crack the Password Using John the Ripper:


Once the hash is extracted, John the Ripper is used to attempt to crack the password. The
tool employs various password-cracking techniques, such as dictionary attacks and brute-
force methods.

4. Monitor Progress and Retrieve the Password:


John the Ripper will output the progress of the cracking attempt and, if successful, will reveal
the cracked password.

5. Time Taken to Crack the Password:


The time taken for the cracking process depends on the complexity of the password and the
system's processing power. It can vary from a few minutes to several hours.

Conclusion:
This exercise demonstrates how John the Ripper can be used to crack password-protected files. The
effectiveness and speed of cracking depend on factors like password complexity and available
computational resources.

You might also like