Cross Site Request Forgery

The nature of a cross-site request forgery (CSRF) is that an attacker can make ''you'' do something without your knowledge. This is similar to stealing your session but limited to specific actions on a site. There are two basic types of CSRF: those based on get requests and those based on post requests.

The HTTP specification defines several types of server requests, among them get and post requests. A get request is probably the most common; it happens every time you click a link or type an address into your browser. A post is generally what happens when you submit a form to a site.

Drupal core provides protection against a post CSRF using a token system. When a form is built using Drupal's Form API (FAPI), a token is added to the form based on the session ID and a private key from the site. When the form is submitted, the Form API confirms the presence and validity of the token. This requires that a post to the site be based on a current session and makes it more difficult for an attacker to develop a generic attack on forms in Drupal.

The more common problem in Drupal comes from modules that take action based on a get request. The Vulnerable module provides a feature that disables user accounts based on the URL. This feature is demonstrated in Figure 1-8.

File Edit View History Bookmarks Tools Help

I £ J http://crackingdrupal.c0m/vulnerable/csrf-disable/l

File Edit View History Bookmarks Tools Help

I £ J http://crackingdrupal.c0m/vulnerable/csrf-disable/l

-

Cracking Drupal

Home

greg

Disable users in a csrf, xss, sql injection kind of way

Code review o My account

Access disabled for uid 1

Create content

Hey, this is pretty vulnerable.

Administer

0 Log out

rWiMI.MB

| Done #

Figure 1-8 Requesting this URL disables any user of the site.

Figure 1-8 Requesting this URL disables any user of the site.

This simple code can be exploited in a variety of ways, such as tricking a user who has the permission to access the page into clicking on a URL like http://example.com/vulnerable/csrf-disable/1 or, even easier, getting the user to look at a page with an ''image'' embedded into it with the source pointed at that URL: <img src=''http://example.com/ vulnerable/csrf-disable/1'' >.

CSRF is increasingly not a problem for Drupal because the few remaining modules that take actions like this are fixed to use a form of some sort. However, it is often tempting when building a rich AJAX feature to slip back into creating a CSRF vulnerability via get requests. The security team is working on an API to make this much easier for module developers, but that API is not yet available. There are still methods that can be used to provide security for links. The system is based on the same token system used to protect Drupal forms. However, because this practice of taking action in response to get requests is not as common or standard as the form system, there is no way to provide this protection automatically or easily.

0 0

Post a comment