In some instances, it can be beneficial to constrain an application's input to only that which meets specific criteria. Such input may be created directly by a person (i.e., a human) or may be the direct product of a computing component.
Input from Humans
Ordinary forms are designed for gathering specific input from a human. For example, if a form field requires a date, the only appropriate input is a valid date (such as Jun. 20, 2001). Electronic forms exists (e.g., JetForm™), designed to limit the format and the type of input that a human enters into such forms. However, many such electronic forms are not well suited for collecting input from computing components.
Input from Computing Components
Many computing components accept input directly from other computing components. Even if the data provided by a computing component originates from a human, such data is considered input from a computing component when it is accepted directly from that component and not a human.
Broadly speaking, a computing component is one that excludes a direct human intervention. Examples of such computing components include (by way of example, but not limitation): applications, program modules, Web pages, Web servers, client computers, and mobile devices.
A prime example of input from a computing component is input accepted by a Web server from another computer (e.g., a client) over a communications network (such as the Internet). Although the bulk of such input is benign and has valid formatting, sometimes such input is accidentally or purposefully made ill-formed. Such purposeful actions may be part of a malicious attack directed by one or more attackers (i.e., interlopers).
Malicious Attacks
Malicious attackers routinely gain unauthorized access into computing systems (e.g., Web servers) by exploiting poor or non-existent filtering of input from computing components.
A malicious interloper may attack a computer system by supplying input, which can manipulate the system into performing otherwise unauthorized actions targeted at subverting the integrity of the system. Examples of such malicious attacks include buffer overruns and other forms of invalid input.
More information on these types of attacks may be found in the following articles from CERT®:                “Understanding Malicious Content Mitigation for Web Developers”, CERT Coordination Center, February 2000, http ://www.cert.org/tech_tips/malicious_code_mitigation.html and http://www.cert.org/tech_tips/malicious_code_FAQ.html; and        “Malicious HTML Tags Embedded in Client Web Requests”, CERT Coordination Center, February 2000, http ://www.cert.org/advisories/CA-2000-02.html).Buffer Overruns        
To cause a buffer overrun, an attacker sends much more data to an application (such as a Web application) than the application can handle in its buffer. Here, “much more” means more data in size than the application implicitly assumes it should be receiving. If the application does not check the length of the data received, it may simply copy it into a fixed-size array of bytes on the stack, often known as a “buffer”. If the copy goes beyond the end of the buffer (“overruns” it), the application may unintentionally modify adjacent memory and potentially overwrite executable code or data, thereby causing a crash-or more sinisterly, overwrite its own code it with new executable actions to direct the computer to perform the bidding of the attacker.
This attack can be prevented if the incoming data is examined to ensure that it does not exceed a given size. However, failing to examine incoming data is typically not examined in this manner is a frequent programming mistake.
Malicious Content
Typically, Web pages contain both text and HTML (HyperText Markup Language) content that is generated by a server and interpreted by a client browser. Servers that generate static pages have full control over how the client will interpret the pages sent by that server. However, servers that generate dynamic pages do not have complete control over how their output is interpreted by the client. If malicious content is introduced into a dynamic page, neither the server nor the client has enough information to recognize that this has happened and therefore take protective actions.
In HTML, to distinguish text from markup, some characters are treated in a special manner. The grammar of HTML determines the significance of “special” characters—different characters are special at different points in the document. For example, the less-than sign (“<”) typically indicates the beginning of an HTML tag. Tags can either affect the formatting of the page or introduce a script program that the browser executes (e.g., the <SCRIPT> tag introduces code from a variety of scripting languages).
Many Web servers generate Web pages dynamically. For example, a search engine may perform a database search and then construct a Web page that contains the results of the search. Any server that creates Web pages by inserting dynamic data into a template should check to make sure that the to-be-inserted data does not contain any special characters (e.g., “<”). If the inserted data contains special characters, the user's Web browser is likely to mistake them for HTML markup. Because HTML markup can introduce programs, the browser could interpret some data values as HTML tags or script rather than displaying them as text.
The risk of a Web server not doing a check for special characters in dynamically generated Web pages is that in some cases an attacker can choose the data that the Web server inserts into the generated page. Then the attacker can trick the user's browser into running a program of the attacker's choice. This program will execute in the browser's security context for communicating with the legitimate Web server, not the browser's security context for communicating with the attacker. Thus, the program will execute in an inappropriate security context with similarly inappropriate privileges.
This vulnerability is sometimes described as “cross-site scripting.”
Impact. Users may unintentionally execute scripts written by an attacker when they follow untrusted links in Web pages, mail messages, or newsgroup postings. Users may also unknowingly execute malicious scripts when viewing dynamically generated pages based on content provided by other users.
Because the malicious scripts are executed in a context that appears to have originated from the targeted site, the attacker may have full access to the document retrieved (depending on the technology chosen by the attacker), and may send data contained in the page back to their site. For example, a malicious script can read fields in a form provided by the real server, and then send this data to the attacker. The attacker can access restricted web sites from the client, or violate domain security policies in other ways.
The specific impact can vary greatly depending on the language selected by the attacker and the configuration of any authentic pages involved in the attack. Some not immediately obvious examples are included here.
Attacks May Come in Many Forms. Attacks may be made persistent through poisoned cookies. An attacker may access restricted web sites from the client. Domain-based security policies may be violated. The use of less-common character sets may present additional risk.
Input-Validation Filters
Since unvalidated input can cause these problems, then validating the input prevents them from occurring. A set of instructions (either to a human or to a computer) that examines input and rejects any invalid input is known as an input-validation filter. Input-validation filters for filtering input from computing components will prevent a malicious attacker from wreaking havoc in the manner described above. To validate an input, it may be filtered by the very application program that uses the input or it may be filtered before that program receives the input.
FIG. 1 shows a computer system, specifically a Web server 130, operatively coupled to a typical computer client 110 via a network 120, such as the Internet. The interloper on computer client 110 sends malicious input to the Web server 130 with hopes of infiltrating one of its applications (such as applications 134a, 134b, 134n) and/or its data.
With internalized filtering, the application programs themselves filter the input. With externalized filtering, the Web server 130 filters the input for the applications. More specifically, the input filter 132 of the server filters its input.
Internalized Filtering
Generally, software developers appear to be well positioned to write their code so that it filters incoming data to ensure that such data is valid and legal. When the application program filters its own input, then filtering is internalized. Unfortunately, most developers are focused on producing functional code rather than code resistant to such attacks; as a result, such security features are often ignored. In reality, software developers tend to be inconsistent in performing all necessary checks for validity of the inputs their applications receive.
Moreover, software developers may not actually be well positioned to write their code so that it filters incoming data to ensure that such data is valid and legal. It is unrealistic to expect the developers to know every possible form of attack on their software; new attacks are often invented, which lead to new requirements for input validation. For example, the “format string attack,” as described in http://news.cnet.com/news/0-1003-200-2719802.html, was discovered in the summer of 2000. One approach to preventing this attack via input validation requires rejecting all input involving percent signs. Therefore, it is prudent practice to have a mechanism for performing additional validation checks in addition to the internal checks.
Externalized Filtering
External filtering for an application is when input into an application is filtered before the application receives the input. The filtering is performed external to the application for which the input is destined.
The prudent practice of externalized filtering may be implemented by a system administrator (or others). An administrator is well positioned to decide when performing such input validation is worthwhile. A good rule of thumb is that filtering should be done when performance considerations (e.g., the overhead incurred by the validity checks) are outweighed by the explicit need for robustness in environments, which cannot be guaranteed to be secure.
In general, externalizing the checks on the input data into a separate filter (i.e., external to the application) ensures that no assumptions (about the application's input data) specified in the filter are left unwarranted.
As illustrated in dashed box 150 (labeled “Background”), many system administrators, on their own, manually write one or more sets of filtering instructions as needed for each application. A filter (such as input filter 132) uses these instructions to filter incoming data. Sometimes the sets of filtering instructions are called “filter scripts.”
The system administrator (of box 150) typically writes these sets of filter instructions in one of several specific languages. Such languages may include those traditionally known as “scripting” languages. This human (such as a system administrator) may use a traditional text-based user-interface (UI), as shown by monitor 152. Effectively, the manually written instruction set 154 becomes the input filter 132 of the server 130. Typically, a server has a mechanism (e.g., ISAPI) for invoking external filters. This mechanism may be used to invoke the instruction sets as an input filter.
External Filters
In a typical computer system, external filters, such as filter 132, are little program modules are performed on the computer system when it is started. They stay in memory until the computer system shuts down. The external filters can be configured to receive a number of special filter-event notifications that occur with each request that the computer system receives, and with each response that the computer system generates in return. They are called external filters because they are external to the applications that actually receive the input. Common examples of such external filters are “ISAPI filters.”
ISAPI Filters. Internet Server API, an API for the Microsoft® Internet Information Server® (IIS) Web server. ISAPI filters are DLLs loaded into the process and they stay in memory until shut-down. After they are loaded, ISAPI filters can be configured to receive a number of special filter-event notifications that occur with each input received (e.g., HTTP request that the Web server) and with each response that the Web server generates in return.
When an ISAPI filter is loaded, the filter passes a data structure to the Web server containing, in addition to other information, a bit field that specifies the types of filter-event notifications for which the filter should be notified. Each time one of these events occurs, an event notification is started, and every ISAPI filter that is set to monitor that event is notified.
Instructions for Filtering
Herein, “instructions” are a set of commands that can be executed without user interaction. Generally, they are computer-implemented instructions. A filter language is a programming language through which one can write the instructions of a filter.
To effect input-validation filtering, many humans (such as system administrators) manually write filtering instructions, such as instruction set 154, on an ad hoc basis. These instructions examine the incoming data as it is received by the system, but before the destination applications receive that data. If the incoming data passes muster, it is forwarded on to the applications that need it.
The following are examples of instruction sets (or partial sets) that a human (such as a system administrator) may write to filter inputs: 
Shortcomings of Manually Generated Filter Instructions
Although the manual generation of input-validation sets of filter instructions does address the ills inflicted by the malicious attacks described above, it does so at the expense of additional manpower. Most humans (such as system administrators) are hard-pressed to find resources (e.g. time) to research and write customized instructions for each separate application receiving input and for each corresponding variety of malicious attacks.
This conventional, manual, ad hoc solution to the problem is slow and inefficient: each human (such as a system administrator) must manually write a filtering instruction for each need. Such a programming practice is inherently slow, tedious, and error-prone.
What is needed is an automated approach for generating filtering instruction sets based upon what the human (such as a system administrator) defines as valid input data and valid parameters of such data for a specific application. This way, the human (such as a system administrator) can avoid the time and expense of manually writing filtering code like the one shown above.
USPTO Backgrounds
USPTO Backgrounds