8

Drupal inserts a form_token as a hidden field when it renders forms. The form_token is then checked on form submission to prevent cross-site request forgery attacks. The form data that is submitted is guaranteed to have come from the original form rendered by Drupal.

However, forms using the "GET" method shouldn't need this token. All it does is lengthen and uglify the resulting URL.

Is there any way of suppressing it?

ctford
  • 7,189
  • 4
  • 34
  • 51
  • 1
    here is an article that just happens to describe why this is an insanely bad idea. http://pixeljets.com/blog/csrf-avoid-security-holes-your-drupal-forms – mirzu Apr 20 '11 at 18:52

4 Answers4

13

Yes, there is a way, but use it consciously (see warning below):

If you create the form yourself, adding

$form['#token'] = FALSE;

to the form definition array should prevent a token from being generated in the first place.

If you are dealing with an existing form, you can bypass the token validation process by unsetting the '#token' element on hook_form_alter:

// Example for removal of token validation from login (NOTE: BAD IDEA!)
function yourmodule_form_alter(&$form, &$form_state, $form_id) {
  if ($form_id == 'user_login_block') {
    unset($form['#token']);
  }
}

Warning: Given your question, I think there is a slight misconception concerning the difference (better, the lack of a difference) between GET and POST requests.

... on forms using the "GET" method shouldn't need this token. All it does is lengthen and uglify the resulting URL.

This is wrong! GET and POST are just two different, but mostly equivalent methods of transmitting data from the client to the server. Since POST is better suited to transfer large amounts of data (or difficult formatted data), it is the established standard for submitting forms, but it is in no way safer/unsafer or more/less secure than GET requests. Both type of requests can be tampered with by malicious users in the same ways, hence both types should use the same protection mechanisms.

With a GET request, the token does exactly the same as with a POST request - it proves to the server that the submitted data comes from the same Browser on the same machine as the request he build the form for! So you should only remove it if you are sure that the request can not be misused via XSRF.

Henrik Opel
  • 19,341
  • 1
  • 48
  • 64
  • 3
    The main difference between GET and POST is that according to the HTTP spec GET is supposed to be "safe". This means that XSRF attacks aren't as much of a problem - tricking a user's browser into making a GET request shouldn't cause any state change on the server anyway. That's why I think the form_token is superfluous. – ctford Oct 01 '09 at 09:42
  • 2
    That's right - in theory :) The important words here are "supposed to be" and "shouldn't". The difference is just a suggestion/best practice, but nothing is stopping you or other developers from using GET requests for 'unsafe' stuff and it is done quite often out of convenience, as a simple link is implemented quicker and more lightweight than a form. But sure, if you know that what your GET does is harmless, remove the token - I just wanted to stretch the point that GET is not 'inherently' safe and that the removal of token handling should be a conscious decision and not happen automatically. – Henrik Opel Oct 01 '09 at 10:37
  • That said, I think I stretched that point a little to far given your question - I edited the answer accordingly, sorry for going a bit overboard with this ;) – Henrik Opel Oct 01 '09 at 10:59
  • I didn't really make it clear in the question. Thanks for your explanation and for refining your answer. – ctford Oct 01 '09 at 15:09
9

This worked for me. I had to unset all the form api elements and set the #token property to false. Notice the after_build function for unsetting the other properties.

   function mymodule_form(&$form_state){
      $form['name'] = array(
        '#type'   => 'textfield',
        '#title'  => 'name',
        '#value'  => 'name', 
      );
      $form['#method'] = 'get';
      $form['#action'] = url('someurl');
      $form['submit'] = array('#type' => 'submit', '#value' => 'go');
      $form['#token'] = false;
      $form['#after_build'] = array('mymodule_unset_default_form_elements');
      return $form;
    }

    function mymodule_unset_default_form_elements($form){
      unset($form['#build_id'], $form['form_build_id'], $form['form_id']);
      return $form;
    }
Leksat
  • 2,923
  • 1
  • 27
  • 26
  • 3
    Thank you, works nicely for me. If you want to remove the op= that comes with the submit, just add `'#attributes' => array('name' => '')` to your submit array. – Nicholas Ruunu Nov 25 '14 at 15:15
4

The site I work on uses the Drupal 6 form API for custom search forms, so by removing the token and build id we were able to cache the results in memcache. Now we've moved to Acquia hosting, it's cached using Varnish.

To remove the form_token and form_build_id from your form and submit it as a GET request, use the following method:

<?php

function module_example_form($form_state, $form_id = NULL) {
  // Form root settings.
  $form = array();

  // Set the submission callback for this form. 
  $form['#submit'][] = __FUNCTION__ . '_submit';

  // Set the request method for this form to GET instead of the default
  // of POST.
  $form['#method'] = 'get';

  // Remove unique form token so request can be cached. This is accompanied by
  // code in hook_form_alter to ignore the token and remove the build_id.
  $form['#token'] = FALSE;

  // Submit button.
  $form['go'] = array(
    '#type' => 'submit',
    '#value' => t('Go!'),
  );

  return $form;
}

/**
 * Implements hook_form_alter().
 */
function module_form_alter(&$form, $form_state, $form_id) {
  // Changes to the 'module_example_form' form.
  if ($form_id == 'module_example_form') {
    // Unset the hidden token field and form_build_id field.
    unset($form['#token'], $form['form_build_id'], $form['#build_id']);
  }
}

?>
Christopher
  • 1,813
  • 17
  • 15
4

I find that simply throwing away the CSRF token is not an option. We solved it using hook_theme_registry_alter() to overwrite the Drupal core theme_hidden() function so that the hidden form element 'form_token' is rendered as an <esi /> tag. The tag will cause Varnish to make a call to a PHP file which we allow to pass through the cache. This file will calculate the proper form token for the current user and will then output the HTML code for the hidden field. You can calculate this token without a Drupal bootstrap, but you will need a single DB query to fetch the *drupal_private_key* for your site, which is stored in the variable table.

malc0mn
  • 41
  • 1