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 GauniyalJan 12, 2017 at 11:06
Add a comment
|
10 Answers
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.
-
17didn't know the last one was also called 'Self-XSS'. Until now, I've called it 'stupidity'.– BiAiBNov 27, 2014 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. :-)– XanderNov 27, 2014 at 14:50
-
Installing unsafe browser extension may consider as "self-inflicted" XSS.– mootmootOct 8, 2018 at 9:41
-
Almost perfect answer but it contains a wrong sentence that needs fixing: "the flaw...is always in the code that is delivered by the server". In DOM-Based XSS you can use a technique where the malicious code doesn't come from the server: "The technique to avoid sending the payload to the server hinges on the fact that URI fragments (the part in the URI after the “#”) is not sent to the server by the browser. Thus, any client side code that references, say, document.location, may be vulnerable to an attack which uses fragments" owasp.org/www-community/attacks/DOM_Based_XSS Jul 28, 2020 at 17:41
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?
answered Nov 26, 2014 at 15:08
-
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? May 13, 2018 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. May 14, 2018 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. May 15, 2018 at 6:47
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.
answered Nov 26, 2014 at 15:27
tl/dr: If the server is building the HTML then the server needs to protect against XSS. If the client is building the HTML then the client needs to protect against XSS.
With changes in the way web applications are built this question deserves a re-visit, since the answer is more than just a matter of semantics. The answer is actually surprisingly simple:
XSS happens wherever HTML is built!
At the time this question was asked, AngularJS and React where roughly 3 years and 1 year old (respectively). This is of note because these frameworks really helped speed the switch to client-side applications, in which HTML is not just rendered client side (as it always has been) but also constructed client side. With client side applications XSS switches from a server-side vulnerability to a client-side vulnerability. The difference is important:
Protecting against XSS
Normally you protect against XSS by escaping the appropriate control characters, depending on your context. So if you are building HTML like this:
<div title="[USER_INPUT]">Hi!</div>
You would convert " to " (among other things). If your server-side application is returning a string of HTML to the browser, then clearly it must take care of this while generating the HTML. In many modern back-end frameworks this happens automatically in the templating systems.
However, if your server is simply returning data (perhaps via a JSON response) to a client side application running something like React or Angular, then it shouldn't do anything at all! The reason is that the client side application is the one that is going to be building the HTML, and so it will perform any necessary XSS protection. If the server escapes the HTML first, then it will end up double escaped, which means that instead of seeing this:
Welcome to Bob's Page!
The user will see this:
Welcome to Bob"s Page!
Because the full system will go through this flow:
- From the database:
" - Escaped by the server and sent to the client:
" - Escaped by the client application and rendered in the browser:
&quot;
Which will clearly cause problems. In addition though it's important to remember that the steps to properly protecting against XSS are context-dependent. Stopping XSS is different in an HTML attribute, versus input that is injected directly into the DOM tree, versus data that is injected into a JavaScript string. As a result, XSS protection has to happen when user input is actually injected into the HTML. Therefore, it can be a server-side issue or a client-side issue, depending on who is doing the actual HTML construction.
answered Jan 27, 2021 at 10:49
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 problemCross 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 RyanJun 30, 2016 at 13:05 -
2It'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. Jun 30, 2016 at 15:17
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
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.
“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]
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?
