Correction device, correction method, and correction program
The device efficiently corrects vulnerabilities in regular expressions by extracting, assessing, and synthesizing non-vulnerable expressions using nondeterministic finite automata, addressing ReDoS and supporting real-world syntax, thus enhancing security in applications.
Patent Information
- Application Number
- JP2024526079
- 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
Conventional techniques face difficulties in efficiently correcting vulnerabilities in regular expressions used in real-world applications, particularly those involving syntax corrections like lookahead, lookbehind, and backreferences, and are not specialized in fixing vulnerable regular expressions within source code.
A device and method that includes an extraction unit to extract regular expressions from source code, a determination unit to assess vulnerability to ReDoS, and a synthesis unit to generate a non-vulnerable regular expression by replacing range characters with predetermined syntax, utilizing nondeterministic finite automata and Thompson construction.
Efficiently corrects vulnerabilities in regular expressions, ensuring they run in linear time, thereby preventing Regular Expression Denial of Service (ReDoS) attacks, and supporting real-world syntax extensions.
Smart Images

Figure 0007800678000001 
Figure 0007800678000002 
Figure 0007800678000003
Abstract
Description
[Technical Field]
[0001] The present invention relates to a correction device, a correction method, and a correction 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, conventional techniques have the problem that it is sometimes difficult to efficiently fix vulnerabilities in regular expressions used in the real world.
[0008] For example, the technology described in Non-Patent Document 1 corrects errors in regular expressions but does not correct vulnerabilities. Also, for example, the technology described in Non-Patent Document 2 does not support syntax corrections such as lookahead, lookbehind, and backreferences, which are extensions widely used in the real world.
[0009] In practice, vulnerable regular expressions may be used in the source code of a program that uses a regular expression engine. However, conventional techniques are not specialized in correcting vulnerable regular expressions in source code. [Means for solving the problem]
[0010] In order to solve the above-mentioned problems and achieve the objectives, the modification device is characterized by having an extraction unit that extracts a first regular expression from source code, a determination unit that determines whether the first regular expression satisfies a condition indicating vulnerability to ReDoS, and a synthesis unit that synthesizes a second regular expression that does not satisfy the condition based on the first regular expression. [Effects of the Invention]
[0011] According to the present invention, vulnerabilities in regular expressions used in the real world can be efficiently corrected. [Brief explanation of the drawings]
[0012] [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 illustrating a method for extracting a list of regular expressions. [Figure 4] FIG. 4 is a diagram illustrating an example of an NFA. [Figure 5] FIG. 5 is a diagram illustrating an example of a path on the NFA. [Figure 6]FIG. 6 is a diagram showing examples of Positive Examples and Negative Examples. [Figure 7] FIG. 7 is a diagram illustrating a method for generating a set of character strings. [Figure 8] FIG. 8 is a diagram for explaining a method for synthesizing regular expressions. [Figure 9] FIG. 9 is a flowchart showing the flow of processing by the repair device according to the first embodiment. [Figure 10] FIG. 10 is a flowchart showing the flow of the regular expression correction process. [Figure 11] FIG. 11 is a flowchart showing the flow of the regular expression synthesis process. [Figure 12] FIG. 12 is a diagram illustrating an example of a computer that executes a correction program. DETAILED DESCRIPTION OF THE INVENTION
[0013] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Preferred embodiments of a repair device, a repair method, and a repair 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.
[0014] [Configuration of the first embodiment] 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 input of source code, corrects regular expressions included in the input source code, and outputs the corrected regular expressions.
[0015] Here, the regular expressions in this embodiment are regular expressions that have been extended to fit the real world, and comply with the syntax defined in Backus-Naur form (BNF). FIG. 2 is a diagram showing an example of the syntax of a regular expression. 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.
[0016] 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).
[0017] 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.
[0018] 1, the description will be given of each unit of the correction device 10. As shown in FIG.
[0019] 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.
[0020] The interface unit 11 may also be a device for performing communication via a network (for example, a network interface card (NIC)).
[0021] The storage unit 12 is a storage device such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), an optical disk, etc. The storage unit 12 may also be a data-rewritable semiconductor memory such as a RAM (Random Access Memory), a flash memory, or an NVSRAM (Non Volatile Static Random Access Memory). The storage unit 12 stores an OS (Operating System) and various programs executed by the correction device 10.
[0022] The storage unit 12 stores substitution candidate syntax information 121. The substitution candidate syntax information 121 is a set of regular expressions or templates, and the syntax of regular expressions to be replaced with range characters or holes.
[0023] For example, the substitution candidate syntax information 121 is "□□, □|□, □*, (□), \i, (?=□), (?!□), (?<=□), (?<!□)". However, "□" is a hole. Holes and templates will be described later.
[0024] 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), GPU (Graphics Processing Unit), or an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array).
[0025] 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. Further, the control unit 13 functions as various processing units when various programs operate. For example, the control unit 13 includes an extraction unit 131, a determination unit 132, a generation unit 133, and a synthesis unit 134.
[0026] The extraction unit 131 extracts the regular expression before correction from the source code. The determination unit 132 determines whether the regular expression before correction satisfies the condition indicating vulnerability to ReDoS. Then, the synthesis unit 134 synthesizes a regular expression after correction that does not satisfy the condition based on the regular expression before correction.
[0027] Note that the regular expression before correction is an example of the first regular expression. Also, the regular expression after correction is an example of the second regular expression.
[0028] In this way, the synthesis unit 134 performs the correction process on the regular expressions that are extracted from the source code by the extraction unit 131 and are vulnerable to ReDoS. This prevents the synthesis unit 134 from performing the correction process on regular expressions that do not actually need to be corrected.
[0029] Furthermore, since the source code, not the regular expression itself, is input to the modifying device 10, it is possible to omit pre-processing steps such as extracting the regular expression from the source code in advance.
[0030] 3 is a diagram illustrating a method for extracting a list of regular expressions. As shown in FIG. 3, first, the extraction unit 131 performs a syntax analysis of the source code and constructs a syntax analysis tree (for example, an AST (Abstract Syntax Tree)) (step S1).
[0031] The extraction unit 131 can analyze the source code using a syntax analysis function provided according to the programming language the source code is written in. For example, if the programming language is Python, the extraction unit 131 analyzes the source code using ANTLR (Another Tool for Language Recognition) (Reference: https: / / www.antlr.org / ).
[0032] Furthermore, the extraction unit 131 performs analysis on the AST to obtain a list of regular expressions (step S2). In this way, the extraction unit 131 can create a list including one or more extracted regular expressions.
[0033] The extraction unit 131 converts the source code into a parse tree, and extracts a regular expression restored based on variables extracted from the parse tree as a regular expression before correction.
[0034] First, the extraction unit 131 traverses the AST and extracts a set of regular expressions, variable names, and values of each variable in the source code.
[0035] When a program based on source code is executed, a regular expression may be generated by combining variables. Therefore, the extraction unit 131 restores the regular expression based on a set of variable names and values.
[0036] The process of restoring a regular expression by the extraction unit 131 will be specifically described using the following source code written in the programming language Python as an example. For the sake of explanation, numbers are added to the left end of each line of the source code to distinguish the line.
[0037] (Source Code) 1: Import re 2: if input() == “example”: 3: s = "example.com" 4: else: 5: s = “example.com / abc” 6: r = 'http: / / ' + s + “.* / index[.]html” 7: re.match(r, input())
[0038] In this case, the value of regular expression r is determined by combining it with the value of variable s. Therefore, regular expression r is not determined until the value of input() in the if statement starting from the second line is determined.
[0039] The extraction unit 131 extracts a set of values {"example.com", "example.com / abc"} corresponding to the variable (name) s, and restores the regular expression r using the set.
[0040] In this case, the extraction unit 131 restores "http: / / example.com.* / index[.]html" and "http: / / example.com / abc.*index[.]html" as the regular expression r, and extracts the regular expression.
[0041] 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), the determination unit 132 determines that the regular expression is not vulnerable to ReDoS. On the other hand, if the regular expression does not satisfy RWS1U, the determination unit 132 determines that the regular expression is vulnerable to ReDoS.
[0042] The generating unit 133 performs the following process on the regular expressions that are determined by the determining unit 132 to be vulnerable to ReDoS among the regular expressions included in the list of regular expressions.
[0043] The generation unit 133 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.
[0044] The Positive Examples are an example of the first set, and the Negative Examples are an example of the second set.
[0045] The generation unit 133 converts the regular expression before correction into a nondeterministic finite automaton (NFA), generates a set of strings obtained by paths on the nondeterministic finite automaton that reach an accepting state as Positive Examples, and generates a set of strings obtained by paths on the nondeterministic finite automaton that do not reach an accepting state as Negative Examples.
[0046] The generation unit 133 constructs an NFA using the Thompson construction method. However, since the Thompson construction method cannot handle captures and backreferences included in regular expressions, the generation unit 133 replaces backreferences with regular expressions in captures referenced by the backreferences by over-approximation.
[0047] For example, for the regular expression "(a*b)(c\1)\2", the generation unit 133 replaces the back reference "\1" in the capture ("(c\1)") with "a*b" to obtain "(a*b)(ca*b)\2". Furthermore, the generation unit 133 replaces the back reference "\2" with "ca*b" to obtain "(a*b)(ca*b)ca*b". Note that the capture is treated as a grouping in the Thompson construction, so it is left as is.
[0048] In this way, the generation unit 133 replaces a back reference with the regular expression in the capture referenced by the back reference. If the capture includes another back reference, the generation unit 133 first replaces the back reference with the regular expression of the capture referenced by the back reference. This eliminates the back reference from the regular expression, making it possible to use the Thompson construction.
[0049] The generation unit 133 converts the regular expression from which the back references in the capture have been removed into an NFA using the Thompson construction method. Fig. 4 is a diagram showing an example of an NFA. Fig. 5 is a diagram showing an example of a path on the NFA. The double circles in Figs. 4 and 5 represent nodes in an accepting state.
[0050] The generation unit 133 generates examples by tracing the paths of the NFA. Since paths a → c and b → d (dashed lines in FIG. 5) reach an accepting state, the generation unit 133 generates a set of Positive Examples {ac, bd}. On the other hand, paths a and b (dashed lines in FIG. 5) do not reach an accepting state, so the generation unit 133 generates a set of Negative Examples {a, b}.
[0051] The generation unit 133 can enumerate paths using known search algorithms such as breadth-first search, depth-first search, etc. However, if there is a loop in the NFA, the generation unit 133 records the paths that have been passed so as not to pass the same path more than once.
[0052] Figure 6 shows examples of Positive Examples and Negative Examples. Here, it is assumed 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).
[0053] The generation unit 133 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 133 may generate Positive Examples and Negative Examples using the method described in Non-Patent Document 1.
[0054] If all the character strings were simply listed, an explosive number of examples would be generated. To avoid this, the generation unit 133 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.
[0055] For example, if the regular expression is "ab[cd]*", the generating unit 133 generates candidate character strings by combining "a" and "b" with one character randomly selected from "[c, d]".
[0056] FIG. 7 is a diagram illustrating a method for generating a set of character strings. In the example of FIG. 7, the regular expression before correction is ".*.*@example[.]com". In this case, the generation unit 133 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 133 classifies the character strings "example.com", "@.com", "@examplecom", "@example.", etc., which are rejected by the regular expression ".*.*@example[.]com", into Negative Examples.
[0057] The synthesis unit 134 synthesizes a modified regular expression, which is a regular expression in which the range characters in the pre-modification regular expression are replaced with a predetermined syntax, and which accepts character strings of the Positive Examples and rejects character strings of the Negative Examples.
[0058] The processing by the synthesis unit 134 can be roughly divided into a step of creating a template and a step of assigning to the template.
[0059] In the step of creating a template, the synthesis unit 134 creates the template by replacing range characters in the regular expression with placeholders.
[0060] In the step of assigning to a template, the synthesis unit 134 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 "□".
[0061] The synthesis unit 134 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 the different subtrees between the ASTs of the regular expression (see, for example, Non-Patent Document 1).
[0062] When extracting an element from the queue, the synthesis unit 134 prioritizes the extraction of the stored template with the highest priority. At the start of processing, the synthesis unit 134 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.
[0063] First, the step of creating a template executed by the synthesis unit 134 will be described. When a template retrieved from the queue contains range characters, the synthesis unit 134 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 134 may replace one of the holes with a predetermined syntax.
[0064] For example, the synthesis unit 134 creates templates "□*.*=.*", ".*□*=.*", and ".*.*=□*" by replacing the range characters in the unmodified regular expression ".*.*=.*" stored in the queue as a template, and stores these in the queue. Note that once a template has been extracted, it is discarded.
[0065] In this way, the synthesis unit 134 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.
[0066] Furthermore, the synthesizing unit 134 can replace the hole with syntax such as "□□", "□|□", "□*", "(□)", "\i", "(?=□)", "(?!□)", "(?<=□)", "(?<!□)" included in the replacement candidate syntax information 121. In this case, the synthesizing unit 134 synthesizes the corrected regular expression based on a template obtained by replacing the hole included in the template with any one of "□□", "□|□", "□*", "(□)", "\i", "(?=□)", "(?!□)", "(?<=□)", "(?<!□)" which is a predetermined syntax including the hole (where □ is the hole).
[0067] Next, the step of assigning to the template executed by the synthesizing unit 134 will be described. Here, assume that the synthesizing unit 134 repeatedly creates a template, for example, creates a template "□*□*=.*" and stores it in the queue. For example, the synthesizing unit 134 obtains the template "□*□*=.*" by replacing the range character "." on the left side of the template "□*.*=.*" with a hole.
[0068] The synthesizing unit 134 searches for an assignment of range characters that satisfy the conditions for the holes included in the template. For example, the synthesizing unit 134 performs the search using a Satisfiability Modulo Theories (SMT) solver (for example, Z3 solver) or the like.
[0069] If the template is "□*□*=.*" and the Positive Examples and Negative Examples are as shown in FIG. 6, the synthesizing unit 134 can obtain an assignment of "[]*[^=]*=.*" through the search. The synthesizing unit 134 removes the empty set "[]" and obtains the regular expression "[^=]*=.*".
[0070] The regular expression "[^=]*=.*" accepts the Positive Examples and rejects the Negative Examples in Figure 6. 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.
[0071] 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.
[0072] The synthesis of invulnerable regular expressions by the synthesis unit 134 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.
[0073] 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.
[0074] Similarly, if the regular expression before correction is ".*.*@example[.]com", the synthesis unit 134 can obtain the non-vulnerable regular expression "[^@]*@example[.]com", as shown in FIG.
[0075] [Processing of the first embodiment] 9 is a flowchart showing the flow of processing by the modifying device according to the first embodiment. As shown in FIG. 9, first, the modifying device 10 receives input of source code (step S11).
[0076] Next, the modifying device 10 extracts regular expressions from the source code (step S12). For example, the modifying device 10 extracts regular expressions using a syntax analysis function corresponding to the programming language in which the source code is written.
[0077] Next, the modification device 10 determines whether the extracted regular expression is vulnerable to ReDoS (step S13).
[0078] If the extracted regular expression is not vulnerable to ReDoS (step S13, No), the modifying device 10 ends the process.
[0079] Then, the modifying device 10 modifies (step S14) the regular expressions that are determined to be vulnerable to ReDoS (step S13, Yes), and outputs the modified regular expressions (step S15).
[0080] Fig. 10 is a flowchart showing the flow of processing by the editing device according to the first embodiment. The processing in Fig. 10 corresponds to step S14 in Fig. 9. First, the editing device 10 accepts input of a regular expression (step S141).
[0081] Next, the editing device 10 generates a set of character strings (Positive Examples) that are accepted by the input regular expression (step S142). The editing device 10 also generates a set of character strings (Negative Examples) that are rejected by the input regular expression (step S143).
[0082] 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.
[0083] Subsequently, the correction device 10 generates (synthesizes) a regular expression based on the input regular expression, the accepted string, and the rejected string (step S144). Then, the correction device 10 outputs the generated regular expression (step S145).
[0084] FIG. 11 is a flowchart showing the flow of the regular expression synthesis process. The process of FIG. 11 corresponds to step S144 in FIG. 10. First, the correction device 10 stores the input regular expression in a queue as a template (step S1441).
[0085] Next, the correction device 10 obtains the template closest to the input regular expression from the queue (step S1442).
[0086] Subsequently, the correction device 10 searches for an assignment of range characters to holes such that the correction device 10 accepts the accepted string, rejects the rejected string, and satisfies the conditions regarding vulnerabilities (step S1443).
[0087] The correction device 10 determines whether an assignment of the search result exists (step S1444). If no assignment of the search result exists (step S1444, No), the correction device 10 replaces the range characters with holes or replaces the holes with a predetermined pattern (step S1445). The predetermined pattern is, for example, a syntax such as "□□", "□|□", "□*", "(□)", "\i", "(?=□)", "(?!□)", "(?<=□)", "(?<!□)". When the input regular expression stored in the queue in step S1441 becomes the target of the search in step S1443, it is regarded as having no assignment (No) in step S1444.
[0088] Then, the correction device 10 stores the processed template in step S1445 in the queue (step S1446). 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.
[0089] On the other hand, if there is an assignment in the search result (Yes at step S1444), the modifying device 10 synthesizes a non-vulnerable regular expression based on the assignment in the search result (step S1447).
[0090] [Advantages of the first embodiment] As explained above, the extraction unit 131 of the modification device 10 extracts a first regular expression from source code. The determination unit 132 determines whether the first regular expression satisfies a condition indicating vulnerability to ReDoS. The synthesis unit 134 synthesizes a second regular expression that does not satisfy the condition based on the first regular expression. This makes it possible to efficiently fix vulnerabilities in regular expressions used in the real world. For example, it is possible to omit the process of extracting regular expressions from source code in advance.
[0091] Furthermore, the embodiments can be used in practical applications such as inspecting the source code of a web application that is subject to a ReDoS attack, and can be used for testing and diagnosing the security of web applications.
[0092] Furthermore, the extraction unit 131 converts the source code into a parse tree, and extracts a regular expression restored based on variables extracted from the parse tree as a first regular expression. In this way, it is possible to dynamically restore regular expressions that are actually used when executing a program, and it is possible to cover all regular expressions to be corrected.
[0093] Furthermore, the generation unit 133 generates a first set, which is a set of character strings accepted by the first regular expression, and a second set, which is a set of character strings rejected by the first regular expression. The synthesis unit 134 synthesizes a second regular expression, which is a regular expression obtained by replacing the range character in the first regular expression with a predetermined syntax, and which accepts character strings in the first set and rejects character strings in the second set. When performing such processing, the efficiency of the processing can be improved by narrowing down regular expressions that are vulnerable to ReDoS attacks.
[0094] The generation unit 133 converts the first regular expression into a nondeterministic finite automaton, generates a first set of strings obtained by paths on the nondeterministic finite automaton that reach an accepting state, and generates a second set of strings obtained by paths on the nondeterministic finite automaton that do not reach an accepting state. This makes it possible to comprehensively obtain regular expressions to be corrected.
[0095] [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.
[0096] 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.
[0097] [program] In one embodiment, the correction device 10 can be implemented by installing a correction program that executes the above correction process as package software or online software on a desired computer. For example, by executing the above correction program on an information processing device, the information processing device can function as the correction device 10. 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).
[0098] The correction device 10 can also be implemented as a correction server device that provides a service related to the above correction process to a client terminal device used by a user. For example, the correction server device is implemented as a server device that provides a correction service that takes source code as input and outputs a corrected regular expression. In this case, the correction server device may be implemented as a web server or as a cloud that provides the above correction process service through outsourcing.
[0099] 12 is a diagram showing an example of a computer that executes a modification 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.
[0100] 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.
[0101] 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, a program that defines each process of the modification device 10 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 the same process as the functional configuration of the modification device 10 is stored in the hard disk drive 1090. The hard disk drive 1090 may be replaced by an SSD (Solid State Drive).
[0102] 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.
[0103] 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]
[0104] 10 Correction device 11 Interface section 12 Storage section 13 Control Unit 121 Replacement candidate syntax information 131 Extraction part 132 Judgment section 133 Generation part 134 Synthesis Section
Claims
1. an extraction unit that converts the source code into a parse tree and extracts a regular expression reconstructed based on variables extracted from the parse tree as a first regular expression; a determination unit that determines whether the first regular expression satisfies a condition indicating vulnerability to ReDoS; a synthesis unit that synthesizes a second regular expression that does not satisfy the condition based on the first regular expression; A repair device comprising:
2. a generator that generates a first set of strings that are accepted by a first regular expression and a second set of strings that are rejected by the first regular expression; 2. The correction device according to claim 1, wherein the synthesizing unit synthesizes a second regular expression, which is a regular expression obtained by replacing a range character in the first regular expression with a predetermined syntax, and which is a regular expression that accepts character strings in the first set and rejects character strings in the second set.
3. 3. The modification device according to claim 2, wherein the generation unit converts the first regular expression into a nondeterministic finite automaton, generates, as the first set, a set of strings obtained by paths on the nondeterministic finite automaton that reach an accepting state, and generates, as the second set, a set of strings obtained by paths on the nondeterministic finite automaton that do not reach an accepting state.
4. A repair method performed by a repair device, comprising: an extraction step of converting the source code into a parse tree and extracting a regular expression reconstructed based on variables extracted from the parse tree as a first regular expression; a determining step of determining whether the first regular expression satisfies a condition indicating vulnerability to ReDoS; a synthesis step of synthesizing a second regular expression that does not satisfy the condition based on the first regular expression; A correction method comprising:
5. an extraction step of converting the source code into a parse tree and extracting a regular expression reconstructed based on variables extracted from the parse tree as a first regular expression; a determining step of determining whether the first regular expression satisfies a condition indicating vulnerability to ReDoS; a synthesis step of synthesizing a second regular expression that does not satisfy the condition based on the first regular expression; A fix program characterized by causing a computer to execute the following.
Citation Information
Patent Citations
Source code vulnerability inspection device
JP2007052625A
Refinement of static analysis of program code
US11200144B1
Modification device, modification method, and modification program
WO2022113308A1