CAPEC-62 - Cross Site Request Forgery (aka Session Riding)

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.

Severity

Likelihood

Confidentiality

Integrity

Availability

  • Attack Methods 2
  • Spoofing
  • Analysis
  • Purposes 1
  • Exploitation
  • Sec Principles 2
  • Complete Mediation
  • Defense In Depth
  • Scopes 3
  • Gain privileges / assume identity
  • Authorization
  • Access_Control
  • Confidentiality
  • Read application data
  • Confidentiality
  • Modify application data
  • Integrity

Medium level: 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.

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.

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

Use Authorization Mechanisms Correctly

Use Authentication Mechanisms, Where Appropriate, Correctly

Step 1 - 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..

Tecnique ID: 1 - Environment(s) env-Web

Use web application debugging tool such as WebScarab, Tamper Data or TamperIE to analyze the information exchanged between the client and the server

Tecnique ID: 2 - Environment(s) env-Web

Use network sniffing tool such as Wireshark to analyze the information exchanged between the client and the server

Tecnique ID: 3 - Environment(s) env-Web

View HTML source of web pages that contain links or buttons that perform actions of interest.

Outcome ID: 1

Type: 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.

Outcome ID: 1

Type: Failure

Attacker cannot identify any functionality that can be executed without sending a session-specific parameter other than the cookie in the HTTP request.



Step 1 - 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..

Tecnique ID: 1 - Environment(s) env-Web

Create a GET request containing all required parameters (e.g. https://www.somebank.com/members/transfer.asp?to=012345678901&amt=10000)

Tecnique ID: 2 - Environment(s) env-Web

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>

Indicator ID: 1 - Environment(s) env-Web

Type: Positive

Success outcome in previous step.

Indicator ID: 2 - Environment(s) env-Web

Type: Negative

Failure outcome in previous step.


Security Control ID: 1

Type: 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.

Security Control ID: 2

Type: 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.


Outcome ID: 1

Type: Success

A link that performs an operation that the attacker desires when it is clicked.

Outcome ID: 2

Type: 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.



Step 1 - 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..

Tecnique ID: 1 - Environment(s) env-Web

Execute a phishing attack and send the user an e-mail convincing him to click on a link.

Tecnique ID: 2 - Environment(s) env-Web

Execute a stored XSS attack on a website to permanently embed the malicious link into the website.

Tecnique ID: 3 - Environment(s) env-Web

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.

Tecnique ID: 4 - Environment(s) env-Web

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.

Indicator ID: 1 - Environment(s) env-Web

Type: Positive

Success outcome in previous step.

Indicator ID: 2 - Environment(s) env-Web

Type: Negative

Failure outcome in previous step.


Security Control ID: 1

Type: 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 Referrer headers most of the time. These can help indicate that the actual request is illegitimate.

Security Control ID: 2

Type: 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.


Outcome ID: 1

Type: Success

A user executes the malicious link crafted by the attacker.

Outcome ID: 2

Type: Failure

Failure outcome in previous step.



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.