June 16, 2026
Cross-site scripting 5 (APPRENTICE)
Lab 7 - DOM XSS in jQuery anchor href attribute sink using location.search source.
Nadia
2 min read
Lab 7 - DOM XSS in jQuery anchor
hrefattribute sink usinglocation.searchsource.
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.Step 1: You need to click the orange button that says "Access the Lab" on the home page.
- Step 2: After clicking "Access the Lab," you'll be taken directly to the home page. Then, select "Submit Feedback" to fill out the feedback form. We also have the option to return to the previous page, but note that this has been built into the page it self it's not a browser back button, whose functionality we can control. This feature was added to the page by the developer, and obviously, its functionality is also controlled by the developer. So let' explore what they've done here.
First, we should inspect that back link. It's an anchor tag or hyperlink, if you prefer with the ID 'backlink', and it has the href attribute, which specifies where the link will take us. If we click it, we'll be navigated to '/', the site's home directory. The href attribute might be there because sometimes it's part of the original HTTP response from the server; in that case, there's really not much we can do to change it at least not if we want to execute arbitrary JavaScript. However, if we look at this script tag, we'll see that element was actually placed there by jQuery, which was manipulating the DOM after receiving the HTTP response from the server. So we have a function defined there, and it's presumably being executed immediately. If we look at the JavaScript code:
$(function() {
$('#backLink').attr("href", (new URLSearchParams(window.location.search)).get('returnPath'));
});
where jQuery retrieves the returnPath parameter value from the URL's 'location.search', then directly inserts that value into the 'href' attribute of the element. The absence of validation or sanitization is what makes it vulnerable to JavaScript URI injection. There is no validation or sanitization of the received input, making the application vulnerable to JavaScript: URI injection.
A URI (Uniform Resource Identifier) is an address identifier format recognized by browsers. One of its schemes is javascript, a browser-native scheme that instructs the browser not to open the URL but to execute the JavaScript code directly. An attacker exploits this by injecting malicious payloads such as 'javascript:alert(document.cookie)'. When the victim clicks the "Back" link, the browser reads the javascript scheme and immediately executes alert(document.cookie), displaying the victim's session cookie.
- Step 3: The next step is to inject the payload into the URL by modifying the URL in the browser's address bar to include the returnPath parameter containing the XSS payload: https://0a08006e042731178075948c001d00b3.web-security-academy.net/feedback?returnPath=javascript:alert(document.cookie). After changing the URL, the href attribute also changes to Back.
- Step 4: Once you click "Back" on the feedback page, the browser will process the request and display an alert containing the session cookie. The message "Congratulations, you solved the lab!" will appear, and the lab's status will change to "solved."