CA2584940A1 - Method and system for stateless validation - Google Patents
Method and system for stateless validation Download PDFInfo
- Publication number
- CA2584940A1 CA2584940A1 CA 2584940 CA2584940A CA2584940A1 CA 2584940 A1 CA2584940 A1 CA 2584940A1 CA 2584940 CA2584940 CA 2584940 CA 2584940 A CA2584940 A CA 2584940A CA 2584940 A1 CA2584940 A1 CA 2584940A1
- Authority
- CA
- Canada
- Prior art keywords
- subsequent request
- validation
- response
- validation rule
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/126—Applying verification of the received information the source of the received data
Abstract
A method of validating parameters of a request from a Web client to a Web application.
The validation rules are sent to a Web client, together with a response to a Web client.
The parameters in a response are updated by the Web client. The updated parameters are sent in a subsequent request to the Web client, along with the validation rules. The updated parameters are validated using the validation rules in the request, thus achieving stateless validation. The validation rules are preferably digitally signed.
The validation rules are sent to a Web client, together with a response to a Web client.
The parameters in a response are updated by the Web client. The updated parameters are sent in a subsequent request to the Web client, along with the validation rules. The updated parameters are validated using the validation rules in the request, thus achieving stateless validation. The validation rules are preferably digitally signed.
Description
I li I4Il .
Method and System for Stateless Validation FIELD OF INVENTION
[oool] The present invention relates to Web applications. More specifically, the present invention relates to Web application security.
BACKGROUND OF THE INVENTION
Method and System for Stateless Validation FIELD OF INVENTION
[oool] The present invention relates to Web applications. More specifically, the present invention relates to Web application security.
BACKGROUND OF THE INVENTION
[0002] The Internet is by far the largest, most extensive publicly available network of interconnected computer networks that transmit data by packet switching using a standardized Intemet Protocol (IP) and many other protocols. The Intemet has become an extremely popular source of virtually all kinds of information.
Increasingly sophisticated computers, software, and networking technology have made Intemet access relatively straightforward for end users. Applications such as electronic mail, online chat and web client allow the users to access and exchange information almost instantaneously.
Increasingly sophisticated computers, software, and networking technology have made Intemet access relatively straightforward for end users. Applications such as electronic mail, online chat and web client allow the users to access and exchange information almost instantaneously.
[0003] The World Wide Web (WWW) is one of the most popular means used for retrieving information over the Internet. The WWW can cope with many types of data which may be stored on computers, and is used with an Intemet connection and a Web client. The WWW is made up of millions of interconnected pages or documents which can be displayed on a computer or other interface. Each page may have connections to other pages which may be stored on any computer connected to the Internet.
Uniform Resource Identifiers (URI) is an identifying system in WWW, and typically consists of three parts: the transfer format (also known as the protocol type), the host iname of the machine which holds the file (may also be referred to as the web server iname) and the path name to the file. URIs are also referred as Universal Resource Locators (URLs). The transfer format for standard web pages is Hypertext Transfer IProtocol (HTTP). Hyper Text Markup Language (HTML) is a method of encoding the information so it can be displayed on a variety of devices.
100041 Web applications are engines that create Web pages from application logic, stored data, and user input. Web applications often preserve user state across sessions. Web applications do not require software to be installed in the client environment. Web applications make use of standard Web browser components to view server-side built pages. Web application can also deliver services through programmatic interface like Software Development Kits (SDKs).
Uniform Resource Identifiers (URI) is an identifying system in WWW, and typically consists of three parts: the transfer format (also known as the protocol type), the host iname of the machine which holds the file (may also be referred to as the web server iname) and the path name to the file. URIs are also referred as Universal Resource Locators (URLs). The transfer format for standard web pages is Hypertext Transfer IProtocol (HTTP). Hyper Text Markup Language (HTML) is a method of encoding the information so it can be displayed on a variety of devices.
100041 Web applications are engines that create Web pages from application logic, stored data, and user input. Web applications often preserve user state across sessions. Web applications do not require software to be installed in the client environment. Web applications make use of standard Web browser components to view server-side built pages. Web application can also deliver services through programmatic interface like Software Development Kits (SDKs).
[0005] HTTP is generally the underlying transactional protocol for transferring files (text, graphic images, sound, video, and other multimedia files) between web clients and servers. HTTP defines how messages are formatted and transmitted, and what actions web servers and web client browsers should take in response to various commands. A web browser as an HTTP client, typically initiates a request by establishing a TCP/IP connection to a particular port on a remote host. An HTTP server monitoring that port waits for the client to send a request string. Upon receiving the request string (and message, if any), the server may complete the protocol by sending back a response string, and a message of its own, in the form of the requested file, an error message, or any other information. The HTTP server can take the form of a Web server with gateway components to process requests. A gateway is a custom web server module or plug-in created to process requests, and generally is the first point of contact for a web application. The term "gateway' is intended to include any gateways known to a person skilled in the art, for example, CGI; ISAPI for the Microsoft Internet Ilnformation Services (IIS) web server; Apache web server module, or a Java servlet.
10006] Web pages regularly refer to pages on other servers, whose selection will elicit additional transfer requests. When the browser user enters file requests by either "opening" a Web file by typing in a Uniform Resource Locator (URL), or clicking on a hypertext link, the browser builds an HTTP request. In actual applications, Web clients may need to be distinguished and authenticated, or a session which holds a state across a plurality of HTTP protocols may need to be maintained by using "state" called cookie.
[00071 Web applications incur a security risk by accepting user input in their application logic. A common strategy for protecting Web applications against malicious data is for Web applications to verify the data they receive prior to processing it. The act of checking data entering a Web application for processing is called input validation.
Web application entry point, for example, a Web application firewall typically examine incoming request, apply generic security rules, and reject requests that fail to comply with these rules. Input validation includes accepting only data deemed acceptable to a Web application, or rejecting data that could be offensive to the Web application. So as to not reject legitimate data, the input validation process requires a great deal of knowledge about the Web application behavior. Failure in doing so may impair the Web application's functionality. Further, when an entry point is shared by multiple Web applications, the validation logic implementation is required to account for applications having different validation logics for data in the same context. Similar requirement exists for an application composed of multiple components.
11 1 Y 4.1 [ooos] A method and system to build rich and yet simple to define rules applied by a validation engine has been described in US Application 11/187,268, titled "Rich Web Application Input Validation" , the entirety of which is hereby incorporated by reference.
The capabilities of the rules allow tight validation of complex Web application data without the need for customized validation code. The syntax of the rules is adapted for human handling, either by using human readable rule definitions, or by manipulating a tool. The syntax of the rules helps to write, to verify correctness, to ensure completeness, and to facilitate updates of the rules.
looos] Validation rules may be numbered in thousands for a large business Web application. One approach to simplify the rule set of the large Web applications is the dynamic generation of rules. For example, a Web application constructing a page with integer parameters can specify that the values for these parameters should be of type integer. The disadvantage of this approach is that the size of the validation rules may Ibecome an issue for applications with memory constraints. In other words, in extreme case it is not practical for the entry point to have knowledge of all the validation rules.
Another limitation for the management of dynamically generated rules is the distributed nature of many applications. To handle large load of requests, entry points can be distributed onto several hosts. Maintaining the list of all validation rules on each entry point of a distributed system may not be optimal.
[oolo] It is therefore desirable to provide stateless validation rules.
Stateless is intended to indicate that the validation rules are sent to the client in a response then back to the server in a request, i.e. in a round trip instead of being stored server-side, for example at an entry point. The validation rule for data part of a request is also part of the request being validated. Impromptu components added to installed Web applications can also benefit from stateless validation. With a proper framework in place, the Web application can have an entry point validate their data without r-egistering their rules to the entry point.
[Oo11] US Application 20030037236 teaches a technology for automated input validation filters generation to allow a user extema[ to the Web application to easily define validation filters.
[0012] US Application 20030037236 does not teach the broadening of the validation capabilities of the input engine to perform validation based on the validation rules in the request. In addition, the relations used in defining assumptions on parameters follow the traditional input validation model as described by the list of validation types in the STRUTS framework. The inclusion of conjunctions and disjunctions is not sufficient to I I 1 M l create the validation rules. Capabilities to ease manual writing of rules are introduced as manual writing of rules is undesirable. US Application 20030037236 does not give t:he rule writers with intimate knowledge of the Web application who seek to achieve the rnost secure validation the capabilities to address complex Web applications validation i-equirements as encountered in Business Intelligence Web applications.
[0013] US Application 20040189708 teaches a system and method for validating entry of data into a structured data file in real-time. The system and method also described a real-time validation tool that enables a developer to create custom validation rules.
These custom validation rules can include preset validation rules. The system and method validates data as to be safely stored in hierarchical structures thus easing the user experience by not generating misleading errors. However, US Application 20040189708 does not introduce new validation capabilities to validate input data against malicious users trying to exploit security vulnerabilities, it only provides a list of preset validation rules matching a sub-set of the STRUTs framework list. These preset validation rules and the custom rules failed to address the validation requirements of complex Web Applications like business intelligence Web applications. More specifically, US Application 20040189708 does not validate input data against malicious users based on the validation rules embedded in the requests.
[0014] One of the benefits of embedding the validation rules in the response and the subsequent requests is the flexibility the Web applications have to validate a request.
An application firewall can be used to process the embedded rules but a component can choose to bypass the application firewall and invoke the validation itself. As long as the data is validated before being processed, security is not compromised.
Because data can go through transformations while being dispatched within an application, it rnay be easier to implement validation rules for data before being processed by a component of the application, because data ready to be processed is often in a simpler form.
[0015] Therefore, there is a need for a method and system that provide a stateless validation of the request. As the validation rules in a stateless validation are sent to an untrusted client, and used by the Web application upon return, the method and system need to ensure the authenticity, and the integrity of the validation rules.
The term untrusted client is intended to include a client who may submit malicious requests to exploit an application security vulnerability. The authenticity check will enforce that the received validation rules come from a trusted server. The integrity check will verify that the validation rules have not been modified by the untrusted client.
I I I Y, 4 ~
SUMMARY OF THE INVENTION
[0016] According to one aspect of the present invention there is provided a method of validating request data transmitted between an untrusted client and a server based on characteristics of a previous response comprising the steps of: building a response with a validation rule, the response having a characteristic indicative of a constraint to be applied to subsequent request data, the validation rule including the constraint;
receiving the response by the untrusted client; building the subsequent request, the subsequent request including the subsequent request data and the validation rule;
sending the subsequent request to the server; receiving the subsequent request at the server; and validating the subsequent request data using the validation rule.
I:oo17] According to another aspect of the present invention there is provided a system for validating request data transmitted between an untrusted client and a server based on characteristics of a previous response comprising: means for building a response 'Nith a validation rule, the response having a characteristic indicative of constraints to Ibe applied to subsequent request data, the validation rule including the constraints;
imeans for receiving the response by the untrusted client; means for building the subsequent request, the subsequent request including the subsequent request data and the validation rule; means for sending the subsequent request to the server;
irneans for receiving the subsequent request at the server; and means for validating the subsequent request data using the validation rule.
[:0018] According to another aspect of the present invention there is provided a storage rnedium readable by a computer encoding a computer program for execution by the computer to carry out a method for validating request data transmitted between an untrusted client and a server based on characteristics of a previous response comprising, the computer program comprising: code means for building a response with a validation rule, the response having a characteristic indicative of constraints to be applied to subsequent request data, the validation rule including the constraints;
code means for receiving the response by the untrusted client; code means for building the subsequent request, the subsequent request including the subsequent request data and the validation rule; code means for sending the subsequent request to the server; code means for receiving the subsequent request at the server; and code means for validating the subsequent request data using the validation rule.
[oo19] This summary of the invention does not necessarily describe all features of the invention.
4, BRIEF DESCRIPTION OF THE DRAWINGS
1[002o] The invention and the illustrated embodiments may be better understood, and the numerous objects, advantages, and features of the present invention and illustrated embodiments will become apparent to those skilled in the art by reference to 'the accompanying drawings. In the drawings, like reference numerals refer to like parts throughout the various views of the non-limiting and non-exhaustive embodiments of the present invention, and wherein:
[0021] FIGURE 1 shows a generic computing system in which the present invention may be implemented;
[0022] FIGURE 2 shows a generic overview of a Web application environment;
[0023] FIGURE 3 shows a Web application environment with validation rules for parameters in a request;
[0024] FIGURE 4 (A) shows an embodiment of the stateless validation;
[0025] FIGURE 4 (B) shows another embodiment of the stateless validation;
[0026] FIGURE 5 shows the steps of the stateless validation;
[0027] FIGURE 6 (a) - (e) illustrate examples of validation rules;
[0028] FIGURE 7 (A) shows components of a Web applications with different signed validation rule;
[0029] FIGURE 7 (B) illustrates the signing of validation rules in accordance with another embodiment of the present invention;
[003o] FIGURE 8 shows steps of a method for hierarchical signing measures; and [0031] FIGURE 9 shows examples of hierarchical signing measures.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
[0032] Reference will now be made in detail to some specific embodiments of the iinvention including the best modes contemplated by the inventors for carrying out the iinvention. Examples of these specific embodiments are illustrated in the accompanying c[rawings. While the invention is described in conjunction with these specific embodiments, it will be understood that it is not intended to limit the invention to the 1=I I 1 YIl n described embodiments. On the contrary, it is intended to cover altematives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. The present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.
[0033] In this specification and the appended claims, the singular forms "a,"
"an," and "the" include plural reference unless the context clearly dictates otherwise.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood to one of ordinary skill in the art to which this invention belongs.
[oo34] Figure 1 and the following discussion are intended to provide a brief general description. Figure 1 illustrates a block diagram of a suitable computing environment in which a preferred embodiment of the present invention may be implemented.
[0035] Those skilled in the art will appreciate that the invention may be practiced with many computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
[0036] Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a personal computer. Generally, program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types.
[0037] With reference to Figure 1 an exemplary system 100 for implementing the invention may be, for example, one of the general purpose computers. The system 100 includes processor 102, which in the exemplary embodiment are each connected to cache memory 104, the cache 104 is connected in tum to a system bus 106 that couples various system components.
O8905sU0CA 7 1.11 1 Y.I{=I
t00381 Also connected to system bus 1006 are a system memory 108 and a host bridge 110. Host bridge 110 connects I/O bus 112 to system bus 106, relaying and/or transforming data transactions from one bus to the other. The system bus 106 and the I/O bus 112 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read-only memory (ROM) 114 and random access memory (RAM) 116. A basic input/output system 118 (BIOS), containing the basic routines that help to transfer information between elements within the personal computer 100, such as during start-up, is stored in ROM 114.
[0039] In the exemplary embodiment, the system 100 may further include a graphics adapter 120 connected to I/O bus 112, receiving user interface information for display device 122. A user may enter commands and information into the system 100 through input devices 130 such as a conventional mouse, a key board 130, or the like.
Other input devices 134 may include a microphone, joystick, game pad, satellite dish, scanner or the like. The devices may be connected via an Industry Standard Architecture (ISA) bridge 126, or a Universal Serial Bus (USB) bridge 132 to I/O bus 112, respectively. PCI device such as a modem 138 may be connected to the I/O
bus 112 via PCI bridge 136.
[004o] The exemplary system 100 may further include a hard disk drive 124 for reading from and writing to a hard disk, connected to the I/O bus via a hard disk interface 140, and an optical disk drive 142 for reading from or writing to a removable optical disk 144 such as a CD-ROM or other optical media. The hard disk drive 124, magnetic disk drive ;28, and optical disk drive 142 may be connected to the I/O bus 112 by a hard disk drive interface 140, and an optical drive interface 146, respectively. The drives and their associated computer-readable media provide non-volatile storage of computer readable instructions, data structures, program modules and other data for the system '100. Although the exemplary environment described herein employs a hard disk and a removable optical disk 144, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read-only memories (ROMs) and the like may also be used in the exemplary operating environment.
Io041] A number of program modules may be stored on the hard disk 124, optical disk '144, ROM 118 or RAM 116, including an operating system 148, one or more application programs 150, other program modules 152 and program data 154.
I I I I Y .4 [0042] The exemplary system 100 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 156.
The remote computer 156 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relat[ve to the exemplary system 100.
The logical connections depicted in Figure 1 include a network 158, for example, a local area network (LAN) or a wide area network (WAN). Such networking environments are commonplace in offices, enterprise-wide computer networks, Intranets and the Internet.
[0043] When used in a networking environment, the exemplary system 100 is connected to the local network 158 through a network interface or adapter 160.
The exemplary system 100 may use the modem 138 or other means for establishing communications 162 over a wide area network such as the Internet. In a networked environment, program modules depicted relative to the exemplary system 100, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
[0044] The exemplary embodiment shown in Figure 1 is provided solely for the purposes of explaining the invention and those skilled in the art will recognize that numerous variations are possible, both in form and function. For instance, the exemplary system 100 may also include a magnetic disc drive, and numerous other optional components. All such variations are believed to be within the spirit and scope of the present invention. The exemplary system 100 and the exemplary figures below are provided solely as examples for the purposes of explanation and are not intended to imply architectural limitations. In fact, this method and system can be easily adapted for use on any programmable computer system, or network of systems, on which software applications can be executed.
[0045] Figure 2 provides an overview of a network 210 with a Web application 218 and a Web client 240, for example but not limited to a Web browser, on a computer over a public network 214 such as Intemet. Optionally, there may be an entry point 216, for example, a validation engine, or an application firewall, separating the Web application 218 and the public network 214. A request 220 is generally intended to include a data flow from a Web client 240, for example but not limited to a Web browser, to a Web application 218. A response 222 is generally intended to include a data flow from a Web application 218 to a Web client 240, for example but not limited to a Web browser. One example of the Web applications 218 may be a business reporting engine.
10046] Figure 3 is a detailed view of a Web application 218. The Web application 218 may have one or more Web application components 302, 304 and 306. The optional entry point 216 may have a dispatcher 308 which may inspect an incoming request 222 and dispatch to a proper application component for example, component C, 302, component C2 306 via component C3 304. Component C3 304 may have a dispatcher -functionality 309 for dispatching the request to component C2 306.
io0471 The following brief description of the validation rules is included to promote a Ibetter understanding of the principles of the present invention. Briefly, Figure 3 shows an example of a request 220 which has the parameters 310: A as a string ("hello"), B
as an integer ("25") and C ("red") as a color. A validation rule 312 resides in the entry point 216 validates the parameters in the request before passing the request 220 to the 'JVeb application 218, for example, Val A is the validation rule for parameter A, Val_B
is the validation rule for parameter B, and Val_C is the validation rule for parameter C, i-espectively.
loo481 Referring to Figure 4(A), according to one embodiment of the present invention, the stateless validation of the requests can be advantageously implemented by embedding the validation rules 404 into the response 402. The validation rules 404 rnatch the parameter types 405 found in the response data such as <string>, <integer>
or <color>. The subsequent request 406 from an untrusted client 212 will comprise both parameter with values 408 and the validation rules 404. The validation rules define the constraints of the parameter values, for example, "string smaller than 256 characters", "a numberfrom 0 to 32", or "one of the color red, green, or blue". The web application 218 on the server does not maintain a state regarding the validation, hence the validation of the rules is stateless with regard to the Web application 218. As the validation of the request 406 will be based on the embedded validation rules 404, either the individual web application components or a centralized entity, for example a single entry point can therefore validate the parameters. When the validation rules are used in a distributed manner, one of a plurality of web appficafion components or, one of a plurality of entry points may perform the validation.
[0049] Referring to Figure 4(B), the validation rules may apply to more than the parameters part of a response. The response with a validation rule sent from a server to a client may have a characteristic indicative of constraints to be applied to a i I Y .14 .
subsequent request. The response 420 from the application 218 to the untrusted client 422 has the parameters Cars and Trucks. The term "untrusted client" is intended to include, but not limited to potentially malicious client. The validation rule in the response is to validate the number vehicles owned. The untrusted client 422 may be a rich client and has a prompting logic 424 interpreting the characteristics of the parameters. The ownership value is obtained from the user based on prompting client logic 424. The untrusted client 422 sends the ownership parameter and value back to the server in a request 426 where it will be validated according to rule 427.
[0050] Other characteristics in a request may include, but not limited to, an organization or a structure of the parameters. Once the response is received by an iuntrusted client, the client builds a subsequent request including the subsequent request data and the validation rule sent by the server. Therefore, the characteristic iindicative of the constraints is a response primitive affecting the subsequent request data.
[0051] The untrusted client then sends the subsequent request to the server.
The server validates the subsequent request data using the validation rule.
[0052] Because the user is not trusted it will be necessary in most circumstances to E:nsure the authenticity, and integrity of the validation rules. Digital signature is a cryptographically based signature assurance scheme which provides these functionalities.
[0053] Keyed-hash message authentication code (HMAC), is a hash based message authentication code (MAC) algorithm. The HMAC algorithm defines how a hash f'unction and a key should be used to secure the authenticity and integrity of a message. To digitally signed the rules, HMAC is preferred over other cryptographic rnethods due to performance reasons. HMAC can be proven secure provided the underfying hash function has reasonable cryptographic strength. Any hash function can be used to compute HMAC, for example but not limited to, MD5, or SHA1.
[0054] Digitally signed messages may still be visible to a client, for example, the hash value of HMAC may be appended to the original message. Therefore, the original message is still visible, and in case of the validation rules, still usable.
This visibility of the digital signed validation rules may be used by the client to ensure the correctness of the request prior to sending it to the server. The client may further instruct the user to provide correct input in the event that the correctness check results in a failure.
= 1 I I 1 Y rll=r 10055i Referring to Figure 5, in accordance with one embodiment of the present invention a method for providing stateless validation using digital signature is provided.
The Web application provides response with parameters to the client 502. The response also includes validation rules for the future values of the parameters 504. The validation rules are digital signed to ensure the integrity and authenticity of the validation rules 506. The digital signature may be performed, for example, using HMAC. The response with the embedded validation rules is received by the client 508.
'When the parameter with its name and value, and the embedded validation rules are retumed in the subsequent request 510, and received at the Web server 512, the values in the request can be validated independently 514. The entry point, for example an application firewall, or a recipient Web application component can perform the validation.
10056] In its simplest form as illustrated in Figure 6(a), the validation rule can be considered to include two basic elements, the data context 602 and the constraint 604.
'The data context indicates which parameter will have its value verified. For example, VAL_A specifies validation for the parameter A. The constraint can be signed in a form S(Constraint A). "S( )" denotes that the elements inside the bracket are digital signed.
The constraint 604 may be, for example, that the parameter A value is a string of less t:han 256 characters. Therefore the signed validation rule for parameter A may be presented as in Figure 6(b). However, simply signing the constraint allows a potential attacker to interchange signed constraints S(string < 256) between parameter contexts without tampering with the signed constraints. For example, the signed constraint for VAL A could be substitute with a S(boolean) constraint defined for an other parameter I believe we are ok here, no illustration needed).
[13057] This disadvantage may be overcome by signing the combination of parameter context and constraint as illustrated in Figures 6(c) and 6(d). Here the whole validation rule is signed; therefore an attacker is unable to exchange part of the rules as in the case of Figures 6 (a) and (b). The signing limits the usage context of a constraint to the specific parameter for which it is signed with. However, this may still be prone to other kinds of attacks as will be described below in Figure 7(a).
[00581 Figure 7(A) shows two components 702, 704, of a Web application, each has a respective signed validation rule 706, 708, which is sent to and received from the client 240. 706 has the signed validation rules S(Val A= string < 256) and S(Val_B =
C) to 32), applicable for the request designated to Component A 702. 708 has the signed validation rules S(Val_A = string < 256) and S(Val_B = string < 256), applicable I Ii I Iki iPor the request designated to component B 704. A malicious user could swap the signed validation rule 708 for signed validation rule 706, and insert a string into the numerical value for component A, bypassing the validation rule VaI_B = 0 to 32, and thus launch an attack.
loossl This kind of attack can be prevented either by having a different signing key in each component or by factoring in a target ID for the destined application, as shown below in Figures 8 and 9. In practice, managing multiple signing keys within an application may not be practical. Having to manage different keys for each component of an application would be burdensome to implement. On the other hand, web applications commonly have component identifiers which can be used as target lDs.
[oo6o] Therefore, referring to Figure 6 (e) and Figure 7 (B), adding a target ID 710 to the rule is one of the preferred solutions. The target ID is a unique value associated with each component 702 704 of an application 218. The rule signature process includes the component target ID to restrict usage of the signed rule to the specific component. The component 702, 704, or the entry point 410, verifying the data and the rule signatures must ensure that the validated data is only dispatched to a component with a matching target ID.
loosi] Similarly, referring to Figure 6 (f) and Figure 7 (B), other IDs may be included in the signed validation rules to prevent other attack types. For example, a user session ID may be included in the signed validation rules 712 to identify the user session in an application where a response is originated, thus preventing the use of signed validation r=ules from another user session. A signed rule for user A cannot be used for user B
because they have different session ID.
100621 In accordance with another embodiment of the present invention there is provided a hierarchical signing measures in the communication of validation rules between a Web client and a Web application. These hierarchical signing measures include the signing of the primitive of the validation rules; signing of the entire validation rule; singing of a group of validation rules for the parameters in the request; the inclusion of a group of validation rules with a target ID for signing and signing of a group of validation rules with a second ID, for example, a session ID. Figures 8 and 9 illustrate the hierarchical signing measures, wherein Figure 8 shows an exemplary embodiment of the different hierarchical signing measures with general increasing security; and Figure 9 shows examples of corresponding validation rules.
[00631 Refen-ing to Figures 8 and 9, a validation rules may have only its constraint signed 802, 902. By way of example only, this signing may be in the form of "S(String < 256) part of the validation rule. This signing may provide sufficient authenticity and integrity.
[oosal Next level of signing 804, 904 is to sign a single, entire validation rule, for example, S(Val A= String < 256) is signed entirely. This signing will prevent a swapping of the signed constraints between the parameters. This level will be sufficient for many applications.
[0065) As depicted by 806 and 906, another stage of signing can be implemented whereby a group of validation rules for the parameters of a request are signed together.
Signing groups of rules allows for different validation rules for parameters with the same name as long as they are in a different group.
ioossi To prevent group substitution, the component receiving parameters must ensure that the rule group has one rule for every parameter it consumes in a given usage context, and only one rule. For example, if a group of three rules Z, X, and Y
require Y to be a string, a different group X and Y could require Y to be an integer.
When a component consumes X, and Y, it will ensure there are only rules for X, Y in the group and validate Y as an integer. Trying to use the group Z, X, Y for the same component consumption will fail because the Z rule would not be used.
19067] Steps 808 and 908 represent yet another stage of signing whereby validation rules are signed together with a second ID, for example a session ID.
100681 Steps 810 and 910 represent another stage of signing whereby validation rules are signed together with a target ID.
[0069] The target ID and a second ID, for example, the session ID may further be signed together with the validation rules as illustrated in 812 and 912.
[007o] As will be readily understood by a person skilled in the art, terms "signing"
"'signed" and "signature" in the above and accompanying figures are intended to include both symmetric and asymmetric algorithm, for example but not limited to cryptographic hash functions, HMACs, or private public key signatures.
[0071] The invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof. Apparatus of the invention can be implemented in a computer program product tangibly embodied in a 1 I I I 1 Y.111 machine-readable storage device for execution by a programmable processor; and method actions can be performed by a programmable processor executing a program of instructions to perform functions of the invention by operating on input data and generating output. The invention can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each computer program can be implemented in a high-level procedural or object oriented programming language, or in assembly or machine language if desired; and in any case, the language can be a compiled or interpreted Ilanguage. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory. Generally, a computer will include one or more mass storage devices for storing data files. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM
disks. Any of the foregoing can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).
[0072] The present invention has been described with regard to one or more embodiments. However, it will be apparent to persons skilled in the art that a number of variations and modifications can be made without departing from the scope of the invention as defined in the claims.
10006] Web pages regularly refer to pages on other servers, whose selection will elicit additional transfer requests. When the browser user enters file requests by either "opening" a Web file by typing in a Uniform Resource Locator (URL), or clicking on a hypertext link, the browser builds an HTTP request. In actual applications, Web clients may need to be distinguished and authenticated, or a session which holds a state across a plurality of HTTP protocols may need to be maintained by using "state" called cookie.
[00071 Web applications incur a security risk by accepting user input in their application logic. A common strategy for protecting Web applications against malicious data is for Web applications to verify the data they receive prior to processing it. The act of checking data entering a Web application for processing is called input validation.
Web application entry point, for example, a Web application firewall typically examine incoming request, apply generic security rules, and reject requests that fail to comply with these rules. Input validation includes accepting only data deemed acceptable to a Web application, or rejecting data that could be offensive to the Web application. So as to not reject legitimate data, the input validation process requires a great deal of knowledge about the Web application behavior. Failure in doing so may impair the Web application's functionality. Further, when an entry point is shared by multiple Web applications, the validation logic implementation is required to account for applications having different validation logics for data in the same context. Similar requirement exists for an application composed of multiple components.
11 1 Y 4.1 [ooos] A method and system to build rich and yet simple to define rules applied by a validation engine has been described in US Application 11/187,268, titled "Rich Web Application Input Validation" , the entirety of which is hereby incorporated by reference.
The capabilities of the rules allow tight validation of complex Web application data without the need for customized validation code. The syntax of the rules is adapted for human handling, either by using human readable rule definitions, or by manipulating a tool. The syntax of the rules helps to write, to verify correctness, to ensure completeness, and to facilitate updates of the rules.
looos] Validation rules may be numbered in thousands for a large business Web application. One approach to simplify the rule set of the large Web applications is the dynamic generation of rules. For example, a Web application constructing a page with integer parameters can specify that the values for these parameters should be of type integer. The disadvantage of this approach is that the size of the validation rules may Ibecome an issue for applications with memory constraints. In other words, in extreme case it is not practical for the entry point to have knowledge of all the validation rules.
Another limitation for the management of dynamically generated rules is the distributed nature of many applications. To handle large load of requests, entry points can be distributed onto several hosts. Maintaining the list of all validation rules on each entry point of a distributed system may not be optimal.
[oolo] It is therefore desirable to provide stateless validation rules.
Stateless is intended to indicate that the validation rules are sent to the client in a response then back to the server in a request, i.e. in a round trip instead of being stored server-side, for example at an entry point. The validation rule for data part of a request is also part of the request being validated. Impromptu components added to installed Web applications can also benefit from stateless validation. With a proper framework in place, the Web application can have an entry point validate their data without r-egistering their rules to the entry point.
[Oo11] US Application 20030037236 teaches a technology for automated input validation filters generation to allow a user extema[ to the Web application to easily define validation filters.
[0012] US Application 20030037236 does not teach the broadening of the validation capabilities of the input engine to perform validation based on the validation rules in the request. In addition, the relations used in defining assumptions on parameters follow the traditional input validation model as described by the list of validation types in the STRUTS framework. The inclusion of conjunctions and disjunctions is not sufficient to I I 1 M l create the validation rules. Capabilities to ease manual writing of rules are introduced as manual writing of rules is undesirable. US Application 20030037236 does not give t:he rule writers with intimate knowledge of the Web application who seek to achieve the rnost secure validation the capabilities to address complex Web applications validation i-equirements as encountered in Business Intelligence Web applications.
[0013] US Application 20040189708 teaches a system and method for validating entry of data into a structured data file in real-time. The system and method also described a real-time validation tool that enables a developer to create custom validation rules.
These custom validation rules can include preset validation rules. The system and method validates data as to be safely stored in hierarchical structures thus easing the user experience by not generating misleading errors. However, US Application 20040189708 does not introduce new validation capabilities to validate input data against malicious users trying to exploit security vulnerabilities, it only provides a list of preset validation rules matching a sub-set of the STRUTs framework list. These preset validation rules and the custom rules failed to address the validation requirements of complex Web Applications like business intelligence Web applications. More specifically, US Application 20040189708 does not validate input data against malicious users based on the validation rules embedded in the requests.
[0014] One of the benefits of embedding the validation rules in the response and the subsequent requests is the flexibility the Web applications have to validate a request.
An application firewall can be used to process the embedded rules but a component can choose to bypass the application firewall and invoke the validation itself. As long as the data is validated before being processed, security is not compromised.
Because data can go through transformations while being dispatched within an application, it rnay be easier to implement validation rules for data before being processed by a component of the application, because data ready to be processed is often in a simpler form.
[0015] Therefore, there is a need for a method and system that provide a stateless validation of the request. As the validation rules in a stateless validation are sent to an untrusted client, and used by the Web application upon return, the method and system need to ensure the authenticity, and the integrity of the validation rules.
The term untrusted client is intended to include a client who may submit malicious requests to exploit an application security vulnerability. The authenticity check will enforce that the received validation rules come from a trusted server. The integrity check will verify that the validation rules have not been modified by the untrusted client.
I I I Y, 4 ~
SUMMARY OF THE INVENTION
[0016] According to one aspect of the present invention there is provided a method of validating request data transmitted between an untrusted client and a server based on characteristics of a previous response comprising the steps of: building a response with a validation rule, the response having a characteristic indicative of a constraint to be applied to subsequent request data, the validation rule including the constraint;
receiving the response by the untrusted client; building the subsequent request, the subsequent request including the subsequent request data and the validation rule;
sending the subsequent request to the server; receiving the subsequent request at the server; and validating the subsequent request data using the validation rule.
I:oo17] According to another aspect of the present invention there is provided a system for validating request data transmitted between an untrusted client and a server based on characteristics of a previous response comprising: means for building a response 'Nith a validation rule, the response having a characteristic indicative of constraints to Ibe applied to subsequent request data, the validation rule including the constraints;
imeans for receiving the response by the untrusted client; means for building the subsequent request, the subsequent request including the subsequent request data and the validation rule; means for sending the subsequent request to the server;
irneans for receiving the subsequent request at the server; and means for validating the subsequent request data using the validation rule.
[:0018] According to another aspect of the present invention there is provided a storage rnedium readable by a computer encoding a computer program for execution by the computer to carry out a method for validating request data transmitted between an untrusted client and a server based on characteristics of a previous response comprising, the computer program comprising: code means for building a response with a validation rule, the response having a characteristic indicative of constraints to be applied to subsequent request data, the validation rule including the constraints;
code means for receiving the response by the untrusted client; code means for building the subsequent request, the subsequent request including the subsequent request data and the validation rule; code means for sending the subsequent request to the server; code means for receiving the subsequent request at the server; and code means for validating the subsequent request data using the validation rule.
[oo19] This summary of the invention does not necessarily describe all features of the invention.
4, BRIEF DESCRIPTION OF THE DRAWINGS
1[002o] The invention and the illustrated embodiments may be better understood, and the numerous objects, advantages, and features of the present invention and illustrated embodiments will become apparent to those skilled in the art by reference to 'the accompanying drawings. In the drawings, like reference numerals refer to like parts throughout the various views of the non-limiting and non-exhaustive embodiments of the present invention, and wherein:
[0021] FIGURE 1 shows a generic computing system in which the present invention may be implemented;
[0022] FIGURE 2 shows a generic overview of a Web application environment;
[0023] FIGURE 3 shows a Web application environment with validation rules for parameters in a request;
[0024] FIGURE 4 (A) shows an embodiment of the stateless validation;
[0025] FIGURE 4 (B) shows another embodiment of the stateless validation;
[0026] FIGURE 5 shows the steps of the stateless validation;
[0027] FIGURE 6 (a) - (e) illustrate examples of validation rules;
[0028] FIGURE 7 (A) shows components of a Web applications with different signed validation rule;
[0029] FIGURE 7 (B) illustrates the signing of validation rules in accordance with another embodiment of the present invention;
[003o] FIGURE 8 shows steps of a method for hierarchical signing measures; and [0031] FIGURE 9 shows examples of hierarchical signing measures.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
[0032] Reference will now be made in detail to some specific embodiments of the iinvention including the best modes contemplated by the inventors for carrying out the iinvention. Examples of these specific embodiments are illustrated in the accompanying c[rawings. While the invention is described in conjunction with these specific embodiments, it will be understood that it is not intended to limit the invention to the 1=I I 1 YIl n described embodiments. On the contrary, it is intended to cover altematives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. The present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.
[0033] In this specification and the appended claims, the singular forms "a,"
"an," and "the" include plural reference unless the context clearly dictates otherwise.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood to one of ordinary skill in the art to which this invention belongs.
[oo34] Figure 1 and the following discussion are intended to provide a brief general description. Figure 1 illustrates a block diagram of a suitable computing environment in which a preferred embodiment of the present invention may be implemented.
[0035] Those skilled in the art will appreciate that the invention may be practiced with many computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
[0036] Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a personal computer. Generally, program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types.
[0037] With reference to Figure 1 an exemplary system 100 for implementing the invention may be, for example, one of the general purpose computers. The system 100 includes processor 102, which in the exemplary embodiment are each connected to cache memory 104, the cache 104 is connected in tum to a system bus 106 that couples various system components.
O8905sU0CA 7 1.11 1 Y.I{=I
t00381 Also connected to system bus 1006 are a system memory 108 and a host bridge 110. Host bridge 110 connects I/O bus 112 to system bus 106, relaying and/or transforming data transactions from one bus to the other. The system bus 106 and the I/O bus 112 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read-only memory (ROM) 114 and random access memory (RAM) 116. A basic input/output system 118 (BIOS), containing the basic routines that help to transfer information between elements within the personal computer 100, such as during start-up, is stored in ROM 114.
[0039] In the exemplary embodiment, the system 100 may further include a graphics adapter 120 connected to I/O bus 112, receiving user interface information for display device 122. A user may enter commands and information into the system 100 through input devices 130 such as a conventional mouse, a key board 130, or the like.
Other input devices 134 may include a microphone, joystick, game pad, satellite dish, scanner or the like. The devices may be connected via an Industry Standard Architecture (ISA) bridge 126, or a Universal Serial Bus (USB) bridge 132 to I/O bus 112, respectively. PCI device such as a modem 138 may be connected to the I/O
bus 112 via PCI bridge 136.
[004o] The exemplary system 100 may further include a hard disk drive 124 for reading from and writing to a hard disk, connected to the I/O bus via a hard disk interface 140, and an optical disk drive 142 for reading from or writing to a removable optical disk 144 such as a CD-ROM or other optical media. The hard disk drive 124, magnetic disk drive ;28, and optical disk drive 142 may be connected to the I/O bus 112 by a hard disk drive interface 140, and an optical drive interface 146, respectively. The drives and their associated computer-readable media provide non-volatile storage of computer readable instructions, data structures, program modules and other data for the system '100. Although the exemplary environment described herein employs a hard disk and a removable optical disk 144, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read-only memories (ROMs) and the like may also be used in the exemplary operating environment.
Io041] A number of program modules may be stored on the hard disk 124, optical disk '144, ROM 118 or RAM 116, including an operating system 148, one or more application programs 150, other program modules 152 and program data 154.
I I I I Y .4 [0042] The exemplary system 100 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 156.
The remote computer 156 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relat[ve to the exemplary system 100.
The logical connections depicted in Figure 1 include a network 158, for example, a local area network (LAN) or a wide area network (WAN). Such networking environments are commonplace in offices, enterprise-wide computer networks, Intranets and the Internet.
[0043] When used in a networking environment, the exemplary system 100 is connected to the local network 158 through a network interface or adapter 160.
The exemplary system 100 may use the modem 138 or other means for establishing communications 162 over a wide area network such as the Internet. In a networked environment, program modules depicted relative to the exemplary system 100, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
[0044] The exemplary embodiment shown in Figure 1 is provided solely for the purposes of explaining the invention and those skilled in the art will recognize that numerous variations are possible, both in form and function. For instance, the exemplary system 100 may also include a magnetic disc drive, and numerous other optional components. All such variations are believed to be within the spirit and scope of the present invention. The exemplary system 100 and the exemplary figures below are provided solely as examples for the purposes of explanation and are not intended to imply architectural limitations. In fact, this method and system can be easily adapted for use on any programmable computer system, or network of systems, on which software applications can be executed.
[0045] Figure 2 provides an overview of a network 210 with a Web application 218 and a Web client 240, for example but not limited to a Web browser, on a computer over a public network 214 such as Intemet. Optionally, there may be an entry point 216, for example, a validation engine, or an application firewall, separating the Web application 218 and the public network 214. A request 220 is generally intended to include a data flow from a Web client 240, for example but not limited to a Web browser, to a Web application 218. A response 222 is generally intended to include a data flow from a Web application 218 to a Web client 240, for example but not limited to a Web browser. One example of the Web applications 218 may be a business reporting engine.
10046] Figure 3 is a detailed view of a Web application 218. The Web application 218 may have one or more Web application components 302, 304 and 306. The optional entry point 216 may have a dispatcher 308 which may inspect an incoming request 222 and dispatch to a proper application component for example, component C, 302, component C2 306 via component C3 304. Component C3 304 may have a dispatcher -functionality 309 for dispatching the request to component C2 306.
io0471 The following brief description of the validation rules is included to promote a Ibetter understanding of the principles of the present invention. Briefly, Figure 3 shows an example of a request 220 which has the parameters 310: A as a string ("hello"), B
as an integer ("25") and C ("red") as a color. A validation rule 312 resides in the entry point 216 validates the parameters in the request before passing the request 220 to the 'JVeb application 218, for example, Val A is the validation rule for parameter A, Val_B
is the validation rule for parameter B, and Val_C is the validation rule for parameter C, i-espectively.
loo481 Referring to Figure 4(A), according to one embodiment of the present invention, the stateless validation of the requests can be advantageously implemented by embedding the validation rules 404 into the response 402. The validation rules 404 rnatch the parameter types 405 found in the response data such as <string>, <integer>
or <color>. The subsequent request 406 from an untrusted client 212 will comprise both parameter with values 408 and the validation rules 404. The validation rules define the constraints of the parameter values, for example, "string smaller than 256 characters", "a numberfrom 0 to 32", or "one of the color red, green, or blue". The web application 218 on the server does not maintain a state regarding the validation, hence the validation of the rules is stateless with regard to the Web application 218. As the validation of the request 406 will be based on the embedded validation rules 404, either the individual web application components or a centralized entity, for example a single entry point can therefore validate the parameters. When the validation rules are used in a distributed manner, one of a plurality of web appficafion components or, one of a plurality of entry points may perform the validation.
[0049] Referring to Figure 4(B), the validation rules may apply to more than the parameters part of a response. The response with a validation rule sent from a server to a client may have a characteristic indicative of constraints to be applied to a i I Y .14 .
subsequent request. The response 420 from the application 218 to the untrusted client 422 has the parameters Cars and Trucks. The term "untrusted client" is intended to include, but not limited to potentially malicious client. The validation rule in the response is to validate the number vehicles owned. The untrusted client 422 may be a rich client and has a prompting logic 424 interpreting the characteristics of the parameters. The ownership value is obtained from the user based on prompting client logic 424. The untrusted client 422 sends the ownership parameter and value back to the server in a request 426 where it will be validated according to rule 427.
[0050] Other characteristics in a request may include, but not limited to, an organization or a structure of the parameters. Once the response is received by an iuntrusted client, the client builds a subsequent request including the subsequent request data and the validation rule sent by the server. Therefore, the characteristic iindicative of the constraints is a response primitive affecting the subsequent request data.
[0051] The untrusted client then sends the subsequent request to the server.
The server validates the subsequent request data using the validation rule.
[0052] Because the user is not trusted it will be necessary in most circumstances to E:nsure the authenticity, and integrity of the validation rules. Digital signature is a cryptographically based signature assurance scheme which provides these functionalities.
[0053] Keyed-hash message authentication code (HMAC), is a hash based message authentication code (MAC) algorithm. The HMAC algorithm defines how a hash f'unction and a key should be used to secure the authenticity and integrity of a message. To digitally signed the rules, HMAC is preferred over other cryptographic rnethods due to performance reasons. HMAC can be proven secure provided the underfying hash function has reasonable cryptographic strength. Any hash function can be used to compute HMAC, for example but not limited to, MD5, or SHA1.
[0054] Digitally signed messages may still be visible to a client, for example, the hash value of HMAC may be appended to the original message. Therefore, the original message is still visible, and in case of the validation rules, still usable.
This visibility of the digital signed validation rules may be used by the client to ensure the correctness of the request prior to sending it to the server. The client may further instruct the user to provide correct input in the event that the correctness check results in a failure.
= 1 I I 1 Y rll=r 10055i Referring to Figure 5, in accordance with one embodiment of the present invention a method for providing stateless validation using digital signature is provided.
The Web application provides response with parameters to the client 502. The response also includes validation rules for the future values of the parameters 504. The validation rules are digital signed to ensure the integrity and authenticity of the validation rules 506. The digital signature may be performed, for example, using HMAC. The response with the embedded validation rules is received by the client 508.
'When the parameter with its name and value, and the embedded validation rules are retumed in the subsequent request 510, and received at the Web server 512, the values in the request can be validated independently 514. The entry point, for example an application firewall, or a recipient Web application component can perform the validation.
10056] In its simplest form as illustrated in Figure 6(a), the validation rule can be considered to include two basic elements, the data context 602 and the constraint 604.
'The data context indicates which parameter will have its value verified. For example, VAL_A specifies validation for the parameter A. The constraint can be signed in a form S(Constraint A). "S( )" denotes that the elements inside the bracket are digital signed.
The constraint 604 may be, for example, that the parameter A value is a string of less t:han 256 characters. Therefore the signed validation rule for parameter A may be presented as in Figure 6(b). However, simply signing the constraint allows a potential attacker to interchange signed constraints S(string < 256) between parameter contexts without tampering with the signed constraints. For example, the signed constraint for VAL A could be substitute with a S(boolean) constraint defined for an other parameter I believe we are ok here, no illustration needed).
[13057] This disadvantage may be overcome by signing the combination of parameter context and constraint as illustrated in Figures 6(c) and 6(d). Here the whole validation rule is signed; therefore an attacker is unable to exchange part of the rules as in the case of Figures 6 (a) and (b). The signing limits the usage context of a constraint to the specific parameter for which it is signed with. However, this may still be prone to other kinds of attacks as will be described below in Figure 7(a).
[00581 Figure 7(A) shows two components 702, 704, of a Web application, each has a respective signed validation rule 706, 708, which is sent to and received from the client 240. 706 has the signed validation rules S(Val A= string < 256) and S(Val_B =
C) to 32), applicable for the request designated to Component A 702. 708 has the signed validation rules S(Val_A = string < 256) and S(Val_B = string < 256), applicable I Ii I Iki iPor the request designated to component B 704. A malicious user could swap the signed validation rule 708 for signed validation rule 706, and insert a string into the numerical value for component A, bypassing the validation rule VaI_B = 0 to 32, and thus launch an attack.
loossl This kind of attack can be prevented either by having a different signing key in each component or by factoring in a target ID for the destined application, as shown below in Figures 8 and 9. In practice, managing multiple signing keys within an application may not be practical. Having to manage different keys for each component of an application would be burdensome to implement. On the other hand, web applications commonly have component identifiers which can be used as target lDs.
[oo6o] Therefore, referring to Figure 6 (e) and Figure 7 (B), adding a target ID 710 to the rule is one of the preferred solutions. The target ID is a unique value associated with each component 702 704 of an application 218. The rule signature process includes the component target ID to restrict usage of the signed rule to the specific component. The component 702, 704, or the entry point 410, verifying the data and the rule signatures must ensure that the validated data is only dispatched to a component with a matching target ID.
loosi] Similarly, referring to Figure 6 (f) and Figure 7 (B), other IDs may be included in the signed validation rules to prevent other attack types. For example, a user session ID may be included in the signed validation rules 712 to identify the user session in an application where a response is originated, thus preventing the use of signed validation r=ules from another user session. A signed rule for user A cannot be used for user B
because they have different session ID.
100621 In accordance with another embodiment of the present invention there is provided a hierarchical signing measures in the communication of validation rules between a Web client and a Web application. These hierarchical signing measures include the signing of the primitive of the validation rules; signing of the entire validation rule; singing of a group of validation rules for the parameters in the request; the inclusion of a group of validation rules with a target ID for signing and signing of a group of validation rules with a second ID, for example, a session ID. Figures 8 and 9 illustrate the hierarchical signing measures, wherein Figure 8 shows an exemplary embodiment of the different hierarchical signing measures with general increasing security; and Figure 9 shows examples of corresponding validation rules.
[00631 Refen-ing to Figures 8 and 9, a validation rules may have only its constraint signed 802, 902. By way of example only, this signing may be in the form of "S(String < 256) part of the validation rule. This signing may provide sufficient authenticity and integrity.
[oosal Next level of signing 804, 904 is to sign a single, entire validation rule, for example, S(Val A= String < 256) is signed entirely. This signing will prevent a swapping of the signed constraints between the parameters. This level will be sufficient for many applications.
[0065) As depicted by 806 and 906, another stage of signing can be implemented whereby a group of validation rules for the parameters of a request are signed together.
Signing groups of rules allows for different validation rules for parameters with the same name as long as they are in a different group.
ioossi To prevent group substitution, the component receiving parameters must ensure that the rule group has one rule for every parameter it consumes in a given usage context, and only one rule. For example, if a group of three rules Z, X, and Y
require Y to be a string, a different group X and Y could require Y to be an integer.
When a component consumes X, and Y, it will ensure there are only rules for X, Y in the group and validate Y as an integer. Trying to use the group Z, X, Y for the same component consumption will fail because the Z rule would not be used.
19067] Steps 808 and 908 represent yet another stage of signing whereby validation rules are signed together with a second ID, for example a session ID.
100681 Steps 810 and 910 represent another stage of signing whereby validation rules are signed together with a target ID.
[0069] The target ID and a second ID, for example, the session ID may further be signed together with the validation rules as illustrated in 812 and 912.
[007o] As will be readily understood by a person skilled in the art, terms "signing"
"'signed" and "signature" in the above and accompanying figures are intended to include both symmetric and asymmetric algorithm, for example but not limited to cryptographic hash functions, HMACs, or private public key signatures.
[0071] The invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof. Apparatus of the invention can be implemented in a computer program product tangibly embodied in a 1 I I I 1 Y.111 machine-readable storage device for execution by a programmable processor; and method actions can be performed by a programmable processor executing a program of instructions to perform functions of the invention by operating on input data and generating output. The invention can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each computer program can be implemented in a high-level procedural or object oriented programming language, or in assembly or machine language if desired; and in any case, the language can be a compiled or interpreted Ilanguage. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory. Generally, a computer will include one or more mass storage devices for storing data files. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM
disks. Any of the foregoing can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).
[0072] The present invention has been described with regard to one or more embodiments. However, it will be apparent to persons skilled in the art that a number of variations and modifications can be made without departing from the scope of the invention as defined in the claims.
Claims (13)
1. A method of validating request data transmitted between an untrusted client and a server based on characteristics of a previous response comprising the steps of:
a) building a response with a validation rule, the response having a characteristic indicative of a constraint to be applied to subsequent request data, the validation rule including the constraint;
b) receiving the response by the untrusted client;
c) building the subsequent request, the subsequent request including the subsequent request data and the validation rule;
d) sending the subsequent request to the server;
e) receiving the subsequent request at the server; and f) validating the subsequent request data using the validation rule.
a) building a response with a validation rule, the response having a characteristic indicative of a constraint to be applied to subsequent request data, the validation rule including the constraint;
b) receiving the response by the untrusted client;
c) building the subsequent request, the subsequent request including the subsequent request data and the validation rule;
d) sending the subsequent request to the server;
e) receiving the subsequent request at the server; and f) validating the subsequent request data using the validation rule.
2. The method as claimed in claim 1, wherein the characteristic is a response primitive affecting the subsequent request data.
3. The method as claimed in claim 2, wherein the response primitive is a parameter.
4. The method as claimed in claim 2, wherein the response primitive is a structure of a plurality of parameters.
5. The method as claimed in claim 1, wherein the request has a parameter, and a validation rule corresponding to the parameter.
6. The method as claimed in claim 1, wherein the response and the subsequent request further comprise a target ID.
7. The method as claimed in claim 1, wherein the response and the subsequent request further comprise a session ID.
8. The method as claimed in claim 1, further comprising the step of digitally signing one member selected from the group consisting of: the constraints in the validation rule, the validation rule, the plurality of validation rules, the plurality of validation rules with target ID, the plurality of validation rules with session ID, and a combination thereof.
9. The method as claimed in claim 8 wherein the step of digitally signing uses a keyed hash message authentication code (HMAC).
10. The method as claimed in claim 8 wherein the step of digitally signing uses a public private key signature.
11. The method as claimed in claim 1, further comprising the step of ensuring the correctness of the subsequent request at the client using the validation rule.
12. A system for validating request data transmitted between an untrusted client and a server based on characteristics of a previous response comprising:
means for building a response with a validation rule, the response having a characteristic indicative of constraints to be applied to subsequent request data, the validation rule including the constraints;
means for receiving the response by the untrusted client;
means for building the subsequent request, the subsequent request including the subsequent request data and the validation rule;
means for sending the subsequent request to the server;
means for receiving the subsequent request at the server; and means for validating the subsequent request data using the validation rule.
means for building a response with a validation rule, the response having a characteristic indicative of constraints to be applied to subsequent request data, the validation rule including the constraints;
means for receiving the response by the untrusted client;
means for building the subsequent request, the subsequent request including the subsequent request data and the validation rule;
means for sending the subsequent request to the server;
means for receiving the subsequent request at the server; and means for validating the subsequent request data using the validation rule.
13. A storage medium readable by a computer encoding a computer program for execution by the computer to carry out a method for validating request data transmitted between an untrusted client and a server based on characteristics of a previous response comprising, the computer program comprising:
code means for building a response with a validation rule, the response having a characteristic indicative of constraints to be applied to subsequent request data, the validation rule including the constraints;
code means for receiving the response by the untrusted client;
code means for building the subsequent request, the subsequent request including the subsequent request data and the validation rule;
code means for sending the subsequent request to the server;
code means for receiving the subsequent request at the server; and code means for validating the subsequent request data using the validation rule.
code means for building a response with a validation rule, the response having a characteristic indicative of constraints to be applied to subsequent request data, the validation rule including the constraints;
code means for receiving the response by the untrusted client;
code means for building the subsequent request, the subsequent request including the subsequent request data and the validation rule;
code means for sending the subsequent request to the server;
code means for receiving the subsequent request at the server; and code means for validating the subsequent request data using the validation rule.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2584940 CA2584940A1 (en) | 2007-04-13 | 2007-04-13 | Method and system for stateless validation |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2584940 CA2584940A1 (en) | 2007-04-13 | 2007-04-13 | Method and system for stateless validation |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2584940A1 true CA2584940A1 (en) | 2008-10-13 |
Family
ID=39855361
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2584940 Abandoned CA2584940A1 (en) | 2007-04-13 | 2007-04-13 | Method and system for stateless validation |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2584940A1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10958682B2 (en) | 2011-09-21 | 2021-03-23 | SunStone Information Defense Inc. | Methods and apparatus for varying soft information related to the display of hard information |
-
2007
- 2007-04-13 CA CA 2584940 patent/CA2584940A1/en not_active Abandoned
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10958682B2 (en) | 2011-09-21 | 2021-03-23 | SunStone Information Defense Inc. | Methods and apparatus for varying soft information related to the display of hard information |
| US11283833B2 (en) | 2011-09-21 | 2022-03-22 | SunStone Information Defense Inc. | Methods and apparatus for detecting a presence of a malicious application |
| US11943255B2 (en) | 2011-09-21 | 2024-03-26 | SunStone Information Defense, Inc. | Methods and apparatus for detecting a presence of a malicious application |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9178705B2 (en) | Method and system for stateless validation | |
| US7475138B2 (en) | Access control list checking | |
| US7542957B2 (en) | Rich Web application input validation | |
| US7984479B2 (en) | Policy-based security certificate filtering | |
| US20050228984A1 (en) | Web service gateway filtering | |
| US8205238B2 (en) | Platform posture and policy information exchange method and apparatus | |
| US20080178278A1 (en) | Providing A Generic Gateway For Accessing Protected Resources | |
| US20100332837A1 (en) | Web application security filtering | |
| US7765310B2 (en) | Opaque cryptographic web application data protection | |
| KR20060100920A (en) | Trusted third party authentication for web services | |
| Gruschka et al. | Server-side streaming processing of ws-security | |
| Bhargavan et al. | A semantics for web services authentication | |
| US8996715B2 (en) | Application firewall validation bypass for impromptu components | |
| US20070277225A1 (en) | Method and system for providing a secure message transfer within a network system | |
| JP2010288313A (en) | Secure data communications in web services | |
| US7313687B2 (en) | Establishing a secure context at an electronic communications end-point | |
| Ladan | Web services: Security challenges | |
| WO2005114956A1 (en) | Method and apparatus for processing web service messages | |
| CA2512931A1 (en) | Rich web application input validation | |
| CA2584940A1 (en) | Method and system for stateless validation | |
| Rodrigues et al. | Engineering secure web services | |
| CA2510633C (en) | Access control list checking | |
| Sidharth et al. | Intrusion resistant soap messaging with iapf | |
| Kadir | RewritingHealer: An approach for securing web service communication | |
| Holtkamp | The role of XML firewalls for web services |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Dead |