Welcome to my introduction to cross-site scripting (XSS), including the basics, the methodology, the dangers and mitigations against XSS attacks. Lets jump right in!
What is XSS?
Cross-site scripting or
XSS, is a vulnerability which allows an attacker to inject & execute malicious code, usually
- The application is reflecting some unsanitized data that it received through a parameter/header/cookie etc. directly in the response
- Attack requires the victim to click on a link. i.e
https://realsite.com/?search=<img src=x onerror=alert(document.cookie)
- When the victim clicks the link, the vulnerable application will execute the payload in the victim's context because the value passed to the
searchparam is being echoed back in the body of the response unsanitized, in the example above the application will try to render an image that does not exist, and thanks to
htmlI can execute
onerrorevent handler, since
document.cookiewe can put it in an
alertprompt for testing.
- The unsanitized data can be saved somewhere in the application's database, for example in an application that contains a profile with an editable bio section, if the user's input is not being properly sanitized an attacker might be able to submit
"><script>prompt</script>in their "bio" and save it, this specific string if left unsanitzed will execute
- This type of
xssis for the most part considered of higher severity than
stored xssdoes not need user interaction to execute, the victim simply has to visit the page for the malicious code to run.
DOM XSSis a bit different, the attack takes advantage of client side
- If the application is using the
URI fragmentto pass down data to the application which is sometimes used by developer to maintain application state, our payload might be able to achieve execution, in the example below the
URI fragmentis being used somewhere in code which then gets written to the
DOMand since this is a script it will execute the
XSS requires a good understanding on how an application responds to unsafe input. Testing all inputs is essential to understanding how the application behaves, sometimes developers forget to sanitize all
API endpoints so always look at an application well and gather as much information as possible, check
xss, I usually try to see if I can inject the following payload first:
"'/><h1>test</h1 // this payload will close the tag before it and start a new tag
This will answer some assumptions about the application I am testing:
- Is the application sanitizing dangerous characters(/,<,>,",')?
- Does the application render the payload?
The process can be done regardless of the type of
xss I am looking for, the main takeaway is seeing what is being echoed back in the body of the response, if I can get the application to render the
html I submitted the next thing to check is if I can execute
Evaluating the impact of
xss like other vulnerabilities comes down to where the vulnerability is in the application and how hard it is to fire an attack.
Reflected xss is typically lower than
stored xss since the latter does not require any interaction, while
reflected xss needs the victim to click a link sent by an attacker - this might be done using phishing techniques.
Account Hijacking - If the attacker is able to steal the victim's cookies the attacker might be able to hijack the session by impersonating the victim.
Defacement - If the attacker can inject
DOM is possible, also if just
html injection is achieved this also applies
Information Disclosure - If sensitive information is stored in clientside
If we only break stuff it means we are only doing half of our job, we also have to provide ways to mitigate the vulnerability.
xss developers should:
- Identify all places user provided input is used in the application
- Escape characters that will allow injection such as
- Output should be encoded everywhere user input is displayed
- Filter and validate user input as strictly as possible
HTTPheaders to your advantage including
Content Secure Policyto restrict access to sources such as external scripts