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.
Attack Execution Flow
Explore
Explore target
website:
The attacker first explores the target website to
determine pieces of functionality that are of
interest to him (e.g. money transfers). The attacker
will need a legitimate user account on the target
website. It would help to have two accounts.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Use web application debugging tool such as
WebScarab, Tamper Data or TamperIE to analyze the
information exchanged between the client and the
server
env-Web
2
Use network sniffing tool such as Wireshark
to analyze the information exchanged between the
client and the server
env-Web
3
View HTML source of web pages that contain
links or buttons that perform actions of
interest.
env-Web
Outcomes
ID
Type
Outcome Description
1
Success
Attacker identifies at least
one piece of interesting functionality that can be
executed by making a single HTTP GET or POST
request containing no session-specific
parameters.
1
Failure
Attacker cannot identify any
functionality that can be executed without sending
a session-specific parameter other than the cookie
in the HTTP request.
Experiment
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.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Create a GET request containing all required
parameters (e.g.
https://www.somebank.com/members/transfer.asp?to=012345678901&amt=10000)
env-Web
2
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>
env-Web
Indicators
ID
Type
Indicator Description
Environments
1
Positive
Success outcome in previous step.
env-Web
2
Negative
Failure outcome in previous step.
env-Web
Outcomes
ID
Type
Outcome Description
1
Success
A link that performs an
operation that the attacker desires when it is
clicked.
2
Failure
Creating a link that performs
an operation that the attacker desires when it is
clicked, is impossible, because the site has
implemented protections against
CSRF.
Security Controls
ID
Type
Security Control Description
1
Preventative
Include a unique HTTP
parameter value in forms every time they are sent
to the client. Verify that the expected value is
in the response received from the client. In this
case, the attacker will not have access to the
correct parameter value for another user, and
thus, will not be able to create forged
requests.
2
Preventative
Check HTTP referrer
for each request to ensure that it is from the
expected site. Note that if the site is vulnerable
to XSS, then the attacker will be able to bypass
this.
Exploit
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.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Execute a phishing attack and send the user
an e-mail convincing him to click on a
link.
env-Web
2
Execute a stored XSS attack on a website to
permanently embed the malicious link into the
website.
env-Web
3
Execute a stored XSS attack on a website
where a 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.
env-Web
4
Include the malicious link on the attacker's
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.
env-Web
Indicators
ID
Type
Indicator Description
Environments
1
Positive
Success outcome in previous step.
env-Web
2
Negative
Failure outcome in previous step.
env-Web
Outcomes
ID
Type
Outcome Description
1
Success
A user executes the malicious
link crafted by the
attacker.
2
Failure
Failure outcome in previous
step.
Security Controls
ID
Type
Security Control Description
1
Detective
Monitor server logs
for referrers. If users are being tricked into
clicking CSRF links through forums or other web
postings, their web browsers will be providing
Referer headers most of the time. These can help
indicate that the actual request is
illegitimate.
2
Corrective
Deny requests and
invalidate session IDs for requests that contain
unexpected referrers. Note that this will not
protect against cases where the target website is
also vulnerable to cross site
scripting.
Typical Likelihood of Exploit
Likelihood: High
Methods of Attack
Spoofing
Analysis
Examples-Instances
Description
While a user is logged into his 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 mimicks 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.
Related Vulnerabilities
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.
Attacker Skills or Knowledge Required
Skill or Knowledge Level: Medium
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.
Probing Techniques
Description
The attacker can observe the way the application accepts requests for
actions. If the application uses a persistent cookie, a non-random
identifier or any such static identification token that does not change
with every request, the attack is fairly straightforward to
accomplish
Obfuscation Techniques
Description
In order to obfuscate the actual URL and its contents passed to the
victim, the attacker can employ a service such as TinyURL and optionally
redirect the request to the actual malicious script
Solutions and 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 Referer 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.
Use Authentication Mechanisms, Where Appropriate, Correctly
Purposes
Exploitation
CIA Impact
Confidentiality Impact: High
Integrity Impact: High
Availability Impact: Low
Technical Context
Architectural Paradigms
Client-Server
Frameworks
J2EE
.NET
Platforms
All
Languages
All
References
"Session Riding: A Widespread Vulnerability in Today's Web
Applications", Thomas Schreiber, SecureNet GmbH, Dec 2004.
http://www.securenet.de/papers/Session_Riding.pdf
Content History
Submissions
Submitter
Organization
Date
Chiradeep B.Chhaya
Cigital, Inc
2007-02-27
Modifications
Modifier
Organization
Date
Comments
Richard Struse
VOXEM, Inc
2007-03-26
Review and feedback leading to changes in Description
and Related Attack Patterns
Sean Barnum
Cigital, Inc
2007-04-13
Modified pattern content according to review and
feedback
Description
