XSS or Cross-Site-Scripting is one of the basic Web-Security fundamentals, web developers should be aware of. Let's begin. . .

What is Cross-Site-Scripting ?

Cross-Site-Scripting is basically a security vulnerability which allows an "attacker" or "hacker" to inject malicious executable client-side code into the website or web-application. Basically, the victim page is executing code on behalf of someone, that is not requested by the user.

• The code is executed by victims.
• This lets the attackers bypass access-controls and impersonate users.
• The victim's browser cannot detect the malicious script which is untrustworthy and gives access to any cookies, session tokens or any other sensitive information.

  ---

So, how it is done ?

With websites becoming more and more dynamic, facilitating interactions with user uploaded contents, websites are no longer traditional static sites.
HTML documents can contain arbitrary JavaScript codes. Insecure JavaScript programs may directly execute code that comes from external sources.

Let's take an example of a vulnerable search engine. We can see if the search field is vulnerable, it can right away execute the scripts.
This happens when the web app doesn't employ enough validations and encoding.

Basically there are three main ways :

• Stored XSS attacks
  Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information.
  
  
• Reflected XSS attacks
  Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other website.
  
  
• Dom based XSS attacks
  This type of attack occurs when the DOM environment is being changed, but the client-side code does not change. When the DOM environment is being modified in the victim’s browser, then the client side code executes differently.
  Lets see an example...
  Original URL

  http://foo.com?q=dogs&default=1
  

  Malformed URL using script as a parameter

  http://foo.com?q=dogs&default=<script> hackThisUser();</ script>
  

  ---

  XSS Defense Techniques

• XSS Filters in Browsers
  

  Browser parsers can check : "Is there an embedded script tag in the URL or Search input ? " In such case, the browser can remove script tags, even before it reaches the server.
  ⚠ Although, this isn't a full proof solution as filters can't fix everything. It is easy to bypass those filters using scripts in <img> tags or using malformed code in HTML, CSS.
  

http://foo.bar?msg=<IMG """><SCRIPT>alert("XSS")</SCRIPT>">
// Blank <img> tag isn't filtered by browsers, but it contains 
script tags in it.

• httponly Cookies

  Server restricting the client-side JavaScript to manipulate the cookies or access it. Such instructions can be specified inside headers.
  ⚠ Again this has a loop-hole, the attacker can still issue requests containing user's cookies by persuading the user to visit an evil site. (CSRF : Cross Site Request Forgery)
  

• Privilege Separation

  A separate domain can be used to host user contents. So, in case of malicious attack, the damage can be limited to that domain and not the entire server.
  ⚠ However, the specific domain can also lead to revealing some confidential information or links to other such places.
  

• Content Sanitization

  Taking untrusted content and convert/encode them in a way that it difficult for browsers to interpret. '<', '>', ';', quotes can be converted into safe characters like &lt, &gt etc. Hence, the browser cannot interpret them as HTML.
  Let's see how Google implements this in practice, when I tried to run some script tags in Search Box...
  

Clearly in the URL bar we can see how the Script tags and other things are sanitized.
⚠ This looks fine from the surface, but such grammars can confuse the browser a lot, increasing complexity. Attacker can also inject scripts through CSS or other attributes.

• Content Security Policy (CSP)
  

  This allows the Server to specify the Browser which kind of resources can be loaded and also the trusted domains or allowed origins from where it can come from.

Content-Security-Policy: default-src 'self'
// A web site administrator wants all content to come from the site's own origin

Content-Security-Policy: default-src 'self' trusted.com *.trusted.com
// A web site administrator wants to allow content from a trusted domain 
// and all its subdomains.

Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com
//  We can specify separate policies for where images can come from, where
// scripts can come from, frames, plugins, etc.

CSP also prevents inline JavaScript, and JavaScript interfaces like eval() which allow for dynamic JavaScript generation.

Conclusion

As Web Technologies advances with time, it is important for developers to take care of these loop-holes which in other cases may lead to adverse consequences.
With more and more user interactions increasing day by day, taking care of web-security is extremely important for public as well as for the organization.
Thank you for Staying till the end !
Here are some resources & references for further reading. . .
Open Web Application Security Project (OWASP)   MDN Web Docs
Some YouTube videos,