I use Formidable Forms for all my web application development using WordPress. The time spent learning the framework is repaid (just) by the speed with which I can build new front ends. In the last year the documentation is improved greatly and the team is targeting enterprise developers.

Formidable Forms is stateless and all information is passed between screens using URL variables. This is great for clustering but poses some security challenges for the developer. I describe these challenges below and suggest a fix. In the absence of a fix a developer can implement secure solutions by creating their own secret tokens to pass between pages. This will be the subject of a later post.

Summary of Issue

Formidable provides Form Level security but not Entry (tuple) Level  security. Entry (tuple) Level security can be implemented by the use of secure views. However this would not be necessary if Edit Links were signed to prevent URL hacking.

Form Level Security

Reading Form data (no problems)

The developer implements Read security using views,

horizontal security using Filters (WHERE)
vertical security by choosing which fields to display in the CONTENT of the view

Where the words “horizontal” and “vertical” refer to rows and columns in a table or Entries and Fields in a Formidable Form.

Writing to Forms

In General Settings the developer can allow the user front end WRITE access to either all Entries in a Form OR only their own Entries.

Let us consider the most general scenario where they are given WRITE access to all records. The only way that a user can edit an entry is to go to a page that contains the form with a URL that contains the edit action and and entry id. For example,

• /my-edit-page/?action=”edit”&entry=25

The user cannot be expected to magically guess the Edit Link so typically the developer will have a view that implements the business logic that creates the Edit Link.

The problem is that the User can defeat the business logic by hacking the link in several ways,

• The can change /my-edit-page/ to allow them to use a different version of the form – for example one with more fields showing. (Vertical Security)
• They can change the “entry”. (Horizontal Security)

Vertical Security is weak

The developer can define additional Field attributes in the Formidable Form shortcode to restrict the fields that can be edited. Consider the case where the form appear on two pages in two versions,

• /my-edit-page/?action=”edit”&entry=25
• /my-edit-page-fewer-fields/?action=”edit”&entry=25

The User can defeat vertical security by changing the Page part of the URL
Horizontal Security is weak

• /my-edit-page/?action=”edit”&entry=25 can be changed to
• /my-edit-page/?action=”edit”&entry=15

An example of an attack: I have a form that contains Bookings and a view that shows the user future bookings so that he can make edits that reflect his changing requirements. My view does not allow the user to edit past bookings because these are used for billing.

The User changes 25 to 15 and changes a past booking to cost less.

This attack is possible because by default Formidable permits URL hacking. A clever developer must understand exactly how Formidable works and his own application works and write custom code to defeat attacks.

A Proposed Mitigation

Formidable Forms is stateless therefore the Edit Link is fundamental to application design.

Formidable Forms should sign each Edit Link with an MD5 hash (say) and check this hash when creating its URL parameters. For example,

• /customer-record/?action=edit&entry=31&signature=A0423534H

If the user changes any of the URL parameters the signature would not match and the an error would be thrown.

This would prevent vertical attacks because the Page could not be changed and horizontal attacks because the Entry could not be changed.