Contact form textarea has no validation for length

Further comments from security.drupal.org:

#1 coltrane commented January 14, 2015 at 3:17am

@blasthaus Do you have more details or a POC on how this can be used for a DOS attack?

While it's true that the message is not limited I suspect any real attack attempt would be mitigated by server post field limit before using up resources enough to restrain the site. Additionally these forms are protected by flooding controls.

Comment #2 blasthaus commented January 14, 2015 at 12:17pm

@coltrane Thanks for the response. No I have no POC and really don't have a way to test.

What I have noticed is attempts on one server using multiple IP addresses to GET a page (which the attacker seemingly knows is a heavy one) multiple times a second and then after that I get a POST to the contact page with a long uri. Now it seems this is a different attack vector to try and overload the server, but it got me looking at the contact form, which is the ultimate target and a big one along with the usual suspects of user/%.

Yes mitigated points would include post_max_size and max_input_vars or equiv. being high in proportion to server memory in addition to the way mail is handled.

I'm only suggesting that the same technique used in user_account_form_validate() be used for this field, even though the contact textarea is not saved to the db. At least the server can be spared the hit of such annoying attempts.

     // user_account_form_validate()...
      $user_schema = drupal_get_schema('users');
      if (drupal_strlen($form_state['values']['signature']) > $user_schema['fields']['signature']['length']) {
        form_set_error('signature', t('The signature is too long: it must be %max characters or less.', array('%max' => $user_schema['fields']['signature']['length'])));
      }

However, I presume it would still be possible for an attacker to post unanticipated fields, so to go much deeper a change could be made to form api to ensure $_POST is in bounds i.e. using $_SERVER['CONTENT_LENGTH'] or $request = http_build_query($_POST); $size = strlen($request);

Obviously any textarea that an anonymous user has access to is vulnerable in the same way, so another way would be to validate all textareas in form API at least to some reasonable length.

Comment #3 greggles commented January 14, 2015 at 3:32pm
Component: » contact.module

I imagine the work effort from the contact form (accepting text, turning it into html to email it) is less than a node (accepting text, inserting it into one or more database tables, filtering it and then rendering it back to the user using Drupal's text formats / markup system. Unless there's something about a contact form that makes it worse than other forms in Drupal, I think the mitigations you mention (post_max_size, max_input_vars, apache/php timeouts) are the best solution.

Comment #4 blasthaus commented January 15, 2015 at 12:38am

The vulnerability could also be mitigated by any contrib module or custom module that does more processing on the contact form. The only 2 forms I know of that have textareas which are available by default to anonymous users in Core are this and the user signature. As shown, the user signature is doing this right.

The contact form along with user forms and node/add are the main targets for spammers as we all know. This core module only recently got to a point where it was reasonably secure. These two points and the performance hit from this form being open to any post length is why it's an issue for me.

We can move this to public issue if it's worthy of further discussion.

Comment #5 David_Rothstein commented January 22, 2015 at 6:33pm

How about we leave this open for another week or so for further comment, and then move it to a public issue?

I agree that the combination of server/PHP-level mitigations for giant POST requests, plus the flood control on the contact form, mean this isn't something that needs to be handled as a security issue.