CN111447195A - Web interface design method for preventing request message from being tampered, attacked and replayed - Google Patents
Web interface design method for preventing request message from being tampered, attacked and replayed Download PDFInfo
- Publication number
- CN111447195A CN111447195A CN202010209006.5A CN202010209006A CN111447195A CN 111447195 A CN111447195 A CN 111447195A CN 202010209006 A CN202010209006 A CN 202010209006A CN 111447195 A CN111447195 A CN 111447195A
- Authority
- CN
- China
- Prior art keywords
- request
- csrftoken
- openid
- parameters
- token
- 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.)
- Granted
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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
- H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
-
- 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/145—Countermeasures against malicious traffic the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
Abstract
The invention discloses a web interface design method for preventing a request message from being tampered, attacked and replayed. The method specifically comprises the following steps: the server constructs Token by combining the specific information, and if the calling party is also the server, the Token is issued in advance; if the browser client side exists, returning to csrfToken; appointing a public parameter signature algorithm, appointing a public parameter of the signature algorithm: noncestrer, openid, timeframe, token; and appointing an abstract service parameter: payload, which refers to the set of all traffic parameters; initiating an API request; according to the validity of the public parameter and the payload check request in the request, the priority of the check flow follows: parameter checking is firstly carried out, simple or complex operation is secondly carried out, and cache delay is inquired. The invention has the beneficial effects that: the method ensures that the packet cannot be leaked even if the request is captured, prevents the security of the browser and the CSRF of the server, prevents the parameters from being tampered, and ensures that the request is not replayed.
Description
Technical Field
The invention relates to the technical field of request message correlation, in particular to a web interface design method for preventing a request message from being tampered, attacked and replayed.
Background
The technical scheme in the prior art is as follows: (1) a method, system and device for defending cross-site request forgery CSRF attack is disclosed, the method generally sends a cookie containing token to the login user, analyzes the token value according to the requested cookie and compares the token value with the cookie. The technology requires that Cookie for storing token must be in httpony mode, otherwise front-end js can be stolen. Secondly, the token value of the technology needs to adopt an encryption algorithm, and a timestamp is needed in an encryption algorithm variable, so that the token can be changed, otherwise, the token can be manually recorded and stored. This technique does not show how to prevent the Cookie from being tampered with.
(2) A method for supporting REST API tamper-proof replay-proof aims at users who have access rights (non-anonymous API or logged-in users), judges whether a request message format is tampered after series comparison and operation, and the most important point is that a calling end and a service end agree a key which cannot be leaked. This prior art technique has an anonymous API access scenario existing if the caller client is a browser, but the anonymous API needs to prevent the request message from being tampered with as well. If the Appkey and the signature algorithm are leaked, any user can construct a signature string, and in the scene that the requesting party is a browser, the front end has no secret statement and is exposed.
Disclosure of Invention
The invention provides a web interface design method for preventing request messages from being tampered, attacked and replayed, and the method can be used for overcoming the defects in the prior art.
In order to achieve the purpose, the invention adopts the following technical scheme:
a web interface design method for preventing request messages from being tampered, attacked and replayed specifically comprises the following steps:
(1) the server constructs Token by combining the specific information, and if the calling party is also the server, the Token is issued in advance; if the browser client side exists, returning to csrfToken;
(2) appointing a public parameter signature algorithm, appointing a public parameter of the signature algorithm: noncestrer, openid, timeframe, token; and appointing an abstract service parameter: payload, which refers to the set of all traffic parameters; initiating an API request;
(3) according to the validity of the public parameter and the payload check request in the request, the priority of the check flow follows: parameter checking is firstly carried out, simple or complex operation is secondly carried out, and cache delay is inquired.
And ensuring that the request is not leaked even if the request is captured on the basis of Token which does not embody user login or caller certificate in the request message. And generating csrfToken by combining specific requestInfo information in the request message and the random character string, so that the purpose that the page csrfToken is random when rendered every time is achieved, and preventing CSRF safety of the browser and the server according to parameters known by only the server during verification algorithm, wherein the CSRF safety is independent of Cookie, and the CSRF safety is also suitable for popular front-end SPA schemes and compatible with SSR rendering schemes. Under the condition that the browser is communicated with a server side, parameters of anonymous requests or login user requests are guaranteed not to be tampered based on a special Openid scheme. And the request is ensured not to be replayed based on the random character string, and the problems of server side API idempotent and the like are reduced. In the http environment, a signature algorithm is provided to prevent parameters from being tampered.
Preferably, in step (1), if the caller is also the server, the method issues in advance: token ═ uuidnamespace (apid).
Preferably, in step (1), if the browser client is a csrfToken, the method returns csrfToken, and first defines the relevant specific parameters:
requestInfo＝remoteIP+URLpath+UserAgentRandomStr＝createNonceStr(timestamp)
wherein, the requestInfo is composed of related special values remoteIP and UR L path in the request information, and RandomStr is a random character string with fixed number of bits;
then in the anonymous interface request scenario:
csrfToken＝RandomStr+HASH(requestInfo+RandomStr+secret)
in the interface request scene of the login user:
csrfToken＝RandomStr+HASH(accessToken+requestInfo+RandomStr+secret)
the HASH algorithm and the secret are self-defined by a server side, and the browser client side does not know the HASH algorithm and the secret; finally, csrfToken responds to the page by requesting it.
Preferably, the csrfToken is generated and stored in the server side, and the expiration time is set
Preferably, in step (2), if the request is anonymous, openid is csrfToken; if the request is a browser login user request, the openid is equal to the user identification code openid in OAuth2.0 caller service, the appointed split character split Str is spliced, and then the csrfToken is spliced, namely: openid + splitst + csrfToken; if the caller is also the server, openid is AppID.
Preferably, in step (2), for the abstract parameter payload:
playload＝publicParamFilter(merge(req.query,req.body))
rawData＝paramsLowercaseSort(playload)
sign＝HASH(paramsLowercaseSort(nonceStr,openid,playload,timestamp,token))appendUrl＝querystring.stringify(nonceStr,openid,timestamp,sign)
the HASH algorithm is agreed by both parties and is required to be open, wherein the payload is equal to 4 common parameters filtered from merged query and body parameters, the rest are a set of payload service parameters, the rawData is equal to abstract service parameter set payload which is converted into lower words and then sorted according to initial letters, the sign signature value is equal to signature by the agreed HASH algorithm after the nonclass, openid, payload, timetag and token5 parameters are converted into lower words and then sorted according to the initial letters, and finally the apndUrl serializes the four final request common parameters and values to be added behind the request UR L in a character string form.
Preferably, in step (3), the specific operation method is as follows:
(31) common parameters in the check request: noncestrer, openid, timestamp, sign;
(32) checking a legal interval of the timestamp, and allowing the timestamp to reach a receiver in an appointed time interval;
(33) inquiring the timeliness and accuracy of token;
(34) acquiring a payload check sign;
(35) the nonceStr is checked and the query cache determines to prevent replay.
Preferably, in step (33), according to the convention in step (2), the cache is queried through openid, and the specific operation steps are as follows:
(331) if the result is AppID, the calling is performed by the server side, and the direct judgment is performed;
(332) if the result is a browser request, if the accessToken of the user cannot be found, entering csrfToken judgment logic to determine whether the accessToken is expired; the accuracy can be verified according to the csrfToken algorithm in the step (1), wherein RandomStr in the csrfToken algorithm of the receiver is not randomly generated any more but intercepts the fixed number of bits of the parameters of the request sender;
(333) if the accessToken is inquired, the request is the request of the login user, and the timeliness and the accuracy are verified in the same way;
(334) and finally, the browser request needs to verify the requestInfo parameter in the step (1) so as to achieve the effect of preventing CSRF attack.
Preferably, in step (34), the specific operation method is as follows: and (3) acquiring the payload method in step (2), then substituting the token in step (33) and the four parameters in step (31) into a signature algorithm, and comparing sign values to prevent the parameters from being tampered.
The invention has the beneficial effects that: and ensuring that the request is not leaked even if the request is captured on the basis of Token which does not embody user login or caller certificate in the request message. And generating csrfToken by combining specific requestInfo information in the request message and the random character string, so that the purpose that the page csrfToken is random when rendered every time is achieved, and preventing CSRF safety of the browser and the server according to parameters known by only the server during verification algorithm, wherein the CSRF safety is independent of Cookie, and the CSRF safety is also suitable for popular front-end SPA schemes and compatible with SSR rendering schemes. Under the condition that the browser is communicated with a server side, parameters of anonymous requests or login user requests are guaranteed not to be tampered based on a special Openid scheme. And the request is ensured not to be replayed based on the random character string, and the problems of server side API idempotent and the like are reduced. In the http environment, a signature algorithm is provided to prevent parameters from being tampered.
Drawings
FIG. 1 is a flow chart of the method of the present invention.
Detailed Description
The invention is further described with reference to the following figures and detailed description.
In the embodiment shown in fig. 1, a method for designing a web interface for preventing a request packet from being replayed by a tamper attack specifically includes the following steps:
(1) the server constructs Token by combining the specific information, and if the calling party is also the server, the Token is issued in advance; if the browser client side exists, returning to csrfToken;
if the calling party is also the server side, the method is released in advance: token ═ uuidnamespace (apid). The Token has timeliness, is associated with the calling party AppID, and is applied by the calling party at the receiving party server in advance and needs to be applied after expiration.
If the browser client side exists, returning to csrfToken, and firstly contracting relevant specific parameters:
requestInfo＝remoteIP+URLpath+UserAgentRandomStr＝createNonceStr(timestamp)
the requestInfo is composed of relevant special values remoteiP and UR L path in request information, RandomStr is a random character string with a fixed bit number, remoteiP refers to a client IP when a client and a server perform TCP handshake and is almost impossible to forge, UR L path is a path for a browser to render a current page, referrer of all requests on the page is equal to the value, RandomStr is intercepted according to the fixed bit number when a receiver authenticates, and the client does not know the fixed bit number of the server nor a generation algorithm.
Then in the anonymous interface request scenario:
csrfToken＝RandomStr+HASH(requestInfo+RandomStr+secret)
in the interface request scene of the login user:
csrfToken＝RandomStr+HASH(accessToken+requestInfo+RandomStr+secret)
the HASH algorithm and the secret are self-defined by the server side and are not known by the browser client side. Here, if the user is a login user, the csfToken generation process has one more accessToken parameter, so that the accessToken is prevented from being exposed in the browser page. Finally, csrfToken responds to the page by requesting, either a hidden element value in the page or a parameter value in a format agreed upon in response. A HASH algorithm such as sha1, or the more secure slow HASH algorithm pbkdf 2; secret is a ciphertext stored at the server; the accessoken parameter is returned after authorization by oauth2.0 login service, and similarly, the accessoken parameter also carries an expiration time when returned in oauth2.0 service.
And the generated csrfToken is stored in the server side and the expiration time is set.
(2) Appointing a public parameter signature algorithm, appointing a public parameter of the signature algorithm: noncestrer, openid, timeframe, token; and appointing an abstract service parameter: payload, which refers to the set of all traffic parameters; initiating an API request;
noncestrer: the random character string is mainly used for preventing the interface from requesting to replay by the server and is generated by a request sender; openid: the identification parameters are self-defined according to users in different scenes; timing and map: a time stamp; oken: the request between the server and the client is csrfToken and the request between the server is accessToken according to the request certificate under different scenes.
If the browser anonymous request is received, the openid is csrfToken; if the request is a browser login user request, the openid is equal to the user identification code openid (which is generated according to uuid ()) in the OAuth2.0 caller service, the appointed split character split Str is spliced and then the csrfToken is spliced, namely: openid + splitst + csrfToken; if the OAuth2.0 service is compared with a large mall, the OAuth2.0 service identifies a user by using an identity card userid, each shop (which is equivalent to a caller service) in the mall uses an openid as a membership card to distribute the user, the shops do not need to know the identity card of the user, and the mall can assist the user when authentication is needed (after the mall authentication is finished, the shops send a ticket accessToken of the user to the shops, and the shops can inquire some information of the user in the mall by the ticket and the membership card), so that openids are different among different caller services, and the real userid of the user is protected from being exposed; the UUID generation specification comprises: RFC 4122; when the character string is spliced, a convention separator can be added, such as: openid + splitStr + csrfTokrn; if the caller is also the server, openid is AppID.
For the abstract parameter payload: the payload is a plurality of service-related request parameter sets in the invention, does not contain an agreed signature algorithm public parameter, and can transmit null if not;
playload＝publicParamFilter(merge(req.query,req.body))
the method comprises the steps that in the process of obtaining the payload, parameter values of query and body in a request are combined through a merge method, then the public parameter of 4 requests in the combined and transmitted parameters is filtered by a public ParamFilter, and the remainder is the payload;
rawData＝paramsLowercaseSort(playload)
the process of obtaining rawData is a params L owerCaseShort method, which converts all parameter key names in an incoming object into small letters and key names ASCII codes for sorting and then converting into a querystring.
sign＝HASH(paramsLowercaseSort(nonceStr,openid,playload,timestamp,token))appendUrl＝querystring.stringify(nonceStr,openid,timestamp,sign)
The HASH algorithm is agreed by two parties and is required to be open, wherein, the payload is equal to 4 public parameters filtered from merged query and body parameters, the rest are a set of payload service parameters, the rawData is equal to abstract service parameter set payload which is converted into lower words and then sorted according to initial letters, the sign signature value is equal to that the noncstr, openid, payload, timetag and token 24 parameters are converted into lower words and then sorted according to the initial letters and then signed by an agreed HASH algorithm, and finally the apedUrl serializes the noncstr, openid, timetag and sign four final request public parameters and values and adds the serialized common parameters and values to the back of the request UR L in a character string mode.
(3) According to the validity of the public parameter and the payload check request in the request, the priority of the check flow follows: firstly, parameter checking, secondly, simple or complex operation, and inquiring cache delay;
the specific operation method comprises the following steps:
(31) and (3) checking common parameters in the request, namely nonces Str, openid, timestamp and sign, requesting to a receiving party service end by a sending party (a browser end or a service end), wherein the UR L has four common parameters through the description in the step (2), and if the common parameters are lacked, terminating the flow.
(32) Checking a legal interval of the timestamp, and allowing the timestamp to reach a receiver in an appointed time interval; in order to accommodate the time inconsistency between the sender and the receiver, for example: and 1 minute before and after.
(33) Inquiring the timeliness and accuracy of the token, wherein the token is a general name of csftoken or accessToken; according to the convention in the step (2), querying a cache through the openid, and separating the openid according to the convention separators: generating AppID, csrfToken and openid according to different algorithms, and setting different digits, which is beneficial to judgment; the specific operation steps are as follows:
(331) if the result is AppID, the calling is performed by the server side, and the direct judgment is performed;
(332) if the result is a browser request, if the accessToken of the user cannot be found, entering csrfToken judgment logic to determine whether the accessToken is expired; the accuracy can be verified according to the csrfToken algorithm in the step (1), wherein RandomStr in the csrfToken algorithm of the receiver is not randomly generated any more but intercepts the fixed number of bits of the parameters of the request sender; the receiver generates a fixed number of bits intercepted by the RandomStr parameter in the csrfToken algorithm to become the request csrfToken parameter, and because the algorithm and some important parameters (such as accessToken) are not exposed to the browser client, the client does not know how csrfToken is generated, and the csrfToken is just directly returned to the receiver server, once the csrfToken is tampered, the receiver generates different csrfToken according to the algorithm in the step (1), and the accuracy check is returned to fail.
(333) If the accessToken is inquired, the request is the request of the login user, and the timeliness and the accuracy are verified in the same way; whether the user logs in can be known through the session of the persistence processing; the representation of sessionid at the browser end is a cookie value of httpony.
(334) And finally, the browser request needs to verify the requestInfo parameter (refer) in the step (1) so as to achieve the effect of preventing CSRF attack.
(34) Acquiring a payload check sign; the specific operation method comprises the following steps: and (3) acquiring the payload method in step (2), then substituting the token in step (33) and the four parameters in step (31) into a signature algorithm, and comparing sign values to prevent the parameters from being tampered.
(35) Checking the noncestrer, and inquiring the cache to judge whether to prevent the replay; if the limited flow requirements are also extended. If no nonceStr value exists in the cache, recording and storing the nonceStr value, and appointing the expiration time; otherwise, the request is terminated; the effect can be achieved by using SETNX of redis. Flow limiting can be achieved using a ZADD data structure in conjunction with redis, with time as score to perform ZRANGE ordering, i.e., to simulate a leaky bucket algorithm.
And ensuring that even the request is captured, the packet cannot be leaked based on Token which does not embody user login or caller certificate in the request message, and if the request is artificially leaked, resetting is needed or safe communication can be carried out after expiration time. And generating csrfToken by combining specific requestInfo information in the request message and the random character string, so that the purpose that the page csrfToken is random when rendered every time is achieved, and preventing CSRF safety of the browser and the server according to parameters known by only the server during verification algorithm, wherein the CSRF safety is independent of Cookie, and the CSRF safety is also suitable for popular front-end SPA schemes and compatible with SSR rendering schemes. Under the condition that the browser is communicated with a server side, parameters of anonymous requests or login user requests are guaranteed not to be tampered based on a special Openid scheme. And the request is ensured not to be replayed based on the random character string, and the problems of server side API idempotent and the like are reduced. In the http environment, a signature algorithm is provided to prevent parameters from being tampered.
Claims (9)
1. A web interface design method for preventing request messages from being tampered, attacked and replayed is characterized by comprising the following steps:
(1) the server constructs Token by combining the specific information, and if the calling party is also the server, the Token is issued in advance; if the browser client side exists, returning to csrfToken;
(2) appointing a public parameter signature algorithm, appointing a public parameter of the signature algorithm: noncestrer, openid, timeframe, token; and appointing an abstract service parameter: payload, which refers to the set of all traffic parameters; initiating an API request;
(3) according to the validity of the public parameter and the payload check request in the request, the priority of the check flow follows: parameter checking is firstly carried out, simple or complex operation is secondly carried out, and cache delay is inquired.
2. The method for designing a web interface to prevent a request packet from being replayed by a tamper attack according to claim 1, wherein in step (1), if the caller is also a server, the method issues in advance: token ═ uuidnamespace (apid).
3. The method as claimed in claim 1 or 2, wherein in step (1), if the browser client is, returning csrfToken, first appointing the relevant specific parameters:
requestInfo＝remoteIP+URLpath+UserAgent
RandomStr＝createNonceStr(timestamp)
wherein, the requestInfo is composed of related special values remoteIP and UR L path in the request information, and RandomStr is a random character string with fixed number of bits;
then in the anonymous interface request scenario:
csrfToken＝RandomStr+HASH(requestInfo+RandomStr+secret)
in the interface request scene of the login user:
csrfToken ═ RandomStr + HASH (accessToken + requestInfo + RandomStr + secret) the HASH algorithm and secret are self-defined by the server side and are unknown to the browser client side; finally, csrfToken responds to the page by requesting it.
4. The method as claimed in claim 3, wherein the csrfToken is generated and stored in the server, and the expiration time is set.
5. The method as claimed in claim 3, wherein in step (2), if the request is anonymous, the openid is csrfToken; if the request is a browser login user request, the openid is equal to the user identification code openid in OAuth2.0 caller service, the appointed split character split Str is spliced, and then the csrfToken is spliced, namely: openid + splitst + csrfToken; if the caller is also the server, openid is AppID.
6. The method for designing a web interface to prevent the request packet from being replayed by a tampering attack as claimed in claim 5, wherein in step (2), for the abstract parameter payload:
playload＝publicParamFilter(merge(req.query,req.body))
rawData＝paramsLowercaseSort(playload)
sign＝HASH(paramsLowercaseSort(nonceStr,openid,playload,timestamp,token))appendUrl＝querystring.stringify(nonceStr,openid,timestamp,sign)
the HASH algorithm is agreed by both parties and is required to be open, wherein the payload is equal to 4 common parameters filtered from merged query and body parameters, the rest are a set of payload service parameters, the rawData is equal to abstract service parameter set payload which is converted into lower words and then sorted according to initial letters, the sign signature value is equal to signature by the agreed HASH algorithm after the nonclass, openid, payload, timetag and token5 parameters are converted into lower words and then sorted according to the initial letters, and finally the apndUrl serializes the four final request common parameters and values to be added behind the request UR L in a character string form.
7. The method for designing a web interface to prevent the request packet from being replayed by a tamper attack according to claim 6, wherein in the step (3), the specific operation method is as follows:
(31) common parameters in the check request: noncestrer, openid, timestamp, sign;
(32) checking a legal interval of the timestamp, and allowing the timestamp to reach a receiver in an appointed time interval;
(33) inquiring the timeliness and accuracy of token;
(34) acquiring a payload check sign;
(35) the nonceStr is checked and the query cache determines to prevent replay.
8. The method for designing a web interface to prevent replay of a request packet from a tamper attack as claimed in claim 7, wherein in step (33), according to the convention in step (2), the cache is queried through openid, and the specific operation steps are as follows:
(331) if the result is AppID, the calling is performed by the server side, and the direct judgment is performed;
(332) if the result is a browser request, if the accessToken of the user cannot be found, entering csrfToken judgment logic to determine whether the accessToken is expired; the accuracy can be verified according to the csrfToken algorithm in the step (1), wherein RandomStr in the csrfToken algorithm of the receiver is not randomly generated any more but intercepts the fixed number of bits of the parameters of the request sender;
(333) if the accessToken is inquired, the request is the request of the login user, and the timeliness and the accuracy are verified in the same way;
(334) and finally, the browser request needs to verify the requestInfo parameter in the step (1) so as to achieve the effect of preventing CSRF attack.
9. The method for designing a web interface to prevent replay of a request packet by a tamper attack as claimed in claim 7, wherein in step (34), the specific operation method is as follows: and (3) acquiring the payload method in step (2), then substituting the token in step (33) and the four parameters in step (31) into a signature algorithm, and comparing sign values to prevent the parameters from being tampered.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010209006.5A CN111447195B (en) | 2020-03-23 | 2020-03-23 | Web interface design method for preventing request message from being tampered, attacked and replayed |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010209006.5A CN111447195B (en) | 2020-03-23 | 2020-03-23 | Web interface design method for preventing request message from being tampered, attacked and replayed |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111447195A true CN111447195A (en) | 2020-07-24 |
| CN111447195B CN111447195B (en) | 2022-04-12 |
Family
ID=71649002
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010209006.5A Active CN111447195B (en) | 2020-03-23 | 2020-03-23 | Web interface design method for preventing request message from being tampered, attacked and replayed |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111447195B (en) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111935164A (en) * | 2020-08-14 | 2020-11-13 | 天元大数据信用管理有限公司 | Https interface request method |
| CN112632447A (en) * | 2021-01-13 | 2021-04-09 | 西安博达软件股份有限公司 | Website dynamic application safety protection method |
| CN112749026A (en) * | 2020-12-30 | 2021-05-04 | 金蝶软件（中国）有限公司 | API calling method and related device |
| CN113343278A (en) * | 2021-07-05 | 2021-09-03 | 湖南快乐阳光互动娱乐传媒有限公司 | Login request verification method and device for preventing CSRF attack |
| CN113872935A (en) * | 2021-08-24 | 2021-12-31 | 青岛海尔科技有限公司 | Data verification method and device, storage medium and electronic device |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120137363A1 (en) * | 2010-11-30 | 2012-05-31 | Ibm Corporation | Method and Device for Preventing CSRF Attack |
| US20130055384A1 (en) * | 2011-08-25 | 2013-02-28 | Amichai Shulman | Dealing with web attacks using cryptographically signed http cookies |
| CN108471432A (en) * | 2018-07-11 | 2018-08-31 | 北京智芯微电子科技有限公司 | Prevent web application interface by the method for malicious attack |
| CN109714370A (en) * | 2019-03-07 | 2019-05-03 | 四川长虹电器股份有限公司 | A kind of implementation method based on http protocol end Yunan County full communication |
-
2020
- 2020-03-23 CN CN202010209006.5A patent/CN111447195B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120137363A1 (en) * | 2010-11-30 | 2012-05-31 | Ibm Corporation | Method and Device for Preventing CSRF Attack |
| US20130055384A1 (en) * | 2011-08-25 | 2013-02-28 | Amichai Shulman | Dealing with web attacks using cryptographically signed http cookies |
| CN108471432A (en) * | 2018-07-11 | 2018-08-31 | 北京智芯微电子科技有限公司 | Prevent web application interface by the method for malicious attack |
| CN109714370A (en) * | 2019-03-07 | 2019-05-03 | 四川长虹电器股份有限公司 | A kind of implementation method based on http protocol end Yunan County full communication |
Non-Patent Citations (1)
| Title |
|---|
| 王应军、傅建明、姜百合: "基于随机化参数名的跨站请求伪造防御方法", 《计算机工程》 * |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111935164A (en) * | 2020-08-14 | 2020-11-13 | 天元大数据信用管理有限公司 | Https interface request method |
| CN111935164B (en) * | 2020-08-14 | 2022-11-08 | 天元大数据信用管理有限公司 | Https interface request method |
| CN112749026A (en) * | 2020-12-30 | 2021-05-04 | 金蝶软件（中国）有限公司 | API calling method and related device |
| CN112632447A (en) * | 2021-01-13 | 2021-04-09 | 西安博达软件股份有限公司 | Website dynamic application safety protection method |
| CN112632447B (en) * | 2021-01-13 | 2022-03-11 | 西安博达软件股份有限公司 | Website dynamic application safety protection method |
| CN113343278A (en) * | 2021-07-05 | 2021-09-03 | 湖南快乐阳光互动娱乐传媒有限公司 | Login request verification method and device for preventing CSRF attack |
| CN113343278B (en) * | 2021-07-05 | 2022-07-26 | 湖南快乐阳光互动娱乐传媒有限公司 | Login request verification method and device for preventing CSRF attack |
| CN113872935A (en) * | 2021-08-24 | 2021-12-31 | 青岛海尔科技有限公司 | Data verification method and device, storage medium and electronic device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111447195B (en) | 2022-04-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111447195B (en) | Web interface design method for preventing request message from being tampered, attacked and replayed | |
| US9537861B2 (en) | Method of mutual verification between a client and a server | |
| US7213149B2 (en) | Message authentication | |
| CN109714370B (en) | HTTP (hyper text transport protocol) -based cloud security communication implementation method | |
| CN113630407B (en) | Method and system for enhancing transmission security of MQTT protocol by using symmetric cryptographic technology | |
| CN113612605A (en) | Method, system and equipment for enhancing MQTT protocol identity authentication by using symmetric cryptographic technology | |
| CN111800378A (en) | Login authentication method, device, system and storage medium | |
| CN103906052A (en) | Mobile terminal authentication method, service access method and equipment | |
| Chen et al. | Security analysis and improvement of user authentication framework for cloud computing | |
| CN110020869B (en) | Method, device and system for generating block chain authorization information | |
| CN112804269B (en) | Method for realizing website interface anti-crawler | |
| CN107517194B (en) | Return source authentication method and device of content distribution network | |
| CN114513339A (en) | Security authentication method, system and device | |
| CN103546292A (en) | Third-party certification system or method with multiple identification codes | |
| CN112383401B (en) | User name generation method and system for providing identity authentication service | |
| CN115955320B (en) | Video conference identity authentication method | |
| CN112566121A (en) | Method for preventing attack, server, electronic equipment and storage medium | |
| CN112311545A (en) | Cloud MES system based transmission method for multiple encryption of user login information | |
| CN114726606B (en) | User authentication method, client, gateway and authentication server | |
| CN101425925B (en) | Method, system and apparatus for providing authentication of data communication | |
| Chatterjee et al. | A novel multi-server authentication scheme for e-commerce applications using smart card | |
| CN105681364B (en) | A kind of IPv6 mobile terminal attack resistance method based on enhancing binding | |
| CN108833452B (en) | Method for encrypting front-end and back-end separated data | |
| CN114513299B (en) | Data transmission method based on open authorization and electronic equipment | |
| CN110532741B (en) | Personal information authorization method, authentication center and service provider |
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 | ||
| CB02 | Change of applicant information | ||
| CB02 | Change of applicant information |
Address after: 22nd floor, block a, Huaxing Times Square, 478 Wensan Road, Xihu District, Hangzhou, Zhejiang 310000 Applicant after: Hangzhou Xiaoying Innovation Technology Co.,Ltd. Address before: 16 / F, HANGGANG Metallurgical Science and technology building, 294 Tianmushan Road, Xihu District, Hangzhou City, Zhejiang Province, 310012 Applicant before: HANGZHOU QUWEI SCIENCE & TECHNOLOGY Co.,Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |