Unified decryption filter of web server

Abstract

The invention discloses a unified decryption filter of a web server, and relates to the technical field of http encryption and decryption, and the unified decryption filter comprises the following steps: the decryption filter matches a path in advance, and if the path is not matched, a request is forwarded to business processing; if the path is matched with the decryptor name, obtaining all decryptor names on the path; if the returned decryptor name is null or only nonCrypt, it is indicated that decryption is not needed, the request is transferred to business processing, otherwise, a CryptRequestWrapper object is initialized, the object packages an http original request object as a new http request object, and the new http request object is expressed as a cryptHttp object; the name is named as nonCrypt. According to the method, unified decryption operation is carried out on the encrypted data, it is ensured that only the correctly decrypted data can enter a subsequent business logic processing link, the encrypted data is effectively prevented from being accessed or tampered by unauthorization, and the safety of important contents such as user passwords, personal privacy information and enterprise confidential data is protected.

Description

Technical Field

[0001] The present invention relates to the technical field of http encryption and decryption, and in particular to a unified decryption filter of a web server. Background Art

[0002] Now the process of http encryption and decryption is mostly as follows Figure 3 As shown: the client encrypts the plain text into cipher text, and then sends the password to the server; the server decrypts the business code first, and then processes the business. The main problems in this are as follows:

[0003] 1. The business code contains a decryption process that is irrelevant to business processing. Especially in the spring mvc framework, the ciphertext cannot be directly converted into business parameters. Therefore, the business code in the spring mvc framework also contains the process of obtaining parameters after decryption. Therefore, for programmers who write business, it undoubtedly increases unnecessary workload.

[0004] 2. Sometimes the same web interface Figure 3 In the \hello\world1, different clients will have different encryption methods. For example, when accessing \hello\world1, the WeChat applet client will use the WeChat applet encryption process, while the WeChat browser will use a custom encryption process. For the server, different encryption processes have different corresponding key acquisition and decryption processes. Writing all of these into the business code will greatly bloat the business code and greatly increase the workload of business programmers.

[0005] 3. Not friendly to logs. Now many industries use AOP to record logs. This method generates a proxy for the business method. When the method is called, the proxy is actually called. The proxy will record relevant information first, and then call the method. The parameters passed in the call are the most important information. If the parameters recorded at this time are encrypted ciphertext, it will be unfavorable for later log analysis.

[0006] Currently, no effective solution has been proposed for the problems in the related technologies. Summary of the invention

[0007] In view of the problems in the related art, the present invention proposes a unified decryption filter for a web server to overcome the above technical problems existing in the existing related art.

[0008] The technical solution of the present invention is achieved in this way:

[0009] A unified decryption filter for a web server includes the following steps:

[0010] The decryption filter pre-matches the path, including: if no match is found, the request is transferred to the business processing; if a match is found, all decryptor names on the path are obtained;

[0011] If the returned decryptor name is empty or only nonCrypt, it means that decryption is not required, and the request is transferred to business processing. Otherwise, a CryptRequestWrapper object is initialized, which wraps the http native request object as a new http request object, represented as a cryptHttp object;

[0012] Except for the one named nonCrypt, all decryptors will be obtained in the decryptor management according to the decryptor name;

[0013] Call the decryptor method in sequence: boolean match(HttpServletRequest request), passing the cryptHttp object as a parameter.

[0014] Furthermore, the decryption filter pre-matches the path, including:

[0015] The path matching rules are marked to perform ant matching on the request path and the paths in the path management one by one, and if a match is found, the matching stops and the decryptor name is returned.

[0016] Furthermore, the step of transferring the request to the business process includes the following steps:

[0017] If no match is found, the next path in the path management is tried, until all paths in the path management are tried, and if no match is found, empty is returned.

[0018] Furthermore, the decryption filter comprises: CryptRequestWrapper (1) and a decryption context manager (2), wherein;

[0019] The CryptRequestWrapper (1) is used to read the request body, and after decryption, write the plaintext back to the request body;

[0020] The decryption context manager (2) is used to check whether the current request path needs to be decrypted. If necessary, the corresponding decryptor is called according to the request to decrypt the request body to obtain the ciphertext.

[0021] Furthermore, the parameter passing of the cryptHttp object includes the following steps:

[0022] If true is returned, first call getBodyData of cryptHttp to obtain the request body data bodyData, then call the decryptor method: byte[]handleSecurity(byte[]rawData, HttpServletRequest request), passing parameters: bodyData, cryptHttp;

[0023] If an exception occurs, the decryptor method will be called:

[0024] VoidhandleException(HttpServletRequestrequest,HttpServletResponserespons e,Throwable e), handles the exception and terminates the request processing;

[0025] Otherwise, the decrypted ciphertext data will be obtained, and then the setBodyData(byte[]bodyData) of cryptHttp will be called, and the parameter: the decrypted ciphertext data will be passed, and finally the request to cryptHttp will be transferred to the business;

[0026] If false is returned, the next decryptor method is tried: boolean match(HttpServletRequestrequest). If all decryptors return false, a 500 response is returned to the client and the request processing is terminated.

[0027] The beneficial effects of the present invention are:

[0028] The present invention uniformly decrypts the encrypted http request body and extracts the decryption process from the business. The user can customize multiple decryptors and configure multiple decryptors for the same web interface through configuration. When the client request is called, it will first pass through the unified decryption filter. The unified decryption filter will first take out the request body, decrypt it, and then fill the decrypted plaintext back into the request body, so as to realize the unified decryption operation on the encrypted data, ensure that only the data after correct decryption can enter the subsequent business logic processing link, effectively prevent the encrypted data from being accessed or tampered with by unauthorized, and protect the security of important contents such as user passwords, personal privacy information, and corporate confidential data. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0030] Figure 1 It is a schematic diagram of a process of a unified decryption filter of a web server according to an embodiment of the present invention;

[0031] Figure 2 is a structural schematic diagram of a unified decryption filter of a web server according to an embodiment of the present invention;

[0032] Figure 3 The present invention is a schematic diagram of an existing process of a unified decryption filter of a web server according to an embodiment of the present invention.

[0033] In the figure:

[0034] 1. CryptRequestWrapper; 2. Decryption context manager. DETAILED DESCRIPTION

[0035] The following will be combined with the accompanying 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 belong to the scope of protection of the present invention.

[0036] According to an embodiment of the present invention, a unified decryption filter of a web server is provided.

[0037] like Figure 1-Figure 2 As shown, the unified decryption filter of the web server according to the embodiment of the present invention includes the following steps:

[0038] Step S1, decryption filter pre-matching path, which includes the following steps:

[0039] Step S101: If no match is found, the request is transferred to business processing.

[0040] Step S102: If a match is found, all decryptor names on the path are obtained.

[0041] Among them, the path matching rule is to perform ant matching on the request path and the path in the path management one by one, and if a match is found, the matching stops and the decryptor name is returned.

[0042] Additionally, the following steps are included:

[0043] Step S103, if no match is found, then try the next path in the path management until all paths in the path management have been tried, and if no match is found, then return empty.

[0044] Specifically, Figure 2 As shown, assuming the requested path is / hi / hello, the returned decryptor name will be empty. Assuming the requested path is / hello / word2, the returned decryptor names are: nonCrypt, wxsappCrypt, userCrypt. Multiple decryptors can be configured for the same path with "|" as a separator.

[0045] Step S2: If the returned decryptor name is empty or only nonCrypt, it means that decryption is not required, and the request is transferred to business processing. Otherwise, a CryptRequestWrapper object is initialized, which wraps the http native request object as a new http request object, represented as a cryptHttp object.

[0046] In this technical solution, because CryptRequestWrapper also implements the methods of the HttpServletRequest interface, cryptHttp can replace the http native request object. Subsequently, cryptHttp is used as the request object to transfer to the business.

[0047] Step S3, except for the one named nonCrypt, all decryptors will be obtained in the decryptor management according to the decryptor name.

[0048] Step S4, calling the decryptor method in order: boolean match(HttpServletRequestrequest), passing the parameter: cryptHttp object, including the following steps:

[0049] Step S401, if true is returned, first call getBodyData of cryptHttp to obtain the request body data bodyData, and then call the decryptor method: byte[]handleSecurity(byte[]rawData, HttpServletRequestrequest), passing parameters: bodyData, cryptHttp.

[0050] Step S402, if an exception occurs, the decryptor method will be called:

[0051] VoidhandleException(HttpServletRequest request, HttpServletResponse response e, Throwable e), handles the exception and terminates the request processing.

[0052] Step S403, otherwise, the decrypted ciphertext data will be obtained, and then the setBodyData(byte[]bodyData) of cryptHttp will be called, and the parameter: the decrypted ciphertext data will be passed. Finally, the cryptHttp request will be transferred to the business.

[0053] Step S404: If false is returned, the next decryptor method is tried: boolean match(HttpServletRequest request). If all decryptors return false, a 500 response is returned to the client and the request processing is terminated.

[0054] In this technical solution, for the above CryptRequestWrapper: when a request is made to a Java web container, the container will create objects of the HttpServletRequest and HttpServletResponse interface types for the request (hereinafter referred to as http native request objects and native http response objects), and the http native request object represents the current request. There is a problem with the http native request object, that is, the request body data can only be read once, and there is no way to modify the request body data.

[0055] Therefore, the present invention provides a CryptRequestWrapper class, which also implements the HttpServletRequest interface. Therefore, an object of the CryptRequestWrapper type is also an object of the HttpServletRequest type, so the http native request object can be replaced by cryptHttp and passed to the service. When the object cryptHttp of the CryptRequestWrapper class is initialized, the http native request object is first assigned to cryptHttp.request (see Figure 2 ), and then read the request body data of the request and assign it to cryptHttp.bodyData. The CryptRequestWrapper class implements the methods getInputStream and getContentLength of the HttpServletRequest interface:

[0056] public ServletInputStream getInputStream()throws IOException{

[0057] return new BufferedServletInputStream(this.bodyData);

[0058] }

[0059] public int getContentLength(){

[0060] return bodyData.length;

[0061] }

[0062] Other methods of the implemented HttpServletRequest interface directly call the method of the same name of cryptHttp.request. At the same time, CryptRequestWrapper also comes with two methods of its own:

[0063] public byte[]getBodyData(){

[0064] return buffer;

[0065] }

[0066] public void setBodyData(byte[]bodyData){

[0067] this.bodyData = bodyData;

[0068] }

[0069] In addition, the decryption filter includes: CryptRequestWrapper (1) and a decryption context manager (2), wherein;

[0070] The CryptRequestWrapper (1) is used to read the request body, and after decryption, write the plaintext back to the request body;

[0071] The decryption context manager (2) is used to check whether the current request path needs to be decrypted. If necessary, the corresponding decryptor is called according to the request to decrypt the request body to obtain the ciphertext.

[0072] For the decryption context manager (2), the decryption path and decryptor are configured. The decryption path consists of the path and the decryptor name used for the decryption of the path. A path can be configured with multiple decryptor names separated by "|". Among them, nonCrypt is a special decryptor name. When a path is configured with nonCrypt, it means that the current path can not be decrypted. The decryptor needs to configure the decryptor name and the decryptor implementation corresponding to the name, such as Figure 2 As shown:

[0073] wxsappCrypt: hello.www.world.WxsappCrypt

[0074] userCrypt: hello.www.world.UserCrypt

[0075] When the decryption context manager is started, it reads the decryption path and decryptor configuration, and checks whether the decryptor names configured on all paths (except nonCrypt) can be found in the decryptor management. If all cannot be found, a startup exception is thrown and startup fails.

[0076] In addition, the present invention only provides a decryptor interface, and the user needs to implement his own decryptor and write the implemented decryptor into the configuration, as follows:

[0077] / / Check whether the current request matches the decryptor

[0078] boolean match(HttpServletRequest request);

[0079] / / Decrypt or verify the request body

[0080] byte[]handleSecurity(byte[]rawData,HttpServletRequest request);

[0081] / / Handle exception when decryption fails

[0082] voidhandleException(HttpServletRequestrequest,HttpServletResponseresponse,Throwable e);

[0083] In summary, with the help of the above technical solution of the present invention, the encrypted http request body is uniformly decrypted, and the decryption process is extracted from the business. The user can customize multiple decryptors, and multiple decryptors can be configured for the same web interface through configuration. When the client request is called, it will first pass through the unified decryption filter. The unified decryption filter will first take out the request body, decrypt it, and then fill the decrypted plaintext back into the request body, so as to achieve a unified decryption operation on these encrypted data, ensuring that only the data that has been correctly decrypted can enter the subsequent business logic processing link, effectively preventing the encrypted data from being accessed or tampered with without authorization, and protecting the security of important content such as user passwords, personal privacy information, and corporate confidential data.

[0084] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. After considering the disclosure of the specification and the examples, those skilled in the art will easily think of other embodiments of the present disclosure. This application is intended to cover any modification, use or adaptation of the present disclosure, which follows the general principles of the present disclosure and includes common knowledge or customary technical means in the art that are not disclosed in the present disclosure. The specification and the examples are only regarded as exemplary, and the true scope and spirit of the present disclosure are indicated by the claims.

[0085] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A unified decryption filter for a web server, characterized in that: The following steps are involved: The decryption filter pre-matches the path, including: if no match is found, the request is transferred to the business processing; if a match is found, all decryptor names on the path are obtained; If the returned decryptor name is empty or only nonCrypt, it means that decryption is not required, and the request is transferred to business processing. Otherwise, a CryptRequestWrapper object is initialized, which wraps the http native request object as a new http request object, represented as a cryptHttp object; Except for the one named nonCrypt, all decryptors will be obtained in the decryptor management according to the decryptor name; Call the decryptor method in sequence: boolean match(HttpServletRequest request), passing the cryptHttp object as a parameter.

2. The unified decryption filter of the web server according to claim 1, characterized in that: The decryption filter pre-matches the path, including: The path matching rules are marked to perform ant matching on the request path and the paths in the path management one by one, and if a match is found, the matching stops and the decryptor name is returned.

3. The unified decryption filter of the web server according to claim 2, characterized in that: The step of transferring the request to the business process includes the following steps: If no match is found, the next path in the path management is tried until all paths in the path management are tried, and if no match is found, empty is returned.

4. The unified decryption filter of the web server according to claim 1, characterized in that: The decryption filter comprises: CryptRequestWrapper (1) and a decryption context manager (2), wherein; The CryptRequestWrapper (1) is used to read the request body, and after decryption, write the plaintext back to the request body; The decryption context manager (2) is used to check whether the current request path needs to be decrypted. If necessary, the corresponding decryptor is called according to the request to decrypt the request body to obtain the ciphertext.

5. The unified decryption filter of the web server according to claim 1, characterized in that: The method of passing the cryptHttp object includes the following steps: If true is returned, first call getBodyData of cryptHttp to obtain the request body data bodyData, then call the decryptor method: byte[]handleSecurity(byte[]rawData, HttpServletRequest request), passing parameters: bodyData, cryptHttp; If an exception occurs, the decryptor method will be called: VoidhandleException(HttpServletRequestrequest,HttpServletResponseresponse,Throwable e), handles the exception and terminates the request processing; Otherwise, the decrypted ciphertext data will be obtained, and then the setBodyData(byte[]bodyData) of cryptHttp will be called, and the parameter: the decrypted ciphertext data will be passed, and finally the request to cryptHttp will be transferred to the business; If false is returned, the next decryptor method is tried: boolean match(HttpServletRequestrequest). If all decryptors return false, a 500 response is returned to the client and the request processing is terminated.

Images