Labs Covered
This write-up includes the following PRACTITIONER-level labs:
5 Low-level logic flaw
This lab shows how attackers can exploit detailed flaws in application logic to bypass intended restrictions or gain unauthorized access.
6 Inconsistent handling of exceptional input
This lab demonstrates how inconsistent validation of unusual or unexpected input can be exploited by attackers.
7 Weak isolation on dual-use endpoint
This lab shows how endpoints that serve multiple purposes without proper isolation can be abused by attackers.
8 Insufficient workflow validation
This lab demonstrates how flaws in validating user workflows can be used to bypass business logic controls.
9 Authentication bypass via flawed state machine
This lab shows how attackers can exploit weaknesses in state management to bypass authentication mechanisms.
10 Infinite money logic flaw
This lab demonstrates how logical flaws in financial transaction systems can allow attackers to generate infinite funds.
11 Authentication bypass via encryption oracle
This lab shows how attackers can abuse encryption oracles to bypass authentication mechanisms.
LAB 5 - Low-level logic flaw
Lab Description :
Solution :
Add an item to the shopping cart; at this point, the maximum quantity is set to 99
🔄 Null Payloads for Repeated Requests
This enables you to generate payloads whose value is an empty string. You can use this to repeatedly issue the base request unmodified — you don’t need to configure payload positions.
You can use this payload type for a variety of attacks, for example:
- Harvesting cookies for sequencing analysis
- Repeating logic-based requests for cumulative effects
🧪 Example Attack Scenario
Now, we will send the value 99 again and again so that the quantity value becomes negative due to flawed backend handling.
In Burp Suite Intruder:
- Set Payload type to:
Null payloads - Set Attack type to:
Sniper(or suitable mode) - Set Payload setting to Continue Indefinitely:
This will cause the base request (with quantity = 99) to be sent repeatedly, exploiting logic flaws in the server’s price calculation or stock handling.
Refresh the shopping cart and observe that the price has become negative:
Next, adjust the quantity to precisely control the amount between 0 and 100 or how you like.
LAB 6 - Inconsistent handling of exceptional input
Lab Description :
Solution :
Finding Admin Panel
First, you need to locate the URI of the admin panel to delete the user “carlos.”
Go to Target -> Sitemap.
Right-click on the lab domain.
Select Engagement tools -> Discover content to find available pages and directories on the website.
When we try to browse to /admin, it says only persons belonging to DontWannaCry company can access this page.
Account Registration
Go to the registration page to create an account with the email ID given to us:
attacker@exploit-0ab1009903bcf40b8008753f01b300db.exploit-server.net
On the registration page, it is mentioned that we can use @dontwannacry.com if we are an employee of that company.
Create an account with very long email address ending with @exploit-0ab1009903bcf40b8008753f01b300db.exploit-server.net.
Example - very-long-string@YOUR-EMAIL-ID.web-security-academy.net
NOTE - The very-long-string should be at least 200 characters long.
So I created an account with a very long string - aafafasighfiyuqabryuawgfibasifnkajsdbgiuafgijaeboifnaijfaokjfiuahfjiahgr90ipqjro89sygfduygsfdtuvdtGUYEDFGWYTDVUYVDuyGDUYucvuavcuyvauyvdfuaycvuayvcuyasvcuyavcuyavcuucauvcuayvclu2o3i1hri97uuc89273r89hiug987niuch89qn397yr89hiu7ay89qah45uiyr0q@exploit-0ab1009903bcf40b8008753f01b300db.exploit-server.net
After completing the registration, a confirmation email is received.
Clicking the link in the email completes the registration successfully.
Login and Email Truncation
Now, log in as the user using the credentials we created:
` Username: test1 Password: 1234 `
Once logged in, we receive a welcome message. However, it’s important to note that the email address was truncated to 255 characters, as shown below:
aafafasighfiyuqabryuawgfibasifnkajsdbgiuafgijaeboifnaijfaokjfiuahfjiahgr90ipqjro89sygfduygsfdtuvdtGUYEDFGWYTDVUYVDuyGDUYucvuavcuyvauyvdfuaycvuayvcuyasvcuyavcuyavcuucauvcuayvclu2o3i1hri97uuc89273r89hiug987niuch89qn397yr89hiu7ay89qah45uiyr0q@exploit-0ab1009
This indicates that the backend is enforcing a maximum character limit (likely 255) for email addresses, possibly truncating values at the database or application level.
KEY INFORMATION TO NOTE
- Total characters in original email used to register an account:
299 characters - Total characters in email after signing in:
255 characters
Register an Account with @dontwannacry.com
Taking note of the email truncation behavior, we can exploit this logic by registering an account with an email address that is:
- Longer than 255 characters
- Ends in our controlled domain
- But when truncated at 255 characters, the visible portion ends with:
The email id to be used now is
aaafasighfiyuqabryuawgfibasifnkajsdbgiuafgijaeboifnaijfaokjfiuahfjiahgr90ipqjro89sygfduygsfdtuvdtGUYEDFGWYTDVUYVDuyGDUYucvuavcuyvauyvdfuaycvuayvcuyasvcuyavcuyavcuucauvcuayvclu2o3i1hri97uuc89273r89hiug987niuch89qn397yr89hiu7ay89qah45uiyr0q@dontwannacry.com.exploit-0ab1009903bcf40b8008753f01b300db.exploit-server.net
Create an account with the above email-id
In the email inbox, click on the link to confirm registration.
Now finally when we log in, we can see that after truncation, our email address ends with @dontwannacry.com.
We can now access the admin panel at /admin.
LAB 7 - Weak isolation on dual-use endpoint
Solution :
The lab description says that user’s privilege level based on their input. So by somehow abusing this logic flaw we need to gain admin privileges.
Login as wiener using the credentials provided.
As expected since weiner is a normal user, he is not allowed to access the /admin panel.
Logic flaw in password change functionality -
When we enter current password and old password to change the password of a user, the following POST request is sent to/my-account/change-password endpoint.
So as per this lab’s overview, we can try to remove a parameter/remove a parameter and value & see if anything wierd happens.
In the above request to change the password, we can see that the password change happens for the username that is being provided.
This is typically dangerous since in the password change functionality, if it is dependant on the username then an attacker can try to enter the username as admin & change the password.
Removing the ¤t-password= parameter -
When we remove the ¤t-password= parameter, notice that the server accepts the request and changes the password of wiener.
csrf=hDmgDzvRuQsMkrIMeamKQa2NiAjlViHD&username=wiener&new-password-1=1212&new-password-2=1212
Resetting admin’s password -
So this time we use this logic flaw to reset the password of administrator user.
In the form fill the username as administrator, and remove the ¤t-password= parameter.
The POST request now looks like this .
And we’ve finally changed/resetted the password of admin user.We can login as admin now using the password we just set.
Go to the admin panel & delete the user carlos to solve the lab.
LAB 8 - Insufficient workflow validation
Lab Description :
Solution :
So we need to abuse the flawed workflow while ordering a product to solve this lab.
Workflow
- First login as wiener .Click on the leather jacket product & add the item to cart.
The following request is sent.
POST /cart HTTP/1.1
Host:aef00b5046c7a4b83d0e156009e00ca. web-security-academy.net
Cookie: session=342CZuircwtnZmoAaSNwDSwpbsUL77uP
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 36
Origin: https://aef00b5046c7a4b83d0e156009e00ca. web-security-academy.net
Referer: https://aef00b5046c7a4b83d0e156009e00ca. web-security-academy.net/product?productId=1
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close
productId=1&redir=PRODUCT&quantity=1
In the cart page, we can see that the product is added & we can now place the order.
- When we place the order the following POST request is sent to
/cart/checkout.
POST /cart/checkout HTTP/2
Host: aef00b5046c7a4b83d0e156009e00ca. web-security-academy.net
Cookie: session=FrFZmMsVa1rg3dwRExGgltBTD0gijy4m
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 37
Origin: https://aef00b5046c7a4b83d0e156009e00ca. web-security-academy.net
Referer: https://aef00b5046c7a4b83d0e156009e00ca. web-security-academy.net/cart
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
csrf=viHBF1tw4OTvvpMH8ukIZ9TjfivZqcew
Case 1 - [ product_value > store_credit ]
But then we can’t buy the jacket($1337) since we have only $100.
Case 2 - [ product_value < store_credit ]
We repeat the same process again but this time we add a product that costs less than $100.
This time when we place the order, we have another request being sent after /cart/checkout which is a GET request to /cart/order-confirmation
Abusing flawed workflow logic -
Thinking from an attacker’s perspective, we can add any costly product, in our case the leather jacket & just resend the GET request to /cart/order-confirmation endpoint with parameter ?order-confirmation=true to place an order wihtout going through the intended workflow.
By this way we’re abusing the flawed workflow mechanism since the server doesn’t validate the workflow properly.
Now to solve the lab perform the following steps.
- Add the leather jacket to cart (can also add n number of jackets as our wish).
- Send GET request to /cart/order-confirmation.
Refresh the page to confirm that the lab is solved.
LAB 9 - Authentication bypass via flawed state machine
Lab Description :
Solution :
We need to exploit the flawed workflow validation to login as administrator & delete the user carlos.
Using the content discovery tool in burpsuiter, we find that the admin directory is at /admin.
- Enter the given credentials for wiener and login.
- The following is the follow-up GET request made to /role-selector , which fetches the page to select the role which we want.
GET /role-selector HTTP/2
Now we’re presented with this page where we can select a role for the user.
- On selecting a role , the following request is sent.
POST /role-selector HTTP/2
role=user&csrf=wuxcQYkIOd5GkUbiEFaHIKkEAbIakcip
Abusing flawed workflow logic -
Thinking from an attacker’s perspective, we can try to just drop the GET request made to /role-selector and see what role we are assigned by default.
After dropping that particular request, we now see a link to Admin panel at the top right side.
This means that by default the application assigns administrator privileges to the user unless he specifies any role of his choice!.
Go to the admin panel and delete the user carlos to solve the lab.
LAB 10 - Infinite money logic flaw
Lab Description :
Solution :
Log in as wiener.
When we scroll down all the products in the home page, we can see that there is a signup feature.
When we signup, then site gives us a coupon code.
In the home page, we have a product called gift card. Add it to cart
Now in the cart section add the coupon SIGNUP30 to avail discount.
Once we place the order, we get a code to redeem.
Paste the coupon in the redeem section available at My-Account page to redeem some credits .
Now we got extra $3 dollars to our store credit.
Summary of the steps -
- Login as wiener .
- Signup for newsletter to get a discount coupon - SIGNUP30.
- Add Gift card product to cart .
- Apply SIGNUP30 coupon .
- Place the order to get a Gift coupon.
- Redeem the coupon in My-Account page to get $3 dollars.
On repeating this process again and again, we can gain more and more credits which will help us to buy the leet leather jacket. In order to automate this multi step process, we use macros feature in burp.
Automate the multi step process using macros -
Go to Project options > "Sessions.
In the Session handling rules panel, click Add. The Session handling rule editor dialog opens.
In the dialog, go to the Scope tab. Under URL Scope, select Include all URLs.
Go back to the Details tab. Under Rule actions, click Add > Run a macro.
Under Select macro, click Add again to open the Macro Recorder.
Select the following sequence of requests:
POST /cart
POST /cart/coupon
POST /cart/checkout
GET /cart/order-confirmation?order-confirmed=true
POST /gift-card
- In the list of requests, select
GET /cart/order-confirmation?order-confirmed=true. ClickConfigure item. In the dialog that opens, clickAddto create a custom parameter.
Name the parameter gift-card and highlight the gift card code at the bottom of the response.
- Select the
POST /gift-cardrequest and clickConfigure itemagain. In theParameter handlingsection, use the drop-down menus to specify that the gift-card parameter should be derived from the prior response (response 4). ClickOK.
- In the Macro Editor, click
Test macro. Look at the response toGET /cart/order-confirmation?order-confirmation=trueand note the gift card code that was generated. Look at thePOST /gift-card request. Make sure that the gift-card parameter matches and confirm that it received a 302 response. Keep clicking “OK” until you get back to the main Burp window.
-
Send the
GET /my-accountrequest to Burp Intruder. Use theSniperattack type. -
On the “Payloads” tab, select the payload type
Null payloads. Under “Payload settings”, choose to generate 420 payloads.
Now start the attack. It takes some time to run.
Once completed, we see that we have $1427 credits.
Now we can buy the leet jacket & solve the lab.
LAB 11 - Authentication bypass via encryption oracle
Lab Description :
Email Address Parsing Discrepancies
Complexity of Parsing Email Addresses
Email address parsing is inherently complex due to the diverse ways email addresses can be structured according to RFC standards.
Applications often need to extract domains from email addresses to determine the organization or to apply specific rules, which can lead to inconsistencies if not handled uniformly.
Exploitation Through Encoding
Attackers can use various encoding techniques to manipulate email addresses in a way that bypasses initial validation but causes discrepancies in parsing logic.
Common techniques include using different forms of encoding (e.g., URL encoding, Unicode) or leveraging rarely used syntax elements in email addresses.
Impact of Discrepancies
When discrepancies exist, attackers can exploit them to register accounts with email addresses that are technically valid but bypass intended restrictions.
This can lead to unauthorized access to parts of the application meant for specific users or roles, such as admin panels or restricted areas.
Example Exploits
An attacker might use an email address that appears to belong to a legitimate domain but includes encoded characters or subdomains that are not properly handled by the application.
This could allow the attacker to gain access to features or functionalities they should not be able to use.
Basic Structure
An email address is generally structured as:
local-part@domain
local-partis the part before the@.domainis the part after the@.
Example 1: "@"@example.com
Explanation:
Here, the local-part of the email address is "@", which is enclosed in quotes. According to RFC 5322, when the local-part is quoted, special characters such as @ are considered literal characters within the quotes. Thus, the email address is effectively:
@example.com
Example 2: "\"\"\""@example.com
Explanation:
In this example, the local-part is "\"\"\"". To include double quotes within a quoted local-part, each double quote must be escaped with a backslash. Therefore, the local-part is interpreted as a literal string containing escaped double quotes, and the email address is effectively:
@example.com
Comments
- Comments are enclosed in parentheses
()and can appear anywhere outside of the local-part. - They are used for annotations and should not affect the interpretation of the address.
Example:
(comment)user@(comment)example.com
This is a valid email address.
- Comments can include spaces and can be nested.
Potential for Confusion
- The combination of quotes, escaping, and comments can indeed be used to create complex and potentially confusing email addresses.
- This can be exploited in scenarios where email parsers or validators might not handle these cases consistently.
Solution :
In the login function, the web application is used stay logged into save user cookies.
A stay-logged-in is base64 cookie and added to the request. However, when decoding, it seems to have been encrypted first.
On the other hand, each post has a comment function. And when we leave an a123 invalid email like below:
Notification Cookie Analysis
The application then reports a line: Invalid email address: a123
and includes a notification Base64 cookie.
Decode it and observe that it is also encrypted.
We can infer (i.e., guess) that:
- The content of the
notificationcookie is the Base64 of the string
Invalid email address: a123 after being encoded. - The encryption algorithm used for
notificationis the same as used for stay-logged-in.
With a value “a” in this notification cookie cookie we generate an internal server error:
With a base64-encoded value “YQ==” we see information about the encryption. It looks it uses padded cipher and blocks of 16 bytes, so it could be AES-128:
We will verify by taking the value stay-logged-in of nofitication.
The results show that the content of stay-logged-in is username:timestamp.
Now, we need to create a value stay-logged-in for administrator or based on the encoding of the field notification. And since notificationit is created through the field email, we will pass the payload at email. We will pass it **administrator:
The message can be seen Invalid email address: administrator:1672593998338 with notification its base64 encoded form value of administrator:1672593998338. To do that, take the notification current value, decode the URL+base64 and remove the first 23 bytes.
Info:
After deleting the above 23 bytes, perform base64 encoding + URL encoding to pass into the cookie notification to see if it has been cut successfully: O3tEa1GHAnSumMNJYUyeNZmLguHpQlzLaC+N7hZEpoujFylp6tXe1Fc%3d. The result of the ciphertext message in notification must be a multiple of 16. I can guess the encryption algorithm for each block of 16 bytes.
So I need to insert any 9 bytes first to combine with the above 23 bytes into 32 bytes to delete.
Knowing it uses 16-bytes blocks and there is a prefix of 23 characters (“Invalid email address: “), we will add 9 characters of ”padding” in that second ciphered block:
We will take the encrypted value, URL-decode and base64-decode it, and delete the first 2 16-bytes blocks:
bRmw%2bImnDFvvwECQSiG1J8dfoUcrqKgkyQfr8wfI1J9bRCG%2bSLS06HPtXsMPhzuBQTkxD8oSxM2l3LhRCdZ3IQ%3d%3d
bRmw+ImnDFvvwECQSiG1J8dfoUcrqKgkyQfr8wfI1J9bRCG+SLS06HPtXsMPhzuBQTkxD8oSxM2l3LhRCdZ3IQ==
...
W0Qhvki0tOhz7V7DD4c7gUE5MQ/KEsTNpdy4UQnWdyE=
W0Qhvki0tOhz7V7DD4c7gUE5MQ/KEsTNpdy4UQnWdyE%3d
First we will set the value “W0Qhvki0tOhz7V7DD4c7gUE5MQ/KEsTNpdy4UQnWdyE%3d” for the “notification” cookie to check it is decrypted correctly:
We can delete the “session” cookie and use this value to log in:
GET /my-account?id=administrator HTTP/2
...
Cookie: stay-logged-in=W0Qhvki0tOhz7V7DD4c7gUE5MQ%2fKEsTNpdy4UQnWdyE%3d
…
And then delete the user and lab is solved: