CN111447195B - 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
- CN111447195B CN111447195B CN202010209006.5A CN202010209006A CN111447195B CN 111447195 B CN111447195 B CN 111447195B CN 202010209006 A CN202010209006 A CN 202010209006A CN 111447195 B CN111447195 B CN 111447195B
- Authority
- CN
- China
- Prior art keywords
- request
- openid
- server
- csrftoken
- parameters
- 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/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 (appid).
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+UserAgent
RandomStr=createNonceStr(timestamp)
wherein, the requestInfo is composed of related special values remoteiP and URLpath in the request information, and the 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 browser is requested anonymously, openid = 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 = openid + splitst + csrfToken; if the caller is also the server, openid = 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 two parties and must be published; wherein, the payload is equal to filtering out 4 public parameters from the merged query and body parameters, and the rest is a collection of payload service parameters; the rawData is equal to the abstract service parameter set payload which is converted into lower case and then sorted according to the initial; the sign signature value is equal to 5 parameters of nonces Str, openid, payload, timestamp and token which are firstly converted into lower case, then sequenced according to initial letters and signed by using a conventional hash algorithm; finally, the apppendUrl serializes the common parameters and values of the four final requests, namely the noncstr, the openid, the timetag and the sign, and appends the serialized parameters and values to the request URL in the form of character strings.
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 (appid). 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+UserAgent
RandomStr=createNonceStr(timestamp)
wherein, the requestInfo is composed of related special values remoteiP and URLpath in the request information, and the RandomStr is a random character string with fixed number of bits; remoteIP refers to the client IP when TCP handshake is performed between the client and the server, which is almost impossible to forge; URLpath is the path of the browser rendering the current page, and the referrer of all requests on the page is equal to the value; and intercepting the RandomStr according to a fixed digit when the receiver verifies, wherein the client does not know the digit fixed by the server end nor the 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; token: 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, openid = 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 agreed split character split Str is spliced and then spliced to csrfToken, namely: openid = 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 = uuidOpenid + splitStr + csrfTokrn; if the caller is also the server, openid = 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 the rawData is a params Lowercase short method, which converts all parameter key names in an incoming object into lowercase and key names ASCII (American standard code for information interchange) codes and then converts the key names 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 must be published; wherein, the payload is equal to filtering out 4 public parameters from the merged query and body parameters, and the rest is a collection of payload service parameters; the rawData is equal to the abstract service parameter set payload which is converted into lower case and then sorted according to the initial; the sign signature value is equal to 5 parameters of nonces Str, openid, payload, timestamp and token which are firstly converted into lower case, then sequenced according to initial letters and signed by using a conventional hash algorithm; finally, the apppendUrl serializes the common parameters and values of the four final requests, namely the noncstr, the openid, the timetag and the sign, and appends the serialized parameters and values to the request URL in the form of character strings. the token parameter will not be embodied in the URL and becomes the sign parameter.
(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) common parameters in the check request: noncestrer, openid, timestamp, sign; and (3) the sender (browser or server) requests the receiver server, the URL is described in the step (2), four public parameters are necessarily available, and if the URL is lacked, the flow is terminated.
(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 (5)
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, and firstly contracting relevant specific parameters:
requestInfo=remoteIP+URLpath+UserAgent
RandomStr=createNonceStr(timestamp)
wherein, the requestInfo is composed of related special values remoteiP and URLpath in the request information, and the 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 through the request;
(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; if the browser anonymous request is received, openid = 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 = openid + splitst + csrfToken; if the calling party is also the server side, openid = AppID; 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 two parties and must be published; wherein, the payload is equal to filtering out 4 public parameters from the merged query and body parameters, and the rest is a collection of payload service parameters; the rawData is equal to the abstract service parameter set payload which is converted into lower case and then sorted according to the initial; the sign signature value is equal to 5 parameters of nonces Str, openid, payload, timestamp and token which are firstly converted into lower case, then sequenced according to initial letters and signed by using a conventional hash algorithm; finally, the apppendUrl serializes the common parameters and values of the four final requests, namely the nonces, the openids, the timetags and the sign, and adds the serialized common parameters and values to the back of the request URL in a character string form;
(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) 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) checking the noncestrer, and inquiring the cache to judge whether to prevent the replay;
wherein: the requestInfo is composed of related special values remoteiP and URLpath in the request information, and the RandomStr is a random character string with fixed number of bits; remoteIP refers to the client IP when TCP handshake is performed between the client and the server; URLpath is the path of the browser rendering the current page; the noncestrer is a random character string, the parameter is mainly used for preventing the interface from requesting to replay by the server and is generated by a request sender; openid is a self-defined identification parameter according to users in different scenes; timestamp is a timestamp; the token is a self-defined request certificate under different scenes, the request between the server and the client is csftoken, and the request between the server is accessToken; secret is a ciphertext stored at the server; the payload is a plurality of request parameter sets related to the service and does not contain an agreed signature algorithm public parameter; the user agent is a character string.
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 (appid).
3. The method as claimed in claim 1, wherein the csrfToken is generated and stored in the server, and the expiration time is set.
4. The method for designing a web interface for preventing a request packet from being replayed by a tamper attack as claimed in claim 1, wherein in the step (33), according to the convention in the 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.
5. The method for designing a web interface to prevent replay of a request packet by a tamper attack as claimed in claim 1, 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 CN111447195A (en) | 2020-07-24 |
| CN111447195B true 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) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 |
| CN112632447B (en) * | 2021-01-13 | 2022-03-11 | 西安博达软件股份有限公司 | Website dynamic application safety protection method |
| 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 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102480490B (en) * | 2010-11-30 | 2014-09-24 | 国际商业机器公司 | Method for preventing CSRF attack and equipment thereof |
| US8448233B2 (en) * | 2011-08-25 | 2013-05-21 | Imperva, Inc. | Dealing with web attacks using cryptographically signed HTTP cookies |
-
2020
- 2020-03-23 CN CN202010209006.5A patent/CN111447195B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 |
|---|
| 基于随机化参数名的跨站请求伪造防御方法;王应军、傅建明、姜百合;《计算机工程》;20181130;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111447195A (en) | 2020-07-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111447195B (en) | Web interface design method for preventing request message from being tampered, attacked and replayed | |
| CN108810029B (en) | Authentication system and optimization method between micro-service architecture services | |
| US9537861B2 (en) | Method of mutual verification between a client and a server | |
| US8627424B1 (en) | Device bound OTP generation | |
| CN100512201C (en) | Method for dealing inserted-requested message of business in groups | |
| CN109714370B (en) | HTTP (hyper text transport protocol) -based cloud security communication implementation method | |
| EP2446392A1 (en) | Authentication method and system | |
| CN113067823B (en) | Mail user identity authentication and key distribution method, system, device and medium | |
| CN111800378A (en) | Login authentication method, device, system and storage medium | |
| CN112804269B (en) | Method for realizing website interface anti-crawler | |
| CN110020869B (en) | Method, device and system for generating block chain authorization information | |
| CN106452763B (en) | One kind using cipher key method by remote dummy USB device | |
| CN106789069A (en) | A kind of zero-knowledge status authentication method | |
| 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 | |
| CN112566121A (en) | Method for preventing attack, server, electronic equipment and storage medium | |
| CN115955320A (en) | Video conference identity authentication method | |
| CN111371811A (en) | Resource calling method, resource calling device, client and service server | |
| CN114726606B (en) | User authentication method, client, gateway and authentication server | |
| CN114389903A (en) | Digital identity information encryption and authentication method | |
| 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 | |
| CN116866093B (en) | Identity authentication method, identity authentication device, and readable storage medium | |
| CN110532741B (en) | Personal information authorization method, authentication center and service provider | |
| CN108833452B (en) | Method for encrypting front-end and back-end separated data |
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 |
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. |
|
| CB02 | Change of applicant information | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |