RackForms v7.6.1
entry viewer
Site Tag Line
Latest Release: Build 936 - April 21, 2020
Contact Us  Purchase Options Purchase Options Contact Us
header-image


 

Starting in late 2019 several major browser vendors implemeted a new security mechanism called Same-Site Cookies.

The purpose of this change is to restrict information that can be set and accessed by any domain that's not the primary domain you're currently visiting. This affects form creators as a common deployment pattern is placing an iframe to www.b.com on a site www.a.com. In this case the iframe form domain, www.b.com, is prevented from setting any cookies.

Blocking cookies in this manner presents a critical issue, as in order for a form to process fields and submit results it must save page requests to just such a cookie. If cookies are blocked this cannot happen, and users will not be able to submit results or even navigate to other pages in the form.

Implications

While an important security feature the unfortunate side-effect of this change is the way we deploy and use forms will need to change. As of now their are two main types of mitigation. The first is changing how we create and deploy forms, the second is to update your server's software to better handle the new restrictions.

Changing Form Creation And Deployment

The first class of fix is to simply avoid the new restriction by changing how we create and deploy forms. This starts with building forms that are simply not embedded within another page. RackForms has a wealth of tools for styling full-page forms, meaning we can simply direct users to a full form page and redirect back to our original page upon completion.

A second version of the first fix is to host forms and parent content on the same domain. That is, if our parent page is www.a.com, the form is also hosted on the same server (www.a.com).

The next class of fix is technical and involves updating our server platform to confirm with the new specification.

Updating The Server

To ensure your forms run appropriately in this new security context a few steps must be taken:

  • First, edit your php.ini to enable secure, http only cookies:

    session.cookie_secure = 1
    session.cookie_httponly = 1

  • Next, we'll tell the PHP session system to tag each cookie request with: SameSite = None

    This setting's implementation differs based on your PHP version. If running 7.3.1 or higher we'll simply update our php.ini as follows:

    session.cookie_samesite=Never

    If running a PHP version older than 7.3.x we'll need to configure our web server to modify each cookie request. In this case we'll cover Apache, please check with your server vendor for others.

    Start by making sure mod_headers.so has been enabled. This task will differ based on your OS and server management software, but will eiether be modifying your httpd.conf directly and making sure this line doesn't have a # in front:

    LoadModule headers_module libexec/apache2/mod_headers.so

    Alternatively, use your server's management tool, such as Webmin, to enable the headers module.

    Now that we have Apache headers enabled, we'll need to modify our .htaccess file so that each header cookie request appends the SameSite=None tag.

    Header always edit Set-Cookie (.*) "$1; SameSite=None;Secure"

    With these steps complete the server should now be sending the proper cookie flags.

Summary

In summary, new cookie rules mean deploying forms is a bit more difficult than it used to be. In many cases the easiest solution will be to simply host forms on the same domain as the parent page. Failing that, the next best solution is to simply build full-page forms and link users to them from your parent site. Finally, we can also modify our server software so that we append the SameSite attribute to secured cookies.


So many features, So little time