DESC:FIELD OF THE INVENTION:
The present invention provides a transparent system for mitigating web vulnerabilities and method thereof. More specifically the present invention discloses a system and method to mitigate cross site scripting (XSS) attack and Structured Query Language (SQL) injection in web applications by using two way interception proxy that parses HTTP request/ response pair.

BACKGROUND OF THE INVENTION:
In last two decades due to the rapid advancement in communication technology and wide spread Internet use, various kind of services such as banking, reservation of tickets are now accessible online. Such service providers use web applications to provide these online services to the service users. The web applications are usually hosted using application servers and are accessed by the users with the help of web browsers.

These web applications are connected to the back end database systems that store huge amount of data which may be private or confidential. The user queries or updates the data in the database through these web applications. The data may be confidential as it contains user credentials which includes credit card number or other user information, therefore the role of these web applications become very critical. The web applications which are not securely designed are vulnerable to some serious threats in terms of attack from the third party who can access the confidential information and may cause significant financial loss to the service user.

Structured Query Language (SQL) injection attack and cross-site scripting attack (XSS) are two types of web application vulnerabilities which involve unauthorized access or modification of data in the database (SQL Injection) and inserting of malicious code into the web application to steal client side data (XSS). The reason for their popularity with web-attackers is attributed to the fact that both these attacks are incredibly easy to implement and do not require specific environment or resources.

SQL is a standard language used to create, modify and retrieve information from relational database systems such as Microsoft Access, Oracle, MS SQL server. In SQL injection attack, the attacker injects malicious SQL statements in the user input fields for their execution in the database system. The result is that the attacker can have unauthorized access of the database system.

This injection of malicious codes into the database through web application have far reaching implication; for example it may allow the third party to get access and control over the database which may result into theft or deletion of sensitive information such as user credentials, credit card numbers etc. stored in the database system.

The web applications which usually contain un-sanitized user provided data are prone to cross site scripting (XSS) attack. These attacks may be through emails or even through user comments. One such example of an XSS attack could be in an online book store which allows the un-sanitized user comments to be visible to other user, the attacker might place a hyperlink embedded with some malicious script at the user comments area. When another user selects that hyperlink, the malicious code steals or copies user cookies and sends them to the attacker. These cookies may allow the attacker to hijack the user session or enable unauthorized access to the user details.

The prevalent solution to mitigate these kinds of vulnerabilities is to perform input data validation in the web application before the input is being used in the rest of the application code. Data validation involves filtering of data using black list of special characters or white list of allowed input at the server side before the submitted data is used in the rest of the application code. But most of the web applications do not perform data validation on the user input as it is not strictly enforced and is left at the discretion of the web application developer. The implementation of the input data validation techniques need to be effective and performance friendly.

In the current state of art many defense strategies namely Browser Enforced Embedded Policies (BEEP), None space and secure web application proxy (SWAP) are being used for securing the web application that are implemented at the server end or at the client side or in some case involving both the server and the client sides.

BROWSER ENFORCED EMBEDDED POLICIES
Browser Enforced Embedded Policies or BEEP is an alternative to the simple data filtration employed in XSS attack mitigation. It is a client side technique with limited interaction from the server side.

The Server Side: The server side provides a policy to allow or disallow script execution. This policy might just be a list of hashes of valid scripts embedded in their web page response. The server side must maintain and update this policy regularly for it to be effective.

The Client Side: The client side policy embedded in the web pages is executed by the client browser. The client side implementation involves a JavaScript security hook which is used to approve/ disapprove scripts. The security hook is always the first JavaScript code to be executed. Extensive browser modification is necessary to ensure that each time a script is invoked, the hook is called. The hook parses the script in some way; most commonly a hash is calculated and compared with the corresponding hash in the policy. If the hashes match, the script is deemed legitimate, and is allowed execution, else it would be ignored.

Policies Used: Two types of policies have been experimented with BEEP: Whitelists and DOM sandboxes. A whitelist of scripts is maintained and each time a script is encountered by the browser, it is matched against this whitelists. A match would allow execution, and a non-match would prevent execution. The script hash method hashes each script and maintains a list of hashes. If the attack script is to be executed, it has to match any one of these hashes. If the hashing algorithm is implemented properly, there will not be any chance of a miss. A DOM sandbox uses a blacklisting approach. This method requires significant contribution from the developer side. The developer has to identify and demarcate the specific locations within the web page where malicious scripts may get executed. The demarcation is usually done using a div class= “noexecute” tag. The hook then checks the DOM tree and identifies all nodes which are marked “noexecute” and prevents execution within such nodes.

Impact and Effectiveness: The BEEP method has significant advantages. The method, if correctly implemented offers a high degree of protection against XSS attacks. Nearly 100% detection can be achieved, but its effectiveness depends on the effectiveness of the hashing algorithm in the whitelisting policy and on the efficiency of the web developer to identify locations where malicious code can execute. These two points are the key determining points in this approach and depending on these, the effectiveness of identifying XSS attacks can be determined.

The list of disadvantages include: Special browser modifications necessary at the client side, to ensure that all scripts pass through the security hook. In case of the DOM approach, the web developer needs to be absolutely aware of all locations of possible intrusion to perform the demarcation. The whitelisting approach requires the usage of a high resolution hash function, which hashes to a significantly large data value to prevent clashes. Hashing must simultaneously be clash free and efficient; this is a difficult tradeoff to maintain. In case of the hashing approach, a trivial change in the script function, such as the addition of even a single whitespace requires rehashing and updating of the policy.

B. Noncespaces
Proposed by Gundy and Chen et al , noncespaces is a highly effective technique which expands upon the nonce concept of cryptography. This method helps in creating a reliable distinguishing feature between the content generated by a web application and the content provided by an adversary when they appear in the same page. To accomplish this, the web application partitions the web content into different “trust classes”. Each trust class has a specific limit to its functionality. This limit is based on a policy which is enforced by the browser. Thus, it is very similar to BEEP, but the functionality of BEEP is enhanced using noncespaces.

The Server Side: The server does not play any role in sanitizing the input. Instead it annotates nodes in an XHTML document with trust classes. To do this, they use randomly generated XML namespace prefixes. XML namespaces usually work by qualifying elements and attributes by associating them with namespaces identified by URL references. To denote the namespace, the user chooses a string as prefix of a tag and associates the prefix with the namespace URI.

E.g:

This prefix is generated randomly from a finite prefix space on every document delivery. Thus, we have a random prefix each time, leading to the name noncespaces. In the example, “prefix” is the random prefix assigned to each tag and unprefixed implies untrusted. The untrusted code is assumed to be embedded by the attacker through some channel.

The Client Side: At the client side, an implementation similar to the one in BEEP is carried out. The policy needs to be communicated to the client if they are to be implemented. Noncespaces uses three additional HTTP headers: The X-Noncespaces-Version,X-Noncespaces-Policy, and X-Noncespaces-Context. Each of them communicates the following to the client:

• X-Noncespaces-Policy: Denotes the URL of the policy for the current document. If the client does not have the policy in its cache, a compliant client must first retrieve the policy before rendering the document.
• X-Noncespaces-Version: Communicates the version of the Noncespaces policy and semantics that should be used, in case future changes are required.
• X-Noncespaces-Context: Maps the namespace prefixes in the policy to the namespace prefixes in the XHTML document contained in the response.

Each time a document is served a separate randomized prefix is used to prevent hackers from attempting to undermine the system. When checking a document’s conformance to a policy, the client considers each rule in order and matches the XPath expression against the nodes in the documents’ Document Object Model. When an allow rule matches a node, the client permits the node and will not consider the node when evaluating subsequent rules. When a deny rule matches a node, the client determines that the document violates the policy and will not render the document. As a failsafe, any nodes remaining unmatched are automatically marked as policy violations. The browser/client side additions include the ones to check and manage the policy and to properly render document using JavaScript in case of namespace unaware browsers.

Impact and Effectiveness: Noncespaces is a highly effective method which is also highly modifiable, given the only changes needed are the ones made to the policy and a mechanism for generating random prefixes. However, the transparency is affected at server side and client side equally and special add-ons are required. However, given the advantages of the method, the method is highly efficient for all classes of web applications.

SWAP: Secure Web Application Proxy
The Secure Web Application Proxy or SWAP in short, is by far the most effective method explored in XSS mitigation. Designed by Wurzinger et.al, SWAP utilizes a reverse proxy which checks for an encoding scheme in the server response. The encoding scheme represents all correctly encoded scripts based on a dictionary. An attackers script, if any, needs to follow the encoding scheme correctly, else it will be identified and marked.

The Server Side: The web developer creates an encoding dictionary. It maps all legitimate scripts, developed by the web developer to an encoded format in the following model:

Consider that:
is encoded to
is encoded to <scrip1>

The encoding is done only for all legitimate scripts. As such, the server maintains a pre-parsed and encoded version of the web page before sending it to the client.

The Reverse Proxy: The reverse proxy captures the HTTP response alone. This response contains both the encoded scripts and the attackers embedded script which is obviously not encoded. The reverse proxy passes the page to a fully functional Firefox browser which is slightly modified to detect the presence of any JavaScript. If any JavaScript execution is detected, then the page is thought to contain an attack as all legitimate scripts are encoded and thus, would not execute. At this point, the reverse proxy can make a choice. It can either remove the illegitimate script or send the response while making a log of an attack attempt or it can block the web page entirely and inform the web developer. In any case, if the web page is sent to the client, it needs to be parsed and decoded, so that the legitimate scripts work at the client side. Hence the encoding dictionary needs to be maintained at the proxy side.

The Client Side: This method is completely transparent to the client and as such would not require any client side modifications or add-ons

Impact and Effectiveness: SWAP is a highly effective method which, not surprisingly, leads to 100% detection of all XSS attempts. It is completely transparent at the client side, and offers a significant level of transparency at the server side. However, the method is not at all performance friendly. The method leads to a performance lag at the proxy side. The lag is not an acceptable loss in performance. Hence, the disadvantages include: If the attacker gets any information about the encoding dictionary, he would be able to craft scripts which match the encoding scheme and bypass the mitigation technique. The method is not performance friendly owing to the use of a Firefox browser and due to decoding at the proxy side. Further said server need to maintain and update pages based on the changes made in script needs to maintain and update pages based on the changes made in script, if any.

However these methods require heavy modifications in either the client side or in the server side. For example users have to install third party application or browser plugin to enhance their browsers. Further, web developers have to worry about extra implementations in order to protect their data. This is a serious drawback in the existing state-of-the-art.

It is significant to note that since the HTTP request/response pair is the primary data exchange link in any client-server communication, therefore all web application attacks which use user data as the attack vector, such as Cross Site Scripting and SQL Injection, must pass through this request/response channel. Hence this channel, if adequately protected can prevent a variety of vulnerabilities from getting exploited. Furthermore protection needs to be performed in such manner that there is a high level of transparency for both the principal participants namely the client and server

OBJECT AND SUMMARY OF THE INVENTION:
In order to obviate the drawbacks in the present state of art the main object of the present invention is to provide a transparent system for mitigating web vulnerabilities such as cross scripting attack and SQL injection attack by using two way interception proxy that parses HTTP request/ response pair.

Another object of the invention is to provide a single point of vulnerability management.

Yet another object of the invention is to provide a method of providing single point vulnerability management which is modular and therefore independent of both principal parties namely the client and the server.

Accordingly the present invention provides a transparent system for mitigating web vulnerabilities and method of performing the same. This invention is a computer implemented system and method to mitigate cross site scripting (XSS) attack and Structured query language (SQL) injection in web applications by using two way interception proxy that parses HTTP request/ response pair.

The present system and method uses a combination of dynamic data tainting and selective escaping implemented in HTTP proxy to mitigate SQL injection and Cross Site Scripting attacks. The fact that user data is the single most important attack vector forms the crux of the solution. The methods disclosed in the invention overcomes the drawbacks in the existing solutions by providing techniques that are highly modular in contrast to existing techniques and therefore separate from both the server and client, thus improving transparency. The disclosed invention creates a single point of vulnerability management where changes are implemented and this makes future modifications and enhancements easier.

The mitigation of Cross Site Scripting attack (XSS) is done using a mini-dictionary based tainting approach. Effective taint propagation ensures that the user is protected from XSS attacks. The method used to mitigate SQL injection attack is by way of minimal syntax matching process using an SQL data model based on SQL grammar. SQL injection is mitigated by taking advantage of the SQL syntax. The attacker must conform to the syntax in order to perform an injection attack and this requirement enables the system to construct an effective data model which helps in identifying SQL injection attempts in the HTTP request.

It is significant to note that since the HTTP request/response pair is the primary data exchange link in any client-server communication, therefore all web application attacks which use user data as the attack vector, such as Cross Site Scripting and SQL Injection, must pass through this request/response channel. Hence this channel, if adequately protected can prevent a variety of vulnerabilities from getting exploited. Furthermore, protection needs to be performed in such manner that there is a high level of transparency for both the principal participants namely the client and server.

Accordingly the present invention provides for transparent system to mitigate cross site scripting (XSS) attack and Structured Query Language (SQL) injection, said system comprising of at least one client side capable of generating HTTP request, at least one server side capable of generating HTTP response(B) in response to HTTP request (A) and at least one Interception Proxy Server acting as independent intermediate between said client side and server side.

The Interception Proxy Server comprises of Request Parser Unit and Response Parser Unit. The Request Parser Unit is capable of intercepting HTTP request sent by client, identifying tainted user data if present in HTTP request, and modifying said tainted user data by demarcating it before sending to said server. The Response Parser Unit is capable of intercepting HTTP Response sent by server decompressing said HTTP Response, identifying tainted data, escaping identified tainted data, if present, into harmless non-executable text, compressing clean data for delivery to client.

The Request Parser Unit comprises at least one mini-dictionary module having list of characters that cause XSS attack, at least one SQL data model having minimalistic data model for simple pattern matching capable of causing SQL Injection, at least one data tainter for demarcating tainted data, if any. When the parser matches the content of HTTP data with the list of said characters of mini-dictionary module as well as with the minimalistic model of SQL data model module and finds a successful match, then said data tainter demarcates said matched data by using demarcation taint tags creating demarcated tainted data before sending the so modified HTTP Request to the Server.

The response parser unit comprising of at least one Decompressor unit (301) for decompressing the said modified HTTP response, at least one taint checker capable of checking said decompressed modified HTTP response for retrieving and separating said demarcated tainted data, at least one escaper module for converting tainted data into harmless non-executable text, at least one compressing unit capable of compressing the modified data for delivery of the modified HTTP Response to the client.

The content of said HTTP Request is matched with minimistical model of SQL data model, said content of said user data contains SQL injection query is altered by said data tainter by adding tainting tags in a manner that said SQL injection is not executed on the server side.

The demarcated data in HTTP response is the data which is matched with the said list of mini-dictionary and subsequently tainted by Data tainter in the request parser unit and capable of causing cross scripting attack on client side.

The escaper unit employs selective escaping technique in which escaper only escapes the demarcated content of HTTP response by redefining them in a manner that said contents are not executable at the client side thereby preventing cross-scripting attack.

The list of minidictionary is special characters such as angle bracket, open bracket semicolon or a colon or any known character without which cross-site scripting (XSS) is not possible.

The invention discloses a transparent method to mitigate cross site scripting (XSS) attack and structured Query language (SQL) injection in web application by using two way interception proxy comprising steps of sending of HTTP request to the server (400) by the client(100), intercepting of an HTTP request (A) by the interception proxy server(100), at request parser, retrieving HTTP user data (HTTP request variables) from HTTP input request, sending of the extracted HTTP data to mini-dictionary, sending of the extracted HTTP data to SQL data, matching the contents of said HTTP data with the list of characters of said mini-dictionary(201) to identify the XSS attack, matching the contents of the extracted HTTP data to the minimalistic SQL data model to identify SQL injection attack, demarcation of matched data which is capable of causing SQL injection attack by tainting it with the demarcation taint tags by using data tainter for identified. Similary demarcation of identified Matched data by tainting it with demarcation taint tags by using data tainter which is capable of causing XSS attack is carried out followed by sending of the modified HTTP request to the server, mitigating SQL injection attack if any due demarcation of tag altering the identified SQL which breaks the SQL injection in to simple text which is not capable of executing on the server end, generation of HTTP response by server, intercepting HTTP response by response parser at decompressor module, decompression of data by decompressing module and sending it to DOM parser unit, separating of demarcated data content of step (506) which is sent along with the HTTP response ) and sending it to the Escaper module.

The method also involves the selective escaping of demarcated data in HTTP response by replacing them with the escaped character in the HTTP response which are only display characters, and not recognized as code which can be executed (300) and compressing of HTTP response data in the compression module thereby generating modified HTML response free from XSS attack to the client.

The system of the present invention is modular, said interception proxy server is independent of client and server side thereby ensuring that any change in interception proxy server does not affect the client server processing exchange severely. Further the system is performance friendly since it only processes HTTP user data which is very limited instead of processing entire HTTP request and HTTP response.

BRIEF DISCRIPTION OF DRAWINGS
FIG 1 illustrates the architecture of the system for mitigating cross scripting attack
Fig 2 illustrates the Flow chart or the method for mitigating the cross-scripting attack
Fig 3 illustrates an HTTP request before demarcation logic is applied.
Fig 4 illustrates the same HTTP request after demarcation logic is applied
Fig 5 depicts the HTTP response in which the script is applied before Escaping logic is applied.
Fig 6 depicts the HTTP response in which attacking script is escaped which is escaped by the escaper.
Fig 7 depicts the SQL minimalistic Data model.
Fig 8 illustrates the fully stacked SQL data model for whole queries.
Fig 9 illustrates the fully stacked model for Query alerting.
Fig 10 illustrates the sample attack 1 with-out interception proxy server
Fig 11 illustrates the successful sample attack 1 without interception proxy server.
Fig 12 illustrates another sample attack 2 without interception proxy server,
Fig 13 illustrates another successful sample attack without interception proxy server.
Fig 14 illustrates another sample attack with interception proxy server.
Fig 15 shows a sample persistent attack script located within the database of the server
Fig 16 illustrates the result of a sample attack on the same without using intercepting proxy
Figure 17 shows unsuccessful XSS attack when intercepting proxy is used.
Figure 18 shows the performance comparison request vs response Time with and without proxy for SQLi script
Figure19 shows the performance comparison request vs response time without proxy server for XSS attack.
Fig 20 shows the performance comparision request vs response with proxy server for XSS attack.

DETAIL DESCRIPTION OF THE INVENTION:
The present invention relates to the transparent system for mitigating the cross-scripting and SQli attack.

The present invention provides a transparent system for mitigating web vulnerabilities. More specifically the present invention discloses the system and method to mitigate cross site scripting (XSS) attack and Structured Query Language (SQL) injection in web applications by using two way interception proxy that parses HTTP request/ response pair.

Definitions
The client is a piece of computer hardware or software that accesses a service made available by a server.
The server is often (but not always) on another computer system, in which case the client accesses the service by way of a network.[1] The term applies to programs or devices that are part of a client–server model.
HTTP is Hypertext Transfer Protocol designed to enable communication between client and browser.
The term “HTTP request” herein specification refers to the request made by a client like web browser to the web server using “Hypertext transfer protocol.
The term “HTTP response herein specification refers to the reply sent by the web server to its client’s (web browser) request using the Hypertext transfer protocol.
The term “ Proxy server” herein specification refers to a server which is computer system or an application that sits between client and server communications channel and perform some processing and/or redirection on the HTTP request /response process.
The term “Parser” herein specification referred to as a module which checks the given input as per the rules of the protocol or the language for which the parser is designed for. For example. SQL parser checks whether the given input string is as per the rules of the SQL grammar, Request Parser checks whether the given input is per the HTTP request format, Response parser checks whether the given input is per the HTTP response format.
HTTP Compression - HTTP protocol supports compression to reduce the size of the data transfer between the client (web browser) and web server. The client can specify the list of compression techniques it supports, using the “Accept-Encoding” header in the HTTP request. The web server can pick of the supported compression techniques from the list received, to compress its response to the client. The compression technique used in the response by the web server is specified using the “Content-Encoding” header in the HTTP response.
Decompressor module herein specification refers to the module which is designed to decompress the data received as per the compression scheme mentioned in the HTTP header.

Compressor module herein specification refers to a module which compress the data back to the required compressed format as mentioned in the HTTP header, once the proxy completes its operations on the input received.

Document Object Model (DOM) is the model using which, all the HTML elements in a webpage are organized in to a tree like structure called the DOM-tree. This structure is used by the web browsers while rendering the webpage on the browser.

Structured Query Language is standard language used to interact with relational databases like MySQL, MSSQL, Oracle, etc.

Javascript – Java script code is used to add dynamic functionalities to the webpage. They are sent along with the HTTP response. They are executed by the web browsers (client).

HTML – Hyper Text Markup Language – Web pages are coded using this language. The HTTP response generally has HTML documents in the HTTP response body. Web page uses HTML for defining the presentation elements, Cascading Style Sheet (CSS) for mentioning the presentation styles used by various HTML elements and Javascript to add dynamic functionality to the web page. CSS and Javascript are optional.

The present invention employs the system in which interception proxy server is used which forms the heart of the implementation. This proxy server captures all HTTP request/response pairs and makes slight modifications to them. The incoming request data, if any, are all demarcated with start and end tags. Then at the response, the demarcations are escaped to prevent XSS attacks. The demarcation is based on the actual content of the data, and this is where the mini-dictionary and the minimalistic SQL data model operate.

Fig 1 illustrates the architecture of the system which mitigates the cross-site scripting and SQL injection attacks. The system comprising of at least one client (100) and at least one server (400), at least one two way intercepting proxy server (200,300). The interception proxy server (300) act as an independent intermediate server between client (100) and server (400) .

The interception proxy server (200,300) comprises of at least one request parser unit (200) and at least one response parser unit (300). The function of request parser unit (200) is to intercept and parse the HTTP request data (A). The function of response parser unit (200) is to intercept and parse the HTTP response (B)

The input request is in the form of HTTP request which contains HTTP header and HTTP request data or content

The request parser unit comprises of three modules namely mini dictionary module (201), SQL Data model module (202), Data tainter(203).

The mini-dictionary module (201) comprising a list of special characters without which XSS attacks would be impossible while the SQL data model (400) contains a minimalistic SQL data model for a simple pattern matching. The request parser unit employs data tainter (203) to demarcate the matched HTTP data using a start tag and end tag which is added on either side of the HTTP Data (variables) .

The Interception proxy server intercepts the HTTP request and sends the received HTTP request to the request parser Unit. The parser (200 extracts the data from HTTP request and passes it through the mini dictionary module (201). The same HTTP data is then passed through the SQL data model module (202) which checks it against the minimalistic data model.

In mini-dictionary module the parser (200) checks for each user HTTP data for any of the characters in the mini-dictionary (201). If there is a match, then it is considered for tainting. The minimalistic SQL model (400) contains a model for a simple pattern matching. If the pattern of the user input HTTP data matches the SQL data model, a match is registered and the data is considered for tainting then the content of HTTP data may have SQL injection.

If a data is being tainted is either an XSS attack or an SQL injection attack, the purpose of the mini dictionary is simply to avoid numerical or date fields from getting tainted. This avoidance also applies for SQLi scripts since the scripts cannot be propagated through numerical or date fields.

Alternatively this check can be done at the client side using JavaScript. However even if such a check is not done, the mini-dictionary (201) or the SQLi data model (202) would taint the attack script leading to non-execution.

Also, the taint is removed from the response on reflection of the user data in the response. So, even if a data is tainted even though it is not an attack, the taint would be removed at the response parsing side and would not affect execution.

Data tainter taints the demarcates the data using a start tag and end tag which is added on either side of the HTTP data (variable). Also, the content-Length field of the HTTP header has to be edited to incorporate the extra length after tainting has been done. The tainter passes data through the dictionary and then through the SQL model. If either of them returns a positive, the data is tainted. The taint has to be any small sequence of patterns which is unlikely to be repeated in the web page. Also, since an attacker who is knowledgeable about the demarcation pattern used, he may attempt to disrupt the tainting process by attempting to provide an end tag and a start tag before and after his data. As such, it is imperative that, before the parsing and tainting step, the proxy has to check the user data for existence of the taint pattern before attempting a taint.

The Response Parser:
The Response Parser works in the HTTP response captured by the interception proxy The Response Parser comprises of at least one Decompression module (301), at least one Taint checker(302), at least one Escaper (303), at least one compression module (304)

The decompression module decompresses HTTP data which is in compressed form which is encoded in some specific format (eg: gzip) as specified in the header of HTTP response. The function of taint checker (302) is to parse the decompressed HTTP data(web page) and separates the content demarcated by the start and end tags.

The escaper module (303) escapes the special characters within the demarcated section in the HTTP response by generating the equivalent escape character sequences. The escaper module (303) generates data with escaped characters which hold no meaning in HTML or JavaScript. The only requirement of the escaper module is that characters such as ‘<’ and‘>’ are escaped as per HTML syntax (< >) and the other special characters like /, ‘,”, etc(/, ', ") have to be escaped as per JavaScript syntax. The escaped statement is replaced back in the http response and the whole content is recompressed in the compressor module (300) as per the original compression scheme (mentioned in the HTTP header)

Fig. 2 is a flowchart illustrating a method to mitigate cross site scripting (XSS) attack and Structured Query Language (SQL) injection by using two way interception proxy that parses HTTP request/ response pair.

The method starts at step (501) when client (100) sends HTTP request to server (400). The HTTP request comprises of HTTP header and content or data. At step (502) request parser (200) intercepts this HTTP request and extracts the HTTP data from HTTP request in step (503). At step 504(a) request parser unit sends the HTTP data to the mini-dictionary module (201) where contents of data are matched with the list of characters of mini-dictionary in step 505(a). At step 505(b), the request parser(200) sends the extracted HTTP data to the SQL data model where its contents are matched with SQL data model.

At step (506) the contents of data which matches either in steps 505 (a) or in 505(b) are tainted in the step (506) by data tainter by demarcating it with start and end tag to it and send it as modified HTTP request to the Server (400) in step (507). The start and end tags are different based on whether the match is for step 505(a) or step 505(b). The SQL injection does not succeed at the server side if there is taint on the SQL injection input at step (506). Depending on the design of the web application, the tainted data can get added as part of the response in step (506). If it is valid inputs from the user, the taint will not happen and hence will not affect the SQL queries generated by valid inputs. With respect to Cross-site scripting, the tainted data will come in the HTTP response and will be handled by the response parser, which escapes the data and hence the script will not be executable by the browser. At step (507) said interception proxy server send the modifed HTTP request to HTTP server,

At step (508), if there is unsuccessful SQL injection if any due to Demarcation tags in the modified HTTP request data which altered the SQL injection query.

At step (509) server generates HTTP response which comprises of HTTP header and content or data. At step (509), said response parser(300) intercepts the HTTP response by receiving it in decompressor module (301) where it performs decompression of data per code specified in HTTP response header and transfers it to the Taint checker (which can make use of DOM parser) unit in step (510). Then at step (511), the Taint checker parses the contents of HTTP response and separates the demarcated content (which can be tainted malicious Java script code or SQL injection) reflected back along with HTTP response and send it to the Escaper module (303) in step (508). At step (508), the escaper module (303) escapes the demarcated data contents by selectively escaping and replacing them with the contents which are interpreted as symbols to be displayed and not as part of code to be executed by the client browser (100) For example in case the demarcated HTTP content data is malicious Java script code, the escaper module redefine it in a manner that browser of the client does not recognize it as a executable script and just displays it as text

The present method employs two way interception proxy to intercept both requests and responses and makes suitable modifications on them. The proxy method is the best choice as server modifications implies a loss of transparency of the server side. The method and system can optionally be incorporated with the core server code, but would be too taxing on the server performance as a whole.

As such, the proxy, if maintained and operated on a separate system, would enhance the server functionality without serving as a hindrance.

DEMARCATION BY TAINTING:
Fig 3 and Fig 4 illustrate the manner in which the present system demarcate the HTTP request. Figure 4 shows an HTTP Request before demarcation logic was applied. Figure 5 shows the result of the present system, where the XSS code gets back to the browser as java script code (<script> alert(“Hello”), which produces a javascript alert box when executed. The alert box can be replaced by malicious java script to steal user data stored on the browser. Figure 6 shows the result of applying demarcative logic, where the special characters involved in defining javascript code is escaped (got replaced by equivalent display characters(<(<),>(>),“("),&(&)- (alert("Hello") )instead of characters which are considered to be part of javascript code)

Traditionally the aim of tainting is to uniquely identify the tainted data with the help of the taint, which is a piece of metadata attached to the data. Tainting is used to identify propagation of a particular data through a system and to study the effects of modification on it. In present invention, tainting is employed for a different purpose in which the HTTP request data is demarcated using a set of taint tags for example |tg and |et as depicted in Fig 4 and Fig 5. The demarcative taint can be anything, which is not generally a part of the web content as it is used to differentiate between web content and user provided data. As such, it is imperative that web developers have some control over the demarcative tag they are going to use to taint their data. Demarcation is done to differentiate between web content and user provided (and hence possibly malicious) content. .

SELECTIVE ESCAPING:
Escaping is done in the HTTP response and hence is performed in the return flow from the server. Escaping changes the meaning of data by redefining it.

The proposed system employs the selective escaping technique implementation, such that Escaper only escapes portion of data which is positively identify as user generated content using the demarcative tags
For example when escaping is done on certain HTTP data it changes the meaning of certain symbols by redefining it such that Browser compiler at the client end identifies the symbols < symbol as a tag open symbol rather than a “less than” symbol. It also makes sure that they are displayed as intended.< and > are the “less than” and “greater than” symbols which hold no meaning in browser code lingo and hence can be effectively used to replace them in user provided content so that such content is never identified as a DOM element and hence a script. Similarly, a variety of symbols can be replaced with its visually similar, but functionally different counterparts.

Many modern browsers, such as Google Chrome already perform this function and hence DOM based attacks are nearly impossible in Chrome. Modern browsers such as Chrome convert the data to its URL encoding format which nullifies the effect of any JavaScript.

The present system employs innovative selective escaping technique in which the portion of data which is demarcated using taints are only escaped and therefore present system only requires to parse and escape is significantly smaller data which in turn improves its performance which is lagging in prior system.

In Figure 5, the highlighted text indicates a script which is injected into the DOM and in this case, the XSS attack is successful. However, Figure 6 indicates the same after escaping logic has been applied. Now, a browser displays the attack script text as it is, but, since the tags are changed, the browser does not identify this as a script and the XSS attack fails.

Mini Dictionary:
The mini-dictionary is a technique used to demarcate data selectively. Here, in the present system the aim is to demarcate the data containing XSS script and not demarcate data which does not contain XSS. The web uses various data formats, and XSS is possible only if the content is reflected back to the user. In case of persistent XSS, the data is stored in the web database before it embedded in a response. However, if all data is demarcated blindly, legitimate numerical and date fields would also be tainted and storage would not work.

The present system prevent this loss of transparency by imparting by employing a mini-dictionary module which contains an array of characters, special characters which should be present in any XSS attack, such as an angle bracket, open bracket, a semicolon or a colon. This ensures that the tainted data is not a purely numerical or date field. The mini dictionary is required since there is no way an HTTP request or response contains the data necessary to identify a variable as a specific type. The mini-dictionary returns true if the user data contains any one of its contents and then, tainting is done. If the mini dictionary return false, no tainting is done.

DOM-XSS Manager Script:
Both reflected and persistent XSS can be easily managed, but in case of the DOM based XSS, it is not necessary that the entire script passes through to the proxy or to the server side as a whole. This is because the anchor for links within a page usually indicated by ‘#’. It is not necessary that the section of the URL after # gets sent to the server side. So, our proxy would be completely ineffective in case of an attack such as this.

Now consider the scenario where a‘#’ is used instead. As noted, the portion of the URL after # is ignored by the browser when crafting the GET request. This is a severe problem for proxy based solutions. To combat the above scenario, there are two possible solutions:

DOM-XSS manager exists in the response parser and can be used to append a piece of JavaScript to the response HTML content. The script is executed before all the other scripts, and as such, the appending has to be done at the beginning. The script contains a copy of the mini-dictionary and escaping would be done on the data after the # anchor. This is the method which is used in the proxy.

Another method is to add a tiny piece of JavaScript which would check if a # was present and resend the request by: window.location.href =“www.mysite.com/page.php”;after removing the # and adding a ?

Minimalistic SQL Data Model:
As the name suggests, the minimalistic data model only outlines the minimum amount of data required to positively identify content as containing SQL syntax and thus, an injection attack. For example, consider the minimalistic model of a select statement as shown
in Figure 8. The figure is just a flow graph based on the SQL grammar. Any SQL injected code starts from the left hand side originating bubble eg: and continues right along a branch until it forms a full injection script.

For example, an SQL injection code, say : ‘or 1=1 or ‘ follows the branch shown below:

The select statement can use multiple SQL commands, but the very minimal select model requires only select and from to be fully functional. Thus, the minimalistic model looks for that in any entered data. Similarly, a full model can be constructed and organized for all possible.SQL commands.

The minimalistic model exists in the forward flow, between client and server and hence works in the HTTP request. After the SQL syntax is detected, it is possible to follow one of two possible courses of action.

Demarcating of the data as it is done for XSS mitigation. As SQL is not a forgiving language as HTML, the slight change is syntax would be enough to error out the SQL attack script.

For example, an SQLi injected script would not work if it had a section of tags,
select * from where value=1 |et |tg
Here, the tags would break SQL grammar and would not be executed.
• Comment out the data which contains the syntax, which would possibly help in evaluating the legitimate content before the SQL syntax.
For example, instead of demarcating tags, we could have a comment option, say: select * from where value=1 --
The comment ‘–‘ would ensure that the injected script would fail.

Among the two options, the former is considered in the present invention as there is little possibility of legitimate content along with an attack script.

ADVANTAGES OF THE INVENTION:
The present system improves the performance and increases the transparency on both sides by using tainting and escaping methodologies., This system implements data tainting which can only be done on the HTTP request from the client, and escaping on the tainted data which must be done in the HTTP response by the server., Since the present invention provides proxy based method which is independent of both server and the client. This system and method provides transparency, modularity and performance improvement over most methods owing to its simplicity.

Transparency:
Since all operation is preformed ina proxy server system, the client is completely unaware of the implementation, and the server is somewhat transparent to the implementation, though the level of transparency is limited for web applications performing extra processing on the user data. They have to consider the data taint while performing any such processing. However, for simple reflection based websites such as blogs, this method is completely transparent.

Further system also provide the opportunity to improve the transparency at the server side by using scripts which automate the removal of any and all tags present in the user data for purposes other than generation of web content. As such, this can be managed using SQL stored procedures which perform such un-tainting.

Modularity:
The present system also provides modulartity at either the client side or the server side and is hence completely modular and separate from both client and server. This ensures that any changes made to the system do not affect client server processing exchanges severely. So, this system method can be used as a separate system entirely independent of the client and server system. .

Performance:
This method is comparatively process-friendly related to SWAP; since escaping is a simple process and escaping is performed on the user input which might be a very limited part when compared to the entire web page. On the other side SWAP needs to scan and decode the scripts in the entire web page in order to perform detection.

EXAMPLE:
For the test purposes the interception proxy server for the present system developed in Java and modified in a manner the it can taint the HTTP request/response pair.

The client is Chromium Browser in Ubuntu 12.04. A vulnerable application has been created in PHP and tested by using the Java based proxy and without the Java based proxy using PHP and MySQL. The said application has been created and hosted it in an Apache2 server. The test results showed reliable detection of both XSS and SQLi attacks

Test Setup: The test setup consists of:
• Server: apache 2.2
• Platform: Ubuntu 12.04
• RDBMS: MySQL
• Client: Chromium Browser in Ubuntu 12.04
• Language: Java(TM) SE Runtime Environment 1.7.025

Results: The demo application used to test for a variety of SQLi scripts. A total of 141 test scripts were used. The set of scripts included REGEX scripts, scripts to check for unauthorized login, data leakage etc. As shown in Table 1, the proxy intervention takes up a very small amount of time. 100% of all scripts were detected and tainted/commented out. Both Altering Queries and Whole Queries were tested for and found that all sets of attack scripts were detected and tainted using the proxy.

Figures 10 and 12 shows two sample attacks which are performed on the demo application without the support of the proxy. The attacks were successful as shown in Figures 11 and 13 respectively. And Figure 14 shows the result of a sample attack on the same but this time using the intercepting proxy. The attack was not successful and was detected and tainted as shown.

Figure 15 shows a sample persistent attack script located within the database. The script can be retrieved through the Retrieve field in the application. Figure 16 shows a successful XSS attack showing execution of the script. Notice that the proxy was not involved here. The same attack was detected when the proxy was used as shown in Figure 17, thus proving the effectiveness of the Proxy method is mitigating both XSS and SQLi attacks.

PERFORMANCE ANALYSIS

The present system increases the performance by running the proxy and server implementation in separate machines which naturally reduces the work load of the server.

Table 1 and 2 shows a performance evaluation and average and total times taken for execution of the demo application without and with proxy support respectively. Each script has been run ten times and the average time over ten iterations has been calculated. All time measurements are shown in milliseconds, so, the amount of lag presented is not visible to a normal user. Also, in case of XSS scripts, the time taken varies according to network constraints and does not show much difference between the two result sets (Proxy and Non-Proxy). Figure 12 shows a comparison of proxy supported application performance in terms of response time when tested with SQL scripts and Figure 13 and 14 shows the same for XSS requests tested with and without proxy respectively..

Simplicity: The suggested method can be implemented quickly and installation is quite easy and even naive users can implement this method on their respective web pages without much hassle.
,CLAIMS:We claim:
1. Transparent system to mitigate cross site scripting (XSS) attack and Structured Query Language (SQL) injection, said system comprising of
- at least one client side (100) capable of generating HTTP request (A) (400),
- at least one server side (400) capable of generating HTTP response(B) in response to HTTP request (A),
- at least one Interception Proxy Server (IPS) acting as independent intermediate between said client side (100) and server side (400),
- said Interception Proxy Server (IPS) comprising of Request Parser Unit (200) and Response Parser Unit (300)
wherein
said Request Parser Unit (200) is capable of intercepting HTTP request (A) sent by client (100), identifying tainted user data if present in HTTP request (A), and modifying said tainted user data by demarcating it before sending to said server(400) while
said Response Parser Unit (300) is capable of intercepting HTTP Response (B) sent by server (400) decompressing said HTTP Response, identifying tainted data, escaping identified tainted data, if present, into harmless non-executable text, compressing modified data for delivery to client (100).

2. The transparent system as claimed in claim 1 wherein said Interception Proxy Server (IPS) comprising of at least one Request Parser Unit (200) and Response Parser Unit (300).

3. The transparent system as claimed in claim 2 wherein said Request Parser Unit (200) comprises
- at least one mini-dictionary module (201) having list of characters that cause XSS attack,
- at least one SQL data model (202) having minimalistic data model for simple pattern matching capable of causing SQL Injection;
- at least one data tainter (203) for demarcating tainted data, if any,
wherein said parser matches the content of HTTP data with the list of said characters of said mini-dictionary module(201) as well as with the minimalistic model of SQL data model module (202) in a manner that when match is registered successful, then said data tainter (203) demarcates said matched data by using demarcation taint tags creating demarcated tainted data before sending the so modified HTTP Request to the Server (400).

4. The transparent system as claimed in claim 2 wherein said response parser unit (300) comprising of
- at least one Decompressor unit (301) for decompressing the said modified HTTP response,
- at least one taint checker (302) capable of checking said decompressed modified HTTP response for retrieving and separating said demarcated tainted data
- at least one escaper module(303) for converting tainted data into harmless non-executable text,
- at least one compressing unit (304) capable of compressing the modified data for delivery of the modified HTTP Response to the client (100)

5. Transparent system as claimed in claim 3 wherein content of said HTTP Request is matched with minimistical model of SQL data model, said content of said user data contains SQL injection query is altered by said data tainter by adding tainting tags in a manner that said SQL injection does not get executed on the server side.
6. Transparent system as claimed in claim 2 wherein said demarcated data in HTTP response is the data which is matched with the said list of mini-dictionary and subsequently tainted by Data tainter in the request parser unit and capable of causing cross scripting attack on client side.

7. Transparent system as claimed in claim 2 wherein said escaper unit employs selective escaping technique in which escaper only escapes the demarcated content of HTTP response by redefining them in a manner that said contents are not executable at the client side thereby preventing cross-scripting attack.

8. Transparent system as claimed in claim 2 wherein said list of mini-dictionary is special characters such as angle bracket, open bracket semicolon or a colon or any known character without which cross scripting (XSS) is not possible.

9. A transparent method to mitigate cross site scripting (XSS) attack and structured Query language (SQL) injection in web application by using two way interception proxy comprising steps of:
- sending of HTTP request to the server (400) by the client(100) in step (501)
- intercepting of an HTTP request (A) by the interception proxy server(100), at request parser(200) in step (502);
- retrieving HTTP user data (HTTP request variables) from HTTP input request (A)in the step (503);
- sending of the extracted HTTP data to mini-dictionary in step 504(a)
- sending of the extracted HTTP data to minimalistic SQL data model in step 504(b)
- matching the contents of said HTTP data with the list of characters of said mini-dictionary(201) to identify the XSS attack in step 505 (a).
- Matching the contents of the extracted HTTP data with the minimalistic SQL data model to identify SQL injection attack in step 505(b);
- demarcation of matched data which is capable of causing SQL injection attack (Step 505 a) by tainting it with the demarcation taint tags by using data tainter for identified in step (505),, similary demarcation of identified Matched data(505b) by tainting it with demarcation taint tags by using data tainter which is capable of causing XSS attack in step 506 ;
- sending of the modified HTTP request to the server in step (507)
- mitigating SQL injection attack if any , due to demarcating taint tags altering the identified SQL injection query in step (506) which prevents the SQL injection query from executing on the server end;
- generation of HTTP response by server in step (508);
- intercepting HTTP response by response parser at decompressor module in step (509);
- decompression of data by decompressing module and sending it to taint checker module in step (510);
- separating of demarcated data content of step (506) which is sent along with the HTTP response and sending it to the Escaper module in step (511);
- selective escaping of demarcated data in HTTP response by replacing them with the escape character in the HTTP response which are only display characters, and not recognized as code which can be executed (300) in step (512) ;
- compressing of HTTP response data in the compression module thereby generating modified HTTP response free from XSS attack to the client in step (513);

10. The transparent system as claimed in claim 1 wherein said system is modular, said interception proxy server is independent of client and server side thereby ensuring that any change in interception proxy server does not affect the client server processing exchange severely.

11. The transparent system as claimed in claim 1 is performance friendly as said system only processes part of the HTTP request and response.