Verification device, verification method, and verification program

The verification device ensures that regular expressions are non-fragile by checking syntax compliance and linear processing time, effectively addressing vulnerabilities and preventing ReDoS attacks.

JP7800679B2Active Publication Date: 2026-01-16NIPPON TELEGRAPH & TELEPHONE CORP
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2024526080
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2022-06-07
Publication Date
2026-01-16
Estimated Expiration
2042-06-07

AI Technical Summary

Technical Problem

Conventional techniques for fixing vulnerabilities in regular expressions do not provide certainty that the vulnerabilities have been effectively addressed.

Method used

A verification device and method that includes a first judgment unit to check syntax compliance and a second judgment unit to verify that processing time is linear with respect to string length, ensuring the regular expression is non-fragile.

Benefits of technology

Enables verification of the likelihood that vulnerabilities in regular expressions have been fixed, reducing the risk of Regular Expression Denial of Service (ReDoS) attacks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007800679000001
    Figure 0007800679000001
  • Figure 0007800679000002
    Figure 0007800679000002
  • Figure 0007800679000003
    Figure 0007800679000003
Patent Text Reader

Abstract

A verification device according to an embodiment of the present invention has a first determination unit and a second determination unit. The first determination unit determines whether a regular expression conforms to a previously specified syntax (for example, syntax of a regular expression according to a Backus Naur form). The second determination unit determines whether a condition (for example, real-world strong 1-unambiguity (RWS1U)) is satisfied, said condition indicating that the processing time of a regular expression when a character string is analyzed is linear with respect to the length of the character string.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to a verification device, a verification method, and a verification program. [Background technology]

[0002] In the real world, regular expressions are implemented as regular expression engines and used in a variety of situations. For example, regular expression engines are used in web applications that have a screen for entering email addresses to verify whether the string entered by the user is an email address. Regular expression engines are also used, for example, to sanitize data sent from external sources, extract elements, and are included in standard libraries of general-purpose programming languages.

[0003] Here, the analysis algorithm based on the backtracking method adopted by many regular expression engines has the drawback that it can take an enormous amount of time to process depending on the combination of the data to be analyzed and the regular expression.Regular Expression Denial of Service (ReDoS) is a known cyber attack that exploits this drawback (Reference: "Regular expression Denial of Service - ReDoS", https: / / owasp.org / www-community / attacks / Regular_expression_Denial_of_Service_-_ReDoS).

[0004] A regular expression that runs in linear time on a regular expression engine relative to the length of the string to be matched is called a non-fragile regular expression. Conversely, a regular expression that runs in exponential time on a regular expression engine relative to the length of the string to be matched is called a fragile regular expression.

[0005] Conventionally, RFixer (see, for example, Non-Patent Document 1) is known as a technology for eliminating the threat of ReDoS, which corrects errors in the language accepted by regular expressions. Also known is a method of obtaining a non-vulnerable regular expression by converting a pure regular expression into a deterministic finite automaton and then converting it back (see, for example, Non-Patent Document 2). [Prior art documents] [Non-patent literature]

[0006] [Non-Patent Document 1] Rong Pan, Qinheping Hu, Gaowei Xu, and Loris D'Antoni. 2019. Automatic Repair of Regular Expressions. Proc. ACM Program. Lang. 3, OOPSLA, Article 139 (Oct. 2019), 29 pages. [Non-patent document 2] Brink van der Merwe, Nicolaas Weideman, and Martin Berglund. 2017. Turning Evil Regexes Harmless. In Proceedings of the South African Institute of Computer Scientists and Information Technologists (SAICSIT'17). Association for Computing Machinery, New York, NY, USA, Article 38, 10 pages. Summary of the Invention [Problem to be solved by the invention]

[0007] However, the conventional techniques have a problem in that it may not be possible to verify the certainty that the vulnerability in the regular expression has been fixed. [Means for solving the problem]

[0008] In order to solve the above-mentioned problems and achieve the objective, the verification device is characterized by having a first judgment unit that judges whether a regular expression complies with a pre-specified syntax, and a second judgment unit that judges whether a condition indicating that the processing time when the regular expression parses a string is linear with respect to the length of the string is satisfied. [Effects of the Invention]

[0009] According to the present invention, it is possible to verify the likelihood that vulnerabilities in regular expressions have been fixed. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram illustrating an example of the configuration of a repair device according to the first embodiment. [Figure 2] FIG. 2 is a diagram showing an example of the syntax of a regular expression. [Figure 3] FIG. 3 is a diagram showing examples of Positive Examples and Negative Examples. [Figure 4] FIG. 4 is a diagram illustrating a method for generating a set of character strings. [Figure 5] FIG. 5 is a diagram for explaining a method for synthesizing regular expressions. [Figure 6] FIG. 6 is a flowchart showing the flow of processing by the repair device according to the first embodiment. [Figure 7] FIG. 7 is a flowchart showing the flow of the regular expression synthesis process. [Figure 8] FIG. 8 is a diagram illustrating an example of the configuration of a verification device according to the first embodiment. [Figure 9] FIG. 9 is a diagram for explaining the determination method of RWS1U. [Figure 10] FIG. 10 is a diagram illustrating a parse tree. [Figure 11] FIG. 11 is a diagram illustrating an example of a path. [Figure 12] FIG. 12 is a flowchart showing the flow of processing by the verification device according to the first embodiment. [Figure 13] FIG. 13 is a flowchart showing the flow of the RWS1U inspection process. [Figure 14] FIG. 14 illustrates an example of a computer that executes a verification program. DETAILED DESCRIPTION OF THE INVENTION

[0011] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A verification device, a verification method, and a verification program according to the present invention will be described in detail below with reference to the accompanying drawings. However, the present invention is not limited to the following embodiments.

[0012] [Repair device of the first embodiment] First, a modification device that modifies vulnerabilities in regular expressions will be described. A verification device verifies the likelihood that a regular expression has been modified by the modification device.

[0013] For example, if the verification result by the verification device indicates that there is a high possibility that a vulnerability in a regular expression has not been corrected, the regular expression is targeted for correction by the correction device.

[0014] On the other hand, for example, if the verification result by the verification device indicates that it is highly likely that the vulnerability in the regular expression has already been corrected, it is determined that correction by the correction device for that regular expression is not necessary.

[0015] In this embodiment, the correction device and the verification device are separate devices, although the verification device may be implemented as part of the functionality of the correction device.

[0016] First, the configuration of a correction device according to the first embodiment will be described with reference to Fig. 1. Fig. 1 is a diagram showing an example of the configuration of a correction device according to the first embodiment. As shown in Fig. 1, a correction device 10 receives an input of a regular expression before correction, corrects the input regular expression, and outputs the corrected regular expression.

[0017] Here, the regular expression input to the modification device 10 is a regular expression that has been extended to the real world and conforms to the syntax defined in Backus-Naur form (BNF). FIG. 2 is a diagram showing an example of the syntax of a regular expression. The regular expression r in FIG. 2 is an example of a regular expression in this embodiment. In the following description, "\" in a regular expression may be replaced with a backslash as appropriate.

[0018] In Figure 2, "C" is a set of characters, "x" is a string, and "i" is a natural number. The syntax in Figure 2 is used in existing regular expression engines (References: "Perldoc Browser", https: / / perldoc.perl.org / perlre.html).

[0019] Also, "." is a symbol that represents any single character. In other words, "." is syntactic sugar for the range character "[C]" in Figure 2. Also, a set of characters that does not match the range character "[C]" can be written as "[^C]". Also, the empty set is written as "[]", which means that it does not match any characters.

[0020] 1, the description will be given of each unit of the correction device 10. As shown in FIG.

[0021] The interface unit 11 is an interface for inputting, outputting, and communicating data. For example, the interface unit 11 accepts data input from input devices such as a keyboard and a mouse. Also, for example, the interface unit 11 outputs data to output devices such as a display and a speaker.

[0022] The interface unit 11 may also be a device for performing communication via a network (for example, a network interface card (NIC)).

[0023] The storage unit 12 is a storage device such as a HDD (Hard Disk Drive), SSD (Solid State Drive), or optical disk. Note that the storage unit 12 may be a semiconductor memory capable of rewriting data, such as a RAM (Random Access Memory), flash memory, or NVSRAM (Non Volatile Static Random Access Memory). The storage unit 12 stores the OS (Operating System) and various programs executed by the correction device 10.

[0024] The storage unit 12 stores replacement candidate syntax information 121. The replacement candidate syntax information 121 is a set of syntaxes of regular expressions or templates, which are regular expression syntaxes to be replaced with range characters or holes.

[0025] For example, the replacement candidate syntax information 121 is "□□, □|□, □*, (□), \i, (?=□), (?!□), (?<=□), (?<!□)". However, "□" is a hole. Holes and templates will be described later.

[0026] The control unit 13 controls the entire correction device 10. The control unit 13 is, for example, an electronic circuit such as a CPU (Central Processing Unit), MPU (Micro Processing Unit), or GPU (Graphics Processing Unit), or an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array).

[0027] In addition, the control unit 13 has an internal memory for storing programs and control data that define various processing procedures, and executes each process using the internal memory. Also, the control unit 13 functions as various processing units when various programs operate. For example, the control unit 13 includes a generation unit 131 and a synthesis unit 132.

[0028] The generation unit 131 generates Positive Examples, which are a set of character strings that are accepted by the regular expression before correction, and Negative Examples, which are a set of character strings that are rejected by the regular expression before correction.

[0029] The Positive Examples are an example of the first set, the Negative Examples are an example of the second set, and the regular expression before correction is an example of the first regular expression.

[0030] Figure 3 shows examples of Positive Examples and Negative Examples. Here, we assume that the regular expression before correction is ".*.*=.*". In this case, "=", "abcd==", "==abcd", and "ab=c" included in the Positive Examples match the regular expression ".*.*=.*" (are accepted). On the other hand, "abc" included in the Negative Examples does not match the regular expression ".*.*=.*" (is rejected).

[0031] The generation unit 131 can enumerate all character strings that combine characters of a specific length or less, and classify each character string into a Positive Example if it is accepted by the regular expression, or into a Negative Example if it is rejected. Note that the generation unit 131 may generate Positive Examples and Negative Examples using the method described in Non-Patent Document 1.

[0032] If all the character strings were simply listed, an explosive number of examples would be generated. To avoid this, the generation unit 131 may generate character strings of Positive Examples and character strings of Negative Examples from only the characters that appear in the regular expression before correction.

[0033] For example, if the regular expression is "ab[cd]*", the generating unit 131 generates candidate character strings by combining "a" and "b" with one character randomly selected from "[c, d]".

[0034] FIG. 4 is a diagram illustrating a method for generating a set of character strings. In the example of FIG. 4, the regular expression before correction is ".*.*@example[.]com". In this case, the generation unit 131 classifies the character strings "@example.com", "a@example.com", and "gc@example.com", which are accepted by the regular expression ".*.*@example[.]com", into Positive Examples. On the other hand, the generation unit 131 classifies the character strings "example.com", "@.com", "@examplecom", "@example.", etc., which are rejected by the regular expression ".*.*@example[.]com", into Negative Examples.

[0035] The synthesis unit 132 synthesizes a modified regular expression, which is a regular expression in which the range character in the pre-modification regular expression is replaced with a predetermined syntax and which accepts character strings of the Positive Examples and rejects character strings of the Negative Examples. The modified regular expression is an example of a second regular expression.

[0036] The processing by the synthesis unit 132 can be roughly divided into a step of creating a template and a step of assigning to the template.

[0037] In the step of creating a template, the synthesis unit 132 creates the template by replacing range characters in the regular expression with placeholders.

[0038] In the step of assigning to a template, the synthesis unit 132 assigns a predetermined syntax to the placeholder to synthesize a non-vulnerable regular expression. Hereinafter, the placeholder will be called a hole and represented by "□".

[0039] The synthesis unit 132 performs processing while maintaining a prioritized queue. Priorities are assigned to templates stored in the queue according to their proximity to the pre-correction regular expression. For example, a higher priority is assigned to a template that is closer to the pre-correction regular expression. Furthermore, the proximity to the regular expression may be expressed by the sum of the sizes of different subtrees between the ASTs (Abstract Syntax Trees) of the regular expression (see, for example, Non-Patent Document 1).

[0040] When extracting an element from the queue, the synthesis unit 132 prioritizes the extraction of the stored template with the highest priority. At the start of processing, the synthesis unit 132 stores the unmodified regular expression in the queue as a template. Note that the unmodified regular expression stored in the queue necessarily has the highest priority.

[0041] First, the steps of creating a template executed by the synthesis unit 132 will be described. When a template retrieved from the queue contains range characters, the synthesis unit 132 replaces the range characters contained in the template with holes. Note that range characters are represented, for example, as "[C]" or ".". On the other hand, when a template retrieved from the queue contains holes, the synthesis unit 132 may replace one of the holes with a predetermined syntax.

[0042] For example, the synthesis unit 132 creates templates "□*.*=.*", ".*□*=.*", and ".*.*=□*" by replacing the range characters of the unmodified regular expression ".*.*=.*" stored in the queue as a template, and stores them in the queue. Note that once a template is extracted, it is discarded.

[0043] In this way, the synthesis unit 132 replaces at least some of the range characters in the pre-correction regular expression with holes, and synthesizes the corrected regular expression based on a template in which the replaced holes are further replaced with a predetermined syntax.

[0044] Furthermore, the synthesizer 132 can replace the hole with syntax such as "□□", "□|□", "□*", "(□)", "\i", "(?=□)", "(?!□)", "(?<=□)", "(?<!□)" included in the replacement candidate syntax information 121. In this case, the synthesizer 132 synthesizes the corrected regular expression based on a template obtained by replacing the hole included in the template with any of "□□", "□|□", "□*", "(□)", "\i", "(?=□)", "(?!□)", "(?<=□)", "(?<!□)", which is a predetermined syntax including the hole (where □ is the hole).

[0045] Next, the step of assigning to the template executed by the synthesizer 132 will be described. Here, assume that the synthesizer 132 repeatedly creates a template, for example, creates a template "□*□*=.*" and stores it in the queue. For example, the synthesizer 132 obtains the template "□*□*=.*" by replacing the range character "." on the left side of the template "□*.*=.*" with a hole.

[0046] The synthesizer 132 searches for an assignment of range characters that satisfy the conditions for the holes included in the template. For example, the synthesizer 132 performs the search using a Satisfiability Modulo Theories (SMT) solver (e.g., Z3 solver) or the like.

[0047] If the template is "□*□*=.*" and the Positive Examples and Negative Examples are as shown in Figure 3, the synthesizer 132 can obtain an assignment of "[]*[^=]*=.*" through the search. The synthesizer 132 removes the empty set "[]" and obtains the regular expression "[^=]*=.*".

[0048] The regular expression "[^=]*=.*" accepts the Positive Examples and rejects the Negative Examples in Figure 3. In addition, the regular expression "[^=]*=.*" contains at most one match for the same character, so it can be said to have a non-vulnerable property.

[0049] In this embodiment, as described above, a regular expression that runs on a regular expression engine in linear time relative to the length of the string to be matched is called a non-fragile regular expression. Conversely, a regular expression that runs on a regular expression engine in, for example, exponential time relative to the length of the string to be matched is called a fragile regular expression.

[0050] The synthesis of invulnerable regular expressions by the synthesis unit 132 utilizes the property of strongly one-unambiguous, which was devised by Koch and Scherzinger et al. (Reference: Christoph Koch and Stefanie Scherzinger. 2007. Attribute Grammars for Scalable Query Processing on XML Streams. The VLDB Journal 16, 3 (July 2007), 317-342.), which has been improved to suit real-world extensions.

[0051] Strongly one-unambiguous means that the next operation that the regular expression engine processes is uniquely determined once the character currently being parsed is determined.

[0052] Similarly, if the regular expression before correction is ".*.*@example[.]com", the synthesis unit 132 can obtain the non-vulnerable regular expression "[^@]*@example[.]com", as shown in FIG.

[0053] [Processing flow of the repair device] 6 is a flowchart showing the flow of processing by the editing device according to the first embodiment. First, the editing device 10 receives an input of a regular expression (step S10).

[0054] Next, the modification device 10 generates a set of character strings (Positive Examples) that are accepted by the input regular expression (Step S20). The modification device 10 also generates a set of character strings (Negative Examples) that are rejected by the input regular expression (Step S30).

[0055] For example, the modifying device 10 can create an extended automaton from the input regular expression before modification, and generate a set of strings that covers all paths of the extended automaton.

[0056] Next, the editing device 10 generates (combines) a regular expression based on the input regular expression, the accepted string, and the rejected string (step S40), and then outputs the generated regular expression (step S50).

[0057] Fig. 7 is a flowchart showing the flow of the regular expression synthesis process. The process in Fig. 7 corresponds to step S40 in Fig. 6. First, the modifying device 10 stores the input regular expression in a queue as a template (step S401).

[0058] Next, the modifying device 10 acquires from the queue the template that is closest to the input regular expression (step S402).

[0059] Next, the modifying device 10 searches for an assignment of range characters to holes that accepts accepted character strings, rejects rejected character strings, and satisfies the conditions regarding vulnerability (step S403).

[0060] The correction device 10 determines whether there is an assignment of search results (step S404). If there is no assignment of search results (step S404, No), the correction device 10 replaces the range characters with holes or replaces the holes with a predetermined pattern (step S405). The predetermined pattern is, for example, a syntax such as "□□", "□|□", "□*", "(□)", "\i", "(?=□)", "(?!□)", "(?<=□)", "(?<!□)". Note that if the input regular expression stored in the queue in step S401 becomes the target of the search in step S403, it is regarded as having no assignment (No) in step S404.

[0061] Then, the correction device 10 stores the template processed in step S405 in the queue (step S406). The processed template here is a template in which range characters are replaced with holes or a template in which holes are replaced with a predetermined pattern.

[0062] On the other hand, if there is an assignment of search results (step S404, Yes), the correction device 10 synthesizes a non-vulnerable regular expression based on the assignment of search results (step S407).

[0063] [Effect by the correction device] As described so far, the generation unit 131 of the correction device 10 generates a first set that is a set of strings accepted by the first regular expression and a second set that is a set of strings rejected by the first regular expression. The synthesis unit 132 synthesizes a second regular expression that is a regular expression obtained by replacing the range characters in the first regular expression with a predetermined syntax and that accepts the strings in the first set and rejects the strings in the second set. Thus, the correction device 10 performs corrections including syntax such as lookahead, lookbehind, and backreference, which are widely used extensions in the real world. Therefore, according to the present embodiment, it is possible to correct the vulnerability of regular expressions used in the real world.

[0064] Furthermore, according to the present embodiment, it becomes possible to ensure that the regular expression used in a web service or the like is not vulnerable, and it becomes possible to protect the service from the threat of ReDoS.

[0065] Also, the generation unit 131 generates the strings of the first set and the strings of the second set from only the characters that appear in the first regular expression. Thereby, the correction device 10 can efficiently create a set of strings (Positive Examples) accepted by the input regular expression and a set of strings (Negative Examples) rejected by the input regular expression.

[0066] Also, the synthesis unit 132 replaces at least a part of the range characters in the first regular expression with a placeholder, and synthesizes the second regular expression based on a template in which the replaced placeholder is further replaced with a predetermined syntax. Thereby, the correction device 10 can eliminate the vulnerability with a minimum of replacement.

[0067] Also, the synthesis unit 132 synthesizes the second regular expression based on a template in which the placeholder included in the template is replaced with any one of "□□", "□|□", "□*", "(□)", "\i", "(?=□)", "(?!□)", "(?<=□)", "(?<!□)", which is a predetermined syntax including a placeholder (where □ is a placeholder). Thereby, the correction device 10 can replace the part causing the vulnerability in the regular expression with a syntax without vulnerability.

[0068] [Verification Device of the First Embodiment] Subsequently, a verification device for verifying whether or not the vulnerability of the regular expression has been corrected will be described.

[0069] First, the configuration of the verification device according to the first embodiment will be described with reference to Fig. 8. Fig. 8 is a diagram showing an example of the configuration of the verification device according to the first embodiment. As shown in Fig. 8, the verification device 20 accepts input of a regular expression and outputs the result of verifying whether or not vulnerabilities in the input regular expression have been fixed.

[0070] Here, the regular expression input to the verification device 20 does not necessarily follow the Backus-Naur form. Also, it is assumed that it is unknown whether the regular expression input to the verification device 20 has been corrected by the correction device 10.

[0071] As shown in FIG. 8, the verification device 20 includes an interface unit 21, a storage unit 22, and a control unit .

[0072] The interface unit 21 is an interface for inputting, outputting, and communicating data. For example, the interface unit 21 accepts data input from input devices such as a keyboard and a mouse. Also, for example, the interface unit 21 outputs data to output devices such as a display and a speaker.

[0073] The interface unit 21 may also be a device (for example, a NIC) for performing communication via a network.

[0074] The storage unit 22 is a storage device such as an HDD, SSD, or optical disk. The storage unit 22 may also be a data-rewritable semiconductor memory such as RAM, flash memory, or NVSRAM. The storage unit 22 stores an OS and various programs executed by the verification device 20.

[0075] The control unit 23 controls the entire verification device 20. The control unit 23 is, for example, an electronic circuit such as a CPU, an MPU, or a GPU, or an integrated circuit such as an ASIC or an FPGA.

[0076] The control unit 23 also has an internal memory for storing programs defining various processing procedures and control data, and executes each process using the internal memory. The control unit 23 also functions as various processing units by running various programs. For example, the control unit 23 has a first determination unit 231 and a second determination unit 232.

[0077] The first determination unit 231 determines whether the regular expression complies with a pre-specified syntax, and the second determination unit 232 determines whether a condition is satisfied indicating that the processing time required for analyzing a character string using the regular expression is linear with respect to the length of the character string.

[0078] That is, the verification by the verification device 20 is realized by two-stage determination by the first determination unit 231 and the second determination unit 232. Furthermore, the first determination unit 231 performs a simpler inspection than the second determination unit 232.

[0079] If the first judgment unit 231 judges that the specified syntax is followed and the second judgment unit 232 judges that the condition is satisfied, the verification device 20 outputs a verification result that the vulnerability of the regular expression has been corrected (or is likely to have been corrected).

[0080] Conversely, if the first judgment unit 231 judges that the specified syntax is not followed, or if the second judgment unit 232 judges that the condition is not satisfied, the verification device 20 outputs a verification result that the vulnerability of the regular expression has not been corrected (or is likely to have not been corrected).

[0081] The first determination unit 231 determines whether or not the input regular expression is composed of the operators shown in Fig. 2. In this case, it can be said that the first determination unit 231 determines whether or not the regular expression complies with the syntax of a regular expression according to the Backus-Naur Form.

[0082] The first determination unit 231 can make the determination using a known syntax analyzer such as ANTLR (Another Tool for Language Recognition) (Reference: https: / / www.antlr.org / ).

[0083] The second determination unit 232 determines that the condition is met if the regular expression satisfies RWS1U (Reference: "Repairing DoS Vulnerability of Real-World Regexes", https: / / www.computer.org / csdl / proceedings-article / sp / 2022 / 131600b049 / 1A4Q3TnrBZK).

[0084] RWS1U guarantees that the processing time required for a regular expression to parse a string is linear with respect to the length of the string.

[0085] This is a sufficient condition to guarantee that the processing time for a regular expression, when input to a regular expression engine with arbitrary input, is always linear with respect to the input length.

[0086] A method for determining whether a regular expression satisfies RWS1U will be described with reference to Fig. 9. Fig. 9 is a diagram for explaining the RWS1U determination method.

[0087] 9, the second determination unit 232 removes look-ahead from the input regular expression (step S1). The second determination unit 232 performs the removal by replacing the look-ahead with a null character ε.

[0088] Here, the input regular expression is assumed to be "[abc]*(?=a)\1". The lookahead includes the positive lookahead "(?=r)" and the negative lookahead "(?!r)" shown in FIG. 2.

[0089] Next, the second determination unit 232 performs bracketing on the regular expression from which the look-ahead has been removed (step S2). Specifically, the second determination unit 232 converts the regular expression into a syntax analysis tree (AST), assigns a unique number i to each vertex of the syntax analysis tree, and i …] i " and then convert the parse tree back to a regular expression.

[0090] 10 is a diagram illustrating a parse tree. As shown in FIG. 10, the second determination unit 232 converts the regular expression "[abc]*\1" from which lookahead has been removed into a parse tree and surrounds each vertex with brackets. Then, the second determination unit 232 converts the parse tree back into the regular expression "[1[2([3abc]3)*]2[4\1]4]1".

[0091] Then, the second determination unit 232 constructs a nondeterministic finite automaton (NFA) from the regular expression to which the brackets are added, using a method that extends the Thompson construction method (step S3).

[0092] Here, the second determination unit 232 checks whether there is a vertex on the NFA where there are multiple different paths that can reach the same character by passing only through brackets and ε transitions (null character transitions). If such a vertex exists, the second determination unit 232 determines that the regular expression does not satisfy RWS1U.

[0093] FIG. 11 is a diagram showing an example of a path. The NFA in FIG. 11 is constructed in step 3 of FIG. 9. As shown in FIG. 11, there are two paths from the leftmost vertex to "a". Therefore, the second determination unit 232 determines that the regular expression "[abc]*(?=a)\1" does not satisfy RWS1U.

[0094] In this way, the second judgment unit 232 converts the regular expression from which lookahead has been removed and brackets have been added into a non-deterministic finite automaton, and judges that the condition is satisfied if there is no vertex on the non-deterministic finite automaton where there are different paths that can reach the same character through only bracket and null character transitions.

[0095] Fig. 12 is a flowchart showing the flow of processing by the verification device according to the first embodiment. As shown in Fig. 12, first, the verification device 20 receives input of a regular expression (step S11).

[0096] Next, the verification device 20 performs a simple check on the input regular expression (step S12). The simple check corresponds to the determination process by the first determination unit 231.

[0097] If the result of the simple inspection is that the regular expression does not conform to the default syntax (No in step S13), the verification device 20 outputs a message indicating that the vulnerability of the regular expression has not been corrected (step S17). For example, if the input regular expression does not conform to the syntax of a regular expression according to the Backus-Naur Form, the verification device 20 determines No in step S13, and otherwise determines Yes in step S13.

[0098] On the other hand, if the regular expression is a default syntax (Yes at step S13), the verification device 20 performs an RWS1U check (step S14). The RWS1U check corresponds to the determination process by the second determination unit 232.

[0099] If the result of the RWS1U check shows that the regular expression does not satisfy RWS1U (No in step S15), the verification device 20 outputs that the vulnerability of the regular expression has not been corrected (step S17). For example, if there is a vertex with multiple paths that reach the same character as in Figure 11, the verification device 20 determines No in step S15, and otherwise determines Yes in step S15.

[0100] On the other hand, if the regular expression satisfies RWS1U (Yes at step S15), the verification device 20 outputs a message indicating that the vulnerability of the regular expression has been fixed (step S16).

[0101] The flow of the RWS1U inspection (corresponding to step 14 in FIG. 12) will be described in detail with reference to FIG. 13. FIG. 13 is a flowchart showing the flow of the RWS1U inspection process.

[0102] First, the verification device 20 removes lookahead from the regular expression (step S141), and then performs syntax analysis and bracketing on the regular expression from which lookahead has been removed (step S142).

[0103] Here, the verification device 20 constructs an NFA from the parse tree (step S143). Then, the verification device 20 determines whether a specific path exists on the NFA (step S144). For example, a specific path is a plurality of different paths that can reach the same character from a certain vertex.

[0104] If a specific path exists (Yes at step S144), the verification device 20 determines that the regular expression does not satisfy RWS1U (step S145).

[0105] On the other hand, if the specific path does not exist (No at step S144), the verification device 20 determines that the regular expression satisfies RWS1U (step S146).

[0106] [Effects of verification equipment] As explained above, the first determination unit 231 of the verification device 20 determines whether a regular expression conforms to a pre-specified syntax. The second determination unit 232 determines whether a condition indicating that the processing time required for analyzing a character string using the regular expression is linear with respect to the length of the character string is satisfied. This makes it possible to verify the likelihood that a vulnerability in the regular expression has been fixed.

[0107] Furthermore, according to the embodiment, the effectiveness of proposed or remediation techniques for vulnerabilities in regular expressions can be evaluated, contributing to the avoidance of vulnerable regular expressions.

[0108] Furthermore, the second determination unit 232 determines that the condition is satisfied if the regular expression satisfies RWS1U. For example, the second determination unit 232 converts the regular expression from which lookaheads have been removed and brackets have been added into a nondeterministic finite automaton, and determines that the condition is satisfied if there is no vertex on the nondeterministic finite automaton where different paths exist that can reach the same character through only transitions between brackets and null characters.

[0109] This makes it possible to narrow down regular expressions that need to be corrected by the correction device 10, thereby improving the efficiency of processing. It is assumed that regular expressions corrected by the correction device 10 satisfy RWS1U.

[0110] By combining the modification device 10 and the verification device 20, it is possible to more efficiently perform processing related to modifying vulnerabilities in regular expressions. Based on the above embodiment, a modification system that combines the modification device 10 and the verification device 20 can be implemented.

[0111] That is, the correction system includes a correction device 10 and a verification device 20. The verification device 20 includes a first determination unit 231 that determines whether a first regular expression complies with a pre-specified syntax, and a second determination unit 232 that determines whether a condition indicating that the processing time required for analyzing a character string using the first regular expression is linear with respect to the length of the character string is satisfied. The modification device 10 has a generation unit 131 that generates a first set, which is a set of strings accepted by the first regular expression, and a second set, which is a set of strings rejected by the first regular expression, when the first determination unit 231 determines that the first regular expression does not conform to a specified syntax, or when the first determination unit 231 determines that the first regular expression conforms to a specified syntax and the second determination unit 232 determines that a condition is not met for the first regular expression (for example, when the first regular expression does not satisfy RWS1U), and a synthesis unit 132 that synthesizes a second regular expression, which is a regular expression in which range characters in the first regular expression are replaced with a predetermined syntax, and which accepts strings in the first set and rejects strings in the second set.

[0112] [System configuration, etc.] Furthermore, the components of each device shown in the figure are functional concepts and do not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of each device is not limited to that shown, and all or part of the devices can be functionally or physically distributed or integrated in any unit depending on various loads, usage conditions, etc. Furthermore, all or any part of the processing functions performed by each device can be realized by a CPU (Central Processing Unit) and a program analyzed and executed by the CPU, or can be realized as hardware using wired logic. Note that the program may be executed not only by the CPU but also by other processors such as a GPU.

[0113] Furthermore, among the processes described in this embodiment, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using a known method.In addition, the information including the processing procedures, control procedures, specific names, various data and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified.

[0114] [program] In one embodiment, the verification device 20 can be implemented by installing a verification program that executes the above-described verification process as package software or online software on a desired computer. For example, by executing the above-described verification program on an information processing device, the information processing device can function as the verification device 20. The information processing device referred to here includes desktop and notebook personal computers. In addition, the information processing device also includes mobile communication terminals such as smartphones, mobile phones, and PHS (Personal Handyphone Systems), as well as slate terminals such as PDAs (Personal Digital Assistants).

[0115] The verification device 20 can also be implemented as a verification server device that provides services related to the above-mentioned verification process to a client terminal device used by a user. For example, the verification server device is implemented as a server device that provides a verification service that takes a regular expression as input and outputs a verification result indicating whether a vulnerability in the regular expression has been fixed. In this case, the verification server device may be implemented as a Web server or as a cloud that provides services related to the above-mentioned verification process by outsourcing.

[0116] 14 is a diagram showing an example of a computer that executes a verification program. The computer 1000 includes, for example, a memory 1010 and a CPU 1020. The computer 1000 also includes a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0117] The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM (Random Access Memory) 1012. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1100. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, for example. The video adapter 1060 is connected to a display 1130, for example.

[0118] The hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, the program that defines each process of the verification device 20 is implemented as a program module 1093 in which computer-executable code is written. The program module 1093 is stored, for example, in the hard disk drive 1090. For example, a program module 1093 for executing processes similar to those of the functional configuration of the verification device 20 is stored in the hard disk drive 1090. The hard disk drive 1090 may be replaced by an SSD (Solid State Drive).

[0119] Furthermore, setting data used in the processing of the above-described embodiment is stored as program data 1094, for example, in the memory 1010 or the hard disk drive 1090. Then, the CPU 1020 reads the program module 1093 or the program data 1094 stored in the memory 1010 or the hard disk drive 1090 into the RAM 1012 as necessary, and executes the processing of the above-described embodiment.

[0120] The program module 1093 and program data 1094 are not limited to being stored in the hard disk drive 1090, but may also be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected via a network (such as a local area network (LAN) or a wide area network (WAN)). The program module 1093 and program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070. [Explanation of symbols]

[0121] 10 Correction device 11, 21 Interface section 12, 22 Storage section 13, 23 Control section 20 Verification Device 121 Replacement candidate syntax information 131 Generation part 132 Synthesis Section 231 First Judgment Section 232 Second Judgment Section

Claims

1. a first determination unit that determines whether the regular expression conforms to a pre-specified syntax; a second determination unit that determines whether a processing time required for analyzing a character string using the regular expression is linear with respect to a length of the character string, based on whether the regular expression satisfies RWS1U; A verification device comprising:

2. A first determination unit that determines whether a regular expression conforms to a pre-specified syntax; a second determination unit that determines whether a condition indicating that a processing time required for parsing a character string using the regular expression is linear with respect to the length of the character string is satisfied; and The second judgment unit converts the regular expression from which lookahead has been removed and brackets have been added into a non-deterministic finite automaton, and judges that the condition is satisfied if there is no vertex on the non-deterministic finite automaton where different paths exist that can reach the same character through only bracket and null character transitions.

3. A verification method performed by a verification device, comprising: a first determination step of determining whether the regular expression conforms to a pre-specified syntax; a second determination step of determining whether a processing time required for analyzing a character string using the regular expression is linear with respect to the length of the character string, based on whether the regular expression satisfies RWS1U; A verification method comprising:

4. A verification method executed by a verification device, comprising: a first determination step of determining whether the regular expression conforms to a pre-specified syntax; a second determination step of determining whether a condition indicating that the processing time required for parsing a string using the regular expression is linear with respect to the length of the string is satisfied; Including, The second determination step is a verification method characterized in that the regular expression from which lookahead has been removed and brackets have been added is converted into a non-deterministic finite automaton, and if there is no vertex on the non-deterministic finite automaton where there are different paths that can reach the same character through only bracket and null character transitions, it is determined that the condition is satisfied.

5. a first determination step of determining whether the regular expression conforms to a pre-specified syntax; a second determination step of determining whether a processing time required for analyzing a character string using the regular expression is linear with respect to the length of the character string, based on whether the regular expression satisfies RWS1U; A verification program that causes a computer to execute the above.

6. A first determination step of determining whether the regular expression conforms to a pre-specified syntax; a second determination step of determining whether a condition indicating that the processing time required for parsing a string using the regular expression is linear with respect to the length of the string is satisfied; on the computer, The second determination step converts the regular expression from which lookaheads have been removed and brackets have been added into a non-deterministic finite automaton, and determines that the condition is satisfied if there is no vertex on the non-deterministic finite automaton where different paths exist that can reach the same character through only bracket and null character transitions.

Citation Information

Patent Citations

  • Modification device, modification method, and modification program

    WO2022113308A1