CSRF Vulnerability on the Ontario Ministry of Labour Complaint Form

Many government agencies offer forms in both PDF and web formats. The web version often mirrors the PDF layout, providing a familiar interface with a submit button at the bottom. The Ontario Ministry of Labour, Training and Skills Development’s workplace health and safety complaint form follows this pattern, allowing workers to submit concerns about workplace safety anonymously or with their contact information.

When examining the form’s submission mechanism, I discovered a critical vulnerability that could allow bad actors to intercept form submissions, display arbitrary content on the government domain, and potentially de-anonymize complainants. This article details the discovery process and the security implications of this vulnerability.

Understanding the Technology Stack

The form is powered by Adobe LiveCycle, an enterprise form management platform. The /lc/ path in the URL structure is a telltale sign of LiveCycle deployment. This can be further confirmed by examining HTTP response headers or analyzing error messages returned by the server.

The server configuration reveals verbose error messages that disclose sensitive information, including Apache version numbers and internal system details. Verbose error disclosure in production environments is a security anti-pattern that can aid malicious actors in reconnaissance.

Context: Adobe LiveCycle reached end of core support in March 2018, with extended support ending in March 2020. The Ontario government is processing sensitive workplace health and safety complaints through software that has been unsupported for over five years. Adobe’s official notice recommends migrating to Adobe Experience Manager Forms.

The Discovery: An Unusual URL Parameter

The form’s URL contains several parameters that control its behavior:

https://www.sus.gov.on.ca/lc/content/mgcs/profiles/default.html?contentRoot=repository:///Applications/016-2026/1.0/Assets&template=016-2026E.xdp&submitUrl=https://localhost:12443/rest/services/016-2026/Processes/HTML/SubmitForm&submitServiceProxy=https://www.sus.gov.on.ca/sub-proxy/all

Two parameters immediately caught my attention:

• submitUrl: Points to https://localhost:12443/rest/services/016-2026/Processes/HTML/SubmitForm — a reference to localhost on a non-standard port, which is unusual for a production website
• submitServiceProxy: Points to https://www.sus.gov.on.ca/sub-proxy/all — appears to be a proxy endpoint for form submissions

The presence of a localhost URL parameter in a production environment suggested that the form submission mechanism might be more flexible than intended, potentially allowing manipulation of where form data is sent.

Investigation and Testing

My initial hypothesis was that modifying the submitServiceProxy parameter would allow redirecting form submissions to an externally controlled server. However, this approach was blocked by Cross-Origin Resource Sharing (CORS) headers that prevented the form from submitting to different domains.

I then attempted to modify the submitUrl parameter to point to an external domain. The first test endpoint returned an error message that initially perplexed me:

This error suggested that the endpoint I was testing was rejecting the POST request, possibly due to an unexpected HTTP referrer header or content type.

A second attempt using a different domain resulted in a 403 Forbidden error:

The error message mentioned “Cloudflare,” which initially seemed inconsistent since the government website didn’t display typical Cloudflare response headers. I realized that the domain I was using for testing (bandzar.com) is hosted behind Cloudflare, and the error was coming from my test endpoint, not the government server.

To gain better insight into what was occurring, I created a request bin using Pipedream, a workflow automation platform that provides detailed request logging. When I modified the submitUrl parameter to point to the Pipedream endpoint, something unexpected happened: the response from Pipedream was proxied through the government domain and displayed back to the user.

Examining the Pipedream console revealed all the POST data that was submitted through the form:

This demonstrated that form submissions could be intercepted by a malicious third-party server while appearing to be processed normally by the government website.

Confirming the Vulnerability

Since the webpage response is proxied through the government domain, a bad actor can return arbitrary HTML and JavaScript that will be displayed to users on the official government website. This creates a significant attack vector.

To demonstrate this capability, I returned a simple JavaScript alert:

The ability to execute arbitrary JavaScript on a government domain opens numerous attack possibilities, as detailed in the following section.

Security Implications

This vulnerability has several serious security implications:

Data Interception

A bad actor could craft a malicious URL with a modified submitUrl parameter pointing to their own server. If an employer distributed this link to employees, the form would appear to function normally, but all submitted data—including personal information, workplace safety concerns, and whether the complainant requested anonymity—would be sent to the bad actor’s server instead of the government. This completely defeats the purpose of anonymous reporting.

Phishing Attacks

Because arbitrary HTML can be displayed on the official government domain, a bad actor could create a convincing fake login screen. Since the page is served from a legitimate government domain, password managers would likely autofill credentials, making credential theft trivial. Users would have no reason to suspect the page is malicious, as it appears to be hosted on the official government website.

Session Hijacking

JavaScript executed on the government domain has access to cookies and session tokens. A bad actor could leverage this to exfiltrate session cookies, potentially gaining unauthorized access to other government services if the same authentication system is used across multiple applications.

Firewall Bypass

By proxying data through a whitelisted government domain, a bad actor could potentially bypass corporate firewalls and security controls. Many organizations whitelist government domains, allowing this exploit to function even in restricted network environments.

Anonymity Defeat

The workplace health and safety complaint form includes an option for anonymous submission. This vulnerability allows a bad actor to:

1. Intercept the complaint before it reaches the government
2. De-anonymize the complainant by capturing their IP address and any identifying information in the form
3. Display a confirmation message to the user, making them believe their complaint was successfully submitted

This completely undermines the protection that anonymous reporting is intended to provide.

Conclusion

According to Adobe’s documentation, the Mobile Forms Service Proxy acts as a pass-through when the submitUrl parameter is not present in the request. However, the documentation does not specify restrictions on what domains the submitUrl parameter may point to, suggesting this may be a design flaw in LiveCycle rather than a misconfiguration.

It remains unclear whether this vulnerability affects all LiveCycle applications or if this particular government deployment is particularly poorly configured. However, the fact that this vulnerability exists on software that has been unsupported since 2020 raises broader concerns about other potential unpatched security issues.

This discovery highlights the critical importance of:

• Validating and sanitizing all URL parameters, especially those that control where data is sent
• Implementing Content Security Policy (CSP) headers to prevent arbitrary JavaScript execution
• Migrating from end-of-life software, particularly for systems handling sensitive personal information
• Regular security audits of government systems that process citizen data

The vulnerability has been reported to Adobe through their HackerOne bug bounty program. Given that LiveCycle is end-of-life, it is unclear whether a patch will be provided, making migration to supported software the only viable long-term solution.