A low-invasive web system application layer security encryption transmission method based on request response preprocessing

Abstract

The application discloses a low-invasion web system application layer security encryption transmission method based on request response preprocessing, first generates a key for symmetric encryption, sets confusion and signature algorithms, performs confusion signature and encryption on a request body in a browser end, performs data transmission, decrypts the request body in a server end, performs signature and replay check on the decrypted request body plaintext, and performs confusion signature and encryption on response content according to the set confusion and signature algorithms, and decrypts and performs signature check on the response content in the browser end. The scheme uses the request response preprocessing idea, encrypts and signs the application layer transmission data at each link, solves the security problem of the web system application layer transmission in a low-invasion manner, reduces the risk of the application layer attack and improves the difficulty of the attacker to excavate system vulnerabilities at a low cost and a small influence, and guarantees stable and safe operation of the web system.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of information technology and software development, and specifically relates to a low-invasive web system application layer security encryption transmission method based on request response preprocessing. BACKGROUND

[0002] In today's highly interconnected digital age, web applications have become the main carrier of information exchange and service provision. However, this has brought serious challenges to the security of web systems, especially in scenarios involving the transmission of sensitive information (such as user credentials, personal privacy, financial data, business secrets, etc.) and the protection of web system server vulnerabilities.

[0003] Traditional end-to-end encryption schemes, such as the widely used HTTPS (based on TLS / SSL) protocol, provide basic confidentiality and integrity protection for web communication by establishing a secure channel at the transmission layer, and have become the cornerstone of Internet security. However, the HTTPS protocol mainly acts on the transmission layer and cannot effectively prevent application layer attacks. Attackers can intercept and tamper with the request body and response content (i.e., the content of application layer data transmission) at the application layer, exploit potential vulnerabilities in web systems, and further penetrate them, thereby obtaining sensitive data or even control of the system and server.

[0004] Therefore, we urgently need a data transmission encryption method that can act on the application layer and ensure security, increase the difficulty of tampering with the request body and response content by attackers, and reduce the possibility of web system vulnerabilities being exploited. At the same time, this method has low invasiveness to existing web systems of various types and has certain universality, which can be quickly deployed and put into operation on various web systems based on browser interaction with low cost, and improve the security protection capability of web systems. SUMMARY

[0005] In view of the fact that the HTTPS protocol cannot guarantee the security of the application layer transmission, and at present, attackers often intercept and tamper with the application layer request body and response content (i.e. the content of the application layer data transmission), and exploit and further attack the web system vulnerabilities, the purpose of the present application is to provide a low-invasive web system application layer security encryption transmission method based on request response preprocessing, which uses a general preprocessing method to encrypt and sign the data transmission before it enters the application layer; after the transmission is completed, the system server and the local browser are checked and decrypted. In the whole transmission process, the data exists in the form of encryption, and it is difficult to be tampered with or replayed, which can greatly improve the data transmission security of the web system application layer and reduce the possibility of exploiting vulnerabilities. The preprocessing process acts as an independent and general component on the four links of browser request initiation, server request data reception, server response data return and browser response data reception, and has less relevance with the business logic and implementation technology of the web system itself, and has low invasiveness to the system itself, so it can be quickly put into operation at low cost.

[0006] The specific technical solution for achieving the purpose of the present application is:

[0007] A low-invasive web system application layer security encryption transmission method based on request response preprocessing, comprising the following steps:

[0008] Step 1, generating a key for symmetric encryption for the web system, and setting a confusion and signature algorithm;

[0009] Step 2, intercepting all request initiations in the browser end, and using the set confusion and signature algorithm to confuse, sign and encrypt the request body for data transmission;

[0010] Step 3, intercepting the received request body on the server side, decrypting the request body, and signing and replaying the decrypted request body plaintext;

[0011] Step 4, intercepting all response contents that need to be transmitted to the browser on the server side, and setting the confusion and signature algorithm to confuse, sign and encrypt the response contents;

[0012] Step 5, intercepting all received server response data in the browser end, and decrypting and signing the response contents.

[0013] Compared with the prior art, the present application has the following advantages:

[0014] The scheme of the application uses the request response preprocessing idea, encrypts and signs the data transmitted in the application layer at four general links of browser request initiation, server request data reception, server response data return and browser response data reception, solves the security problem of the application layer transmission of the Web system in a low-invasion manner, and is applicable to the Web system under different technical architectures, business models and application scenarios. Finally, the risk of attack on the application layer is reduced, the difficulty of attackers to exploit system vulnerabilities is improved, and the stable and safe operation of the Web system is ensured at a low cost and with a small impact.

[0015] The application will be further described below in combination with the specific embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 The figure is a flowchart of the low-invasion Web system application layer security encryption transmission method based on request response preprocessing of the application.

[0017] Figure 2 The figure is a flowchart of the embodiment of the application. DETAILED DESCRIPTION

[0018] EMBODIMENT

[0019] The technical solutions in the embodiments of the application will be clearly and completely described below in combination with the drawings in the embodiments of the application. The described embodiments are only some of the embodiments of the application, rather than all the embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative work under the premise that no exception is explicitly prompted by the context, belong to the protection scope of the application.

[0020] As shown in the application and claims, unless the context clearly indicates otherwise, the words “one”, “a”, “an” and / or “the” do not refer to the singular, but also include the plural. Generally, the terms “comprise” and “include” only indicate the inclusion of the steps and elements explicitly identified, and these steps and elements do not constitute an exclusive list, and the method or device can also include other steps or elements.

[0021] The relative arrangement of parts and steps, numerical expressions, and numerical values set forth in the examples herein are not meant to limit the scope of the present application unless otherwise specifically stated. Also, it is to be understood that the dimensions of the various parts shown in the drawings are not drawn to scale for the sake of convenience. Techniques, methods, and equipment known to those of ordinary skill are not discussed in detail because such techniques, methods, and equipment are considered to be part of the patent specification. In all examples shown and discussed herein, any specific value is to be interpreted as merely exemplary and not as a limitation. Thus, other examples of the exemplary embodiments can have different values. It is to be noted that like numbers and letters refer to like elements throughout the several views of the drawings, and that the use of or reference to certain terms in various places of the specification and claims does not exclude them from use in other contexts.

[0022] In conjunction Figure 1 , a low-invasive web system application layer security encryption transmission method based on request response preprocessing includes the following steps:

[0023] Step 1, generate a key for symmetric encryption for the Web system, and set the obfuscation and signature algorithm;

[0024] Considering that the encryption key and the signature salt value will be stored in the code on the browser side, the code needs to be obfuscated and encrypted to avoid the key and salt value being easily obtained. At the same time, it can be considered to replace the key and signature salt value regularly, for example: replace it every time the version is updated; generate and replace it randomly after each user login (the key and encryption salt value are still transmitted to the browser side in a secure encryption transmission manner, and the browser side receives the new key and salt value and decrypts and verifies the signature to pass, and then replaces the existing key and salt value).

[0025] Step 2, intercept all request initiations in the browser side, and use the set obfuscation and signature algorithm to obfuscate and sign the request body and encrypt the data transmission:

[0026] Step 2-1, obfuscate the request body plaintext: generate a random salt value composed of characters and special characters, and use the salt value to obfuscate the plaintext through an obfuscation algorithm:

[0027] ;

[0028] ;

[0029] wherein, represents the i-th character of the plaintext, represents the i-th character of the generated random salt value S, ​represents the request body plaintext after being confused by a random salt value, || represents the string concatenation operation, and N represents the number of characters of the plaintext, represents the request body plaintext after being confused by a random salt value; m represents the number of characters of the random salt value S, which is 32 bits in this embodiment, represents the use of modulo operation to cyclically obtain the index from the salt value of length m;

[0030] Step 2-2, signing and encrypting the request body plaintext:

[0031] A certain number of millisecond-level timestamps and a certain number of random numbers are obtained to form a request unique identifier, which is added to the request header; the request unique identifier is also concatenated to the front of the unconfused plaintext to obtain a to-be-signed plaintext, and a signature algorithm is used to sign the to-be-signed plaintext to obtain a request signature result, and the request signature result is added to the request header;

[0032] For example, in this embodiment, a current 13-bit millisecond-level timestamp and a 6-bit random number are obtained, concatenated into 19 bits as a request unique identifier, concatenated to the front of the unconfused plaintext to obtain a to-be-signed plaintext, and a SHA256 or other similar signature algorithm is used to sign the to-be-signed plaintext to obtain a 32-byte signature result;

[0033] .

[0034] Step 2-3, obtaining the request body ciphertext to be transmitted by using the symmetric encryption key:

[0035] The request unique identifier and the confused request body plaintext are concatenated, and symmetric encryption is performed by using the symmetric encryption key to obtain the request body ciphertext to be transmitted;

[0036] The request header and the request body ciphertext are transmitted to the server side.

[0037] Step 3, the server side intercepts the received request body, decrypts the request body, and performs signature and replay verification on the decrypted request body plaintext:

[0038] Step 3-1, decrypting the received request body by using the symmetric encryption key:

[0039] Step 3-2, if the decryption is successful, the decrypted request body plaintext is signed and request replay verification is performed, and the request body plaintext information that passes the verification is passed to the subsequent business code; if the decryption fails, the request body is regarded as an invalid request, and the request body information, including the operator, the source IP, the request body message, and the source device information, is recorded for attack tracing;

[0040] Step 3-2-1, compare the request unique identifier in the decrypted request body plaintext with the request unique identifier in the request header. If they are not consistent, it is considered an invalid request, and the source information is recorded.

[0041] Determine whether the request unique identifier has been recorded within a certain time, for example, 10 minutes. If so, it is considered an invalid request, and the source information is recorded.

[0042] Compare the timestamp in the request unique identifier with the current time. If the difference exceeds a certain time, for example, 2 minutes, it is considered an invalid request, and the source information is recorded.

[0043] Step 3-2-2, after removing the request unique identifier from the decrypted request body plaintext, divide it into an array according to the number of double characters. If the division fails, it is considered an invalid request, and the source information is recorded. Specifically, when the plaintext is obfuscated, a confusion character is concatenated after each character, so the number of characters in the obfuscated plaintext is definitely even. In specific cases, the attacker may have obtained the key and simulated an attack request, but did not follow the rules for obfuscation, which may result in illegal obfuscated plaintext.

[0044] Step 3-2-3, according to the set obfuscation algorithm, the characters in the array are de-obfuscated, and the salt value characters used for obfuscation are separated from the array. The length of the separated salt value may be less than the original salt value, so the separated salt value characters are completely matched with the original salt value in terms of character order and character content (the character order and content must be consistent, and the length does not require consistency). If the match fails, it is considered an invalid request, and the source information is recorded.

[0045] After the salt value is completely matched, the plaintext characters of each array element are obtained, and the unobfuscated plaintext is reconstructed by concatenating them.

[0046] Step 3-2-4, concatenate the request unique identifier in the request header with the unobfuscated plaintext obtained in step 3-2-3, and use a signature algorithm such as SHA256 to sign it. Compare the calculated signature result with the signature result in the request header. If they are not consistent, it is considered an invalid request, and the source information is recorded.

[0047] Step 3-2-5, pass the plaintext information that has passed the above verification to the subsequent business code, and record the request unique identifier.

[0048] Step 4, intercept all response content that needs to be transmitted to the browser on the server side, and set the obfuscation and signature algorithm response content for obfuscation, signature, and encryption:

[0049] Step 4-1, obfuscate the plaintext of the response content: generate a random salt value composed of special characters, and use the salt value to obfuscate the plaintext through an obfuscation algorithm:

[0050] ;

[0051] ;

[0052] wherein, represents the i-th character of the plaintext, represents the i-th character of the generated random salt value S, represents the i-th character of the request body plaintext after being confused by the random salt value, represents the request body plaintext after being confused by the random salt value; m represents the number of characters of the random salt value S, represents the request body plaintext after being confused by the random salt value; m represents the number of characters of the random salt value S, represents the use of modulo to realize the cyclic acquisition of the index from the salt value of length m;

[0053] Step 4-2, signing and encrypting the plaintext of the response content:

[0054] Obtain the current time stamp of a certain number of bits and the random number of a certain number of bits to form the request unique identifier, splice to the front of the unconfused plaintext to obtain the plaintext to be signed, and use the signature algorithm to sign the plaintext to be signed;

[0055] Step 4-3, using the symmetric encryption key to obtain the request body ciphertext to be transmitted:

[0056] The confused response content plaintext is symmetrically encrypted using the symmetric encryption key to obtain the response content ciphertext to be transmitted.

[0057] Step 5, intercept all received response data of the server on the browser side, and decrypt and sign the response content:

[0058] Step 5-1, using the symmetric encryption key to decrypt the received response content:

[0059] Step 5-2, if the decryption is successful, the decrypted response content plaintext is signed and the request replay is checked, if the decryption fails or the signature fails, the original response content is directly returned, at this time the original response content refers to: no longer attempt decryption and subsequent actions, at this time the browser side will not display the data normally;

[0060] Step 5-2-1, obtain the decrypted response body plaintext, and divide it into an array according to the even number of characters, if the division fails, it is regarded as an invalid request, and the source information is recorded;

[0061] Step 5-2-2, according to the set of confusion algorithm on the segmented character group, separate the salt value characters used for confusion from the array, and match the separated salt value characters with the original salt value in terms of character order and character content. If the match fails, it is considered an invalid request, and the source information is recorded.

[0062] After the salt value is completely matched, the plaintext characters of each array element are obtained, and the unconfused plaintext is reassembled.

[0063] Step 5-2-3, the unconfused plaintext obtained in step 5-2-2 is signed using a signature algorithm to obtain a calculated signature result, which is compared with the signature result in the request header. If they are not consistent, it is considered an invalid request, and the source information is recorded.

[0064] Step 5-2-4, the plaintext information that has passed the above verification is passed to the subsequent business code, and the request unique identifier is recorded.

[0065] The specific implementation process of the present scheme is described in the form of specific embodiments as follows:

[0066] Step 100: Generate SM4 or AES symmetric encryption keys for existing Web systems, generate random 32-bit check salt values with alphanumeric special characters, and store the keys and salt values on the browser side and the JAVA server side respectively;

[0067] Taking an existing Web system based on Java Servlet annotation as an example, the browser and the server perform application layer data transmission through AJAX+content type JSON, and using SM4 or AES symmetric encryption algorithm combined with Java SecureRandom random mode, a 16-byte key is generated for the Web system. Continue to use Java SecureRandom random mode to randomly generate and concatenate a 32-character string from alphanumeric special characters as a check salt value.

[0068] Step 200: In the JavaScript of the browser-side code, implement the interception of the request initiation, and realize the confusion signature and encryption of the request body without destroying the JSON request type.

[0069] Taking the classic Jquery framework as an example, intercept the json request body data of the ajax request, convert it to a string, and use the confusion signature and encryption scheme described in the technical scheme to confuse and sign the obtained string. The signature algorithm selects SHA256, and finally obtains the signature result, the request unique identifier, and the encrypted ciphertext.

[0070] The signature result is added to the request header and named requestSign

[0071] Add a unique identifier to the request header, named requestId.

[0072] Convert the encrypted request to JSON format and replace the existing request body to avoid corrupting the JSON request format as follows:

[0073] {"requestEncContent": "ciphertext"}

[0074] Step 300: Create a new filter in the server-side of the project (i.e., in the Java code). This filter takes precedence over all other filters and intercepts all browser requests.

[0075] The Filter retrieves the JSON-formatted request body, obtains the ciphertext from requestEncContent, retrieves the signature result from the requestSign header, and retrieves the unique request identifier from the requestId header.

[0076] Step 400: Decrypt the ciphertext obtained by the filter and verify the validity of the signature and the unique identifier of the request;

[0077] The SM4 decryption algorithm is used for decryption. If decryption fails, the request is considered invalid. Key source information such as the operator, source IP, request body message, and source device information is recorded to facilitate attack tracing.

[0078] If decryption is successful and plaintext is obtained, then signature and request unique identifier verification are performed. The verification algorithm is as follows, and the steps are executed accordingly:

[0079] 1. Obtain the first 19 bits of the plaintext (13-bit millisecond timestamp + 6-bit random number in the signature algorithm) as a unique identifier for the request and compare it with the requestId. If they do not match, the request is considered invalid and the source information is recorded.

[0080] 2. Retrieve the unique request identifier (requestId) recorded within the last 10 minutes from a cache database with an expiration policy (such as Redis). If a match is found, it means that the request has been used and should be subject to a replay attack. In this case, it is considered an invalid request, and the source information is recorded.

[0081] 3. If the timestamp obtained after removing the last 6 digits of the requestId is more than 2 minutes from the current time, it is considered an invalid request, and the source information is recorded. In this step, the accuracy of the server-side clock must be ensured.

[0082] 4. After removing the first 19 characters from the plaintext, split the plaintext into arrays of two characters each. If the splitting fails (the string length is not divisible by 2), it is considered an invalid request, and the source information is recorded.

[0083] 5. Take the first 32 elements of the array (if the index is less than 32, take all elements), then take the second character of each array element, and concatenate them to obtain the salt value. The separated salt value is then matched exactly with the original salt value according to the character order and content (character indices and content must match, lengths do not need to match). If a match cannot be found, it is considered an invalid request, and the source information is recorded.

[0084] 6. After a complete match, retrieve the first character of each array element and reassemble the unobfuscated plaintext.

[0085] 7. Concatenate the request unique identifier from the request header with unobfuscated plaintext, and sign it using the SHA256 algorithm to obtain the calculated signature result. Compare it with the signature result requestSign in the request header. If they do not match, the request is considered invalid, and the source information is recorded.

[0086] After the above decryption and signature verification are completed, the final unobfuscated plaintext information is converted into the original JSON format of the request, and passed to the subsequent business filter using the decorator mechanism and the filter chaining mechanism. The unique identifier of the request is also recorded in the cache database (such as Redis) with an expiration time of 10 minutes.

[0087] Step 500: In the server-side filter, encrypt and sign the response content to ensure that the browser receives encrypted and signed data, and add the unique response identifier and response signature to the response header;

[0088] By utilizing Java's response decorator mechanism, the response content can be read and modified.

[0089] The obtained string is obfuscated and encrypted in the same way as the browser, according to the obfuscation signature and encryption scheme described in the technical solution. The signature algorithm is SHA256, and the final result is the signature, the unique identifier of the response, and the encrypted ciphertext.

[0090] Add the signature result to the response header and name it responseSign;

[0091] Add a unique identifier to the request header and name it responseId (but it will not be used for uniqueness verification at this time).

[0092] Convert the encrypted message to a JSON string and replace the existing response body to avoid corrupting the JSON response format, as follows:

[0093] {"responseEncContent": "ciphertext"}

[0094] At the same time, the size of the response must be reset according to the length of the final JSON string using the setContentLength method.

[0095] Step 600: In the JavaScript of the browser-side code, intercept the server response and decrypt the response content, and perform validity check on the signature and response unique identifier

[0096] Get the JSON format response content in the Ajax response, get the ciphertext from responseEncContent, get the signature result from the request header responseSign, and get the request unique identifier from the request header responseId.

[0097] Decrypt using the SM4 or AES decryption algorithm. If decryption fails, directly prompt the browser that the response content is invalid and stop subsequent processing (response decryption or verification error, no need to record source information).

[0098] If the decryption is successful, get the plaintext, and then perform signature verification. The verification algorithm is as follows:

[0099] 1. Get the first 19 bits of the plaintext as the response unique identifier and compare it with responseId. If they are not consistent, prompt that the response content is invalid and stop subsequent processing.

[0100] 2. Remove the first 19 characters in the plaintext, and then split the plaintext into an array according to two characters. If the splitting fails (the string length cannot be divided by 2), prompt that the response content is invalid and stop subsequent processing.

[0101] 3. Take the 2nd character of each array element and match the salt value character according to the array order. The value obtained by dividing the array index by 32 corresponds to the character position of the salt value. If there is 1 character that cannot be matched, prompt that the response content is invalid and stop subsequent processing.

[0102] 4. After complete matching, get the 1st character of each array element and reassemble the unobfuscated plaintext.

[0103] 5. Concatenate responseId and the unobfuscated plaintext, and perform signature using the SHA256 algorithm to obtain the calculated signature result. Compare it with the signature result responseSign in the request header. If they are not consistent, prompt that the response content is invalid and stop subsequent processing.

[0104] After the above decryption and signature verification are completed, return the final unobfuscated plaintext information in the form of a JSON string for subsequent business code to use. The business code is not aware of the overall processing process.

[0105] Step 700: Obfuscate and encrypt the browser-side JavaScript code using the javascript-obfuscator or webpack, and replace the key and signature salt value every time the system is released

[0106] The key, signature salt value, and corresponding algorithm in the system are also used in the browser, so the JavaScript needs to be obfuscated and encrypted to reduce readability and increase cracking difficulty.

[0107] At the same time, the key and signature salt value can be randomly generated and replaced with the existing key and signature salt value in the system engineering every time the system is released, and even the signature algorithm and algorithm call entry can be changed to reduce the possibility of cracking the system data transmission code.

[0108] Step 800: When the web system browser side transmits data with the backend, through the browser's debugger mode or using proxy tools such as BurpSuite to capture application layer request and response, it is impossible to obtain plaintext information and difficult to tamper with requests or perform request replay attacks

[0109] After the above steps, it is difficult to obtain the real plaintext data and encryption signature rules of the system transmission through various tools, and it is difficult to analyze and tamper with request data to perform application layer vulnerability exploitation attacks such as SQL injection, SHELL injection, unauthorized access, SHELL upload, etc. At the same time, due to the existence of request unique identification verification, it can also effectively prevent request replay attacks that do not need to tamper with request data. Combined with the two, further improve the security of the system data transmission and the difficulty of attackers to exploit system vulnerabilities.

[0110] The present scheme also provides a low-invasive web system application layer security encryption transmission system based on request response preprocessing, comprising the following modules:

[0111] Encryption module: used to generate a key for symmetric encryption for the web system, and set obfuscation and signature algorithms;

[0112] Browser-side module: used to intercept all request initiations on the browser side and use the set obfuscation and signature algorithms to obfuscate and sign the request body and encrypt the data for transmission;

[0113] At the same time, intercept all received server response data on the browser side and decrypt and sign the response content for verification;

[0114] Server-side module: used to intercept the received request body on the server side, decrypt the request body, and sign and replay the decrypted request body plaintext for verification;

[0115] And intercept all the response content need to be transmitted to the browser on the server side, set the confusion and signature algorithm response content confusion signature and encryption.

[0116] The above-described embodiments are merely illustrative of several embodiments of the present application, and the description is more specific and detailed, but it should not be understood as limiting the scope of the patent. It should be noted that for ordinary skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are within the scope of the present application. Therefore, the scope of protection of the patent of the present application should be subject to the appended claims.

Claims

1. A low-invasive web system application layer security encryption transmission method based on request response preprocessing, characterized in that, The method comprises the following steps: Step 1, generating a key for symmetric encryption for a Web system, and setting a confusion and signature algorithm; Step 2, intercepting all request initiations in a browser end, and confusing, signing and encrypting a request body by using the set confusion and signature algorithm, and performing data transmission; Step 3, intercepting a received request body in a server end, decrypting the request body, and signing and replay checking a decrypted request body plaintext: Step 3-1, decrypting the received request body by using the symmetric encryption key: Step 3-2, if the decryption is successful, signing and request replay checking the decrypted request body plaintext, and passing the request body plaintext information after the checking to subsequent business code, and if the decryption fails, regarding the request body as an invalid request, and recording request body information: Step 3-2-1, comparing a request unique identifier in the decrypted request body plaintext with a request unique identifier in a request header, and if the two identifiers are inconsistent, regarding the request as an invalid request, and recording source information; determining whether the request unique identifier has been recorded and used within a certain time, and if yes, regarding the request as an invalid request, and recording source information; comparing a timestamp in the request unique identifier with a current time, and if a difference between the two exceeds a certain time, regarding the request as an invalid request, and recording source information; Step 3-2-2, removing the request unique identifier from the decrypted request body plaintext, and dividing the plaintext into an array according to even number of characters, and if the division fails, regarding the request as an invalid request, and recording source information; Step 3-2-3, de-confusing the divided character groups according to the set confusion algorithm, separating salt value characters used for confusion from the array, and completely matching the separated salt value characters with an original salt value according to character order and character content, and if the matching fails, regarding the request as an invalid request, and recording source information; after the complete salt value matching, obtaining plaintext characters of each array element, and reassembling the plaintext to obtain unconfused plaintext; Step 3-2-4, using the request unique identifier in the request header and the unconfused plaintext obtained in step 3-2-3 to perform signature by using a signature algorithm, obtaining a calculated signature result, and comparing the calculated signature result with a signature result in the request header, and if the two results are inconsistent, regarding the request as an invalid request, and recording source information; Step 3-2-5, passing the plaintext information after the above checking to subsequent business code, and recording the request unique identifier; Step 4, intercepting all response contents needing to be transmitted to a browser in a server end, and confusing, signing and encrypting the response contents by using the set confusion and signature algorithm; Step 5, intercepting all received response data of the server end in a browser end, and performing decryption and signature checking on the response contents.

2. The method for request-response pre-processing based low intrusive web system application layer security encryption transmission as claimed in claim 1, wherein, The confusion, signing and encryption on the request body in step 2, and the data transmission, specifically comprise the following steps: Step 2-1, confusing the request body plaintext: generating a random salt value composed of character special characters, and confusing the plaintext by using the salt value and a confusion algorithm: ； ； wherein, represents the i-th character of the plaintext, represents the generated random salt value S the i-th character in , represents the request body plaintext obfuscated via the random salt value, || represents the string concatenation operation, N represents the number of characters of the plaintext, represents the request body plaintext obfuscated via the random salt value; m represents the number of characters of the random salt value S , represents the implementation of the cyclic index acquisition from the salt value with the length m by using modulo division; Step 2-2, performing unique identifier and signature processing on the request body plaintext: Obtain a certain number of millisecond-level time stamps and a certain number of random numbers to form a request unique identifier, which is added to the request header; the request unique identifier is also spliced at the front of the unobfuscated plaintext to obtain a to-be-signed plaintext, and a signature algorithm is used to sign the to-be-signed plaintext to obtain a request signature result, and the request signature result is added to the request header; Step 2-3: Obtain the to-be-transmitted request body ciphertext by using the symmetric encryption key: Splice the request unique identifier and the obfuscated request body plaintext, and use the symmetric encryption key to perform symmetric encryption to obtain the to-be-transmitted request body ciphertext; The request header and the request body ciphertext are transmitted to the server side.

3. The method for request-response pre-processing based low intrusive web system application layer security encryption transmission as claimed in claim 1, wherein, The obfuscated signature and encryption of the response content in step 4 are as follows: Step 4-1: Obfuscate the plaintext of the response content: generate a random salt value composed of special characters, and use the salt value to obfuscate the plaintext through an obfuscation algorithm: ； ； wherein, represents the i-th character of the plaintext, represents the generated random salt value S the i-th character in , represents the request body plaintext obfuscated via the random salt value, || represents the string concatenation operation, N represents the number of characters of the plaintext, represents the request body plaintext obfuscated via the random salt value; m represents the number of characters of the random salt value S , represents the implementation of the cyclic index acquisition from the salt value with the length m by using modulo division; Step 4-2: Sign and encrypt the plaintext of the response content: Obtain a certain number of millisecond-level time stamps and a certain number of random numbers to form a request unique identifier, which is spliced at the front of the unobfuscated plaintext to obtain a to-be-signed plaintext, and a signature algorithm is used to sign the to-be-signed plaintext; Step 4-3: Obtain the to-be-transmitted request body ciphertext by using the symmetric encryption key: Use the symmetric encryption key to perform symmetric encryption on the obfuscated response content plaintext to obtain the to-be-transmitted response content ciphertext.

4. The method for request-response pre-processing based low intrusive web system application layer security encryption transmission as claimed in claim 1, wherein, The decryption and signature verification of the response content in step 5 include: Step 5-1: Use the symmetric encryption key to decrypt the received response content: Step 5-2: If the decryption is successful, the decrypted response content plaintext is signed and request replay verified, and if the decryption fails or the signature fails, the original response content is directly returned.

5. The method for low intrusion web system application layer security encryption transmission based on request response pre-processing according to claim 4, characterized in that, The signature and request replay verification of the decrypted response content plaintext in step 5-2 are as follows: Step 5-2-1: Obtain the decrypted response body plaintext, and divide it into an array according to the number of even characters. If the division fails, it is considered as an invalid request, and the source information is recorded; Step 5-2-2: According to the set obfuscation algorithm, the characters in the divided array are de-obfuscated, the salt value characters used for obfuscation are separated from the array, and the separated salt value characters are completely matched with the original salt value in terms of character order and character content. If the match fails, it is considered as an invalid request, and the source information is recorded; After the salt values are completely matched, the plaintext characters of each array element are obtained, and the unobfuscated plaintext is reassembled; Step 5-2-3: The unobfuscated plaintext obtained in step 5-2-2 is signed using a signature algorithm to obtain a calculated signature result, which is compared with the signature result in the request header. If they are inconsistent, it is considered as an invalid request, and the source information is recorded; Step 5-2-4: The plaintext information that has passed the above verification is passed to the subsequent business code, and the request unique identifier is recorded.

6. The method for request-response pre-processing based low intrusive web system application layer security encryption transmission as claimed in claim 1, wherein, The symmetric encryption key, obfuscation, and signature algorithm in step 1 need to be changed regularly or randomly.

7. The method for request-response pre-processing based low intrusive web system application layer security encryption transmission as claimed in claim 1, wherein, The code on the browser side is obfuscated and encrypted according to the set obfuscation algorithm.

8. A low-invasive web system application layer security encryption transmission system based on request response preprocessing, characterized in that, The code includes the following modules: Encryption module: used to generate keys for symmetric encryption for web systems, and set confusion and signature algorithms; Browser-side module: used to intercept all request initiations at the browser side, and use the set confusion and signature algorithms to confuse and sign the request body and perform data transmission; At the same time, intercept all received server response data at the browser side, and decrypt and sign the response content; Server-side module: used to intercept the received request body at the server side, decrypt the request body, and sign and replay the decrypted request body plaintext, including: Decrypt the received request body using the symmetric encryption key: If the decryption is successful, sign and request replay the decrypted request body plaintext, and pass the request body plaintext information that passes the verification to the subsequent business code, if the decryption fails, the request body is considered invalid request, and the request body information is recorded: Compare the request unique identifier of the decrypted request body plaintext with the request unique identifier in the request header, if they are inconsistent, consider it as an invalid request, and record the source information Determine whether the request unique identifier has been recorded and used within a certain time, if so, consider it as an invalid request, and record the source information; Compare the timestamp in the request unique identifier with the current time, if the difference exceeds a certain time, consider it as an invalid request, and record the source information; Decrypt the request body plaintext, remove the request unique identifier, and split it into an array according to the number of double characters, if the split fails, consider it as an invalid request, and record the source information; According to the set confusion algorithm, the character group after splitting is deconfused, the salt value characters used for confusion are separated from the array, and the separated salt value characters are completely matched with the original salt value in terms of character order and character content, if they cannot be matched, consider it as an invalid request, and record the source information; After the salt value is completely matched, get the plaintext characters of each array element, and reassemble them to form the unconfused plaintext; Use the request unique identifier in the request header and the unconfused plaintext obtained in step 3-2-3 to splice, use the signature algorithm to sign, obtain the calculation signature result, and compare it with the signature result in the request header, if they are inconsistent, consider it as an invalid request, and record the source information; Pass the plaintext information that completes the above verification to the subsequent business code, and record the request unique identifier; And intercept all response content that needs to be transmitted to the browser at the server side, set the confusion and signature algorithm response content to confuse and sign and encrypt.

Images