DEV Community

Cover image for intro to xss
pirateducky
pirateducky

Posted on • Edited on

intro to xss

#hacking

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 to html I can execute JavaScript by using the onerror event handler, since JavaScript has access to the document.cookie we can put it in an alert 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 execute JavaScript each time the page is visited.
    • This type of xss is for the most part considered of higher severity than reflected xss since stored xss does not need user interaction to execute, the victim simply has to visit the page for the malicious code to run.
  • dom
    • DOM XSS is a bit different, the attack takes advantage of client side JavaScript that uses unsanitized user input,might be possible to execute JavaScript 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 the URI fragment is being used somewhere in code which then gets written to the DOM and since this is a script it will execute the alert 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
Enter fullscreen mode Exit fullscreen mode

This will answer some assumptions about the application I am testing:

  1. Is the application sanitizing dangerous characters(/,<,>,",')?
  2. 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
Enter fullscreen mode Exit fullscreen mode

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 the DOM is possible, also if just html injection is achieved this also applies
  • Information Disclosure
    • If sensitive information is stored in clientside JavaScript it can be exfiltrated a number of ways

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 including Content Secure Policy to restrict access to sources such as external scripts

Top comments (0)