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
search
param 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 tohtml
I can executeJavaScript
by using theonerror
event handler, sinceJavaScript
has access to thedocument.cookie
we can put it in analert
prompt 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 executeJavaScript
each time the page is visited. - This type of
xss
is for the most part considered of higher severity thanreflected xss
sincestored xss
does 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 XSS
is a bit different, the attack takes advantage of client sideJavaScript
that uses unsanitized user input,might be possible to executeJavaScript
in the victim's context https://evil.com/#pirateducky"><script>alert(1)</script>
- If the application is using the
URI fragment
to pass down data to the application, our payload might be able to achieve execution, in the example below theURI fragment
is being used somewhere in code which then gets written to theDOM
and since this is a script it will execute thealert
prompt.
-
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
JavaScript
changing theDOM
is possible, also if justhtml
injection is achieved this also applies
- If the attacker can inject
- Information Disclosure
- If sensitive information is stored in clientside
JavaScript
it 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
HTTP
headers to your advantage includingContent Secure Policy
to restrict access to sources such as external scripts
Top comments (0)