TWI489309B - System and method for defending against cross-site scripting - Google Patents

Description

Cross-site attack defense system and method

The present invention relates to a cross-site attack prevention system and method, and is particularly related to a cross-site attack prevention system and method that can accurately intercept malicious code.

With the rapid development and popularization of the Internet, web content has become more and more abundant. At the same time, the composition of web pages has evolved from an early static web page to a dynamic web page using a large number of dynamic web technologies. Due to the development of web technology, web applications are more diversified and provide more interactivity. However, it also creates security issues for various web systems, and increases the difficulty of computer protection systems to detect intrusions and security.

Cross-Site Scripting (XSS) is one of the most serious security weaknesses in the world. It is a typical web security vulnerability that can be exploited by attackers to steal user cookies or user data. The attack method of cross-site attack is usually that the attacker embeds malicious script parameters in the code of the webpage provided by the web server, and then uses social engineering techniques to attract webpage viewers to click. When the browser clicks, if the application provided by the web server does not filter the redundant code, the browser will execute the malicious script parameter code and transmit the victim's cookie to the attacker. Pre-established third-party websites, so attackers can steal private information about victims, such as online accounts, passwords, and even credit card numbers. It not only hurts the user's personal information security, but also affects people's livelihood, economy, and even national defense. Great impact.

Based on the trend of interactive web applications today, the web architecture is more complex than before, and the technical difficulty and complexity of detecting cross-site attacks are increasing. Even experienced programmers are not easy to target. All kinds of code are completely filtered. In addition, as far as the user side is concerned, the general public is less aware of cross-site attacks, so it is extremely difficult to expect that the average user actively discovers or defends against cross-site attacks.

At present, the system erection for preventing cross-site attacks includes three configurations: setting on the client side, setting on the server side, and mixing on the client side and the server side. The method of setting it on the user side is too complicated for most network users to install and set the security system. Therefore, the biggest problem with this solution is how to ensure that the user correctly installs and executes the check program. . The method of mixing and setting on the client side and the server side is more complicated. In addition to the difficulty of setting the above-mentioned setting on the user side, the system set on the server side also needs to cooperate with the system of the user end, thereby multiplying the complexity. In addition, the system set on the server side requires the programmer to take the time to set and test the firewall rules. Although it is less complicated than the above two methods, it is still not easy to set such a rule. The program developer must be experienced. And be very careful to set up a system with sufficient defense capabilities.

Although all of the above three architectures have their own shortcomings, they can only be solved by the experienced developers through the server side. However, in cross-site attack defense, how to effectively detect the data input by the user, whether malicious content is the most difficult part. Therefore, there is still a need to develop a defense system or method that can accurately determine malicious code and can be easily set up to solve the problems of the prior art.

One aspect of the present invention is to provide a cross-site attack defense system to solve the problems of the prior art.

According to a specific embodiment, the cross-site attack defense system of the present invention comprises a source code acquisition module, a confirmation module, a transmission module, a reading module, and a parsing module, wherein the source code acquisition module, the confirmation module, and The transmission module is disposed in the network server, and the reading module is disposed between the network server and the client, and the profiling module is connected to the reading module.

In this embodiment, the source code acquisition module can be used to obtain the source code of the web application of the web server. The confirmation module is connected to the source code acquisition module, which can be used to detect the source code of the web application and find the JavaScript and the URL from it. Then, the confirmation module can generate a white list according to the found JavaScript and the URL, and then The transfer module transmits the white list. The reading module can receive the white list transmitted by the transmitting module, and the parsing module receives the white list by the reading module, and performs the HTTP response and the white list generated by the web server corresponding to the HTTP request of the user end. Compare, to intercept the malicious code. Therefore, the malicious code is intercepted in the HTTP response finally transmitted to the client, which can prevent the client from being attacked by a cross-site.

Another aspect of the present invention is to provide a cross-site attack defense method to solve the problems of the prior art.

According to a specific embodiment, the cross-site attack defense method of the present invention comprises the steps of: obtaining a source code of a web application of a web server; obtaining a JavaScript and a URL in the source code, and according to the JavaScript And the URL generates a whitelist; the whitelist is transmitted to the proxy server; and the HTTP response generated by the web server corresponding to the HTTP request of the client is compared with the whitelist in the proxy server, thereby intercepting the HTTP response Malicious code in the middle.

The advantages and spirit of the present invention will be further understood from the following detailed description of the invention.

Referring to FIG. 1, FIG. 1 is a schematic diagram of a cross-site attack defense system 1 according to an embodiment of the present invention. As shown in FIG. 1 , the cross-site attack defense system 1 can be installed between the network server S and the client C, and includes a source code acquisition module 10, a confirmation module 12, a transmission module 14, and a reading module. 16 and the parsing module 18. The source code obtaining module 10, the confirming module 12 and the transmitting module 14 are disposed in the network server S, and the reading module 16 and the parsing module 18 are disposed on the network server S and the client terminal C. between. In this embodiment, the reading module 16 and the parsing module 18 may be disposed in the proxy server P, but the invention is not limited thereto, as long as the two are set on the network server S and the client. Can be between C.

When the client C connects to the web server S for web browsing, the client C will make an HTTP request to the web application of the web server S, and the web application will respond HTTP as required. For example, the client C can request the webpage application to browse the webpage, and the webpage application responds to the specific webpage of the client C according to the required HTTP. The general malicious code for cross-site attacks may be entrained in the HTTP response of the web application, if the client C performs an HTTP response. The malicious code in it will be attacked by cross-sites. Please note that the reading module 16 and the parsing module 18 of the specific embodiment are disposed in the proxy server P, in other words, the request made by the client C to the network server S and the network server S are given. The HTTP response of the client C is transmitted to the other party through the proxy server P.

In this embodiment, the source code acquisition module 10 can be used to obtain the source code of the web application in the network server S. The confirmation module 12 is connected to the source code acquisition module 10 to receive the acquired source code from the source code acquisition module 10. The validation module 12 can analyze the source code to find JavaScript from it. Most of the cross-site attacks are accompanied by external malicious links, so for broader interception, the validation module 12 can also find the URLs in the source code at the same time. The JavaScript and URL found by the confirmation module 12 are valid JavaScript and URLs instead of malicious codes. In detail, it is based on preset rules to find valid JavaScript and URLs. The designer of the application to develop. Since the designer of the web application can clearly know which JavaScript and URL are valid in the web application and its HTTP response, and other JavaScript and URLs may be malicious code implanted by the attacker, therefore, the confirmation mode Group 12 can find valid JavaScript and URLs based on preset rules set by the designer. Next, the confirmation module 12 hashes the obtained valid JavaScript and the URL to form a white list.

The transfer module 14 is coupled to the validation module 12, which receives the whitelist and transmits the whitelist to the read module 16. In practice, the delivery module 14 can wrap the whitelist in the HTTP packet, and the network server S then encapsulates the HTTP packet and entrains the HTTP response that the web application should give to the client C. The HTTP response is sent to the proxy server P, and the read module 16 extracts the whitelist from the HTTP response. In addition to being entrained in the HTTP response, the transport module 14 can also directly transmit the packet to the read module 16 and cause the read module 16 to directly receive the whitelist. In addition, in addition to the above-mentioned white list formed by valid JavaScript and URL, the reading module 16 can further extract the DNS information and the web program file name from the HTTP response of the web application as two other white lists. .

The parsing module 18 is coupled to the read module 16 to receive the extracted whitelist from the read module 16. The parsing module 18 can obtain the JavaScript or the URL from the HTTP response sent by the web server S, and then compare the JavaScript or URL in the HTTP response with the whitelist, if the result of the comparison does not match the whitelist The included JavaScript and URL means that the JavaScript or URL in the HTTP response is not the JavaScript and URL that should be included in the original web application and its HTTP response, and can be judged as suspicious code or even malicious code. In contrast, if the JavaScript or URL in the HTTP response matches the JavaScript and URL contained in the whitelist, it can be judged as the JavaScript and URL that should be included in the original web application and its HTTP response. After these malicious codes are judged, the parsing module 18 can remove the malicious code from the HTTP response, and the whitelisted JavaScript or URL will remain in the HTTP response. Since the code of the malicious attack is mostly encoded to confuse the audiovisual, in practice, the parsing module 18 can first decode the JavaScript or URL obtained in the HTTP response, and then compare it with the whitelist.

After the malicious code in the above HTTP response is deleted, the proxy server P The HTTP response can be sent to the client C for execution, so the client C can avoid cross-site attacks. Please note that since the dynamic comparison of the malicious code is completed in the proxy server P at the front end of the client C, that is, the client C does not need to perform a complicated defense system installation procedure, but is represented by a professional program developer. This is done in the server P, thereby overcoming the installation problem of the defense system set in the prior art in the prior art. In addition, through the preset rules set by the designer of the website application, it is possible to know which JavaScript and URL are valid codes, so as to accurately determine the suspicious or malicious code in the HTTP response.

Please refer to FIG. 1 and FIG. 2 together. FIG. 2 is a flow chart showing the steps of the cross-site attack defense method according to an embodiment of the present invention. Please note that the method of the specific embodiment can be cross-site through FIG. The attack defense system 1 is performed. The units of the website attack defense system 1 are described in the foregoing specific embodiments, and details are not described herein. As shown in FIG. 2, the cross-site attack defense method includes the following steps: in step S20, the source code of the web application of the web server S is obtained; in step S22, the JavaScript and the URL in the source code of the web application are obtained. And generating a whitelist according to the obtained JavaScript and the URL; transmitting the whitelist to the proxy server P in step S24; and, in step S26, the web server corresponding to the HTTP request of the client in the proxy server P The generated HTTP response is compared against the whitelist to intercept the malicious code in the HTTP response of the web server.

Step S20 can retrieve the original code by using the original code acquisition module 10 of the above specific embodiment. Then, in step S22, the verification module S12 can obtain the JavaScript and the URL in the original code. Due to the design of web applications It is clear to the web application and its HTTP response which JavaScript and URL are valid, while other JavaScript and URLs may be malicious code implanted by the attacker. Therefore, step S22 can be used to confirm the module S12. According to the preset rules set by the designer, it is determined whether the JavaScript and the URL are valid, and the obtained valid JavaScript and the URL are hashed to form a white list.

Step S24 can transmit the white list to the proxy server P by the transfer module 14. As described in the foregoing embodiment, the transport module 14 can package the whitelist in the HTTP packet and entrain it in the HTTP response, so that the network server S can transmit the whitelist together with the whitelist, and the read module Group 16 can extract whitelists from HTTP responses. Then, step S26 can compare the HTTP response and the whitelist by the parsing module 18 in the proxy server P to intercept the malicious code in the HTTP response. As described in the previous embodiment, the parsing module 18 can retrieve the JavaScript or URL in the HTTP response and compare it to the whitelist. If the HTTP response URL or URL matches the whitelist, it will remain in the HTTP response. If the comparison result does not match the whitelist, it will be judged as malicious code and deleted from the HTTP response, thereby intercepting the HTTP response. Malicious code.

The website attack defense method of this embodiment can delete the malicious code in the HTTP response transmitted by the network server S, so the HTTP response is transmitted by the proxy server P to the client C for execution, and does not affect the client C. Generate cross-site attacks. In addition, since step S22 is based on the preset rules established by the designer of the web application to find valid JavaScript and URL, it is possible to accurately determine which JavaScript and URL are the embedded code in the HTTP response.

In summary, the cross-web attack system and method of the present invention uses a web server application source code of a web server through a source code acquisition module, a confirmation module, and a transmission module installed on a web server. The JavaScript and the URL are used to form a whitelist, and then the read module and the parsing module set between the web server and the client are used to compare the whitelist with the HTTP response sent by the web server. In this way, the malicious code in the HTTP response is intercepted to avoid the client being attacked by the cross-site. Web-based application designers know exactly which JavaScript and URLs are valid in a web application, so the resulting whitelist can accurately compare HTTP responses, suspicious JavaScript, and URLs. In addition, the above-mentioned action of comparing the malicious code of the HTTP response is performed by the proxy server, so the user terminal does not need complicated installation and setting, which simplifies the process of system setup.

The features and spirit of the present invention will be more apparent from the detailed description of the preferred embodiments. On the contrary, the intention is to cover various modifications and equivalents within the scope of the invention as claimed. Therefore, the scope of the patented scope of the invention should be construed as broadly construed in the

1‧‧‧cross-site attack defense system

10‧‧‧ source code acquisition module

12‧‧‧Confirmation module

14‧‧‧Transmission module

16‧‧‧Reading module

18‧‧‧analysis module

S‧‧‧Web server

P‧‧‧Proxy server

C‧‧‧Client

S20~S26‧‧‧ Process steps

1 is a schematic diagram of a cross-site attack defense system in accordance with an embodiment of the present invention.

2 is a flow chart showing the steps of a cross-site attack defense method according to an embodiment of the present invention.

1‧‧‧cross-site attack defense system

10‧‧‧ source code acquisition module

12‧‧‧Confirmation module

14‧‧‧Transmission module

16‧‧‧Reading module

18‧‧‧analysis module

S‧‧‧Web server

P‧‧‧Proxy server

C‧‧‧Client

Claims (8)

A cross-site attack defense system is established between a network server and a client, and the client sends an HTTP request to the network server, and the network server corresponds to the HTTP server. Requesting an HTTP response, the cross-site attack defense system includes: a source code acquisition module, which is disposed in the network server, and the source code acquisition module is used to obtain one of the network servers. a source code of the web application; a confirmation module is disposed in the web server and connected to the source code acquisition module, wherein the confirmation module is configured to obtain the web application according to a preset rule At least one JavaScript and at least one URL in the source code, and generating a white list according to the at least one JavaScript and the at least one URL, wherein the preset rule is determined by a designer of the web application; a transmitting module The system is disposed on the network server and connected to the confirmation module, the transmission module is configured to transmit the white list; a reading module is disposed on the network server and the user terminal between, The reading module is configured to receive the white list transmitted by the transmitting module; and a profiling module is connected to the reading module, wherein the parsing module is configured to compare the whitelist and the web The HTTP response generated by the server to intercept one of the HTTP responses. The cross-site attack defense system of claim 1, wherein the confirmation module performs a hash operation on the obtained at least one JavaScript and the at least one URL to generate the whitelist. The cross-site attack defense system of claim 1, further comprising a network server and a proxy server of the client, the read module and the parsing module being disposed on the proxy In the server, the proxy server is configured to transmit the HTTP request of the client to the network server, and send the HTTP response of the network server back to the client. The cross-site attack defense system of claim 1, wherein the parsing module extracts at least one first JavaScript or at least one first URL from the HTTP response and performs a hash operation with the white list. If the comparison result is inconsistent with the whitelist, the at least one first JavaScript or the at least one first URL is determined as the malicious code, and the malicious code is deleted from the HTTP response. A cross-site attack defense method includes the following steps: obtaining a source code of a web application of a web server; obtaining at least one JavaScript and at least one URL in a source code of the web application according to a preset rule And generating a white list according to the at least one JavaScript and the at least one URL, wherein the preset rule is determined by a designer of the web application; transmitting the white list to a proxy server; and the proxy The server compares the whitelist and one of the HTTP responses generated by the network server corresponding to one of the HTTP requests of the client to intercept one of the HTTP responses. The cross-site attack defense method of claim 5, further comprising the step of hashing the obtained at least one JavaScript and the at least one URL to generate the whitelist. The cross-site attack defense method according to claim 5, wherein the proxy server is configured to transmit the HTTP request of the client to the network server, and the HTTP server of the network server The response is passed back to the client. The cross-site attack defense method according to claim 5, further comprising the steps of: extracting at least one first JavaScript or at least a first URL from the HTTP response, and performing a hash operation on the whitelist And if the result of the comparison is that the whitelist is not met, the at least one first JavaScript or the at least one first URL is determined as the malicious code and deleted from the HTTP response.