Patent Publication Number: US-8997222-B2

Title: Method and device for preventing CSRF attack

Description:
PRIORITY CLAIM 
     The present application is a continuation of and claims priority from U.S. patent application Ser. No. 13/306,394, filed on Nov. 29, 2011, titled “Method and Device for Preventing CSRF Attack,” and claims benefit of priority under 35 USC §120 and §365 to the previously filed China Patent Application No. 201010580357.3 entitled, “Method and Device for Preventing CSFR Attack” with a priority date of Nov. 30, 2010. The content of both applications are incorporated by reference herein. 
    
    
     TECHNICAL FIELD 
     The invention relates to network security, and more particularly, the invention relates to a method for preventing network attack. 
     DESCRIPTION OF THE RELATED ART 
     As application of Internet becomes wider and wider, Internet security becomes a problem of increasing concern to people. In various existing attack methods that might threaten network security, Cross-Site Request Forgery (CSRF) attack is an attack method which forces an end user to execute unwanted actions on a web application which he is currently logged into. An attacker can force the user of a web application to execute actions selected by the attacker just with the help of little social engineering tricks, such as, via a link sent by email or chat software. For example, a user logs into a network bank to check his balance of deposit, and he goes to his favorite forum without exiting the network bank system. If the attacker has well-constructed a malicious link in the forum and induces the user to click on the link, then the user&#39;s funds in the network bank account may be transferred to an account specified by the attacker. When CSRF makes an attack directed to an ordinary user, data and operation instructions of the end user will be seriously threatened. When the attacked end user has administrator account, a CSRF attack will imperil the whole web application. Thus the hazard of CSRF attack is very great. 
     As for CSRF attack, the most secure prevention method is to rebuild all the existing servers so that they are capable of preventing CSRF attack. However, this is obviously impractical. As for existing server, some other solutions in the art also can not effectively prevent CSRF attack. Thus, there is a need for a method and device that are capable of effectively preventing CSRF attacks. 
     BRIEF SUMMARY 
     In illustrative embodiments of the disclosure, it is recognized that the existing technology can not effectively prevent Cross-Site Request Forgery (CSRF) attack, thus a method and device that can effectively prevent CSRF attack without modifying existing servers are proposed. 
     According to an embodiment of the disclosure, there is provided a method for preventing CSRF attacks, the method comprising: intercepting a request sent from a client browser to a server; generating a token; generating a response to the request; inserting the token into the response to the request; and sending to the client browser the response to the request with the token inserted in the response. 
     According to an embodiment of the disclosure, there is provided a method for preventing CSRF attacks, comprising: intercepting a request sent from a client browser to a server; reading a token in the request sent from the client browser to the server; verifying whether the token in the request sent from the client browser to the server is valid. 
     An embodiment of the disclosure also provides a computer program product corresponding to the above method. 
     With the above one or more embodiments provided in the embodiments of the disclosure, CSRF attack can be effectively prevented without modifying existing servers. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The invention may be better understood by combining the description referring to drawings below, in which same or similar reference number represents same or similar component throughout drawings. The drawings are contained in the description and constitute a part of thereof along with the detailed description below, and the drawings are used to illustrate preferred embodiments and explain the principle and advantage of the disclosure, in which: 
         FIG. 1  shows a principle diagram of a Cross-Site Request Forgery (CSRF) attack; 
         FIG. 2  shows a method  200  for preventing a CSRF attack according to an embodiment of the disclosure; 
         FIG. 3   a  shows a method  300  for preventing a CSRF attack according to an embodiment of the disclosure; 
         FIG. 3   b  shows some optional steps that may be included in the method  300  for preventing a CSRF attack according to an embodiment of the disclosure; 
         FIG. 4  shows a signal flow according to an embodiment of the disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     Illustrative embodiments of the invention are described below in conjunction with accompany drawings. For the purpose of clarity and conciseness, not all features of an actual implementation are described in this specification. However, it will be appreciated that in the development of any such actual embodiment, numerous implementation-specific decisions should be made to achieve the developers&#39; specific goals, such as being in compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it will be appreciated that although such a development effort might be complex and time-consuming, it is a routine undertaking for those of ordinary skill in the art having the benefit of this disclosure. 
     Here, it shall be noted that, in order to avoid obscuring the invention by unnecessary details, only functional structures and/or process steps that are closely associated with the solution of the invention are illustrated in the drawings, and other details that have little relationship therewith are omitted. 
     To better explain the principle of the technical solution in the disclosure, the principle of a Cross-Site Request Forgery (CSRF) attack will be first described with reference to  FIG. 1 . 
       FIG. 1  illustratively shows the principle of a CSRF attack. In system  100  shown in  FIG. 1 , user  102  accesses a web application  110  located at server side  108  through his client browser  104 . Normally, server  108  first needs to verify identity of the user  102 . There are various ways to verify the identity of the user  102 . Generally, these verification methods are performed by prompting user  102  to input authentication information for accessing the web application  110 . After the user  102  receives the input prompt, the user inputs authentication information for accessing the web application  110  and sends a login request containing the authentication information to server  108 . Server  108  verifies whether user  102  is a legal user of web application  110  by verifying authentication information of user  102  contained in the received login request. Assume that user  102  has inputted correct authentication information, then server  108  will consider user  102  as a legal user of the web application  110 . Since server  108  identifies user  102  by a cookie, client browser  104  will get a cookie for the identifying identity of user  102  after user  102  passes through identity verification. The cookie contains authentication information of user  102  and is used to identify a session between client browser  104  of user  102  and web application  110  of server  108 . Here, the procedure of CSRF attack will be described by assuming web application  110  is a network bank and that user  102  wants to perform a transfer operation through the network bank, for example. Assume that user  102  has an account UA in the bank, and he wants to transfer 1000 CNY to another account UA2 through the network bank. Normally, request sent by user  102  through his client browser  104  should be as follows:
         http://bank.example/withdraw?account=UA&amp;amount=1000&amp;for=UA2       

     Assume that attacker  106  has an account ATT in that bank. Meanwhile the attacker knows that this Universal Resource Locator (URL) in the context may perform a transfer operation. At this moment, attacker  106  embeds the following codes in a certain page in which he has authority:
         src=“http://bank.example/withdraw?account=UA&amp;amount=1000&amp;for=ATT”       

     Attacker  106  induces user  102  to access the page having the above embedded codes via advertisement and the like. If user  102  has accessed the page having the above embedded codes, the above embedded codes will be executed. That is, client browser  104  of user  102  will send URL in the above embedded codes:
         http://bank.example/withdraw?account=UA&amp;amount=1000&amp;for=ATT
 
together with cookie in client browser  104  of user  102  for identifying session between client browser  104  of user  102  and network bank to the network bank. It can be seen that, the URL corresponds to a transfer request of transferring 1000 CNY in account UA of user  102  to account ATT of attacker  106 . Normally, the request will fail, because the network bank requires authentication information of user  102 . However, if the cookie in client browser  104  of user  102  for identifying a session between client browser  104  of user  102  and network bank has not yet expired, since the cookie contains therein authentication information of user  102 , the network bank will receive the transfer request that contains authentication information of user  102  for transferring 1000 CNY in account UA of user  102  to account ATT of attacker  106 . Since the request contains therein authentication information of user  102 , the network bank will process the above request as legal request, i.e. transfer 1000 CNY in account UA of user  102  to account ATT of attacker  106 .
       

     The principle of CSRF attack is briefly described in the above. The method and device for preventing CSRF attack according to embodiments of the disclosure will be continually described with reference to the above examples. The description below are all illustrative, and based on the content described in the disclosure, those skilled in the art can obtain other possible embodiments falling into the scope covered by the concept of the disclosure by manner of adding, reducing, combining, modifying and the like, all of which will fall into the protection scope of the disclosure. 
     The disclosure introduces a device for intercepting request sent from a client browser to a server, and the device adds a token into request sent by the client browser. Thereafter, the device will verify each request sent by the client browser to determine whether each request is safe. 
     Referring to  FIG. 2 , in which is shown a device  200  for preventing CSRF attack according to an embodiment of the disclosure. Device  200  comprises:
         a request intercepting module  202  for intercepting request sent from a client browser to a server;   a token generating module  204  for generating a token;   a response generating module  206  for generating a response to the request;   a token inserting module  208  for inserting the token into the response to the request; and   a response sending module  210  for sending the response to the request inserted with the token to the client browser.
 
The response to the request may be a HTTP 307 response.
       

     Further, the device  200  for preventing CSRF attack according to an embodiment of the disclosure may further comprise: a token reading module  212  for reading token in the subsequent request sent from the client browser to the server; a token verifying module  214  for verifying whether the token in the subsequent request sent from the client browser to the server is valid. If there is no token in the URL requested in the subsequent request sent from the client browser to the server, but there is a token in the Referer header and the token verifying module  214  verifies that the token is valid, then: the response generating module  206  generates a response to the subsequent request; the token inserting module  208  inserts the token into the response to the subsequent request; and the response sending module  210  sends the response to the subsequent request to the client browser with the token inserted in the response. 
     Further, the device  200  for preventing CSRF attack according to an embodiment of the disclosure may further comprise: a request forwarding module  216  for forwarding to the server the subsequent request sent from the client browser to the server. If there is a token in URL requested in the subsequent request sent from the client browser to the server and the token verifying module  214  verifies that the token is valid; then the request forwarding module  216  forwards the subsequent request to the server. 
     Further, the device  200  for preventing CSRF attack according to an embodiment of the disclosure may further comprise: a request judging module  218  for judging whether the subsequent request sent from the client browser to the server is an Ajax request. If the request judging module  218  determines that the subsequent request sent from the client browser to the server is an Ajax request, and there is no token in the requested URL but there is a token in the Referer header and the token verifying module  214  verifies that the token is valid, then the request forwarding module  216  forwards the subsequent request to the server. If the request judging module  218  determines that the subsequent request sent from the client browser to the server is not an Ajax request, and there is no token in the requested URL but there is a token in the Referer header and the token verifying module  214  verifies that the token is valid, then: the response generating module  206  generates a response to the subsequent request; the token inserting module  208  inserts the token into the response to the subsequent request; and the response sending module  210  sends the response to the subsequent request inserted with the token to the client browser. 
     It is to be emphasized by the applicant that, although the device  200  for preventing CSRF attack shown in  FIG. 2  comprises a plurality of modules, not every module is necessary, some of which may be added or removed according to design requirement. For example, the device  200  for preventing CSRF attack may only comprise those modules shown by solid lines. 
     Referring to  FIG. 3   a , in which a method  300  for preventing CSRF attack according to an embodiment of the disclosure is shown. 
     The method  300  of  FIG. 3   a  starts from step  302 . Next, the method  300  proceeds to step  304 , in which a request sent from a client browser to a server is intercepted. The request may be intercepted by a request intercepting module  202  in device  200  as shown in  FIG. 2 , and the request intercepting module  202  may be implemented by using Java Servlet, for example. Any existing approach for intercepting a request may be used to achieve the above object, and here these approaches are omitted for brevity. 
     Next, the method  300  proceeds to step  306 , in which a token is generated. The token will be inserted into a response to be returned to the client browser. Generation of the token may utilize the algorithm and methods in the art, such as a universal unique identifier (UUID) or random algorithm. 
     Next, the method  300  proceeds to step  308 , in which a response to the intercepted request sent from the client browser to the server is generated. According to an embodiment of the disclosure, the response is a HTTP 307 response. The HTTP 307 response is a response for redirecting and follows HTTP 1.1 protocol, and the HTTP 307 response can redirect a HTTP request (including HTTP GET and HTTP POST) sent from a client browser to a preset location. 
     Next, the method  300  proceeds to step  310 , in which the generated token is inserted into the generated response to the intercepted request sent from the client browser to the server. At this moment, the token generated in step  306  is included in the response returned to the client browser. 
     Next, the method  300  proceeds to step  312  where the method ends. Or, optionally, the method  300  may also proceed to  FIG. 3   b.    
     Referring to  FIG. 3   b , in which some optional steps that may be included in the method  300  for preventing CSRF attack according to an embodiment of the disclosure are shown. 
     Continuing from  FIG. 3   a , the method  300  for preventing CSRF attack according to an embodiment of the disclosure may further include a step  314 , in which subsequent request sent from the client browser to the server is intercepted. Here, the subsequent request corresponds to a request sent after the method shown in  FIG. 3   a  is executed and the client browser has received the response returned by device  200 . Since a token is inserted into the response returned to the client browser by device  200 , the token will also be included in the subsequent request subsequently sent from the client browser to the server. 
     Next, the method  300  proceeds to step  316 , in which the token in the subsequent request sent from the client browser to the server is read. 
     Next, the method  300  proceeds to step  318 , in which it is verified whether the token in the subsequent request sent from the client browser to the server is valid. Thereafter, the method  300  proceeds to step  320 , in which it is determined whether the token in the subsequent request sent from the client browser to the server is valid. The determination is made by comparing the read token in the subsequent request sent from the client browser to the server with the token recorded in the device  200  and inserted into the response returned to the client browser by the device  200 . If the two tokens are different, the method proceeds to step  322 , at which the request is considered invalid. Thereafter, the method  300  returns to step  314 . Subsequent request sent from the client browser to the server is continually intercepted. If the two tokens are the same, the method  300  proceeds to step  324 , at which it is further verified whether there is a token in the URL requested in the subsequent request sent from the client browser to the server. If there is a token in the URL requested in the subsequent request sent from the client browser to the server and the token is valid, the method  300  proceeds to step  326 , at which the subsequent request is forwarded to the server. Since the attacker can not know the value of the token, the request is safe in the case where there is a valid token in the requested URL, and thus the request may be forwarded to the server for processing. 
     If there is no token in the URL requested in the subsequent request sent from the client browser to the server, then it is further verified whether there is a token in Referer header in subsequent request sent from the client browser to the server and whether the token is valid. The Referer header is a field in the hypertext transfer protocol (HTTP) head defined in HTTP protocol. The Referer header allows a client to specify the address of a source resource of requested URL, which will allow a server to generate a back-off linked list. For example, if a user accesses to IBM technical support page (www.ibm.com/support) by clicking a link in IBM home page (www.ibm.com), then address of IBM home page will be included in the Referer header in a request sent by a client browser for accessing the IBM technical support page. For example, the request might be as follows: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 GET http://www.ibm.com/support 
               
               
                   
                       ... 
               
               
                   
                  Referer: http://www.ibm.com 
               
               
                   
                       ... 
               
               
                   
                   
               
            
           
         
       
     
     If there is no token in URL requested in the subsequent request sent from the client browser to the server, but there is a token in Referer header and the token is valid, the method  300  proceeds to step  328 , in which a response to the subsequent request is generated. Thereafter, in step  330 , the token is inserted into the response to the subsequent request. And in step  332 , the response to the subsequent request inserted with the token is sent to the client browser. 
     Optionally, if there is no token in the URL requested in the subsequent request sent from the client browser to the server, but there is a token in the Referer header and the token is valid, the method  300  may further proceed to step  334 , in which it is judged whether the subsequent request sent from the client browser to the server is an Ajax request. If the subsequent request is an Ajax request, the method  300  proceeds to step  326 , in which the subsequent request is forwarded to the server. If it is not an Ajax request, the method  300  proceeds to step  328 , in which a response to the subsequent request is generated. Thereafter, in step  330 , the token is inserted into the response to the subsequent request, and in step  332 , the response to the subsequent request inserted with the token is sent to the client browser. Due to the nature of an Ajax request, in the case where the validity of the token has been verified, the request can be considered to be safe, and thus the request can be forwarded to the server for processing. 
     Referring to  FIG. 4 , in which a signal flow according to an embodiment of the disclosure is shown. It is to be emphasized by the applicant that  FIG. 4  is merely for purpose of illustration and can not be construed as a limit to the protection scope of the disclosure. In  FIG. 4 , assume that a user requests access to the protected resource URL  1  through his client browser, as shown by  402 . The request is sent to an authentication module of server, and the authentication module prompts the user to input authentication information, as shown by  404 . Then, the user provides authentication information, as shown by  406 . Then, the authentication module of the server verifies authentication information provided by user. If the authentication information is correct, the authentication module of server forwards the request to URL  1 , as shown by  408 . In prior art, after the authentication module of server verifies that authentication information of user is correct, the request will be directly forwarded to a Web application in the server. According to one or more embodiments of the disclosure, the device  200  intercepts the request (here, the request is a request of accessing to &lt;URL  1 &gt; forwarded by the authentication module of server). Thereafter, a token generating module in device  200  generates a token XXX (such as Token=XXX shown by  410 ), and the token XXX is inserted into a response returned to the client browser, as shown by  410 . According to an embodiment of the disclosure, device  200  returns a HTTP 307 response to the client browser, and redirects the request to &lt;URL  1 &gt;. The response is typically shown as follows: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                  HTTP 307 Temporary Redirect 
               
               
                   
                 Location: &lt;URL 1&gt;?Token=XXX 
               
               
                   
                   
               
            
           
         
       
     
     It can be seen that the token XXX is inserted into the response, and the token is inserted into URL  1  that will be again requested by user, i.e., &lt;URL  1 &gt;?Token=XXX, as shown by  412 . 
     After the client browser receives the response inserted with token XXX, the client browser requests to access to address &lt;URL  1 &gt; specified in the response. At this moment, the request is typically shown as follows.
         GET &lt;URL  1 &gt;?Token=XXX       

     It can be seen that, token XXX is also inserted into URL of the request, i.e., &lt;URL  1 &gt;?Token=XXX, as shown by  414 . At this moment, device  200  intercepts the request again, and verifies whether there is a token in the URL requested in the request and whether the token is valid. If there is a token in the requested URL and the token is valid, i.e., the requested URL is &lt;URL  1 &gt;?Token=XXX and Token=XXX, device  200  forwards the request to the Web application of server, as shown by  416 . The web application responds to the request after the web application receives the request, and returns requested resource &lt;URL  1 &gt; to the client browser, as shown by  418 . At this moment, token XXX is also inserted into address of page corresponding to the returned resource &lt;URL  1 &gt;, i.e., address corresponding to the returned page is &lt;URL  1 &gt;?Token=XXX. 
     Assume that user requests to access to resource &lt;URL  2 &gt; by clicking a link in a page corresponding to resource &lt;URL  1 &gt;. According to HTTP protocol, at this moment, the request will have a Referer header to indicate the origin of accessing to resource &lt;URL  2 &gt;. At this moment, since token XXX has been inserted into address of page corresponding to resource &lt;URL  1 &gt;, i.e., &lt;URL  1 &gt;?Token=XXX, the typical request will be as follows: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                   GET &lt;URL 2&gt; 
               
               
                   
                     ... 
               
               
                   
                 Referer: &lt;URL1&gt;?Token=XXX 
               
               
                   
                     ... 
               
               
                   
                   
               
            
           
         
       
     
     That is, token XXX is also inserted into the request, and the token is located at the Referer header, as shown by  420 . 
     According to one or more embodiments of the disclosure, device  200  intercepts the request again (here, it is a request sent by client browser for accessing &lt;URL  2 &gt; through &lt;URL  1 &gt;), and verifies whether there is a token in the URL requested in the request and whether the token is valid, as shown by  422 . If there is no token in the requested URL (here, URL  2 ), but there is a token in Referer header and the token is valid, i.e., Referer: &lt;URL  1 &gt;?Token=XXX, and Token=XXX, device  200  again inserts token XXX into a response returned to the client browser, as shown by  424 . According to an embodiment of the disclosure, device  200  returns a HTTP 307 response to the client browser, and redirects the request to &lt;URL  2 &gt;, and inserts token XXX again. The response is typically as follows: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                  HTTP 307 Temporary Redirect 
               
               
                   
                 Location: &lt;URL 2&gt;?Token=XXX 
               
               
                   
                   
               
            
           
         
       
     
     It can be seen that, token XXX is also inserted into the response, and the token is inserted into URL 2  that will be again requested by user, i.e., &lt;URL  2 &gt;?Token=XXX, as shown by  424 . 
     After client browser receives the above response inserted with the token, client browser requests to access to address &lt;URL  2 &gt; specified in the response. At this moment, the request is typically as follows:
         GET &lt;URL  2 &gt;?Token=XXX       

     It can be seen that, token XXX is also inserted into the URL requested in the request, as shown by  426 . At this moment, device  200  intercepts the request again, and verifies whether there is a token in URL requested in the request and whether the token is valid. If there is a token in the requested URL and the token is valid, i.e., the requested URL is &lt;URL  2 &gt;?Token=XXX and Token=XXX, device  200  forwards the request to the web application of server, as shown by  428 . The web application responds to the request after the web application receives the request, and returns the requested resource &lt;URL  2 &gt; to the client browser, as shown by  430 . At this moment, token XXX is also inserted into address of a page corresponding to the returned resource &lt;URL  2 &gt;, i.e., &lt;URL  2 &gt;?Token=XXX. 
     Below, some other embodiments according to the disclosure will be briefly described. According to an embodiment of the disclosure, a device for preventing CSRF attack comprises: a request intercepting module for intercepting request sent from a client browser to a server; a token reading module for reading token in subsequent request sent from the client browser to the server; a token verifying module for verifying whether the token in the subsequent request sent from the client browser to the server is valid. 
     Optionally, the device for preventing CSRF attack further comprises: a request forwarding module for forwarding to the server the request sent from the client browser to the server. If there is a token in the URL requested in the request sent from the client browser to the server and the token verifying module verifies that the token is valid, then the request forwarding module forwards the subsequent request to the server. 
     Optionally, the device for preventing CSRF attack further comprises: a response generating module for generating a response to the request; a token inserting module for inserting the token into the response to the request; and a response sending module for sending the response to the request inserted with the token to the client browser. If there is no token in URL requested in the request sent from the client browser to the server, but there is a token in a Referer header and the token verifying module verifies that the token is valid, then: the response generating module generates a response to the request; the token inserting module inserts the token into the response to the request; and the response sending module sends the response to the request to the client browser with the token inserted into the response. 
     Optionally, the device for preventing CSRF attack further comprises: a request judging module for judging whether the request sent from the client browser to the server is an Ajax request. If the request judging module determines that the request sent from the client browser to the server is an Ajax request, and there is no token in the requested URL but there is a token in Referer header and the token verifying module verifies that the token is valid, then the request forwarding module forwards the request to the server. If the request judging module determines that the request sent from the client browser to the server is not an Ajax request, and there is no token in the requested URL but there is a token in Referer header and the token verifying module verifies that the token is valid, then: the response generating module generates a response to the request; the token inserting module inserts the token into the response to the request; and the response sending module sends the response to the request to the client browser with the token inserted into the response. 
     According to an embodiment of the disclosure, a method for preventing CSRF attack comprises: intercepting request sent from a client browser to a server; reading a token in the request sent from the client browser to the server; verifying whether the token in the request sent from the client browser to the server is valid. 
     Optionally, the method for preventing CSRF attacks further comprises: if there is a token in the URL requested in a subsequent request sent from the client browser to the server and the token is valid, then forwarding the subsequent request to the server. 
     Optionally, the method for preventing CSRF attack further comprises: if there is no token in URL requested in the request sent from the client browser to the server, but there is a token in the Referer header and the token is valid, then: generating a response to the request; inserting the token into the response to the request; and sending the response to the request to the client browser with the token inserted into the response. 
     Optionally, the method for preventing CSRF attacks further comprises: judging whether the request sent from the client browser to the server is an Ajax request. If the request sent from the client browser to the server is an Ajax request, and there is no token in the requested URL but there is a token in the Referer header and the token is valid, then forwarding the request to the server. If the request sent from the client browser to the server is not an Ajax request, and there is no token in the requested URL but there is a token in the Referer header and the token is valid, then: generating a response to the request; inserting the token into the response to the request; and sending the response to the request to the client browser with the token inserted into the response. 
     It can be seen from the above illustrative description that, with the method and device of the disclosure, a token is inserted into a user&#39;s request for accessing a resource through a client browser. Thus device  200  can assure that the request is issued by the user himself by verifying whether the token in the request is valid, thereby preventing a CSRF attack. 
     The basic principles of the disclosure are described above in conjunction with specific embodiments, however, it is to be noted that, for those of ordinary skill in the art, it will be understood that all or any step or component of the method and apparatus of the invention may be implemented in any computing apparatus (including processor, storage medium etc) or network of computer apparatus in form of hardware, firmware, software or a combination thereof, which is achievable for those of ordinary skill in the art by using their basic programming skills after reading the description of the embodiments. 
     Thus, the object of the embodiments may also be implemented by a program or a group of programs executed on any computing apparatus. The computing apparatus may be known general purpose apparatus. Thus, the object of the invention may also be implemented by merely providing program product containing program codes for implementing the method or apparatus. That is, such program product may also constitute the invention, and the storage medium on which such program product is stored also constitutes the invention. Obviously, the storage medium may be any known storage medium or any storage medium that will be developed in future. 
     It should also be noted that, in the apparatus and method of the invention, obviously, each component or each step may be separated and/or recombined. Such separation and/or recombination should be considered as an equivalent solution of the invention. Further, the steps for performing the above series of processes may be naturally executed in a time sequence according to a sequence of description, but does not necessarily need to execute in time sequence. Some steps may be executed in parallel or independently to each other. 
     Although the invention and its advantages have been described in detail, it should be appreciated that various modifications, replacements and alternations may be made without departing from the spirit and scope of the invention defined by the appended claims. Further, the term “comprising”, “including” or any other variations is intended to cover non-exclusive inclusion, thereby making a procedure, method, item or apparatus that contains a series of elements not only includes those elements, but also contains other elements that aren&#39;t listed explicitly, or contains elements inherent in such procedure, method, item or apparatus. Unless otherwise defined, an element defined by phase “including a . . . ” does not exclude other same element that also exist in the procedure, method, item or apparatus that contains that element.