26

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?

  • how about peer to peer connections where XSS is introduced? So definitely client-side vulnerability. – Abhinav Gauniyal Jan 12 '17 at 11:06
43

In a cross-site scripting attack, the malicious script is run on the client, but the actual flaw is in the application. That doesn't necessarily mean that it is a strictly server-side vulnerability, in that the flaw could be in the application's JavaScript, but generally, it is indeed in server-side code, and always in code that is delivered by the server.

There are client-side mitigations, such as the XSS-Protection that is now built into major browsers, or plugins that prevent the execution of JavaScript, but ultimately XSS is a web application vulnerability, and needs to be fixed by the application developers.

I should mention that there is another form of XSS that exploits neither flaws in the client (the browser) nor flaws in the server (the application) but flaws in the user. This is often called Self-XSS, and exploits the willingness of a inept user to execute JavaScript he has copied and pasted from the Internet and into his browser's developer tools console, solely on base on the promise that against all hope, it will magically allow him to read his ex-girlfriend's Facebook posts despite the fact she has unfriended and blocked him.

  • 14
    didn't know the last one was also called 'Self-XSS'. Until now, I've called it 'stupidity'. – BiAiB Nov 27 '14 at 14:44
  • 1
    @BiAiB I actually hate the term "Self-XSS." I once proposed changing it to something similar to yours, but considerably less succinct. :-) – Xander Nov 27 '14 at 14:50
  • Installing unsafe browser extension may consider as "self-inflicted" XSS. – mootmoot Oct 8 '18 at 9:41
8

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?

  • You know, that's actually a good question. Should I clean up all inputs in the client side or the server side? Say I'm populating some text with AJAX. Now, should I serve the files XSS-prevented or should I serve them normally, then un-XSS them in the client side? What are the security implications of each approach? – Rakshith Ravi May 13 '18 at 15:25
  • Whatever happens on the client side, is not in your control. But you do have control over what happens on the server side. – user1720897 May 14 '18 at 10:28
  • Of course you have control. I don't think you understood my question properly. I see two ways to approach this: 1. Data is taken from database -> Server serves content to client -> Data is un-XSSed -> Data is populated in the DOM. 2. Data is taken from the database -> The data is un-XSSed -> Server serves the un-XSSed content to the client -> Client populates the data to the DOM. I just wanted to know the security implications of each approach. – Rakshith Ravi May 15 '18 at 6:47
6

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.

3

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.

  • Cross-site scripting is not, in and of itself, a security problem Cross site scripting is security problem. What it is not, is that it is not a security problem that can be solved on the client side. – Lie Ryan Jun 30 '16 at 13:05
  • 1
    It's not a security problem in sites specifically designed to allow for it. jsFiddle and its bretheren come to mind, and even some Stack Exchange sites do the same sorts of things. But what prevents XSS from becoming a security risk in that context is that these sites are carefully set up so that nothing runs without the user's knowledge: for example, the scripts are never automatic. XSS attacks generally rely on running without the user's knowledge, and this is what makes them a security problem. – The Spooniest Jun 30 '16 at 15:17
1

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:

  • Performance
  • 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.

Filtering on XSS attacks should be done on user input, You generally should not accept any type of Javascript input. If you absolutely require that your clients can input Javascript, in case of for example programming sites, you should escape it first.

Hope it helped. I recommend this read for further information: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

0

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)

0

Its a server-side vulnerability that can be exploited via client-side applications.

  • Although you're correct, another answer has already pointed this out. – forest Feb 8 '18 at 2:48
0

“Basically an attacker, by crafting a specially formatted email, can embed JavaScript in it so that the script will be executed in the victim’s browser when the email is viewed on Yahoo Mail,” Pynnonen said in an email to Threatpost. “The attacker didn’t need special access. In fact the attack can be carried out without even registering on Yahoo Mail. Only the victim’s Yahoo email address is needed.”

In a description of the vulnerability published Thursday, Pynnonen explained how he could format an email with malicious data-* attributes that would sneak malicious JavaScript past Yahoo’s filters that execute by abusing the way Yahoo Mail displays links to whitelisted sites such as YouTube.[enter preformatted text here][1]

-1

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

Make sense?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.