Reflected XSS into HTML context with nothing encoded
This is the first in a series of labs from PortSwigger Web Security Academy that deal with Cross Site Scripting, or XSS. Reflected XSS involves injecting malicious executable code into a vulnerable webpage. The injected script, in a search query for example, is reflected off the web server as the search result.
In this lab you are brought to a simple blog page with several posts and a search bar.
First, let’s test the search bar. Type in any search query. However, it should be a string of random letters and numbers. At least something you know will not return any search results.
When you click search, you should notice your search query, in full, returned back on the page.
Next, we can test to see if the site will accept special characters in the search. Adding <h1></h1> tags around your query should tell us what we need to know. Type the new query into the search bar
Notice your query is on a new line. Next, let’s see what’s happening behind the web page. Right click on or near your search result. SELECT Inspect(Q) from the drop-down. Your search query should be highlighted, but the <h1></h1> tags are also included!
That should not happen. All input from users, especially any special characters, should be sanitized and encoded on the back-end of the website.
To solve the lab, we need to perform a cross-site scripting attack that calls the alert function. To do that we need a simple JavaScript payload to use. <script>alert(document.cookie)</script> should do the trick. This simple script is broken down like this:
- <script></script> — HTML script tags that define a block of JavaScript code to be executed by the browser.
- alert — JavaScript method that opens a pop-up window.
- (document.cookie) — JavaScript expression that displays the cookies associated with the current document.
Enter your payload into the search bar.
A pop-up alert window should now be visible. Congratulations! You have just solved the first XSS lab!
The basic way a reflected XSS attack could be used would be for an attacker to send an infected link to a user in an email or text (i.e. https://some.domain.com/?search=<script>*…malicious_code…*</script>). The user will click on the infected link and the their browser will execute the malicious code. Usually not a simple pop-up to say hello. The malicious script can access any cookies, session tokens, or other sensitive information.
For more information please visit the following sites:
