CN107294994B - CSRF protection method and system based on cloud platform - Google Patents
CSRF protection method and system based on cloud platform Download PDFInfo
- Publication number
- CN107294994B CN107294994B CN201710544734.XA CN201710544734A CN107294994B CN 107294994 B CN107294994 B CN 107294994B CN 201710544734 A CN201710544734 A CN 201710544734A CN 107294994 B CN107294994 B CN 107294994B
- Authority
- CN
- China
- Prior art keywords
- request packet
- request
- module
- packet
- logged
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses a CSRF protection method and a system based on a cloud platform, wherein the method comprises the following steps: receiving a request packet to be analyzed; checking the login state of the request packet, and directly passing through the request packet which is not logged in or is logged in but does not contain the request parameters; checking the request packet which is logged in and contains the request parameters; and judging whether the request packet is directly released or released after the cache is cleared according to the inspection result. According to the CSRF protection method and system based on the cloud platform, disclosed by the invention, by judging the login authority of requesting to access the system, the false blocking behavior of the open operation interface can be reduced, the detection efficiency is improved, and the influence on the performance of the cloud platform is reduced; CSRF protection can be carried out on the whole website by identifying a request mode, configuring sensitive operation parameters and carrying out related processing on the requested refer, configuration is simple and convenient, and professional requirements on operators are low.
Description
Technical Field
The invention relates to the field of computer network data security, in particular to a CSRF protection method and system based on a cloud platform.
Background
With the rapid development of World Wide Web (Web) application technology, an attack method, namely Cross-site Request Forgery (CSRF), appears on the internet to hijack other terminal users to execute malicious operations on their application systems in a login state. The attack method can execute the function operation on the WEB application under the condition that a victim is unknown, and specifically can be shown in the following steps that when the victim successfully logs in a certain WEB application system, the victim requests to access a link page constructed by an attacker during use, the attacker completes CSRF attack by using a code constructed in advance while loading the page, and successfully executes the function operation of the WEB application system by using the user right of the victim, so that the privacy information and the right of a user are threatened.
The CSRF defense can be mainly performed from three layers of service end, user end and safety equipment. The defense of the server can be divided into (1) refer verification: a referrer field is arranged in a hypertext Transfer Protocol (HTTP) header, and records a source address of an HTTP request, a request for accessing a security-restricted page must be from the same website, and when a user submits a request, a referrer value of the request needs to be a Uniform Resource Locator (URL) of a page where a submit button (trigger request) is located. (2) token verification: putting information which cannot be forged by an attacker into the request and is not in the cookie, the developer can add a randomly generated token in the http request in the form of a parameter and establish an interceptor at the server to verify the token. If there is no token in the request or the content in the token is incorrect, it indicates that it is likely an attack launched by the attacker. (3) Verification code: each time the user submits, a random string on a picture is filled in on the form as the authentication code. (4) Other verification methods: all class requests are added with the Http header attribute of csrfton at a time through the class of extensible hypertext transfer requests (Xml Http requests, XHR) and the token value is put into it.
However, these protection methods still have some drawbacks: (1) the token tracking method needs to perform a series of complex operations such as Document Object Model (DOM) analysis on a Web page, positioning of a form position, modification of a form request content and the like, and has low protection efficiency; (2) other protection methods configure the protection address according to the service function, the change of the service function can affect the use of the protection function, the configuration content needs to grab the service addresses one by one, and the configuration process is complicated.
Disclosure of Invention
In order to solve the problems in the prior art, embodiments of the present invention provide a method and a system for CSRF (Cross-site request forgery) protection based on a cloud platform. The technical scheme is as follows:
in one aspect, a CSRF protection method based on a cloud platform includes the following steps:
receiving a request packet to be analyzed;
checking the login state of the request packet, and directly releasing the request packet which is not logged in or is logged in but does not contain the request parameters;
checking the request packet which is logged in and contains the request parameters;
and judging whether the request packet is directly released or released after the cache is cleared according to the checking result.
Further, the step of verifying that the log-in and including the request parameter includes:
judging whether the referrer field of the request packet is empty or not;
if the referrer of the request packet is empty, further judging the request mode of the request packet;
if the request is a POST request, clearing the cache of the request packet and then releasing the request packet;
and if the GET request is the GET request, identifying the sensitive operation.
Further, if the referrer field of the request packet is not empty, whether the referrer field is a trusted domain is judged;
if the referrer field is a trusted domain, directly passing the request packet;
if the referrer field is an untrusted field, further judging the request mode of the request packet;
if the request is a POST request, clearing the cache of the request packet and then releasing the request packet;
and if the GET request is the GET request, identifying the sensitive operation.
Further, the specific steps of the sensitive operation identification include:
and judging whether the request packet is sensitive operation, directly releasing the request packet which is not sensitive operation, and releasing the request packet which is sensitive operation after clearing the cache.
Specifically, the sensitive operation comprises adding, deleting, modifying and inquiring.
Further, the protection method further comprises the following steps:
before checking the login state of the request packet, firstly judging whether the request packet is an authentication request packet;
if the authentication request packet is not the authentication request packet, the login status of the request packet is further checked.
In another aspect, a cloud platform-based CSRF protection system includes:
the login state module is used for receiving a request packet to be analyzed, checking the login state of the request packet, directly releasing the request packet which is not logged in or is logged in but does not contain the request parameters, and sending the request packet which is logged in and contains the request parameters to the checking module;
the verification module is used for verifying the logged request packet containing the request parameters;
and the protection processing module is used for clearing the cache of the request packet and then releasing the request packet according to the inspection result.
Specifically, the inspection module specifically includes:
the referrer field judging module is used for judging whether the referrer field of the request packet is empty or not, sending the request packet with the referrer field empty to the request mode judging module, and sending the request packet with the referrer field not empty to the trusted domain judging module;
the request mode judging module is used for judging whether the request packet with the reference field not being empty is in the reference domain or not, sending the request packet with the reference field not being in the reference domain to the request mode judging module and directly releasing the request packet with the reference field being in the reference domain;
the request mode judging module is used for judging whether the request mode of the request packet is a POST request or a GET request, then sending the POST request to the protection processing module and sending the GET request to the sensitive operation judging module;
and the sensitive operation judging module is used for judging whether the request packet is sensitive operation, directly releasing the request packet which is not sensitive operation, and sending the request packet which is sensitive operation to the protection processing module.
Further, sensitive operations include adding, deleting, modifying, querying.
Specifically, the login status module specifically includes:
a receiving module, configured to receive a request packet to be analyzed;
the login state checking module is used for checking the login state of the received request packet to be analyzed, directly releasing the request packet which is not logged in and sending the logged request packet to the parameter condition checking module;
and the request parameter checking module is used for checking whether the logged request packet contains the request parameter, directly releasing the logged request packet which does not contain the request parameter, and sending the logged request packet which contains the request parameter to the checking module.
Further, the login status module further includes:
and the authentication uniform resource locator module is used for judging whether the received request packet to be analyzed is an authentication request packet or not and sending the non-authentication request packet to the login state checking module.
The technical scheme provided by the embodiment of the invention has the following beneficial effects: according to the CSRF protection method and system based on the cloud platform, disclosed by the invention, by judging the login authority of requesting to access the system, the false blocking behavior of the open operation interface can be reduced, the detection efficiency is improved, and the influence on the performance of the cloud platform is reduced; CSRF protection can be carried out on the whole website by identifying a request mode, configuring sensitive operation parameters and carrying out related processing on the requested refer, configuration is simple and convenient, and professional requirements on operators are low.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
Fig. 1 is a flowchart of an embodiment of a CSRF protection method based on a cloud platform provided in the present invention;
FIG. 2 is a detailed flowchart of step S103 in FIG. 1;
FIG. 3 is a flowchart of FIG. 1 with the addition of step S301;
fig. 4 is a block diagram of an embodiment of the cloud platform-based CSRF protection system 100 provided by the present invention;
FIG. 5 is a detailed block diagram of the verification module 102 of FIG. 4;
FIG. 6 is a detailed block diagram of the login status module 101 in FIG. 4;
fig. 7 is a block diagram of the add authentication uniform resource locator module 1014 of fig. 6.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail with reference to the accompanying drawings.
Fig. 1 shows an embodiment of a CSRF (Cross-site request for forgery) protection method based on a cloud platform according to the present invention, which includes the following steps:
step S101, a request packet to be analyzed is received.
In this embodiment, when a client such as a browser sends an access request to a World Wide Web (Web) server through a hypertext transfer protocol (HTTP), a cloud platform first receives a request packet to be analyzed.
Step S102, checking the registration state of the request packet, and directly releasing the request packet which is not registered or is registered but does not contain the request parameter.
Since the CSRF attack can be successfully attacked only by using the logged-in user as the object and cannot form a threat to the user who is not in the logged-in state, the invention firstly checks and judges the logged-in state of the request packet when the CSRF protection is carried out. For the request packet which is not logged in, the request packet can be directly released because the attack threat does not exist; for the logged request packet, because the request parameter is used for indicating whether the request packet needs to be protected by CSRF, the request parameter is not included to indicate that the request packet does not need to be protected, and the request packet is directly released; the request packet containing the request parameter indicates that protection processing is required, and the process proceeds to step S103, where the request packet that has logged in and contains the request parameter is checked, and protection is continued.
Step S103, the request packet which is logged in and contains the request parameters is checked.
For a request packet in the login state and containing request parameters, such a request packet has a potential attack threat and needs to be further verified. Therefore, error bar behaviors of the public operation interface can be reduced, and the detection efficiency is improved.
In this embodiment, the verification of the registered request packet including the request parameter includes a determination of whether a referrer field of the request packet is empty, a determination of whether the referrer field is a trusted domain, a determination of a request packet request mode, and a determination of a request packet sensitive operation.
And step S104, judging whether to perform direct release or release after clearing the cache on the request packet according to the checking result.
After the above judgment operations, the request packet without the CSRF attack threat is directly released according to the check result, and the request packet which may have the CSRF attack threat is released after the cache is removed. Clearing the cache information of the data packet is equivalent to exiting the login state, so that the attack action also fails, and the CSRF attack can be prevented; meanwhile, the cache information is cleared, namely the data packet does not have any authority, and the use of the function is not influenced when the operation which is not required to be executed by the authority is executed, so that the use of some special interfaces is not influenced.
As shown in fig. 2, specifically, step S103 specifically includes the following steps:
step S1031, determining whether the referrer field of the request packet is empty.
When the browser sends a request to the ww an server through the http, the header of the request packet generally includes a referrer field, where the referrer field includes a link address of a source page of the request, and the cloud platform can obtain a Uniform Resource Locator (URL) of the source page of the request packet through the referrer field, so as to determine the security of the request packet.
In this embodiment, after the cloud platform finishes checking the login status of the request packet, it is determined whether the referrer field of the request packet that has been logged in and contains the request parameter is empty, and if the referrer field of the request packet is not empty, step S1032 is performed; if the referrer field of the request packet is empty, step S1033 is performed.
In step S1032, it is determined whether the referrer field is a trusted domain. And if the cloud platform judges that the refer field of the logged request packet containing the request parameters is not empty, continuously judging whether the refer field in the request packet is a trusted domain. If the referrer field is a trusted domain, the step S1035 is carried out to directly pass the request packet; if the refer field is not a trusted domain, step S1033 is performed.
The cloud platform stores the known safe and reliable websites in a white list of the referrer field, and the referrer field in the white list is the trusted domain. The Referer field is a request packet of the trusted domain, and represents a source website of the request packet which can be trusted by the cloud platform, the security of the request packet is guaranteed, and the CSRF attack is less likely. Therefore, the cloud platform can directly pass through the request packet without other processing.
Step S1033, a request mode of the request packet is determined.
The Referer field is null, and the request packet may come from an attack page; or although the referrer field is not null, the referrer field is not in the trusted domain of the cloud platform, which indicates that although the cloud platform can know the source page of the request packet, the security of the source page is not trusted by the cloud platform. In both cases, the request packet is likely to be initiated through the page of other website, and is not the request initiated by the function operation of the current website, and the request is likely to be an attack behavior. Therefore, in order to avoid CSRF attack on the request packet in the above two cases, the cloud platform first determines that the request mode of the request packet is a GET request or a POST request for such request packet. If the request mode of the request packet is GET request, go to step S1034; if the request mode of the request packet is the POST request, the process proceeds to step S1036.
The request mode of the hypertext transfer protocol request packet includes GET, HEAD, POST, PUT, DELETE, options, and TRACE, among which the GET request and POST request are mainly used. Therefore, in this step, the present invention mainly determines whether the request packet is a GET request or a POST request, and does not consider other types of request packets. Typically, a GET request is used to retrieve data from a server and a POST request is used to send data to the server. The GET request is more popular in the functional operation of the website, and the resource loading and the connection click request are both directly initiated through the GET request, so that whether the request packet is sensitive operation such as addition, deletion, modification, check and the like needs to be further judged, and protection processing is performed according to the sensitive operation, but the step is not needed for the POST request.
Step S1034, identifying the sensitive operation.
It is determined whether the request packet of the GET request is a sensitive operation, step 1035 is performed for the request packet that is not a sensitive operation, and step 1036 is performed for the request packet that is a sensitive operation.
And the cloud platform continues to judge whether the request packet is sensitive operation or not for the request packet in the GET request mode. If the request packet is not a sensitive operation, go to step S1023; if the request packet is a sensitive operation, then step S1034 is performed.
The sensitive operation refers to actions of adding, deleting, modifying, searching and the like of sensitive information such as user information, account passwords and the like in a request packet, and as the actions directly relate to information security and property security of a user, CSRF attack also takes the aim as the most, the request packet which is the sensitive operation needs to be protected in a key way.
In step S1035, the request packet is directly released.
For non-sensitive operation, the request packet has no attack significance and can be ignored, and the cloud platform can directly release the request packet.
In step S1036, the request packet is released after the cache data (cookies, etc.) in the request packet is cleared.
After the cloud platform clears the cache data in the request packet in the POST request mode or the GET request mode of the sensitive operation, the request packet can be released.
For a request packet in a POST request mode, when a referrer field is not in a white list, the request is most likely to be initiated through pages of other websites, and the request is a highly-probable attack behavior and needs to be intercepted; but also to take into account that there may be some request packages for special common interfaces that can be executed without user rights.
For a request packet in a GET request mode of a sensitive operation, two cases may be included: (1) the functional operation needs the user authority to execute and can influence the data of the user; (2) the functional operation can be executed without any authority, and is a common functional operation.
Clearing the cache data at this time corresponds to exiting the log-in state, so even if the request packet is a CSRF attack, the attack will fail to execute, and the attack is prevented. Meanwhile, after the cache data is cleared, no authority exists, and the use of functions and special interfaces cannot be influenced for executing operations which do not need to be executed by the authority.
As shown in fig. 3, in the embodiment of the cloud platform-based CSRF protection method provided in the present invention, the step S102 checks the login status of the request packet, and before directly passing through the request packet that is not logged in or has logged in but does not include the request parameter, the method further includes:
step S301, determine whether the request packet is an authentication request packet.
Before checking the login state of the request packet, the cloud platform judges whether the request packet is an authentication request packet. If the request packet is not the authentication request packet, step S102 is performed to check the login state of the request packet, and the request packet which is not logged in or is logged in but does not contain the request parameters is directly released; if the packet is an authentication request packet, the session identification processing of step S302 is performed.
Authentication (authentication) refers to verifying whether a user has a right to access a system, an authentication Uniform Resource Locator (URL) refers to a registered URL, and an authentication request packet refers to a request packet carrying the authentication URL. The CSRF protection process is only required if the request packet is not an authentication request packet, and the session identification process of step S302 is adopted for the authentication request packet. The session identification processing in step S302 is not included in the content of the present invention, and is not described herein again.
One embodiment of the cloud platform-based CSRF protection system 100 provided in the present invention is shown in fig. 4, and includes: a login status module 101, a verification module 102 and a protection processing module 103.
The login state module 101 is configured to receive a request packet to be analyzed, check a login state of the request packet, directly pass through the request packet that is not logged in or is logged in but does not include a request parameter, and send the request packet that is logged in and includes the request parameter to the inspection module 102; the verification module 102 is used for verifying the request packet which is logged in and contains the request parameters; the protection processing module 103 is configured to clear the cache for the request packet and then release the request packet according to the check result.
After receiving a hypertext transfer protocol request packet sent from a client such as a browser, the CSRF protection system 100 first receives the request packet to be analyzed through the login status module 101, and checks and determines the login status of the request packet. Because the CSRF attack can be successfully attacked only by taking the logged-in user as an object and cannot form a threat to the user not in the logged-in state, the request packet which is not logged in can be directly released; for the registered request packet, the login status module 101 further checks whether the request packet includes a request parameter, where the request parameter is used to indicate whether the registered request packet needs to be protected by CSRF, and for the request packet that is registered but does not include the request parameter, since there is no CSRF protection request parameter, it is stated that it does not need to be protected, so that it can be released directly. The request packet, which is logged in and contains the request parameters, indicates that a guard process is required and is sent to the verification module 102 for further processing. After receiving the logged request packet containing the request parameters, the checking module 102 determines whether the referrer field is empty, determines whether the referrer field is a trusted domain, determines a request packet request mode, and determines a request packet sensitive operation for the request packet. After the check module 102 performs the above determination operations, the request packet without the CSRF attack threat is directly released according to the check result, and the request packet with the CSRF attack threat is sent to the protection processing module 103 to clear the cache of the request packet and then released. Clearing the cache information of the data packet is equivalent to exiting the login state, so that the attack action also fails, and the CSRF attack can be prevented; meanwhile, the cache information is cleared, namely the data packet does not have any authority, and the use of the function is not influenced when the operation which is not required to be executed by the authority is executed, so that the use of some special interfaces is not influenced.
As shown in fig. 5, the checking module 102 specifically includes: a referrer field determining module 1021, a trusted domain determining module 1022, a request mode determining module 1023 and a sensitive operation determining module 1024.
The referrer field judging module 1021 is configured to judge whether a referrer field of the request packet is empty, send the request packet with the referrer field empty to the request mode judging module 1023, and send the request packet with the referrer field not empty to the trusted domain judging module 1022; the trusted domain determining module 1022 is configured to determine whether a referrer field of a request packet whose referrer field is not empty is a trusted domain, send a request packet whose referrer field is not a trusted domain to the request mode determining module 1023, and directly pass the request packet whose referrer field is a trusted domain; the request mode judging module 1023 is used for judging whether the request mode of the request packet is a POST request or a GET request, then sending the POST request to the protection processing module 103, and sending the GET request to the sensitive operation judging module 1024; the sensitive operation determining module 1024 is configured to determine whether the request packet is a sensitive operation, directly pass the request packet that is not a sensitive operation, and send the request packet that is a sensitive operation to the protection processing module 103.
When the verification module 102 receives the request packet containing the request parameters and being logged in from the login status check module 101, it is first handed over to the referrer field determination module 1021 for processing. The referrer field determining module 1021 identifies the packet header of the request packet, searches whether the referrer field of the packet header of the request packet is empty (whether the packet header contains the referrer field), and sends the request packet with the referrer field empty to the request mode determining module 1023. The request packet with the referrer field not empty in the header of the request packet is sent to the trusted domain determining module 1022, and the trusted domain determining module 1022 determines whether the referrer field of the request packet is a trusted domain. For a request packet whose referrer field is a trusted domain, the trusted domain determining module 1022 directly passes the request packet, and for a request packet whose referrer field is not a trusted domain, the trusted domain determining module 1022 sends the request packet to the request mode determining module 1023. The request mode determining module 1023 determines the type of the request packet after receiving the request packet whose referrer field is empty or the referrer field is not the trusted domain, and sends the request packet of the POST request to the protection processing module 103, and sends the GET request to the sensitive operation determining module 1024. The sensitive operation judging module 1024, after receiving the request packet of the GET request, judges whether the request packet is sensitive operations such as addition, modification, deletion, search and the like, and if the request packet of the GET request is not the sensitive operations, directly passes the request packet; if the request packet of the GET request is these sensitive operations, the request packet is sent to the guard processing module 103.
After the protection processing module 103 receives the request packet of the POST request sent from the request mode determining module 1023 or the request packet of the GET request of the sensitive operation sent from the sensitive operation determining module 1024, the cache data in the request packet is cleared, and then the request packet can be released.
As shown in fig. 6, the login status module 101 specifically includes: a receiving module 1011, a login status checking module 1012, and a request parameter checking module 1013.
The receiving module 1011 is configured to receive a request packet to be analyzed; the login state checking module 1012 is configured to check the login state of the received request packet to be analyzed, directly pass through the request packet that is not logged in, and send the logged request packet to the parameter condition checking module 1013; the request parameter checking module 1013 is configured to check whether the logged request packet contains the CSRF protection request parameter, directly pass through the logged request packet that does not contain the CSRF protection request parameter, and send the logged request packet that contains the CSRF protection request parameter to the verification module 102.
As shown in fig. 7, the login status module 101 further includes: an authenticate uniform resource locator module 1014.
The authentication url module 1014 is configured to determine whether the received request packet to be analyzed is an authentication request packet, and send a non-authentication request packet to the login status checking module 1012.
Before the login status checking module 1012 checks the login status of the request packet, it needs to first determine whether the request packet is an authentication request packet by the authentication uniform resource locator module 1014, and perform other processing (session identification processing) on the authentication request packet; if not, it is sent to the login status check module 1012 to continue the protection process.
According to the CSRF protection method and system based on the cloud platform, disclosed by the invention, by judging the login authority of requesting to access the system, the false blocking behavior of the open operation interface can be reduced, the detection efficiency is improved, and the performance of the cloud platform is not influenced; CSRF protection can be carried out on the whole website by identifying a request mode, configuring sensitive operation parameters and carrying out related processing on the requested refer, configuration is simple and convenient, and professional requirements on operators are low.
The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.
The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like that fall within the spirit and principle of the present invention are intended to be included therein.
Claims (11)
1. A CSRF protection method based on a cloud platform is characterized by comprising the following steps:
receiving a request packet to be analyzed;
checking the login state of the request packet, and directly passing through the request packet which is not logged in or is logged in but does not contain the request parameters;
the method comprises the steps of checking a request packet which is logged and contains request parameters, wherein the checking comprises the steps of judging a request packet request mode and judging the sensitive operation of the request packet;
and judging whether the request packet is directly released or released after the cache is cleared according to the inspection result.
2. The cloud platform-based CSRF safeguard method of claim 1, wherein the step of verifying the request packet that is logged in and contains the request parameters comprises:
judging whether the referrer field of the request packet is empty or not;
if the referrer of the request packet is empty, further judging the request mode of the request packet;
if the request packet is a POST request, clearing the cache of the request packet and then releasing the request packet;
and if the GET request is the GET request, identifying the sensitive operation.
3. The cloud platform-based CSRF defense method of claim 2,
if the referrer field of the request packet is not empty, judging whether the referrer field is a trusted domain;
if the referrer field is a trusted domain, directly passing the request packet;
if the referrer field is an untrusted field, further judging the request mode of the request packet;
if the request packet is a POST request, clearing the cache of the request packet and then releasing the request packet;
and if the GET request is the GET request, identifying the sensitive operation.
4. The cloud platform-based CSRF protection method according to claim 2 or 3, wherein the specific step of the sensitive operation identification comprises:
and judging whether the request packet is sensitive operation, directly releasing the request packet which is not sensitive operation, and releasing the request packet which is sensitive operation after clearing the cache.
5. The cloud platform-based CSRF protection method of claim 4, wherein: the sensitive operation comprises adding, deleting, modifying and inquiring.
6. The cloud platform-based CSRF safeguard method of claim 1, wherein the safeguard method further comprises:
before checking the login state of the request packet, judging whether the request packet is an authentication request packet or not;
if not, the login status of the request packet is further checked.
7. A CSRF protection system based on a cloud platform, comprising:
the login state module is used for receiving a request packet to be analyzed, checking the login state of the request packet, directly releasing the request packet which is not logged in or is logged in but does not contain the request parameters, and sending the request packet which is logged in and contains the request parameters to the checking module;
the verification module is used for verifying the logged request packet containing the request parameters, and the verification comprises the judgment of the request packet request mode and the judgment of the sensitive operation of the request packet;
and the protection processing module is used for clearing the cache of the request packet and then releasing the request packet according to the inspection result.
8. The cloud platform-based CSRF protection system of claim 7, wherein the verification module specifically comprises:
the referrer field judging module is used for judging whether the referrer field of the request packet is empty or not, sending the request packet with the referrer field being empty to the request mode judging module, and sending the request packet with the referrer field not being empty to the trusted domain judging module;
a trusted domain judging module, configured to judge whether the referrer field of the request packet whose referrer field is not empty is a trusted domain, send the request packet whose referrer field is not a trusted domain to a request mode judging module, and directly release the request packet whose referrer field is a trusted domain;
the request mode judging module is used for judging whether the request mode of the request packet is a POST request or a GET request, then sending the POST request to the protection processing module and sending the GET request to the sensitive operation judging module;
and the sensitive operation judging module is used for judging whether the request packet is sensitive operation, directly releasing the request packet which is not sensitive operation, and sending the request packet which is sensitive operation to the protection processing module.
9. The cloud platform-based CSRF protection system of claim 8, wherein the sensitive operations comprise add, delete, modify, query.
10. The cloud platform-based CSRF protection system of claim 9, wherein the login status module specifically comprises:
a receiving module, configured to receive the request packet to be analyzed;
the login state checking module is used for checking the login state of the received request packet to be analyzed, directly releasing the request packet which is not logged in, and sending the logged request packet to the parameter condition checking module;
and the request parameter checking module is used for checking whether the logged request packet contains the request parameter, directly releasing the logged request packet which does not contain the request parameter, and sending the logged request packet which contains the request parameter to the verifying module.
11. The cloud platform-based CSRF shield system of claim 10, wherein the login status module further comprises:
and the authentication uniform resource locator module is used for judging whether the received request packet to be analyzed is an authentication request packet or not and sending a non-authentication request packet to the login state checking module.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710544734.XA CN107294994B (en) | 2017-07-06 | 2017-07-06 | CSRF protection method and system based on cloud platform |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710544734.XA CN107294994B (en) | 2017-07-06 | 2017-07-06 | CSRF protection method and system based on cloud platform |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107294994A CN107294994A (en) | 2017-10-24 |
| CN107294994B true CN107294994B (en) | 2020-06-05 |
Family
ID=60100349
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710544734.XA Active CN107294994B (en) | 2017-07-06 | 2017-07-06 | CSRF protection method and system based on cloud platform |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107294994B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108197467A (en) * | 2018-01-11 | 2018-06-22 | 郑州云海信息技术有限公司 | A kind of automated detection method and system of CSRF loopholes |
| CN111327621A (en) * | 2020-02-27 | 2020-06-23 | 紫光云技术有限公司 | Method for defending CSRF attack based on custom http request header |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101883024A (en) * | 2010-06-23 | 2010-11-10 | 南京大学 | Dynamic detection method for cross-site forged request |
| CN102480490A (en) * | 2010-11-30 | 2012-05-30 | 国际商业机器公司 | Method for preventing CSRF attack and equipment thereof |
| CN102571846A (en) * | 2010-12-23 | 2012-07-11 | 北京启明星辰信息技术股份有限公司 | Method and device for forwarding hyper text transport protocol (HTTP) request |
| CN102685081A (en) * | 2011-03-17 | 2012-09-19 | 腾讯科技（深圳）有限公司 | Webpage request safe processing method and system |
| US8341200B2 (en) * | 2008-06-12 | 2012-12-25 | Pomian & Corella, Llc | Protecting a web application against attacks through shared files |
| CN103679018A (en) * | 2012-09-06 | 2014-03-26 | 百度在线网络技术（北京）有限公司 | Method and device for detecting CSRF loophole |
| CN104424434A (en) * | 2013-08-29 | 2015-03-18 | 腾讯科技（深圳）有限公司 | Data verification method and device |
| CN104601558A (en) * | 2014-12-31 | 2015-05-06 | 微梦创科网络科技（中国）有限公司 | Method and device for defending cross-site request forgery attacks |
| CN105100084A (en) * | 2015-07-07 | 2015-11-25 | 中国科学院计算技术研究所 | Method and system for preventing cross-site request forgery attack |
| CN105635064A (en) * | 2014-10-31 | 2016-06-01 | 杭州华三通信技术有限公司 | CSRF attack detection method and device |
| CN105991615A (en) * | 2015-03-04 | 2016-10-05 | 杭州迪普科技有限公司 | Protection method and device based on CSRF attack |
-
2017
- 2017-07-06 CN CN201710544734.XA patent/CN107294994B/en active Active
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8341200B2 (en) * | 2008-06-12 | 2012-12-25 | Pomian & Corella, Llc | Protecting a web application against attacks through shared files |
| CN101883024A (en) * | 2010-06-23 | 2010-11-10 | 南京大学 | Dynamic detection method for cross-site forged request |
| CN102480490A (en) * | 2010-11-30 | 2012-05-30 | 国际商业机器公司 | Method for preventing CSRF attack and equipment thereof |
| CN102571846A (en) * | 2010-12-23 | 2012-07-11 | 北京启明星辰信息技术股份有限公司 | Method and device for forwarding hyper text transport protocol (HTTP) request |
| CN102685081A (en) * | 2011-03-17 | 2012-09-19 | 腾讯科技（深圳）有限公司 | Webpage request safe processing method and system |
| CN103679018A (en) * | 2012-09-06 | 2014-03-26 | 百度在线网络技术（北京）有限公司 | Method and device for detecting CSRF loophole |
| CN104424434A (en) * | 2013-08-29 | 2015-03-18 | 腾讯科技（深圳）有限公司 | Data verification method and device |
| CN105635064A (en) * | 2014-10-31 | 2016-06-01 | 杭州华三通信技术有限公司 | CSRF attack detection method and device |
| CN104601558A (en) * | 2014-12-31 | 2015-05-06 | 微梦创科网络科技（中国）有限公司 | Method and device for defending cross-site request forgery attacks |
| CN105991615A (en) * | 2015-03-04 | 2016-10-05 | 杭州迪普科技有限公司 | Protection method and device based on CSRF attack |
| CN105100084A (en) * | 2015-07-07 | 2015-11-25 | 中国科学院计算技术研究所 | Method and system for preventing cross-site request forgery attack |
Non-Patent Citations (2)
| Title |
|---|
| CSRF原理以及防护措施;杨家;《电脑与电信》;20160310(第3期);全文 * |
| 跨站请求伪造_CSRF_分析与检测技术研究;郑新新等;《中国通信学会青年工作委员会会议论文集》;20140905(第10期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107294994A (en) | 2017-10-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10855700B1 (en) | Post-intrusion detection of cyber-attacks during lateral movement within networks | |
| CN106357696B (en) | SQL injection attack detection method and system | |
| CN107077410B (en) | Analyzing client application behavior to detect anomalies and prevent access | |
| Jovanovic et al. | Preventing cross site request forgery attacks | |
| EP3219068B1 (en) | Method of identifying and counteracting internet attacks | |
| Stringhini et al. | Shady paths: Leveraging surfing crowds to detect malicious web pages | |
| US8024804B2 (en) | Correlation engine for detecting network attacks and detection method | |
| KR101890272B1 (en) | Automated verification method of security event and automated verification apparatus of security event | |
| US8601586B1 (en) | Method and system for detecting web application vulnerabilities | |
| RU2680736C1 (en) | Malware files in network traffic detection server and method | |
| US20050188215A1 (en) | Method and apparatus for high-speed detection and blocking of zero day worm attacks | |
| CN105939326A (en) | Message processing method and device | |
| CN111786966A (en) | Method and device for browsing webpage | |
| CN108369541B (en) | System and method for threat risk scoring of security threats | |
| CN104967628A (en) | Deceiving method of protecting web application safety | |
| CN107465702A (en) | Method for early warning and device based on wireless network invasion | |
| CN106209907B (en) | Method and device for detecting malicious attack | |
| RU2762528C1 (en) | Method for processing information security events prior to transmission for analysis | |
| CN107294994B (en) | CSRF protection method and system based on cloud platform | |
| US10757118B2 (en) | Method of aiding the detection of infection of a terminal by malware | |
| Zhao et al. | Network security model based on active defense and passive defense hybrid strategy | |
| Modi et al. | Design and implementation of RESTFUL API based model for vulnerability detection and mitigation | |
| CN107517226A (en) | Alarm method and device based on wireless network invasion | |
| CN112637171A (en) | Data traffic processing method, device, equipment, system and storage medium | |
| Izagirre | Deception strategies for web application security: application-layer approaches and a testing platform |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |