Input Validation Introduction
This topic is based on Research Spotlight Technology Review – The Importance of Input Validation, CMS TRB Technical Topics, 12 October 2017.
The Equifax data breach is old news, but its lessons raise basic questions on effective IT processes for monitoring common vulnerabilities and the timely patching of the servers. The root of the problem Equifax faced lies in the vulnerability of the Open Source Apache Struts framework that allows an attacker to execute random code inserted into Content-Type of the HTTP header. It is possible to perform a remote code execution attack with a malicious Content-Type value. A workaround to this problem is to implement a servlet filter to validate Content-Type and throw away requests with suspicious values not matching multipart / form-data.
Some commercial vulnerability monitoring services have observed a new Apache vulnerability that is being actively exploited. The vulnerability (CVE-2017-5638) is a remote code execution bug that affects the Jakarta Multipart parser in Apache Struts. They have observed simple commands (e.g., whoami) as well as more sophisticated commands, including malicious code execution. The adverse effects of this inserted code include stopping the Linux firewall and subsequently downloading and executing a malicious payload from a web server simply by injecting this code into the HTTP header. All input must be validated to assure that malicious code will not be executed.
CMS TRA and CMS ARS Requirements
The CMS Services Framework (CMS Services Framework) and the TRA Multi-Zone Architecture (CMS Multi Zone Architecture) require challenge requests for validation, authorization, and malicious content. This generally occurs within the Presentation Zone, where business applications first receive data from external sources. Specifically, the Application Development, Web-based UI Services business rule for Input Validation (BR-UI-16) suggests that the CMS websites must validate all user input at a minimum on the server side, although validating on both the client and server side is recommended.
According to the Common Weakness Enumeration®:
Use an allowlist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a denylist). However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, and consistency across related fields, and conformance to business rules.
The CMS ARS Security Control, SI-10, Information Input Validation, provides supplemental guidance as follows:
Structured messages can contain raw or unstructured data interspersed with metadata or control information. If software applications use attacker-supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata. Consequently, the module or component that receives the tainted output will perform the wrong operations or otherwise interpret the data incorrectly. Prescreening inputs prior to passing to interpreters prevents the content from being unintentionally interpreted as commands. Input validation helps to ensure accurate and correct inputs and prevent attacks such as cross-site scripting and a variety of injection attacks.
Implications for CMS Development
Many CMS applications have used the Apache Struts framework extensively, and a few applications have used functionality specific to the file upload / download capability of this framework. The CMS data centers provision boundary appliances enable the header inspection and validation before the payload is accepted for further processing in the deeper tiers of the application.