Securing dompdf
The following is a list of options you have for securing your dompdf installation. Click through for more details and options related to each topic.
- Install dompdf to a location outside your website's document root
- Remove non-library code
- Restrict access to dompdf
- Disable embedded script support
- Sanitize user input
- Do not allow user control of operational configuration
Some of the files provided or generated by dompdf may expose your system to information disclosure, denial of service, and arbitrary code execution. Because the dompdf files do not need to be publicly accessible in order to make use of the library you should place them outside your website's document root.
The most vulnerable code from earlier version of dompdf has been removed as of the 0.7.0 release. However, some additional code in the form of unit tests has been added.
Removing this code is not strictly necessary if you place dompdf outside the publicly accessible directories of your server. But to avoid the possibility of exploit we still recommend you remove these files.
If you place dompdf in a publicly accessible location you can still achieve some level of protection by restricting who has access to the files. There are two relatively common methods used to restrict access to files and/or paths:
- limiting the hosts and/or IP address allowed
- requiring a username and password
How you implement these restrictions is highly dependent on your system and beyond the scope of this document.
Restricting access is not as secure as making the dompdf files inaccessible. Systems implementing access restrictions may still be vulnerable to more targeted attacks that trick authorized users into clicking specially crafted links that exploit dompdf vulnerabilities.
Embedded script (or inline script) is simply PHP code that dompdf evaluates during the rendering process. This feature can expose your system to arbitrary code execution, if you pass user-generated HTML to dompdf.
Instead of relying on sanitizing user input we recommend using Dompdf callbacks and Canvas class methods instead of embedded script. These methods provide access to the same functionality exposed through embedded script with a lower level of risk.
Class methods can be used after calling $dompdf->render() and before
calling $dompdf->stream() or $dompdf->output(). The class methods
give you access to the functionality exposed through the Canvas object.
As an example, consider adding text to every page in the document. With embedded script you could use the following HTML:
<html>
<body>
...
<script type="text/php">
if ( isset($pdf) ) {
$font = $fontMetrics->getFont("helvetica", "bold");
$pdf->page_text(72, 18, "Header: {PAGE_NUM} of {PAGE_COUNT}", $font, 6, [0, 0, 0]);
}
</script>
</body>
</html>To do the same with the class methods you could use the following PHP:
$dompdf = new Dompdf();
$domdpf->loadHtml($html);
$dompdf->render();
$font = $dompdf->getFontMetrics()->getFont("helvetica", "bold");
$dompdf->getCanvas()->page_text(72, 18, "Header: {PAGE_NUM} of {PAGE_COUNT}", $font, 6, [0, 0, 0]);
$dompdf->stream();There is one major limitation with the class methods. Because of the way dompdf renders documents you can not use objects to encapsulate varying content and place that content on all pages. The exception being page text and page scripts, which are rendered on all pages when the final PDF is compiled when the stream or output methods are called. Please see the usage documentation for more information.
While not a perfect solution, you can decrease the attack surface by sanitizing content that originated outside the system (such as from end users). User input sanitization can take many forms, but the most basic would be to HTML-encode user content that shouldn't contain HTML elements. Content that may contain HTML can restrict which elements are allowed.
You should never provide untrusted users control over the operational configuration of your Dompdf installation. This includes any of the configuration options available through the Options class. These options are a mix of administrative (e.g., rendering artifact paths) and functional (e.g., page size) settings. Because these options are intended to be set by the implementation and not by users the values are not sanitized by Dompdf. Allowing untrusted users to specify values without restriction could lead, in extreme cases, to execution of user code execution.
| Vulnerability | References | Type | Severity | Mitigations | Addressed In |
|---|---|---|---|---|---|
| Resource exhaustion caused by infinite recursion when validating SVG images | GHSA-3qx2-6f78-w2j2 | Resource Exhaustion | Medium | Yes | 2.0.4 (41cbac16) |
| URI validation failure on SVG parsing | GHSA-3cw5-7cxw-v5qg, CVE-2023-23924 | Remote Code Execution | Critical | Yes | 2.0.2 (7558f07f) |
| Remote Code Execution via font installation | #2994, CVE-2022-41343, Tanto | Remote Code Execution | Critical | No | 2.0.1 (#2995) |
| External Control of File Name or Path | #2564, CVE-2022-2400, huntr.dev | Information Disclosure | Medium | Yes | 2.0.0 (#2859) |
| Server-Side Request Forgery | #2564, CVE-2022-0085, huntr.dev | SSRF | Medium | Yes | 2.0.0 (#2859) |
| Improper Restriction of XML External Entity Reference | #2564, CVE-2021-3902, huntr.dev | Remote Code Execution | Critical | No | 2.0.0 (#2859) |
| Deserialization of Untrusted Data | #2564, CVE-2021-3838, huntr.dev | Remote Code Execution | Critical | Yes | 2.0.0 (#2859) |
| Remote Code Execution via remote font installation | Positive Security, #2598 CVE-2022-28368 | Remote Code Execution | Critical | Yes | 1.2.1 (#2808) |
| Information Disclosure via local image | #2152 | Information Disclosure | Low | No | 0.8.6 (#2215) |
| Remote Code Execution (complement of CVE-2014-2383) | CVE-2014-5013 | Remote Code Execution | Critical | Yes | 0.6.2 |
| Denial Of Service Vector | CVE-2014-5012 | Information Disclosure | Medium | No | 0.6.2 |
| Information Disclosure | CVE-2014-5011 | Information Disclosure | Medium | No | 0.6.2 |
| Arbitrary file read in dompdf using PHP stream filters | CVE-2014-2383 | Information Disclosure | Medium | No | 0.6.1 (partial), 0.6.2 |
| PHP remote file inclusion vulnerability in dompdf.php | CVE-2010-4879 | Remote File Inclusion | Critical | Yes | 0.6.1 |
| Information disclosure due to directory traversal | yehg | Information Disclosure | Medium | No | 0.5.2 |