Application Discovery
In order to discover exposed endpoints, we’ll first visit the application home page and observe the additional endpoints that the application reaches out to in order to generate the page.
While it might be tempting to ignore directories that contain images, CSS, and JavaScript, they might leave clues as to how the application works. Each and every clue has potential value during a black box assessment.
Client-Side JavaScript Dist Folder
When a JavaScript library is successfully built, the output files are typically written to a dist (or public) subdirectory. During the build process, the necessary files are typically minified, unnecessary files removed, and the resulting .js library can be distributed and ultimately imported into an application.
However, the existence of a dist directory suggests that the application developer included the entire directory instead of just the .js library file. Any unnecessary files in this directory could expand our attack surface.
Trending Towards Webpack
- JavaScript-heavy applications are trending towards using a bundler like webpack and a package manager like Node Package Manager(npm) instead of manual distribution methods.
- This type of workflow streamlines development and may ensure that only the proper files are distributed.
Introducing Client-side Vulnerabilities via Libraries
- Server-side executable files (such as .php) are rarely included in vendor libraries, meaning this may not be the best location to begin hunting for SQL injection or RCE vulnerabilities.
- However, the libraries may contain HTML files that could introduce reflected cross-site scripting (XSS) vulnerabilities.
- Since these “extra files” are typically less-scrutinized than other deliberately-exposed files and endpoints, we should investigate further.
- Since these HTML files are not dynamically generated by a server, traditional reflected XSS and stored XSS won’t work since user-supplied data cannot be appended to the HTML files.
===================================================================================
What is DOM-based XSS?
What is the DOM?
- When a browser interprets an HTML page, it must render the individual HTML elements.
- The rendering creates objects of each element for display.
- HTML elements like div can contain other HTML elements like h1. When parsed by a browser, the div object is created and contains a h1 object as the child node.
- The hierarchical tree created by the objects that represent the individual HTML elements make up the Document Object Model.
- The HTML elements can be identified by id, class, tag name, and other identifiers that propagate to the objects in the DOM.
- Browsers generate a DOM from HTML so they can enable programmatic manipulation of a page via JavaScript. Developers may use JavaScript to manipulate the DOM for background tasks, UI changes, etc, all from the client’s browser. While the dynamic changes could be done on the server side by dynamically generating the HTML and sending it back to the user, this adds a significant delay to the application.
- For this manipulation to occur, JavaScript implements the Document interface.
- To query for an object on the DOM, the document interface implements APIs like getElementById, getElementsByClassName, and getElementsByTagName. The objects that are returned from the query inherit from the Element base class.
- The Element class contains properties like innerHTML to manipulate the content within the HTML element. The Document interface allows for direct writing to the DOM via the write() method.
- DOM-based XSS can occur if unsanitized user input is provided to a property, like innerHTML or a method like write().
<!DOCTYPE html>
<html>
<head>
<script>
const queryString = location.search; // from URL
const urlParams = new URLSearchParams(queryString);
const name = urlParams.get('name') // from URL 'name' parameter
document.write('<h1>Hello, ' + name + '!</h1>'); // directly written to DOM
</script>
</head>
</html>
==============================================================================
Creating a database for exploitation of DOM XSS
- A login page will make the XSS page look more realistic, but it isn’t very useful in furthering exploitation.
- Before we devise a method of sending and receiving content from the victim, we will need a system of capturing and storing data (either user input or data obtained from the victims’ session). To store data, we will use a SQLite database.
- We will start by creating a script to initialize the database and provide functions to insert data. The database script should be able to be run from the command line.
- In addition, both the API server and script to dump the database should be able to import the functions from the database script. Allowing the script to be imported will make our code reusable and more organized.