CAPEC-62
Cross Site Request Forgery
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.
On this page
Ask an AI about this attack pattern
Show the prompt
Explain the attack pattern CAPEC-62: Cross Site Request Forgery: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/62.html and https://cve.bz/cve/capec/62?via=ask-ai-copy, which lists recent CVEs with the weaknesses it exploits. Cite the sources.Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this attack pattern's id and public links.
How the attack unfolds
Explore
The attacker looks for a way in.
[Explore target website] The attacker first explores the target website to determine pieces of functionality that are of interest to them (e.g. money transfers). The attacker will need a legitimate user account on the target website. It would help to have two accounts.
3 techniques
- Use web application debugging tool such as WebScarab, Tamper Data or TamperIE to analyze the information exchanged between the client and the server
- Use network sniffing tool such as Wireshark to analyze the information exchanged between the client and the server
- View HTML source of web pages that contain links or buttons that perform actions of interest.
Experiment
They probe what they found.
[Create a link that when clicked on, will execute the interesting functionality.] The attacker needs to create a link that will execute some interesting functionality such as transfer money, change a password, etc.
2 techniques
- Create a GET request containing all required parameters (e.g. https://www.somebank.com/members/transfer.asp?to=012345678901&amt=10000)
- Create a form that will submit a POST request (e.g. <form method="POST" action="https://www.somebank.com/members/transfer.asp"><input type="hidden" Name="to" value="012345678901"/><input type="hidden" Name="amt" value="10000"/><input type="submit" src="clickhere.jpg"/></form>
Exploit
They carry out the attack.
[Convince user to click on link] Finally, the attacker needs to convince a user that is logged into the target website to click on a link to execute the CSRF attack.
4 techniques
- Execute a phishing attack and send the user an e-mail convincing them to click on a link.
- Execute a stored XSS attack on a website to permanently embed the malicious link into the website.
- Execute a stored XSS attack on a website where an XMLHTTPRequest object will automatically execute the attack as soon as a user visits the page. This removes the step of convincing a user to click on a link.
- Include the malicious link on the attackers' own website where the user may have to click on the link, or where an XMLHTTPRequest object may automatically execute the attack when a user visits the site.
Skills required
- Medium skill
The attacker needs to figure out the exact invocation of the targeted malicious action and then craft a link that performs the said action. Having the user click on such a link is often accomplished by sending an email or posting such a link to a bulletin board or the likes.
Resources required
All the attacker needs is the exact representation of requests to be made to the application and to be able to get the malicious link across to a victim.
Consequences
| Impact | Affects | Note |
|---|---|---|
| Gain Privileges | Confidentiality, Access Control, Authorization | |
| Read Data | Confidentiality | |
| Modify Data | Integrity |
Mitigations
Use cryptographic tokens to associate a request with a specific action. The token can be regenerated at every request so that if a request with an invalid token is encountered, it can be reliably discarded. The token is considered invalid if it arrived with a request other than the action it was supposed to be associated with.
Although less reliable, the use of the optional HTTP Referrer header can also be used to determine whether an incoming request was actually one that the user is authorized for, in the current context.
Additionally, the user can also be prompted to confirm an action every time an action concerning potentially sensitive data is invoked. This way, even if the attacker manages to get the user to click on a malicious link and request the desired action, the user has a chance to recover by denying confirmation. This solution is also implicitly tied to using a second factor of authentication before performing such actions.
In general, every request must be checked for the appropriate authentication token as well as authorization in the current session context.
Weaknesses it exploits
- CWE-306 Missing Authentication for Critical Functionality
- CWE-352 Cross-Site Request Forgery
- CWE-664 Improper Control of a Resource Through its Lifetime
- CWE-732 Incorrect Permission Assignment for Critical Resource
- CWE-1275 Sensitive Cookie with Improper SameSite Attribute
Recent CVEs with these weaknesses
- –CVE-2026-97870
When Hessian remoting endpoints are served by the embedded HTTP server, configured authentication and transport security requirements are silently ignored. A remote unauthenticated attacker can invoke the exposed EJB methods without creden…
- –CVE-2026-97872
When an EJB is exposed over the optional Hessian protocol inside an existing web application, some configured authentication and transport security settings are silently not enforced. A remote unauthenticated attacker can invoke the expose…
- 9.4CVE-2026-121683
Missing authentication in Ivanti Cloud Services Application version 5.0.8 allows a remote unauthenticated attacker to add and delete arbitrary trusted EPM Core certificate entries.
- –CVE-2026-111251
The admin service of the standalone OpenEJB server accepts stop requests without any authentication. Any local user or process able to connect to the admin port can stop the server, leading to denial of service; the admin service is enable…
- –CVE-2026-111256
When JAX-WS or JAX-RS endpoints are published by the embedded OpenEJB HTTP server rather than Tomcat, some configured authentication methods are silently ignored and the endpoint is published without authentication. A remote unauthenticate…
- –CVE-2026-87756
The internal system EJBs used for remote deployment and configuration did not enforce their administrative role check when the server ran with the default profile. A remote unauthenticated attacker able to reach the remote EJB endpoint cou…
- –CVE-2026-111263
Authentication configured for an EJB JAX-WS endpoint in the TomEE deployment descriptor is not enforced when the endpoint is published within an existing web application. A remote unauthenticated attacker can invoke the web service operati…
- 5.1CVE-2026-112137
A vulnerability has been identified in Mendix Studio Pro 11 (All versions >= V11.15.0 < V11.16.0), Mendix Studio Pro 11.12 (All versions >= V11.12.6 < V11.12.7). The affected products MCP Server does not properly validate Content-Type and …
The newest records naming one of them. Each weakness's page lists them all.
Related attack patterns
- Part of
- CAPEC-21 Exploitation of Trusted Identifiers
- More specific patterns
- CAPEC-467 Cross Site Identification
Examples
While a user is logged into their bank account, an attacker can send an email with some potentially interesti…
While a user is logged into their bank account, an attacker can send an email with some potentially interesting content and require the user to click on a link in the email.
The link points to or contains an attacker setup script, probably even within an iFrame, that mimics an actual user form submission to perform a malicious activity, such as transferring funds from the victim's account.
The attacker can have the script embedded in, or targeted by, the link perform any arbitrary action as the authenticated user. When this script is executed, the targeted application authenticates and accepts the actions based on the victims existing session cookie.
See also: Cross-site request forgery (CSRF) vulnerability in util.pl in @Mail WebMail 4.51 allows remote attackers to modify arbitrary settings and perform unauthorized actions as an arbitrary user, as demonstrated using a settings action in the SRC attribute of an IMG element in an HTML e-mail.
MITRE's words, unchanged: CAPEC-62 at MITRE. CAPEC is Copyright © 2007–2026, The MITRE Corporation, used under the CAPEC terms of use: “The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use Common Attack Pattern Enumeration and Classification (CAPEC™) for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.” CAPEC and the CAPEC logo are trademarks of The MITRE Corporation. Credits. All attack patterns.