Gravity PDF 6.4: A Focus on Security

Featured image for the Gravity PDF 6.4 Release blog post

After the discovery and subsequent fix of a reflected cross-site scripting vulnerability, the focus has been on auditing the codebase to improve the overall security. Thanks to the help of the WordPress.org Plugins Team, we were able to identify a vulnerability in the Core Font Installer, and refactor a number of areas in the codebase that had a bad smell. To put it in simple terms, we rewrote a bunch of legacy code to follow the latest best practices, included additional checks and balances, updated third-party software, and fixed a few bugs, too. Gravity PDF 6.4 is the culmination of this work. 

tl;dr A vulnerability in the Core Font installer has the potential for a remote code execution attack (RCE) under very specific conditions. Other security-related changes were made to reduce the potential of any unknown vulnerabilities that could be exploited. For developers, there are changes in functionality you should be aware of.

Core Font Installer

Let’s start with the elephant in the room: the Core Font installer vulnerability. Without going into too many specifics, for the vulnerability to be exploited on a typical WordPress installation an attacker would need direct access to a compromised user with the administrator role and a non-standard directory structure needs to exist on the server. The likelihood of this occurring is low, but if it did, a bad actor could successfully execute an RCE attack, and that puts this vulnerability in the medium severity category. This vulnerability is present in Gravity PDF 5.0 – 6.3.1.

Allowed Core Template HTML

In this release, all HTML generated in Core and Universal PDF templates are sanitized with the help of a modified version of wp_kses_post(), which includes support for PDF-specific tags and styles. This change doesn’t affect the standard Gravity Forms field output in your PDFs, but if you are doing any weird and wonderful things with Custom Content you may need to tweak your HTML mark-up.

Capability Check

To bring Gravity PDF in line with Gravity Forms capabilities, a user will need the gravityforms_edit_forms capability to manage PDFs on a form, which includes adding, editing, and deleting PDFs. Previously the gravityforms_edit_settings capability was used. The Font Manager capability was also adjusted to gravityforms_edit_settings

This change will only affect websites that use custom roles to restrict user access to specific Gravity Forms features.

PDF Engine Update

This release saw most Gravity PDF dependencies get updated to the latest version, including the mPDF library which is responsible for turning HTML into PDFs. The mPDF update includes a change in how images are processed which caused some display problems for the Tritan and Aryal templates. This was on our radar early in the development process and we release an update for both templates at the start of this month

License Keys

If you’ve a premium Gravity PDF extension installed on your website, the License settings page now masks saved keys so they cannot be copied.

Functionality Changes for Developers

Template Filename

In the past, we had no hard restrictions on the filename that could be used for a PDF template, and developers were free to use any valid string supported by the filesystem. However, if taking advantage of the template configuration file, the config class name needed to be valid PHP and follow our naming conversion which meant no special characters. 

To prevent any confusion and increase reliability, we have added restrictions on the template filename. It must now only contain the following: A-Z, a-z, 0-9, underscore (_) or dash (-), followed by the .php extension. Existing templates created for v4 or higher that don’t follow this naming convention will remain functional (with the exception of deleting templates via the PDF Template Manager), but aren’t guaranteed to in future versions. 

To prevent any problems moving forward, we recommend developers update template names to follow the new convention.

Helper Parameters

Template

The template name helper parameter is a quick and easy way for administrators to swap between PDF templates. From 6.4, this input must only contain: A-Z, a-z, 0-9, underscore (_) or dash (-). This change also affects legacy templates (v3) which haven’t been officially supported since 2017.

Data and HTML

The data and html helper parameters are useful debugging tools to help administrators build custom templates. From 6.4, this functionality will only work if the WordPress environment is not production, or Gravity PDF Debug Mode is active

How to Update Gravity PDF

This update is available via WordPress One-Click Updates, or the plugin can be downloaded from WordPress.org and installed manually via File Upload or FTP.

If you have any questions or need assistance, please reach out to our friendly support team.

Changelog

Security Updates

  • Move from early escaping to late escaping variables on output
  • Add additional validation checks to the Core Font installer
  • Escape text returned from WordPress l10n functions
  • Escape any and all strings from the Gravity Forms form object, in any context (including PDFs)
  • Move to earlier sanitizing of user input
  • Custom PDF template filenames are now limited to the following characters: A-Za-z0-9_-
  • The ?html=1 and ?data=1 developer helper parameters now only work in non-production environments (WP_ENVIRONMENT_TYPE !== 'production'), or when Gravity PDF Debug Mode is explicitly enabled
  • Prevent directory traversal when loading the various Gravity PDF UI components
  • Change PDF Form Settings capability check from gravityforms_edit_settings to gravityforms_edit_forms
  • Change Font Manager CRUD capability check from gravityforms_view_entries to gravityforms_edit_forms
  • Switch to sodium_crypto_secretbox_keygen() function with modified fallback to wp_generate_password() when generating new PDF URL signing secret key
  • Switch from a Text to Password field for the Gravity PDF License Keys
  • Update PHP and JavaScript dependencies

Performance Update

  • Register JavaScript in the footer on Gravity PDF admin pages

Privacy Update

  • Added “Get more info” link in the Core Font Installer instructions, and disclaimer to plugin’s README.txt installation section

Developer Change

  • Added \GFPDF\Statics\Kses::output($html) and \GFPDF\Statics\Kses::parse($html) methods for use with escaping/sanitizing HTML in PDFs (as an alternative to wp_kses_post()).

Bugs Fixed

  • Fix issue passing PDF URL to Gravity Forms Mailchimp add-on
  • Allow hyphen in custom font key when updating or deleting to remain backwards compatible
  • Fix PHP8.1 type conversion warning in the template cache when transient’s are flushed
  • Remove empty repeater sections from Core PDFs when not filled in by the user
Stay on top!
Never miss out on the latest news and updates in Gravity PDF land. Subscribe to our newsletter now!