CN113783824B - Method, apparatus, client, system and medium for preventing cross-site request forgery - Google Patents
Method, apparatus, client, system and medium for preventing cross-site request forgery Download PDFInfo
- Publication number
- CN113783824B CN113783824B CN202010524868.7A CN202010524868A CN113783824B CN 113783824 B CN113783824 B CN 113783824B CN 202010524868 A CN202010524868 A CN 202010524868A CN 113783824 B CN113783824 B CN 113783824B
- Authority
- CN
- China
- Prior art keywords
- webpage
- token
- url
- server
- credible
- 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/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- 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/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- 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/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- 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/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
Abstract
The present disclosure provides a method, an apparatus, a client, a network system and a storage medium for preventing cross-site request forgery, which relates to the technical field of computers, wherein the method comprises: receiving an original token sent by a server, and verifying whether a first webpage is a trusted webpage or not; if the first page is a credible webpage, storing the original token; when the POST request needs to be sent to the server side, verifying whether the second webpage is a credible webpage or not; if the second webpage is a credible webpage, acquiring the stored original token for preset processing to generate a new token value; and sending the POST request carrying the new token value to the server. The method, the device and the storage medium can avoid the condition that the token is revealed because the HTTP request is sent, can avoid the risk that the page is nested by a hacker website, and greatly improves the security of the token of the user.
Description
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a method, an apparatus, a client, a network system, and a storage medium for preventing a cross-site request from being forged.
Background
A token is generally adopted for traditional defense of cross-site request forgery attack, a client user logs in by using a user name and a password, the token is returned after the server side succeeds in verification, the token is stored by the client side, the token is carried by the front side when the front side needs to send a request to the back side, and corresponding data are returned after the back side verifies the token. However, the existing token verification method has vulnerabilities: the token is added after all requests, if the user clicks the link to jump in the forum-type website, the token with the user can be taken to reach the link pages of other websites, the token of the user is easy to be revealed, and potential safety hazards are caused.
Disclosure of Invention
In view of the above, an object of the present invention is to provide a method, an apparatus, a client, a network system, and a storage medium for preventing cross-site request forgery.
According to a first aspect of the present disclosure, there is provided a method of preventing cross-site request forgery, comprising: receiving an original token sent by a server, and verifying whether a first webpage is a trusted webpage or not; if the first page is a trusted webpage, storing the original token; when the POST request needs to be sent to the server side, verifying whether the second webpage is a trusted webpage or not; if the second webpage is a credible webpage, acquiring the stored original token for preset processing to generate a new token value; and sending a POST request carrying the new token value to the server so that the server performs validity check on the new token value.
Optionally, the receiving an original token sent by the server includes: sending login verification information to the server; wherein the login authentication information includes: a user name and password; and receiving the original token returned by the server after the login verification information is successfully authenticated.
Optionally, the verifying whether the first webpage is a trusted webpage includes: acquiring a top page as the first webpage; acquiring a first URL of the first webpage, and verifying whether the first URL is a credible URL or not based on a preset credible URL list; and if the first URL is a credible URL, determining that the first webpage is a credible webpage, and if the first URL is not the credible URL, performing reminding processing.
Optionally, the storing the original token comprises: storing the original token in a storage unit; wherein the storage unit comprises the cookie, the localStorage, or the sessionstorege.
Optionally, the verifying whether the second webpage is a trusted webpage includes: acquiring a top page as the second webpage; acquiring a second URL of the second webpage, and verifying whether the second URL is a credible URL or not based on the credible URL list; and if the second URL is a credible URL, determining that the second webpage is a credible webpage, and if the second URL is not the credible URL, performing reminding processing.
Optionally, the obtaining the stored original token to perform preset processing, and generating a new token value includes: reading the original token stored in advance in the storage unit; and performing salting treatment on the original token to generate the new token value.
Optionally, the performing, by the server, validity checking on the new token value includes: the server-side carries out reverse operation of the salting processing on the new token value to obtain the original token; the server side carries out validity verification on the original token; if the verification is successful, the server returns data corresponding to the POST request; and if the verification fails, the server returns prompt information.
Optionally, when sending a GET request to the server, the original token or the new token value is not added to the GET request.
According to a second aspect of the present disclosure, there is provided an apparatus for preventing cross-site request forgery, comprising: the identification receiving module is used for receiving an original token sent by the server; the verification module is used for verifying whether the first webpage is a credible webpage or not; the storage module is used for storing the original token if the first page is a credible webpage; the verification module is further used for verifying whether the second webpage is a trusted webpage or not when the fact that the POST request needs to be sent to the server side is judged; the new value generation module is used for acquiring the stored original token for preset processing to generate a new token value if the second webpage is a trusted webpage; and the request sending module is used for sending the POST request carrying the new token value to the server so as to enable the server to carry out validity check on the new token value.
According to a third aspect of the present disclosure, there is provided an apparatus for preventing cross-site request forgery, comprising: a memory; and a processor coupled to the memory, the processor configured to perform the method as described above based on instructions stored in the memory.
According to a fourth aspect of the present disclosure, there is provided a client comprising: such as the above, to prevent cross-site request forgery.
According to a fifth aspect of the present disclosure, there is provided a network system including: a server and a client as described above.
According to a sixth aspect of the present disclosure, there is provided a computer readable storage medium storing computer instructions for execution by a processor to perform the method as above.
The method, the device, the client, the network system and the storage medium for preventing the cross-site request from being forged ensure that the token is sent for verification on the premise that the page is credible, can avoid the condition that the token is leaked due to the sending of the HTTP request, process the token stored in the browser, avoid the token from being leaked due to the insecurity of the browser, avoid the risk that the page is nested by a hacker website, and greatly improve the safety of the token of the user.
Drawings
In order to more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present disclosure, and other drawings can be obtained by those skilled in the art without inventive exercise.
FIG. 1 is a flow diagram of one embodiment of a method of preventing cross-site request forgery according to the present disclosure;
FIG. 2 is a schematic flow diagram of obtaining an original token in one embodiment of a method of preventing cross-site request forgery according to the present disclosure;
FIG. 3 is a schematic flow chart diagram illustrating another embodiment of a method of preventing cross-site request forgery according to the present disclosure;
FIG. 4 is a block diagram illustrating one embodiment of an apparatus for preventing cross-site request forgery according to the present disclosure;
FIG. 5 is a block diagram of another embodiment of an apparatus for preventing cross-site request forgery according to the present disclosure.
Detailed Description
The present disclosure now will be described more fully hereinafter with reference to the accompanying drawings, in which exemplary embodiments of the disclosure are shown. The technical solutions in the embodiments of the present disclosure will be described clearly and completely with reference to the drawings in the embodiments of the present disclosure, and it is obvious that the embodiments described are only some embodiments of the present disclosure, rather than all embodiments. All other embodiments, which can be derived by one of ordinary skill in the art from the embodiments disclosed herein without making any creative effort, shall fall within the scope of protection of the present disclosure. The technical solution of the present disclosure is described in various aspects below with reference to various figures and embodiments.
The terms "first", "second", etc. are used hereinafter only for descriptive distinction and have no other special meaning.
FIG. 1 is a flow diagram of one embodiment of a method of preventing cross-site request forgery according to the present disclosure, as shown in FIG. 1:
Token is a string of character strings generated by the server and can be used as a Token for the client to make a request. After the client logs in for the first time, the server generates a Token and returns the Token to the client, and then the client only needs to carry the Token request data without carrying the user name and the password again. The purpose of Token is to reduce the stress on the server, reduce the frequent query on the database, and make the server more robust. The original token refers to a token which is sent by a server and is not subjected to encryption and other processing.
And 102, if the first page is a credible webpage, storing the original token.
And 103, when the POST request needs to be sent to the server side, verifying whether the second webpage is a trusted webpage or not. The POST request is a request in the HTTP protocol, which is transmitted in ASCII code, and builds an application layer specification on top of the TCP/IP protocol.
And step 104, if the second webpage is a trusted webpage, acquiring the stored original token for preset processing, and generating a new token value. The preset process may be various processes such as an encryption process, a salt adding process, and the like.
And 105, sending a POST request carrying the new token value to the server so that the server performs validity check on the new token value.
Fig. 2 is a schematic flowchart of obtaining an original token in an embodiment of a method for preventing cross-site request forgery according to the present disclosure, as shown in fig. 2:
In one embodiment, a top-level page is obtained as a first web page, where the top-level page refers to a page without a parent page. Acquiring a first URL (Uniform Resource Locator) of the first webpage, and verifying whether the first URL is a trusted URL or not based on a preset trusted URL list. And if the first URL is the credible URL, determining that the first webpage is the credible webpage, and if the first URL is not the credible URL, performing reminding processing.
If the pages are nested, it may happen that a hacker guides the user to click, resulting in an attack. And constructing a JS (JavaScript) module, defining the credible URL as the attribute name of the constant object in the module, and freezing the object. The trusted URL list can be preset, the URL in the trusted URL list is the trusted URL, the trusted URL in the trusted URL list can be stored in the JS module, and the JS module is arranged in a page of the client.
A verification method is set in the JS module, and is used for verifying whether a first URL (for example, top. If the first URL is in the credible URL list, the first URL is a credible URL, and the first webpage is determined to be a credible webpage; if the first URL is not in the list of trusted URLs, then the first URL is not a trusted URL, suggesting that there is a risk of CSRF (Cross-site request forgery).
In one embodiment, the primitive token is stored in a storage unit comprising a cookie, localStorage or sessionStorage, or the like. When the POST request needs to be sent to the server side, acquiring a top page as a second page; the first web page may be the same as or different from the first web page. And acquiring a second URL of the second webpage, and verifying whether the second URL is a credible URL or not based on the credible URL list. And if the second URL is in the credible URL list, the second URL is a credible URL, the second webpage is determined to be a credible webpage, and if the second URL is not the credible URL, reminding processing is carried out to prompt that CSRF risks exist.
And when the token is judged to be required to be read, reading the original token from the cookie or localStorage or sessionstorege. The token stored by the cookie, localStorage and sessiontorage can be used for verification with the server, so that the risk caused by the insecurity of the browser exists. And (4) performing salting treatment and the like on the original token to generate a new token value. The original token may be deciphered if it is not salted or otherwise processed. Salting is an artificial process of forming a new character by combining a set of random characters with the user's original token, thereby increasing the difficulty of deciphering. Various existing salting processes may be used.
Introducing a JS module into a page needing to send a POST request, calling a method in the JS module, obtaining a token after adding salt, and carrying the token to send the request to a server. The server performs reverse operation of salt adding treatment on the new token value to obtain an original token; the server side carries out validity verification on the original token; if the verification is successful, the server returns data corresponding to the POST request; and if the verification fails, the server returns prompt information to prompt that the CSRF risk exists.
By verifying the top-level page URL, the risk of nesting pages by hacker websites is avoided. The GET request in the appointed website is only used for requesting data with low confidentiality, and the GET request does not need to carry token for verification; in order to avoid token leakage due to the GET request, when the GET request is sent to the server, the original token or the new token value is not added to the GET request. The server does not verify the GET request, i.e. the token is not added after the link, so that the leakage risk does not exist.
FIG. 3 is a schematic flow chart diagram illustrating another embodiment of a method for preventing cross-site request forgery according to the present disclosure, as shown in FIG. 3:
And step 310, carrying the token to send a POST request. And carrying the token by the POST request, and verifying at the server.
And step 313, displaying the information. And if the verification is successful, returning corresponding data.
In one embodiment, as shown in fig. 4, the present disclosure provides an apparatus 40 for preventing cross-site request forgery, comprising: an identity receiving module 41, a verification module 42, a storage module 43, a new value generation module 44 and a request sending module 45. The identifier receiving module 41 receives an original token sent by the server. The verification module 42 verifies whether the first web page is a trusted web page.
If the first page is a trusted web page, the storage module 43 stores the original token. When it is determined that the POST request needs to be sent to the server, the verification module 42 verifies whether the second webpage is a trusted webpage. If the second web page is a trusted web page, the new value generation module 44 obtains the stored original token to perform a preset process, and generates a new token value. The request sending module 45 sends a POST request carrying the new token value to the server, so that the server performs validity check on the new token value.
The identification receiving module 41 sends login verification information to the server; the login authentication information includes a user name, a password, and the like. The identifier receiving module 41 receives the original token returned by the server after the login verification information is successfully authenticated.
The verification module 42 retrieves the top-level page as the first web page. The verification module 42 obtains the first URL of the first webpage, and verifies whether the first URL is a trusted URL based on a preset trusted URL list. If the first URL is a trusted URL, the verification module 42 determines that the first webpage is a trusted webpage, and if the first URL is not a trusted URL, performs a reminding process. The storage module 42 stores the original token in a storage unit, which includes a cookie, a localStorage or a sessionstorege, and the like.
The verification module 42 retrieves the top-level page as the second web page. The verification module 42 obtains the second URL of the second web page, and verifies whether the second URL is a trusted URL based on the trusted URL list. If the second URL is a trusted URL, the verification module 42 determines that the second webpage is a trusted webpage, and if the second URL is not a trusted URL, performs a reminding process.
The new value generation module 44 reads a pre-stored original token in the storage unit; and (4) performing salting treatment on the original token to generate a new token value. And the server performs the reverse operation of the salting treatment on the new token value to obtain the original token. If the verification is successful, the server returns data corresponding to the POST request; and if the verification fails, the server returns prompt information. When sending the GET request to the server, the request sending module 45 does not add the original token or the new token value to the GET request.
In one embodiment, fig. 5 is a block diagram of another embodiment of an apparatus for preventing cross-site request forgery according to the present disclosure. As shown in fig. 5, the apparatus may include a memory 51, a processor 52, a communication interface 53, and a bus 54. The memory 51 is used for storing instructions, the processor 52 is coupled to the memory 51, and the processor 52 is configured to execute the method for preventing cross-site request forgery based on the instructions stored in the memory 51.
The memory 51 may be a high-speed RAM memory, a non-volatile memory (non-volatile memory), or the like, and the memory 51 may be a memory array. The storage 51 may also be partitioned and the blocks may be combined into virtual volumes according to certain rules. Processor 52 may be a central processing unit CPU, or an application Specific Integrated circuit asic, or one or more Integrated circuits configured to implement the method of preventing cross-site request forgery of the present disclosure.
In one embodiment, the present disclosure provides a client comprising the apparatus for preventing cross-site request forgery as in any of the above embodiments.
In one embodiment, the present disclosure provides a network system comprising a server and a client as in any of the above embodiments.
In one embodiment, the present disclosure provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement a method of preventing cross-site request forgery as in any of the above embodiments.
The method, the device, the client, the network system and the storage medium for preventing the cross-site request forgery provided by the embodiment ensure that the Token is sent for verification on the premise that the page is credible, can avoid the condition that the Token is leaked due to the sending of the HTTP request, process the Token stored in the browser, avoid the Token from being leaked due to the insecurity of the browser, and also avoid the risk that the page is nested by a hacker website, so that the security of the Token of the user is greatly improved.
The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.
The description of the present disclosure has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the disclosure in the form disclosed. Many modifications and variations will be apparent to practitioners skilled in this art. The embodiment was chosen and described in order to best explain the principles of the disclosure and the practical application, and to enable others of ordinary skill in the art to understand the disclosure for various embodiments with various modifications as are suited to the particular use contemplated.
Claims (13)
1. A method of preventing cross-site request forgery, comprising:
receiving an original token sent by a server, and verifying whether a first webpage is a trusted webpage or not;
if the first page is a credible webpage, storing the original token;
when the POST request needs to be sent to the server side, verifying whether the second webpage is a trusted webpage or not;
if the second webpage is a trusted webpage, acquiring the stored original token for preset processing to generate a new token value;
and sending a POST request carrying the new token value to the server so that the server performs validity check on the new token value.
2. The method as claimed in claim 1, wherein the receiving the original token sent by the server includes:
sending login verification information to the server; wherein the login authentication information includes: a user name and password;
and receiving the original token returned by the server after the login verification information is successfully authenticated.
3. The method of claim 1, the verifying whether the first web page is a trusted web page comprising:
acquiring a top page as the first webpage;
acquiring a first URL of the first webpage, and verifying whether the first URL is a credible URL or not based on a preset credible URL list;
and if the first URL is a credible URL, determining that the first webpage is a credible webpage, and if the first URL is not the credible URL, performing reminding processing.
4. The method of claim 3, the storing the original token comprising:
storing the original token in a storage unit; wherein the storage unit comprises a cookie, a localStorage or a sessionstorege.
5. The method of claim 3, the verifying whether the second webpage is a trusted webpage comprising:
acquiring a top page as the second webpage;
acquiring a second URL of the second webpage, and verifying whether the second URL is a credible URL or not based on the credible URL list;
and if the second URL is a credible URL, determining that the second webpage is a credible webpage, and if the second URL is not the credible URL, performing reminding processing.
6. The method of claim 4, wherein obtaining the stored original token for a predetermined process, and generating a new token value comprises:
reading the original token stored in advance in the storage unit;
and performing salting treatment on the original token to generate the new token value.
7. The method of claim 6, the server side performing a validity check on the new token value comprising:
the server performs the reverse operation of the salting processing on the new token value to obtain the original token;
the server side carries out validity verification on the original token;
if the verification is successful, the server returns data corresponding to the POST request;
and if the verification fails, the server returns prompt information.
8. The method of claim 6, further comprising:
when sending a GET request to the server, not adding the original token or the new token value in the GET request.
9. An apparatus to prevent cross-site request forgery, comprising:
the identification receiving module is used for receiving an original token sent by the server;
the verification module is used for verifying whether the first webpage is a credible webpage or not;
the storage module is used for storing the original token if the first page is a credible webpage;
the verification module is further used for verifying whether the second webpage is a trusted webpage or not when the fact that the POST request needs to be sent to the server side is judged;
the new value generation module is used for acquiring the stored original token for preset processing to generate a new token value if the second webpage is a trusted webpage;
and the request sending module is used for sending the POST request carrying the new token value to the server so as to enable the server to carry out validity check on the new token value.
10. An apparatus for preventing cross-site request forgery, comprising:
a memory; and a processor coupled to the memory, the processor configured to perform the method of any of claims 1-8 based on instructions stored in the memory.
11. A client, comprising:
an apparatus for preventing cross-site request forgery as claimed in claim 9 or 10.
12. A network system, comprising:
a server and a client as claimed in claim 11.
13. A computer-readable storage medium having stored thereon, non-transitory, computer instructions for execution by a processor to perform the method of any one of claims 1-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010524868.7A CN113783824B (en) | 2020-06-10 | 2020-06-10 | Method, apparatus, client, system and medium for preventing cross-site request forgery |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010524868.7A CN113783824B (en) | 2020-06-10 | 2020-06-10 | Method, apparatus, client, system and medium for preventing cross-site request forgery |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113783824A CN113783824A (en) | 2021-12-10 |
| CN113783824B true CN113783824B (en) | 2022-08-30 |
Family
ID=78834790
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010524868.7A Active CN113783824B (en) | 2020-06-10 | 2020-06-10 | Method, apparatus, client, system and medium for preventing cross-site request forgery |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113783824B (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101296087A (en) * | 2007-04-23 | 2008-10-29 | Sap股份公司 | Method and system for preventing cross-site attack |
| CN103312666A (en) * | 2012-03-09 | 2013-09-18 | 腾讯科技（深圳）有限公司 | Method, system and device for preventing CSRF (cross site request forgery) attack |
| CN103944900A (en) * | 2014-04-18 | 2014-07-23 | 中国科学院计算技术研究所 | Cross-station request attack defense method and device based on encryption |
| CN104660556A (en) * | 2013-11-20 | 2015-05-27 | 深圳市腾讯计算机系统有限公司 | Cross site request forgery vulnerability detection method and device |
| CN106790238A (en) * | 2017-01-19 | 2017-05-31 | 北京神州绿盟信息安全科技股份有限公司 | It is a kind of to forge CSRF defence authentication method and device across station request |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102480490B (en) * | 2010-11-30 | 2014-09-24 | 国际商业机器公司 | Method for preventing CSRF attack and equipment thereof |
-
2020
- 2020-06-10 CN CN202010524868.7A patent/CN113783824B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101296087A (en) * | 2007-04-23 | 2008-10-29 | Sap股份公司 | Method and system for preventing cross-site attack |
| CN103312666A (en) * | 2012-03-09 | 2013-09-18 | 腾讯科技（深圳）有限公司 | Method, system and device for preventing CSRF (cross site request forgery) attack |
| CN104660556A (en) * | 2013-11-20 | 2015-05-27 | 深圳市腾讯计算机系统有限公司 | Cross site request forgery vulnerability detection method and device |
| CN103944900A (en) * | 2014-04-18 | 2014-07-23 | 中国科学院计算技术研究所 | Cross-station request attack defense method and device based on encryption |
| CN106790238A (en) * | 2017-01-19 | 2017-05-31 | 北京神州绿盟信息安全科技股份有限公司 | It is a kind of to forge CSRF defence authentication method and device across station request |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113783824A (en) | 2021-12-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102069759B1 (en) | Dynamic Updates for CAPTCHA Challenges | |
| US8910247B2 (en) | Cross-site scripting prevention in dynamic content | |
| TWI620090B (en) | Login failure sequence for detecting phishing | |
| CN102571846B (en) | Method and device for forwarding hyper text transport protocol (HTTP) request | |
| US9059985B1 (en) | Methods for fraud detection | |
| KR101723937B1 (en) | Cloud-assisted method and service for application security verification | |
| US9241004B1 (en) | Alteration of web documents for protection against web-injection attacks | |
| CN107046544B (en) | Method and device for identifying illegal access request to website | |
| US10225260B2 (en) | Enhanced authentication security | |
| GB2509045A (en) | Generating a device identifier by receiving a token from a server, signing a request including the token with a private key and verifying the request | |
| US20170085567A1 (en) | System and method for processing task resources | |
| CN108259619B (en) | Network request protection method and network communication system | |
| CN102073822A (en) | Method and system for preventing user information from leaking | |
| CN111817845A (en) | Anti-crawler method and computer storage medium | |
| KR20150033053A (en) | User authentication method and apparatus | |
| CN111818088A (en) | Authorization mode management method and device, computer equipment and readable storage medium | |
| CN103444215A (en) | Methods and apparatuses for avoiding damage in network attacks | |
| EP3476077A1 (en) | Password generation device and password verification device | |
| CN110581841B (en) | Back-end anti-crawler method | |
| CN111355730A (en) | Platform login method, device, equipment and computer readable storage medium | |
| CN109688109B (en) | Verification method and device of verification code based on client information identification | |
| CN111193691B (en) | Authorization method, system and related equipment | |
| CN113783824B (en) | Method, apparatus, client, system and medium for preventing cross-site request forgery | |
| CN111949952B (en) | Method for processing verification code request and computer-readable storage medium | |
| US20160366172A1 (en) | Prevention of cross site request forgery attacks |
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 |