School of Information and Technology Engineering

Addis Ababa Institute of Technology

Addis Ababa University

Software Security Vulnerabilities Lab Report

PREPARED BY :

1, Biruk Worku ID : UGR/8359/13

2, Birhan Aschalew ID : UGR/9050/13

3, Natnael Dejene ID : UGR/4254/13

4, Rahel Solomon ID : UGR/9946/13

5, Yeabsra Aemro ID : UGR/5733/12

Submission Date: 07/08/2024

Submitted To: Dr. Seleshi
Introduction

This comprehensive lab report focuses on web application vulnerabilities and documents a series
of practical exercises aimed at exploring and gaining hands-on experience with different types of
vulnerabilities commonly found in web applications. By actively participating in these labs, we
had the opportunity to delve deeper into the understanding of these vulnerabilities, their potential
impact on web applications, and effective strategies to mitigate them. The objective of this report
is to provide a detailed overview of the lab series, including the methodology employed, the
results obtained, and the key takeaways derived from the exercises. Through this immersive
learning experience, we were able to enhance our knowledge and skills in web application
security, empowering us to make valuable contributions to the development of more secure web
applications

Objective
The primary objective of these lab exercises was to provide us with practical experience in
identifying, exploiting, and mitigating common web application vulnerabilities. By actively
engaging in these hands-on exercises, we were able to gain a deeper understanding of the risks
associated with these vulnerabilities and learn effective techniques for securing web applications.
The specific objectives of the lab series were to develop our ability to identify common
vulnerabilities in web applications, gain hands-on experience in exploiting these vulnerabilities
to understand their potential impact, learn and implement effective mitigation strategies, and
apply our knowledge and skills to real-world scenarios. Through these objectives, we aimed to
enhance our knowledge and skills in web application security, enabling us to contribute to the
development of more secure web applications and protect against potential threats
Lab: SQL injection vulnerability allowing login bypass
- Login as admin and also for password use admin then we get the error invalid
username or password so we call this a non-verbal generic error message. The reason
is that if we said that the username was invalid that means the attacker would be able
to enumerate the username on the system and so that’s a vulnerability on its own that
an invalid response it doesn’t tell which input vector is invalid.
- SELECT firstname FROM users where username=’ admin ’ and password=’admin’
- password=’admin’

- SELECT firstname FROM users where username=’ ’ ’ and password=’hbdv’

- When we put sql character into the username field and a random character for the password
the application reacts internal server error which means something happened at the back
end. So this is a good indication that vulnerable to SQL injection.

- SELECT firstname FROM usres where username=’ administrator - - ’ and

password=’adminshhakl’
- Then logged in
-We can see we are logged in page and the username is changed to administrator.
- We can see we are logged in page and successfully solved the lab.
Lab: Blind SQL injection with time delays
In this cheat sheet, we are going to fuzz the application with all the different payloads.

- First, select SELECT sleep(10) then we add in tracking id in burp suit and send and immediately
get the response; that it didn’t sleep 10 seconds. Even if we don’t put that the time it took to
respond is the same.
- Then remove that and add postgreSQL part SELECT pg_sleep(10) put into burp and send
it doesn’t sleep 10 sec still.
- we have an unclosed single quote and then we have got semicolon so we need to do is comment
out the rest of the query. So we did SELECT sleep(10) - -
But it doesn’t get 10 seconds of sleep.
- Next, we try in the above step SELECT pg_sleep(10) - - t
- So in this step, we see the delay in the response that is a 10-second time delay. so this is
vulnerable to SQL injection.
Lab: DOM XSS in innerHTML sink using source
location.search

Upon inspecting the Dev Tools Elements view after performing searching “hello”, a script was
discovered. The script is designed to update the content of an HTML element with the ID
"searchmessage" based on the provided query.

This is how the contents of <span id="searchMessage"> are set to “hello”.

The provided script analyzed the URL input to determine if a query parameter existed. If a query
parameter was present, it retrieved the HTML element with the ID "searchMessage" and updated
its content by setting the innerHTML property to the value of the query parameter. This allowed
the script to dynamically display the search query within the designated element.

Lab Solution
We wanted to trigger an alert() and could inject content into the page. And we tried the script:

hello<script>alert(1)</script>

The script tags appeared in the HTML but do not trigger an alert:
The above script did appear in the HTML but it did not show any alert, we needed another script
that was able to trigger an alert, an error-based script like:

<img src=x onerror=alert(1)>

When we used the above script which was error-based did trigger an alert.

Lab: CSRF where token validation depends on the request

method

During the analysis of the lab, it was observed that the email change functionality is vulnerable
to Cross-Site Request Forgery (CSRF) attacks. This report is intended to give an analysis of how
we attacked this vulnerability. The system had some
We accessed the first lab and logged into the test account using the given credentials wiener:
peter. Then, we navigated to My Account and noticed the Update email functionality.

Then updated the email to test@test.ca:

But there was an additional defense mechanism implemented by the CSRF token:
First, we tried to remove the CSRF token to check if we could bypass this CSRF protection, but
the request was not successful.

And then we tried to change the request method from POST to GET:
We were able to construct a CSRF payload using this information. We generated the following
exploit code with the form method GET and submitted it to the exploit server. The lab was
completed successfully!

Lab: URL-based access control can be circumvented

This website had an unauthenticated admin panel at /admin, but a front-end system has been
configured to block external access to that path. However, the back-end application is built on a
framework that supports the X-Original-URL header.

we attempted to access the admin panel from the front end by the given credentials, but we
encountered an “Access denied” error.
In the Repeater tool, we introduced a new header named "X-Original-header" with the value
"/admin" to bypass the admin panel. And, the GET request path was modified from "/admin" to
"/" to ensure that the manipulation took effect.

After implementing the header manipulation, we successfully accessed the admin panel.
However, we noticed the presence of a user named "Carlos." When attempting to delete "Carlos"
from the front-end, we encountered an "Access Denied" error. As a result, we had to adopt an
alternative approach.
Utilizing Burp Suite's Repeater module, we adapted the GET request path to
"/?username=carlos," and set the value of "X-Original-header" to "/delete/admin." Following the
user deletion request, we achieved success. "Carlos" was successfully deleted, and we were able
to secure access to the admin panel, thus accomplishing our ultimate goal.