Security considerations when working with TYPO3 Formhandler extension

The TYPO3 extension formhandler is known as the swiss army knife, when it comes to all kind of forms in TYPO3. Formhandler is flexible in many ways and allows a TYPO3 integrator not just to create complex forms with several validation options, but also to prefill fields when a form is loaded or to save/update fields in the TYPO3 database when a form is successfully submitted. I really like this extension and use it in many projects because of it's clean structure, flexibility and because it is actively maintained.

Formhandler is often not just used to create simple contact forms, but also to provide forms which shows, creates or modifies records from/in the TYPO3 database. If the TYPO3 integrator does not think about security at this point, there are several things that can go wrong.

I'm not really a security expert, so if I write totally nonsence in this article, feel free contact me, so the article will contain correct and helpfull information for others.
Example 1 - PreProcessor_LoadDB and GP variable causing leackage of sensitive data

In the first example, a website user does submit data through a form from a third party extension. After the data is submitted, the user receives an e-mail containing a link to a formhandler page, where the user has to fill out some other form fields. The link, which is sent to the user is like shown below:

http://www.domain.tld/myform.html?formname[uid]=123

The parameter "formname[uid]" contains the uid of the newly created record from the third party extension.

When I opened the form the first time, I did not see anything special (expect from the URL parameter). All form fields where empty, so I asked myself, why the URL contained the parameter. After I had a look at the output of the website, I knew, what the URL was used for. The output of the website contained 3 hidden formfields like shown below:

<input type="hidden" name="formname[uid]" value="123">
<input type="hidden" name="formname[recipientname]" value="John Doe">
<input type="hidden" name="formname[email]" value="[email protected]">

Ouch, now I could easily find out, who else did submit data through the form from the third party extension by just increasing/decreasing the uid. The original TYPO3 integrator used a PreProcessor_LoadDB preprocessor to load the additional data in the hidden fields.

Depending on how the database lookup is integrated, it could result in a SQL injection, if you just pass the given UID directly to the select.where of the PreProcessor_LoadDB preprocessor.

Example 2 - Finisher_DB and GP variable causing unwanted data manipulation

The second example uses the same form as shown in example 1. When a website user fills out the form, all fields get submitted to the server and an e-mail ist sent with a Finisher_Mail finisher. As you may guess, the recipient email is taken from the hidden input field, which in case is very bad, since you just can replace the e-mail address in the hidden field with another e-mail address and after form submission, a totally different recipient will receive an e-mail sent from the server.

If you don't think it can get worst, it actually will. The formhandler setup did also contain a Finisher_DB finisher, which updated some fields on a given record in the TYPO3 database. Since the uid to this record is parsed directly through GET/POST variables, it can just be changed and within that, you can just submit the form with different uids and update the fields that the Finisher_DB updates with garbage - of course for all records in the table.

Problem summary and solution approach

All named problems rely on the some cause - user input is just seen as trusted. At no point it is actually checked, if the user has changed the uid or has replaced the values from hidden input fields with own content.

Actually, to take benefit from PreProcessor_LoadDB to prefill fields with Database values or Finisher_DB to update records, you actually need to know the uid from the record where to fetch/update the desired values. So how can you make sure, that the uid is not changed by the user?

Adding a HMAC to the URL

We can add a second parameter to the URL, that contains the HMAC for the uid parameter. This HMAC will later on be used to validate, if the uid has been modified by the user.

TYPO3 has a HashService (TYPO3\CMS\Extbase\Security\Cryptography\HashService), which can be used to generate and validate HMACs. To generate a HMAC for a given string, the TYPO3 HashService uses the TYPO3 encryption key as shared secret. The function generateHmac($string) returns a HMAC for a given string as shown below (short version without type/encryption key check)

hash_hmac('sha1', $string, $encryptionKey);

The TYPO3 HashService also has a function called validateHmac($string, $hmac) to validate, if the given string matches a given HMAC.

Using the generateHmac function, I end up with formhandler URLs like shown below:

http://www.domain.tld/myform.html?formname[uid]=123&formname[uidhmac]=averylonghmac

Adding HMAC check to formhandler

Formhandler has interceptors, which can be used on init and on save of a form. Init-interceptors are called each time a form is displayed and save-interceptors are called before the form-finishers are executed. So the best approach to add the HMAC check is to do this through an own interceptor.

I created a configurable interceptor, which is able to use the validation functions from the TYPO3 HashService.

The source code for the new interceptor is available in this gist. You can just create an own extension with this class and then use it in the formhandler TypoScript settings. Below follows an example TypoScript setup, which uses the new interceptor.

initInterceptors.1 {
  class = Tx_MyFormhandlerExtension_Interceptor_HashService
  config {
    redirectPage = 11
    validateHmac {
      fields.uid = uidhmac
    }
  }
}  

The configuration above now validates, if the given uidhmac is the correct HMAC for the given uid. If this validation fails, the user is redirected to a configured page.

You can also use the interceptor with appended HMAC string. Those HMACs are created using the appendHmac function in the HashService. Basically it just takes the given string and appends the HMAC for the string to it. An url could look like shown below.

http://www.domain.tld/myform.html?formname[appendedhmac]=123averylonghmac

To validate the given appended HMAC string you can use the interceptor as shown below.

initInterceptors.1 {
  class = Tx_MyFormhandlerExtension_Interceptor_HashService
  config {
    redirectPage = 11
    validateAndStripHmac {
      fields.1 = appendedhmac
    }
  }
}