Cross-site scripting (XSS) and cross-site request forgery (CSRF) are some of the most common and well-known web vulnerabilities. Although they are often mentioned together and may seem similar, they exploit different aspects of web applications and browsers.
Overview of XSS (Cross-Site Scripting)
What is XSS?
XSS attacks target end users by injecting malicious scripts into websites. The attacker’s intention is to have their script executed inside the target user’s web session. It can steal cookies, hijack sessions, deface pages, or redirect users to malicious sites.
How XSS attacks are carried out
XSS payloads are typically sent through input fields, query parameters, or other entry points that are displayed or stored by the application without proper sanitization. The most common types are:
- Reflected XSS: The attacker’s input is immediately returned to the server’s response, causing the malicious script to run in the target’s browser without being stored.
- Stored XSS: The malicious payload is saved on the server. Whenever another user accesses the compromised content, the script is executed in their browser.
- DOM-based XSS: The payload manipulation occurs entirely in the browser via JavaScript.
Overview of CSRF (Cross-Site Request Forgery)
What is a CSRF attack?
CSRF forces authenticated users to perform unwanted actions on a website where they are logged in. For example, this could include changing account settings or initiating transactions.
How CSRF attacks are carried out
When a user is authenticated in a web application, their browser automatically includes session cookies on any request to that domain. CSRF exploits this by tricking the user into sending a forged request without their knowledge. For example, via a form on a malicious site.
Key differences between XSS and CSRF
Attack mechanism
- XSS involves injecting malicious scripts into a user’s browser. They exploit trust in a particular website, allowing the attacker to execute JavaScript in the context of it.
- CSRF occurs when a browser sends unwanted requests to a web application that the user is already authenticated with. The attacker does not need to inject code, but instead tricks the browser into making a request that the server believes is legitimate.
Potential consequences
- XSS allows attackers to directly interact with the browser’s DOM and session data, which makes it possible for them to steal tokens, manipulate page content, log keystrokes, and more.
- CSRF forces users to unwittingly perform actions such as form submissions, data updates, or transactions. The attacker uses existing credentials and sessions without needing access to them.
Defense strategies
- Protection against XSS involves a multi-layered approach that includes input sanitization (validating and cleaning user input), output encoding (safely displaying content in HTML or JavaScript), and the use of Content Security Policy (CSP) headers to restrict the sources of script execution.
- Protection against CSRF requires verifying that each request for a state change comes from an authorized source. Common defenses involve adding CSRF tokens to forms, configuring cookies with the SameSite attribute to block cross-origin requests, and prompting users to reauthenticate before performing critical actions. Such practices help prevent attackers from forging requests.
Real-world examples and use cases
XSS in comment fields
An attacker posts a comment on a blog with an embedded script tag. When another visitor opens the page, the code runs in their browser, which may lead to stolen session cookies or redirection to a malicious site.
CSRF in form submissions
An authenticated user visits a malicious website that secretly submits a form to change their email address on a banking website. The browser contains valid session cookies, and the change is processed without the user’s knowledge.
Which is more dangerous, XSS or CSRF?
Both vulnerabilities are serious, but differ in scope. XSS is generally considered more dangerous because it gives attackers direct access to the client-side runtime, allowing them to perform a wide range of malicious actions.
CSRF relies on existing authenticated sessions and typically requires some form of user interaction. However, when combined with other security flaws (such as weak authentication), CSRF can still have serious consequences.
Detecting XSS and CSRF with DAST
To detect XSS, DAST tools inject a number of payloads and monitor how a web application processes and outputs user input, identifying places in the browser where malicious scripts can be executed.
To find CSRF, modern DAST solutions evaluate the presence and implementation of security controls, such as CSRF tokens and SameSite cookie attributes, to identify weaknesses that could allow unauthorized requests.
The Invicti platform based on DAST automatically confirms the existence of most serious vulnerabilities, including XSS and CSRF, allowing teams to eliminate these problems immediately without wasting effort on re-checking.
