Penetration Testing with Kali Linux OffSec

Target
tab and then 
Site 
map
. We can then retrieve the entire map of the paths we have been testing so far. 
Figure 110: Using the Site Map to organize API testing 
From Burp’s Site map, we can track the API we discovered and forward any saved request to the 
Repeater or Intruder for further testing. 
In this Learning Unit, we explored how to debug web applications through the web browser 
console and network developer tools. We then learned what REST APIs are, their role in web 
applications, and how we can approach a black-box penetration test to find weaknesses and 
abuse them. 
In the next Learning Unit, we are going to learn about one of the most poplar and widespread 
vulnerabilities that affects web applications, Cross-Site Scripting. 

---

Penetration Testing with Kali Linux
PWK - Copyright © 2023 OffSec Services Limited. All rights reserved. 
233 
8.4
Cross-Site Scripting 
This Learning Unit covers the following Learning Objectives: 
•
Understand Cross-Site Scripting vulnerability types 
•
Exploit basic Cross-Site Scripting 
•
Perform Privilege Escalation via Cross-Site Scripting 
One of the most important features of a well-defended web application is 
data sanitization
,
358
a 
process in which user input is processed so that all dangerous characters or strings are removed 
or transformed. Unsanitized data allows an attacker to inject, and potentially execute, malicious 
code. 
Cross-Site Scripting
(XSS)
359
is a vulnerability that exploits a user’s trust in a website by 
dynamically injecting content into the page rendered by the user’s browser. 
Once thought to be a relatively low-risk vulnerability, XSS today is both high-risk and prevalent, 
allowing attackers to inject client-side scripts, such as JavaScript, into web pages visited by other 
users. 
8.4.1
Stored vs Reflected XSS Theory 
XSS vulnerabilities can be grouped into two major classes: 
stored
360
or 
reflected
.
361
Stored XSS attacks
, also known as 
Persistent XSS
, occur when the exploit payload is stored in a 
database or otherwise cached by a server. The web application then retrieves this payload and 
displays it to anyone who visits a vulnerable page. A single Stored XSS vulnerability can therefore 
attack all site users. Stored XSS vulnerabilities often exist in forum software, especially in 
comment sections, in product reviews, or wherever user content can be stored and reviewed 
later. 
Reflected XSS attacks
usually include the payload in a crafted request or link. The web application 
takes this value and places it into the page content. This XSS variant only attacks the person 
submitting the request or visiting the link. Reflected XSS vulnerabilities can often occur in search 
fields and results, as well as anywhere user input is included in error messages. 
Either of these two vulnerability variants can manifest as client- (browser) or server-side; they can 
also be 
DOM-based
. 
DOM-based XSS
362
takes place solely within the page’s 
Document Object Model
(DOM).
363
While 
we won’t cover too much detail for now, we should know that browsers parse a page’s HTML 
content and then generate an internal DOM representation. This type of XSS occurs when a 
page’s DOM is modified with user-controlled values. DOM-based XSS can be stored or reflected; 
358
(Wikipedia, 2022), https://en.wikipedia.org/wiki/Data_validation 
359
(OWASP Foundation, Inc, 2022), https://owasp.org/www-community/attacks/xss/ 
360
(Wikipedia, 2022), https://en.wikipedia.org/wiki/Cross-site_scripting#Persistent_(or_stored) 
361
(Wikipedia, 2022), https://en.wikipedia.org/wiki/Cross-site_scripting#Non-persistent_(reflected) 
362
(Wikipedia, 2022), https://en.wikipedia.org/wiki/Cross-site_scripting#Server-side_versus_DOM-based_vulnerabilities 
363
(Mozilla, 2022), https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction 

---

Penetration Testing with Kali Linux
PWK - Copyright © 2023 OffSec Services Limited. All rights reserved. 
234 
the key is that DOM-based XSS attacks occur when a browser parses the page’s content and 
inserted JavaScript is executed. 
No matter how the XSS payload is delivered and executed, the injected scripts run under the 
context of the user visiting the affected page. This means that the user’s browser, not the web 
application, executes the XSS payload. These attacks can be nevertheless significant, with 
impacts including session hijacking, forced redirection to malicious pages, execution of local 
applications as that user, or even trojanized web applications. In the following sections, we will 
explore some of these attacks. 
8.4.2
JavaScript Refresher 
JavaScript is a high-level programming language that has become one of the main components 
of modern web applications. All modern browsers include a JavaScript engine that runs 
JavaScript code from within the browser itself. 
When a browser processes a server’s HTTP response containing HTML, the browser creates a 
DOM tree and renders it. The DOM is comprised of all forms, inputs, images, etc. related to the 
web page. 
JavaScript’s role is to access and modify the page’s DOM, resulting in a more interactive user 
experience. From an attacker’s perspective, this also means that if we can inject JavaScript code 
into the application, we can access and modify the page’s DOM. With access to the DOM, we can 
redirect login forms, extract passwords, and steal session cookies. 
Like many other programming languages, JavaScript can combine a set of instructions into a 
function.
364
function multiplyValues(x,y) { 
return x * y; 
} 
let a = multiplyValues(3, 5) 
console.log(a)