Method for realizing synchronous dynamic modification of front-end signature and back-end signature of web application

Abstract

The invention belongs to the technical field of web security, and discloses a method for realizing synchronous dynamic modification of front and rear end signatures of a web application, which comprises the following steps of: providing a function of customizing and configuring signature rules by a user, dynamically generating front end JS signature logic and rear end Java signature verification logic according to configuration, and finally packaging into a Starter conforming to Spring Boot development specifications to realize synchronous dynamic modification. According to the method, the Spring Boot Starter is introduced, the development process of signature and signature verification logic is simplified, compared with a traditional method, a developer only needs to introduce a specified JS address at the front end, the back end only needs to configure and start an anti-brushing function and add an annotation (at) AntiBrush on an interface method needing signature verification, and then the signature and signature verification functions can be automatically completed; meanwhile, the signature rule can be adjusted through the configuration page, and developers do not need to frequently modify codes, so that the development and communication cost is greatly reduced, the whole development process becomes more efficient, and modification of the signature rule becomes simpler.

Description

Technical Field

[0001] The invention belongs to the technical field of web security, and in particular is a method for realizing synchronous dynamic modification of front-end and back-end signatures of web applications. Background Art

[0002] With the development of the Internet, there are more and more web applications. In order to attract users, various companies have also launched many marketing activities on web applications. The interfaces of these marketing activities usually need to add signatures to prevent the server interfaces from being directly accessed by external programs. However, because they are web applications, all signature logic is exposed on the browser side. The signature logic is easy to be identified and simulated, thereby bypassing the server-side verification of the interface signature and performing a large number of interface accesses.

[0003] At present, when the development and maintenance personnel of web applications find this situation, they will use the signature + timestamp method to prevent the interface from being illegally accessed by external programs. The signature can verify whether the htt request is sent by a trusted client, and whether the parameters have been tampered with. The timestamp parameter can be used to prevent request replay. The server can refuse to respond to the request if it finds that the timestamp has expired. The implementation logic of the signature in the web application is on the h5 web page side, implemented by the front-end developer, and the signature verification logic is implemented by the back-end developer in the server program.

[0004] However, the development model of web applications is usually separated from the front-end and back-end, which requires the front-end developers and back-end developers to unify the logic of signing and verifying signatures in order to complete the signing and verification process of the entire web application interface. The process is lengthy and the communication cost is high, so the development efficiency is low. This method is even more clumsy when it is found that an external program has begun to make a large number of illegal requests to the application interface. Moreover, when the signature logic is developed and the application is released, even if the front-end and back-end are released at the same time, some normal users' interface requests may be accidentally damaged, because the signature verification logic takes effect after the back-end releases the service, and the user may not refresh the front-end page, and the new signature logic is not executed on the h5 web page. This causes the server to fail to verify the signature and reject the legitimate requests of some users. Summary of the invention

[0005] The purpose of the present invention is to provide a method for realizing synchronous dynamic modification of front-end and back-end signatures of web applications, so as to solve the problems raised in the above-mentioned background technology.

[0006] In order to achieve the above-mentioned purpose, the present invention provides the following technical solutions: a method for realizing synchronous dynamic modification of front-end and back-end signatures of web applications, which provides the function of user-defined configuration of signature rules, and dynamically generates front-end JS signature logic and back-end Java signature verification logic according to the configuration, and finally encapsulates them into a Starter that complies with the Spring Boot development specification to realize synchronous dynamic modification, and the method of using the Starter is as follows:

[0007] A1. Import the Starter dependency package into the application and start it. Then enter the logic configuration page from the browser and configure the parameters on the page.

[0008] A2, click the Verify button, the program will automatically generate the signature js through freemarker and template code according to the configuration rules;

[0009] A3, the program generates a server-side signature verification proxy object based on cglib according to the configuration rules;

[0010] A4, the program dynamically calls the signature js script to sign the preset parameter case, and uses the signature verification proxy object to verify the signature; A5, after the verification passes, a self-incrementing signature rule version id is generated and saved together with the verification rule;

[0011] A6, Save the configuration, configure Redis related configuration in the configuration file, or store the configuration rules in the MySQL relational database through custom storage.

[0012] Preferably, the Starter dependency package consists of a configuration file attribute module, a custom annotation module, a signature rule configuration module, a front-end signature js file module, a back-end signature verification java method generation module, a front-end request interception module, and a back-end request interception module;

[0013] Among them, the configuration file property module can enable the signature anti-brush function by setting the auto.anti.brush.enabled property in the Spring Boot configuration file. When this property is configured to true, SpringBoot will automatically initialize the anti-brush component and load the latest signature rules when the application starts.

[0014] Preferably, the custom annotation module marks the @AntiBrush annotation on the interface in the Controller to indicate that the interface enables the signature anti-brush function of this Starter.

[0015] Preferably, when the application introduces the Starter and configures auto.anti.brush.enabled to true, the developer can access a signature rule configuration page through the signature rule configuration module, on which the developer can configure the order of signature parameters, specify which parameters participate in signature calculation and which parameters do not participate in signature, and set the salt parameters used.

[0016] Preferably, the front-end signature js file module dynamically generates the signature JS file required by the front-end according to the signature rules through the Freemarker template engine, thereby ensuring that after each signature rule configuration change, the generated signature JS always remains consistent with the latest signature rules.

[0017] Preferably, the generation module of the backend signature verification java method generates a dynamic proxy object of the backend signature verification logic according to the signature rules by using CGLIB.

[0018] Preferably, the front-end request interception module intercepts the front-end request based on jQuery's ajax request interceptor, and the back-end request interception module performs signature verification on the front-end request based on springboot interceptor technology.

[0019] Preferably, the implementation process of the signature logic release of the method in real time is:

[0020] B1, introduce the dynamic js address in the front-end page of the web application, and after the jar package intercepts the front-end request, go to the storage layer to request the signature configuration rule;

[0021] B2, after requesting the signature rules, generates a signature js script that complies with the signature based on freemarker and returns it to the client;

[0022] B3, dynamically inject the signature version autoSignVersion and signature salt autoSignSalt. At this time, autoSignVersion is the self-incrementing version number of the signature configuration generated when the signature rule is configured in the background, and autoSignSalt is the salt value configured in the background of the signature rule configuration;

[0023] B4, when the client operation generates an interface request, the signature js will process the request parameters based on the jquery.ajax request interceptor;

[0024] B5, when the request reaches the server, the interceptor AntiBrushInterceptor is triggered. The interceptor first determines whether the controller method that processes the request has the annotation @AntiBrush. If there is no annotation, no processing is performed, true is returned, and the business code is continued to be executed. If there is an annotation, the signature verification logic step is entered;

[0025] B6, according to the client's autoSignVersion parameter, obtain the signature verification proxy object from the cache. If the acquisition is successful, use the proxy object to verify the signature. If the acquisition fails, query the signature rules from the storage layer through autoSignVersion, and then generate a new proxy object of the autoSignVersion version according to the requested signature rules for signature verification;

[0026] B7, when the verification is passed, no business processing is performed and a failure prompt is returned. When the verification is passed, the next step of real business processing is performed;

[0027] B8, business processing is completed and the processing result is returned to the client.

[0028] Preferably, the Starter dependency package also provides an ISignRuleConfigService interface, allowing developers to customize the storage and query methods of signature rules.

[0029] The beneficial effects of the present invention are as follows:

[0030] 1. The present invention simplifies the development process of signature and verification logic by introducing Spring Boot Starter. Compared with the traditional method, developers only need to introduce the specified JS address on the front end, and the back end only needs to configure the anti-brush function and add the annotation @AntiBrush to the interface method that needs to be verified. The signature and verification functions can be automatically completed. At the same time, the signature rules can be adjusted through the configuration page. Developers do not need to modify the code frequently, which greatly reduces the development and communication costs, makes the entire development process more efficient, and simplifies the modification of signature rules.

[0031] 2. The present invention verifies the signature rules through the Starter dependency package, so that developers can automatically verify whether the signature and verification logic are normal by clicking a button, avoiding tedious manual testing. At the same time, when publishing, the signature rule configuration can be completed and published with one click, and the front-end and back-end configurations take effect immediately, avoiding delays and errors in the publishing process. Finally, by introducing the signature version number mechanism, even if the front-end signature JS has been cached, the back-end can ensure that the correct signature rules are used for verification through the version number, thereby avoiding accidental harm to legitimate users.

[0032] 3. The present invention provides a dynamic signature rule configuration page, so that developers can quickly adjust the signature rules when illegal requests are found, and immediately publish them to take effect. This flexible configuration method allows developers to quickly respond to security threats and prevent illegal requests from continuing to attack. At the same time, the signature version number mechanism ensures that even if the signature rules change, the front end can still use the correct signature method to make requests, avoiding signature verification failures or accidental injuries to legitimate users due to front-end cache problems. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 This is the functional framework diagram of the Starter dependency package of the present invention;

[0034] Figure 2 A flow chart for configuring the signature rules of the present invention;

[0035] Figure 3 A timing diagram for configuring the signature rule of the present invention;

[0036] Figure 4 This is a diagram showing the implementation of dynamic modification of signature rules of the present invention. DETAILED DESCRIPTION

[0037] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0038] like Figures 1 to 4 As shown, the embodiment of the present invention provides a method for realizing synchronous dynamic modification of front-end and back-end signatures of web applications. The method provides the function of user-defined configuration of signature rules, and dynamically generates front-end JS signature logic and back-end Java signature verification logic according to the configuration (the generation process is implemented based on CGLib and Freemarker). Finally, it is encapsulated as a Starter that complies with the Spring Boot development specification to realize synchronous dynamic modification, and the method of using the Starter is as follows:

[0039] A1. Import the Starter dependency package into the application and start it. Then enter the logic configuration page from the browser and configure the parameters on the page (signature order, which parameters are not included in the signature, input signature salt, etc.);

[0040] A2, click the Verify button, the program will automatically generate the signature js through freemarker and template code according to the configuration rules;

[0041] A3, the program generates a server-side signature verification proxy object based on cglib according to the configuration rules;

[0042] A4, the program dynamically calls the signature js script to sign the preset parameter case, and uses the signature verification proxy object to verify the signature; if the signature verification fails, it means there is a problem with the logic, and a prompt will be given on the configuration page;

[0043] A5, after verification is passed, a self-incrementing signature rule version id is generated and saved together with the verification rule;

[0044] A6, Save the configuration (by default, the configuration is stored in redis). Configure the redis-related configuration in the configuration file. You can also store the configuration rules in a relational database such as MySQL through custom storage. This custom storage is based on the java spi mechanism, which requires developers to implement the defined rule storage and query interface and perform spi configuration.

[0045] By introducing Spring Boot Starter, the development process of signature and verification logic is simplified. Compared with the traditional method, developers only need to introduce the specified JS address on the front end, and the back end only needs to enable the anti-brush function and add the annotation @AntiBrush to the interface method that needs to be verified. The signature and verification functions can be automatically completed. At the same time, the signature rules can be adjusted through the configuration page. Developers do not need to modify the code frequently, which greatly reduces the development and communication costs, makes the entire development process more efficient, and simplifies the modification of signature rules.

[0046] The Starter dependency package consists of a configuration file property module, a custom annotation module, a signature rule configuration module, a front-end signature js file module, a back-end signature verification java method generation module, a front-end request interception module, and a back-end request interception module.

[0047] Among them, the configuration file property module can enable the signature anti-brush function by setting the auto.anti.brush.enabled property in the Spring Boot configuration file. When this property is configured to true, SpringBoot will automatically initialize the anti-brush component and load the latest signature rules when the application starts.

[0048] At this point, the system can automatically identify and apply the currently valid signature rules without the need for manual intervention.

[0049] Signature rule configuration module: If the application introduces this Starter and configures auto.anti.brush.enabled to true, the developer will be able to access a signature rule configuration page, where the developer can configure the order of signature parameters, specify which parameters participate in signature calculation and which parameters do not participate in signature calculation, and set the salt parameters used previously;

[0050] After the configuration is completed, you can click Publish. At this time, after publishing, the front-end signature logic and the back-end signature verification logic will change at the same time.

[0051] The signature rules are verified through the Starter dependency package, so that developers can automatically verify whether the signature and verification logic are normal by clicking a button, avoiding tedious manual testing. At the same time, when publishing, the signature rules can be published with one click after configuration is completed, and the front-end and back-end configurations take effect immediately, avoiding delays and errors in the publishing process. Finally, by introducing the signature version number mechanism, even if the front-end signature JS has been cached, the back-end can ensure that the correct signature rules are used for verification through the version number, thereby avoiding accidental harm to legitimate users.

[0052] The custom annotation module marks the @AntiBrush annotation on the interface in the Controller to indicate that the interface enables the signature anti-brush function of this Starter.

[0053] When the @AntiBrush annotation is applied to an interface method, the system will automatically use the signature verification logic in Starter to verify the signature of the interface request. Developers only need to add annotations to the method and no longer need to manually write the signature verification logic.

[0054] Among them, when the application introduces the Starter and configures auto.anti.brush.enabled to true, the developer can access a signature rule configuration page through the signature rule configuration module. On this page, the developer can configure the order of signature parameters, specify which parameters participate in signature calculation and which parameters do not participate in signature calculation, and set the salt parameters used.

[0055] After the configuration is completed, you can click Publish. At this time, after publishing, the front-end signature logic and the back-end signature verification logic will change at the same time.

[0056] Among them, the front-end signature js file module uses the Freemarker template engine to dynamically generate the signature JS file required by the front-end according to the signature rules, thereby ensuring that after each signature rule configuration change, the generated signature JS always maintains consistency with the latest signature rules. Avoid the problem of version asynchrony caused by hard-coded fixed signature logic;

[0057] The specific freemarker template is as follows:

[0058]

[0059]

[0060]

[0061] Among them, the generation module of the back-end signature verification java method uses CGLIB to generate a dynamic proxy object of the back-end signature verification logic according to the signature rules.

[0062] Through CGLIB, the backend can generate the corresponding signature verification proxy object to perform signature verification based on the signature information sent by the frontend at runtime, thereby realizing flexible and dynamic signature verification functions.

[0063] Among them, the front-end request interception module intercepts the front-end request based on jQuery's ajax request interceptor. Before the request is sent, the interceptor will process the request parameters, automatically calculate the signature and add it to the request parameters. In addition, a timestamp and signature version number parameter will be added to the request to ensure that each request can carry a valid signature and version information; the back-end request interception module performs signature verification on the front-end request based on the springboot interceptor technology. Before the request reaches the back-end Controller, the Spring Boot interceptor will intercept all methods annotated with @AntiBrush to verify whether the requested signature is valid. The interceptor dynamically loads the corresponding version of the signature rule according to the autoSignVersion parameter in the request and performs signature verification. If the signature verification fails, the system will reject the request and return an error prompt; if the signature verification passes, the back-end business logic will continue to execute.

[0064] The implementation process of the signature logic release of this method to take effect in real time is as follows:

[0065] B1, introduce the dynamic js address in the front-end page of the web application, and after the jar package intercepts the front-end request, go to the storage layer to request the signature configuration rule;

[0066] B2, after requesting the signature rules, generate a signature js script that complies with the signature based on freemarker and return it to the client; this js script dynamically generates the core logic of the signature method (according to the parameter signature sequence configured in the background, excluding parameters that do not participate in the signature);

[0067] B3, dynamically inject the signature version autoSignVersion and signature salt autoSignSalt. At this time, autoSignVersion is the self-incrementing version number of the signature configuration generated when the signature rule is configured in the background, and autoSignSalt is the salt value configured in the background of the signature rule configuration;

[0068] B4, when the client operation generates an interface request, the signature js will process the request parameters based on the jquery.ajax request interceptor;

[0069] The specific processing is as follows: the timestamp parameter is added to the parameter, and its value is the current timestamp of the client; the autoSignVersion parameter is added to the signature version, and its value is the version number generated when the signature rule is configured in the background; the autoSign parameter is added, and its value is the value calculated by calling the signature js signature method;

[0070] B5, when the request reaches the server, the interceptor AntiBrushInterceptor is triggered. The interceptor first determines whether the controller method that processes the request has the annotation @AntiBrush. If there is no annotation, no processing is performed, true is returned, and the business code is continued to be executed. If there is an annotation, the signature verification logic step is entered;

[0071] B6, according to the client's autoSignVersion parameter, obtain the signature verification proxy object from the cache. If the acquisition is successful, use the proxy object to verify the signature. If the acquisition fails, query the signature rules from the storage layer through autoSignVersion, and then generate a new proxy object of the autoSignVersion version according to the requested signature rules for signature verification;

[0072] B7, when the verification is passed, no business processing is performed and a failure prompt is returned. When the verification is passed, the next step of real business processing is performed;

[0073] B8, business processing is completed and the processing result is returned to the client.

[0074] By providing a dynamic signature rule configuration page, developers can quickly adjust the signature rules when illegal requests are found and publish them immediately. This flexible configuration method allows developers to quickly respond to security threats and prevent illegal requests from continuing to attack. At the same time, the signature version number mechanism ensures that even if the signature rules change, the front end can still use the correct signature method to make requests, avoiding signature verification failures or accidental damage to legitimate users due to front-end cache problems.

[0075] The Starter dependency package also provides the ISignRuleConfigService interface, allowing developers to customize the storage and query methods of signature rules.

[0076] This interface can be used in three ways:

[0077]

[0078] After introducing this starter, developers can implement the interface by themselves and add the spring annotation @Service to the implementation class. When the spring container is started, the class will be automatically instantiated and managed by the spring container. When the starter saves or queries signature rules in the configuration background, it will first search for an instance of ISignRuleConfigService in the spring container. If so, it will call the instance method to save and query the signature rule configuration.

[0079] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0080] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for implementing synchronous dynamic modification of front-end and back-end signatures of a web application, characterized in that: This method configures the function of user-defined configuration signature rules, and dynamically generates front-end JS signature logic and back-end Java signature verification logic according to the configuration. It is finally encapsulated as a Starter that complies with the Spring Boot development specification to achieve synchronous dynamic modification. The usage of the Starter is: A1. Import the Starter dependency package into the application and start it. Then enter the logic configuration page from the browser and configure the parameters on the page. A2, click the Verify button, the program will automatically generate the signature js through freemarker and template code according to the configuration rules; A3, the program generates a server-side signature verification proxy object based on cglib according to the configuration rules; A4, the program dynamically calls the signature js script to sign the preset parameter case, and uses the signature verification proxy object to verify the signature; A5, after verification is passed, a self-incrementing signature rule version id is generated and saved together with the verification rule; A6, Save the configuration, configure Redis related configuration in the configuration file, or store the configuration rules in the MySQL relational database through custom storage.

2. A method for implementing synchronous dynamic modification of front-end and back-end signatures of a web application according to claim 1, characterized in that: The Starter dependency package consists of a configuration file attribute module, a custom annotation module, a signature rule configuration module, a front-end signature js file module, a back-end signature verification java method generation module, a front-end request interception module, and a back-end request interception module; Among them, the configuration file property module can enable the signature anti-brush function by setting the auto.anti.brush.enabled property in the Spring Boot configuration file. When this property is configured to true, SpringBoot will automatically initialize the anti-brush component and load the latest signature rules when the application starts.

3. A method for implementing synchronous dynamic modification of front-end and back-end signatures of a web application according to claim 2, characterized in that: The custom annotation module marks the @AntiBrush annotation on the interface in the Controller to indicate that the interface enables the signature anti-brush function of this Starter.

4. A method for implementing synchronous dynamic modification of front-end and back-end signatures of a web application according to claim 2, characterized in that: When the application introduces the Starter and configures auto.anti.brush.enabled to true, developers can access a signature rule configuration page through the signature rule configuration module. On this page, developers can configure the order of signature parameters, specify which parameters participate in signature calculation and which parameters do not participate in signature calculation, and set the salt parameters used.

5. A method for implementing synchronous dynamic modification of front-end and back-end signatures of a web application according to claim 1, characterized in that: The front-end signature js file module dynamically generates the signature JS file required by the front-end according to the signature rules through the Freemarker template engine, thereby ensuring that after each signature rule configuration change, the generated signature JS always remains consistent with the latest signature rules.

6. A method for implementing synchronous dynamic modification of front-end and back-end signatures of a web application according to claim 2, characterized in that: The generation module of the backend signature verification java method generates a dynamic proxy object of the backend signature verification logic according to the signature rules by using CGLIB.

7. A method for implementing synchronous dynamic modification of front-end and back-end signatures of a web application according to claim 2, characterized in that: The front-end request interception module intercepts the front-end request based on jQuery's ajax request interceptor, and the back-end request interception module performs signature verification on the front-end request based on springboot interceptor technology.

8. A method for implementing synchronous dynamic modification of front-end and back-end signatures of a web application according to claim 1, characterized in that: The implementation process of the signature logic release of this method to take effect in real time is as follows: B1, introduce the dynamic js address in the front-end page of the web application, and after the jar package intercepts the front-end request, go to the storage layer to request the signature configuration rule; B2, after requesting the signature rules, generates a signature js script that complies with the signature based on freemarker and returns it to the client; B3, dynamically inject the signature version autoSignVersion and signature salt autoSignSalt. At this time, autoSignVersion is the self-incrementing version number of the signature configuration generated when the signature rule is configured in the background, and autoSignSalt is the salt value configured in the background of the signature rule configuration; B4, when the client operation generates an interface request, the signature js will process the request parameters based on the jquery.ajax request interceptor; B5, when the request reaches the server, the interceptor AntiBrushInterceptor is triggered. The interceptor first determines whether the controller method that processes the request has the annotation @AntiBrush. If there is no annotation, no processing is performed, true is returned, and the business code is continued to be executed. If there is an annotation, the signature verification logic step is entered; B6, according to the client's autoSignVersion parameter, obtain the signature verification proxy object from the cache. If the acquisition is successful, use the proxy object to verify the signature. If the acquisition fails, query the signature rules from the storage layer through autoSignVersion, and then generate a new proxy object of the autoSignVersion version according to the requested signature rules for signature verification; B7, when the verification is passed, no business processing is performed and a failure prompt is returned. When the verification is passed, the next step of real business processing is performed; B8, business processing is completed and the processing result is returned to the client.

9. A method for implementing synchronous dynamic modification of front-end and back-end signatures of a web application according to claim 1, characterized in that: The Starter dependency package also provides the ISignRuleConfigService interface, allowing developers to customize the storage and query methods of signature rules.

Images