introduction to cross-site scripting(xss), basics, methodology, dangers & mitigations
This was written as part of my application to SecAppDev 2020 which got cancelled due to the current pandemic
What is XSS?
Cross-site scripting or XSS, is a vulnerability which allows an attacker to inject & execute malicious code, usually javascript, into an application under the victim's context, it is listed under the OWASP Top 10 Vulnerabilities as #7, some popular types of XSS are:
-
reflected- The application is reflecting some unsanitized data that it received through a parameter 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 tohtmlI can executeJavaScriptby using theonerrorevent handler, sinceJavaScripthas access to thedocument.cookiewe can put it in analertprompt for testing.
-
stored- 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 executeJavaScripteach time the page is visited. - This type of
xssis for the most part considered of higher severity thanreflected xsssincestored xssdoes not need user interaction to execute, the victim simply has to visit the page for the malicious code to run.
- 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
-
dom-
DOM XSSis a bit different, the attack takes advantage of client sideJavaScriptthat uses unsanitized user input,might be possible to executeJavaScriptin the victim's context https://evil.com/#pirateducky"><script>alert(1)</script>- If the application is using the
URI fragmentto pass down data to the application, our payload might be able to achieve execution, in the example below theURI fragmentis being used somewhere in code which then gets written to theDOMand since this is a script it will execute thealertprompt.
-
Methodology
Finding 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 JavaScript files and see if you can find where user input is being passed down to the application(sinks). When testing for 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 JavaScript, some ways of doing this are:
"><script>alert(1)</script> // straight to point, executes using script tag
"><img src=x onerror=prompt /> // a bit more covert, executes JavaScript using error handlers
<body onload=alert(1)/> // executes using event handlers
Impact
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
JavaScriptchanging theDOMis possible, also if justhtmlinjection is achieved this also applies
- If the attacker can inject
- Information Disclosure
- If sensitive information is stored in clientside
JavaScriptit can be exfiltrated a number of ways
- If sensitive information is stored in clientside
Mitigation
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.
To mitigate 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
- Use
HTTPheaders to your advantage includingContent Secure Policyto restrict access to sources such as external scripts
Top comments (0)