Understanding XSS vs CSRF

When it comes to web application vulnerabilities and attacks, malicious actors are a lot like Cookie Monster, screaming, “Me love cookie!” Digital cookies may not be as tasty as chocolate chips, but they’re just as deliciously enticing because they often contain sensitive information or enable attackers to gain unauthorized access. 

While both Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) attacks use similar terminology and can impact user access and session cookies, they have different methodologies and impacts. To correctly secure your application, you should understand the differences between  XSS and CSRF attacks as well as different mitigation strategies. 

What is Cross-Site Scripting (XSS)?

A cross-site scripting attack (XSS) is a type of injection attack where threat actors insert malicious code into an application or website, typically through a browser-side script. Attackers use weaknesses around user-supplied input, like lack of input validation or encoding. In an XSS attack, malicious actors trick an end-user’s browser into thinking that the code came from a trusted source. When the browser executes the script, the malicious actors can:

• Access cookies
• Access session tokens
• Access sensitive data
• Rewrite HTML content

Three types of XSS vulnerabilities exit:

• Reflected XSS (non-persistent or Type I): The web application returns user input as an error message, search result, or other response that includes some of the original user-supplied input.
• Stored XSS (persistent or Type II): The target server stores user inputs so threat actors can insert the data into the application, returning the malicious data when users make requests. 
• Document Object Model (DOM-based) XSS (Type-0): The malicious actors modify the victim browser’s DOM “environment” that the client-side script uses so that the code runs in an unexpected way. 

An XSS attack can occur at the:

• Server: generates an HTTP response that includes untrusted user-supplied data
• Client: untrusted user-supplied data comes from a request or a stored location on the client or its server

What is Cross-Site Request Forgery (CSRF)?

A Cross-Site Request Forgery (CSRF) attack typically begins with social engineering, like sending a malicious link in an email, that tricks an authenticated user into taking action within the application. After authenticating into the application, the browser sends a rogue HTTP request to the application. Since the user and browser are authenticated, the application executes the request, even though the user did not initiate it. 

Two types of CSRF attacks exist:

• Login CSRF: forcing non-authenticated user to login to an attacker-controlled account

• Stored CSRF: malicious code stored in a field that accepts HTML

Key Differences Between CSRF and XSS?

XSS and CSRF exploit the trust established between the user and the website. However, they differ in methodology and impact. 

User Interaction

The human element is the core difference between the two attacks:

• CSRF: Social engineering so the end user who must take an action against their best interests
• XSS: Injecting malicious code into pages through user-supplied inputs

Session Requirement

Although both attacks targets user sessions, they do so differently:

• CSRF: Attacker needs an active session for the server to recognize the request. 
• XSS: Malicious code executes with or without an active session. 

Trust Exploitation

While both attacks exploit the trust that users place in websites and web application, they take different approaches:

• CSRF:Tricks victims into unknowingly performing actions in trusted applications that can result in fraudulent transactions, unauthorized changes to settings, or private information disclosures.
• XSS: Acts on victims behave to steal sensitive information, manipulate content, or perform unauthorized actions

Scope of Actions

The attacks have a different impact based on their different methodologies:

• CSRF: Limited to the user’s actions within the target application or website
• XSS: Ability to interact with the targeted site and user’s browser, including accessing cookies, local storage, or other browser resources beyond the targeted site

Mitigating XSS and CSRF Risks

For a comprehensive approach to risk mitigation, you should implement protections against both types of vulnerabilities and attacks. CSRF mitigation techniques do not protect against XSS attacks. For a comprehensive risk mitigation approach, you should implement the following:

• Identify software components: You should identify all open-source software components and dependencies to ensure you understand all potential threats. 
• Scan code for vulnerabilities: You should be regularly scanning your code for known vulnerabilities that attackers can exploit and updating components with security patches. 
• Sanitize data inputs: You should remove unwanted elements, like HTML tags or characters, that attackers can use as part of an attack. 
• Use built-in protections: Many frameworks offer synchronizer token defenses which can streamline security activities. 
• Use server-side CSRF tokens: Tokens should be unique per user session, secret, and unpredictable. 
• Use double-submit cookie patterns: When unable to maintain the CSRF token on the server, you should use the Signed Double-Submit Cookie which uses a secret key that only the server knows so attackers cannot create and inject their own. 
• Disallow non-simple requests: When using <form> tags, implement alternate security approaches like tokens. 
• Disallow simple content types: Set the server or API to disallow text/plain content types. 
• Employ custom request headers: For AJAX/API endpoints, custom request headers can be a user-friendly alternative to synchronizer tokens and double-submit cookies. 
• Encode outputs: When displaying data that users type, you should use output encoding that covers variables placed:
  • Between two basic HTML tags
  • In HTML attribute values
  • Into inline JavaScript then embedded in an HTML document
  • Into inline CSS
  • Into a URL
  • Directly in a script
  • Inside an HTML comment
  • Directly in CSS
  • To define an attribute
  • To define a tag
  • In callback functions
  • Where code handles URLs
  • In all JavaScript event handlers
  • In unsafe JavaScrip functions
• Sanitize HTML: When allowing users to change content styling or structure, HTML sanitization strips dangerous HTML from a variable to return a safe string of HTML
• Use safe sinks: You should try to use textContent or value so that the locations in the webpage that contain variables treat them as text and never execute them. 
• Use Content-Security-Policy (CSP) headers: CSPs can mitigate risk when customized for each individual application and used as part of a defense-in-depth strategy. 

Qwiet AI: Reduce Noise and Identify Vulnerabilities to Mitigate XSS and CSRF Risks

With Qwiet AI, you can scan millions of lines of code in minutes for visibility into all components, dependencies, and reachable vulnerabilities. Our platform quickly returns accurate and detailed findings while significantly reducing false positives. With our Code Property Graph (CPG), you gain a holistic view of your code, including data flows across the application, to quickly determine reachability and risk impact.

At Qwiet AI, we provide more than just tools – we can deliver a fully managed application security service tailored specifically to your organization’s unique needs. Our deep expertise in application security combined with seamless CI/CD integration ensures you’re not just deploying a solution but establishing a robust partnership. We delve deep into the unique business logic that drives your application. Our specialized focus on these flaws ensures that every facet of your application’s logic is meticulously tested and secured.

Try Qwiet AI’s preZero platform for free to see how it can help you mitigate risks and protect against command and code injection attacks.