My colleagues claim that XSS is a vulnerability on the server side. I always thought that this is a client side vulnerability. Which one of us is correct, and why?
It manifests itself on the client side, but that is because it is allowed to do so by the web application. The application doesn't validate the code that it sends back to the browser. And thats why it is a server side vulnerability. Think about it this way. What would you do to fix the issue of XSS? Fix the server side code or fix the browser?
Cross-site Scripting (XSS) attacks can generally be categorized as one of:
- Stored XSS Attacks
- Reflected XSS Attacks
- DOM Based XSS Attacks
The attack itself is taking place on the client. All three attack types could fully manifest themselves in the browser itself in the case of a single page or offline application. However, if the data is stored on the server or reflected from the server, then the server is assisting in the vulnerability.
IE8 introduced X-XSS-Protection, which made reflected attacks more difficult to exploit.
The terminology is a little slippery, but usually an "XSS bug" is a client-side exploit of a server-side vulnerability.
Cross-site scripting is not, in and of itself, a security problem. The problem is that it can happen without the end user's knowledge. Most sites aren't coded for this to happen, of course: either they don't use cross-site scripting at all, or they make it clear that this is what they're doing. But if users can post their own content, then you need to keep them from adding arbitrary script tags to the pages. Otherwise, they could slip stuff into the page that sends data to who knows where.
To prevent this, you need to parse out the user-created content, and then generate "clean" HTML for display which doesn't have the tags you don't want (like script tags). Some sites use this opportunity to have users create their content in a language that isn't HTML: Stack Exchange uses Markdown. But as long as you still parse the content properly, you can use HTML as the input language too. There's no performance benefit to properly done HTML-to-HTML, since it goes through the same kind of parse/generate cycle that other languages would, but it's one less language for developers (and possibly users) to learn. You do, however, have to resist the temptation to just reuse the HTML content as-is, or to do some light string substitutions instead of a parse/generate cycle.
An "XSS bug" is what happens when people figure out how to post arbitrary HTML to the site. Usually this happens when developers directly use HTML input without going through the parse/generate cycle, but sometimes somebody finds a way to trick the site's generator into giving them HTML that it wasn't designed to give. Either way, the end result is the same: once a user can post arbitrary HTML, they can do cross-site scripting with it, and that's why we call it an XSS bug. But the bug isn't in the XSS itself: it's in the server-side code that allowed arbitrary scripts to be posted in the first place.
It is generally best practice to filter as many things as you can on the server side and not on the client size for the following reasons:
- Liability (Once you have sent out data you shouldn't have, you can not control the effects of it)
- User Safety (You generally don't know what version of your client the users have)
An XSS attack is not much different from an SQL injection. Both are caused by not controlling user input properly. XSS attacks are generally stored in your database and distributed through your system to your clients.
Hope it helped. I recommend this read for further information: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
I've read some people who care about not using the url or whatever to load different user info or whatever (such as some here in google's tutorial - https://xss-game.appspot.com/)
While that's nice to be aware of, you gotta remember that every single function and piece of code on the client side can be arbitrarily executed. Validation and protection for XSS comes comes from the server. I mean think about it, you can open up the console itself.
The idea is the injection of malicious code from client that ends up being a vulnerability on the server. This may cause the other clients to receive web pages with crappy scripts embedded in them. Think of a forum -- if you just saved and render tags in that post someone made you could be making be arbitrarily execute code for whoever views that forum post.
For example, if stackoverflow wasn't escaped properly, you probably would have been redirected to google.com w/ the below
window.location.href = 'http://google.com' (imagine this being surrounded by script tags, SE formats them out and too lazy to escape them)
Its a server-side vulnerability that can be exploited via client-side applications.
[enter preformatted text here]
Contrary to what many other believe, xss is both client side and server side.
A persistent xss is server side as the server stores the code to be executed in the client. When it is non-persistent, it is considered client side, as the client can only get the result through that input