Prevent the interface access process from requesting replay attacks

Replay attacks, similar to repeated submissions of WEB forms, interface visitors use the same message body to constantly access the interface provider's process, resulting in increased pressure on the interface provider or even server failure, data loss and so on.

The general practice of preventing replay attacks is for the requester and provider to contract a unique TID, which therequester carries with this ID, and theprovider check ID. A few common practices:

1.the requesting party requests a unique TID from the provider each time

Working process:

• Requesting party to apply for TID
• Carry this TID when requesting the server
• The provider has authenticated the TID and, through it, continues to

This method is simple, but the interaction times need to double, and the Tid volume will be very large, the management of Tid has problems.

2.generate a unique TID from the client , such as using the UUID generation method

The provider determines if the UUID has been used, or if it has not been used, the decision can continue, otherwise interrupt processing

This approach is simpler, but how the service provider saves so many UUID is a serious challenge.

China Mobile M- currency system is the use of this method of construction, the processing capacity can only hehe.

3.apply for key key and add only Sequence solution

Principle

• Each requestor's machine and even each process distributes a unique Clientcode
• Request Direction service provider to request a key, the service provider retains Clientcode,key correspondence, and the default corresponding serverseq=1
• Add authcode=AES(clientcode+clientseq, KEY) and Clientcode two in the HTTP header of the requester provider HTTP Header
• The service provider receives a request to Locate the Clientcode, key, and serverseq combinations of server-side storage based on Clientcode , using key for authcode decryption, compare to clientseq=serverseq+1, if satisfied, then verify success, continue processing, otherwise interrupt

Advantage, one request, multiple visits, safe and effective.

Requester multithreading / thread pool processing:

Create a simple clientcodepool, cache all the Clientcode and states, pseudo code as follows:

Class Clientcodepool {

Set<clientcode> Clientcodes;

Clientcode Getfreeclientcode ();

Void Releaseclientcode (Clientcode)

Void Applynewclientcode ()

Class clientcode{

String Clientcode;

String Key

Long Clientseq

Boolean Isfree

}

}

Whichever thread requires Clientcode to be fetched from the pool , after the server returns,release this clientcode, before returning to the application, Clientcode. Isfree=false , clientcode after release . Isfree=true

The provider also has some common data issues, preferably using Zookeeper Unified Storage, of course, if the requirements are not high, using Redis is also OK, after all, both the checksum failed, the client re-apply once Clientcode key .

Prevent the interface access process from requesting replay attacks