JP2012043344A - Information processor, information processing method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To avoid information leakage and data corruption which results from an improper data manipulation instruction by SQL injection issued when measures are insufficient against SQL injection by a malicious cracker, in a system containing a database.SOLUTION: To achieve security of a database, risk of reducing rules used in reducing data manipulation instructions is properly judged, and data manipulations having malicious intention are restricted.

Description

  The present invention relates to an information processing method, apparatus, and program for taking measures against attacks that alter a database or illegally obtain information from the database.

  In recent years, the capacity of storage and recording media has been increasing, and the data processing load such as search is increasing even in relatively small devices. In a large-scale system such as a server, a database management system (DBMS) has been devised in order to cope with an increase in data processing load, and an application generally constructs a system using a database. The DBMS can standardize the data format and usage procedure and make the database independent of a specific application.

  The use of a database has also been proposed for small-scale systems such as devices, and many databases (embedded databases) suitable for embedded devices have been proposed and used.

  The database can easily describe complicated data operations for a large amount of data sets by using a data access language such as SQL. Therefore, the application development load can be reduced. On the other hand, it is possible to easily operate the data in the database through the application using SQL, and from the viewpoint of security, there is a risk that confidentiality is lowered and information is illegally acquired. SQL injection is one example.

SQL injection occurs because the developer codes the application program based on the belief that “the user must input the correct (desired) character string”. A malicious system cracker assumes that a database accessed by an application can be operated with SQL, the most common language. Therefore, a character string that becomes a part of the SQL sentence is input in response to the user input prompt of the application. If the application connects to the SQL statement without selecting the character string, the cracker aims to execute the SQL statement with an unauthorized intention on the database. With SQL injection, the cracker performs illegal actions such as bypassing user authentication, obtaining unauthorized data in the database comprehensively, or destroying inconvenient data.
Many countermeasures against such SQL injection have been proposed so far.

  The most standard method is to always use special characters in the user input character string after escaping them, or to make the user input character string a placeholder. A placeholder is a process of substituting a symbol typically indicated by “?” At a position where a user input character string should be placed in an SQL sentence, and binding the user input character string as a parameter to the symbol at the time of execution. Is the method. The bound value is treated as a literal. Most SQL injections can be avoided by escaping and placeholder techniques.

However, in reality, there are always developers who make mistakes. In the case of a web application, a lack of countermeasures caused a social problem that user data leaked into the city. He has suffered billions of yen due to post-system modifications, user apology / compensation, reduced sales due to reputational damage, etc.
In order to avoid damage due to such countermeasure omission, there has been a system that detects a vulnerability on the application program side in advance.

  For example, Patent Document 1 monitors the execution status of an application program, and executes a character string operation with a possibility of illegal SQL injection by changing it to an appropriate SQL sentence. The execution status of the application program is monitored, and a program code execution location where a partial character string that is not fixed but has the possibility of SQL injection is added to the SQL statement is detected. Then, a partial character string that is not fixed is changed into an SQL sentence that is processed as a parameter, and executed.

JP 2009-129128 A

  The injection countermeasure technique using escape and placeholder has a drawback that if a person happens to forget the countermeasure in an application program, damage occurs.

  Further, in the countermeasure according to [Patent Document 1], a fixed command sentence in which a character string having a possibility of SQL injection is parameterized is dynamically created without interpreting the meaning of the character string. Appropriate judgment is not made as to whether the input character string has illegal intentions. Therefore, for example, it is not possible to distinguish whether the data operation condition of the input character string is invalid and should not be executed, or it may be executed because it is a normal data operation condition. In addition, when a special database operation command is included in the input character string of an authorized user, it is not possible to flexibly cope with the database operation command.

  The present invention has been made in view of the above problems, and provides an information processing apparatus, a method thereof, and a program for appropriately determining SQL injection with an unauthorized intention and restricting database operations. Objective.

  An information processing apparatus according to the present invention has the following configuration. That is, a receiving means for receiving a data operation instruction for performing a data operation on a database, a holding rule for holding a reduction rule for reducing the data operation instruction, and a determination item for risk of the data operation instruction using the reduction rule And a reduction means for reducing the data operation instruction received by the reception means using the reduction rule, and a restriction means for restricting the data operation when the reduction rule that is dangerous in the reduction means is used.

  According to the present invention, since the risk of a data operation command is flexibly determined, data operation with an unauthorized intention can be restricted and the security of the database can be improved.

It is a block diagram which shows the whole structure of the data processor of this embodiment. It is the figure which showed the example of the SQL sentence which implement | achieves the login screen in the data processor of this embodiment, and a login permission process. It is the figure which showed the example of the SQL statement which implement | achieves the log list screen in the data processor of this embodiment, and a log list creation process. It is the figure which showed the example of the SQL injection attack in the login screen and log list screen of the data processor of this embodiment. It is the figure which showed the structure of the user list table in the data processor of this embodiment, a log table, and a counter table. It is the figure which showed the example of the grammar of the SQL sentence which the data processor of this embodiment accepts. It is the figure which showed the example of the structure of the parsing tree of the result of having parsed the SQL sentence in the data processor of this embodiment, and the reduction. It is the figure which showed the example of conversion from a SQL intermediate language and a SQL sentence in the data processor of this embodiment. It is the figure which showed the example of the reduction of the SQL intermediate language in the data processor of this embodiment. It is the figure which showed the example of the parsing tree reduction rule and the instruction sequence reduction rule in the data processor of this embodiment. It is the figure which showed the example of the high risk list | wrist in the data processor of this embodiment. It is a flowchart which shows an example of the process sequence of the whole data processor of this embodiment. It is a flowchart which shows an example of the process sequence of a login process. It is a flowchart which shows an example of the process sequence of a log list display process. 3 is a flowchart illustrating an example of a processing procedure of database processing according to the first embodiment. It is the figure which showed the example of the structure of the external production | generation intermediate language table in the data processor of this embodiment. 10 is a flowchart illustrating an example of a processing procedure of database processing according to the second embodiment. 14 is a flowchart illustrating an example of a processing procedure of database processing according to the third embodiment.

<Embodiment 1>
DESCRIPTION OF EMBODIMENTS Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the drawings.

FIG. 1 is a block diagram showing the configuration of the data processing apparatus of this embodiment.
In the configuration shown in the figure, the CPU 1-1 is a microprocessor, and performs operations such as login processing, log list display processing, screen control processing, copy processing, printing processing, scanning processing, logical determination, etc., via the bus. Control each device connected to the bus.

BUS1-7 is a bus and transfers an address signal and a control signal instructing each device to be controlled by the microprocessor CPU1-1. Data transfer between devices is also performed.
The input unit 1-2 is a button, a touch panel, a keyboard, a mouse, or the like, and an operator gives various instructions.
The display unit 1-3 is a liquid crystal display or the like.
The reading unit 1-4 is a scanner. The original is read and converted into electronic data.
The printing unit 1-5 is a printer. Print out electronic data on paper. If the electronic data of the original read by the reading unit 1-4 is directly printed out on paper by the printing unit 1-5, a copy function of the original can be realized.
The communication unit 1-6 is a network controller. Data exchange with the outside is performed via a communication line.

  The ROM 1-8 is a read-only nonvolatile memory. A boot program by the microprocessor CPU1-1 and initial data used in various processes are stored. The boot program loads initial data into the RAM 1-9 when the system is started, and causes the microprocessor CPU 1-1 to execute the control program. The control program will be described in detail later with reference to a flowchart.

  The RAM 1-9 is a readable / writable random access memory, and is used for primary storage of various data from each device. Various data whose values are changed during processing, such as a stack for executing an intermediate language, various work areas for temporarily storing data necessary for processing, and a buffer for temporarily storing display data necessary for display, are stored.

  The HDD 1-10 is a hard disk. It is for storing a large amount of data in a changeable manner, and can be configured by an SSD or the like. A control program or the like executed by the microprocessor CPU1-1 is also stored here, and loaded into the main memory shown in the RAM1-9 and executed as necessary. Stores user list table, log table, counter table, SQL grammar, parsing tree reduction (degeneration) rule, instruction sequence reduction (degeneration) rule, high risk list, externally generated intermediate language table, etc. used in this data processing device The contents are corrected as necessary.

  This data processing apparatus comprising such devices operates in response to various events from the input unit 1-2 or the like. When an interrupt from the input unit 1-2 or the like is supplied, an interrupt signal is sent to the microprocessor CPU1-1. Along with that, an event occurs, and according to the event, the CPU 1-1 reads out various instructions stored in the ROM 1-8 or RAM 1-9, and various controls are performed by the execution of the CPU 1-1.

  Note that the CPU of the data processing apparatus according to the first embodiment functions as various means by executing a program. Note that a control circuit such as an ASIC that operates in cooperation with the CPU may function as these means. These means may be realized by cooperation between the CPU and the control circuit. Further, the CPU need not be a single one, and may be a plurality. In this case, a plurality of CPUs execute processing in a distributed manner. The plurality of CPUs may be arranged in a single computer, or may be arranged in a plurality of physically different computers. Note that the means realized by the CPU executing the software may be realized by a dedicated circuit.

  FIG. 2 is a diagram illustrating an example of a login screen and an SQL sentence that realizes a login permission process. The screen is a touch panel, and the corresponding action can be instructed by touch. An example of the login screen is shown in FIG. Screen 2-1 is a login screen. The input column 2-1-1 is an input column for allowing the operator to input a user ID. In this example, “17412” is entered. The input field 2-1-2 is a password input field. Requests the input of the password associated with the user ID. After the input, user authentication is started by selecting (touching, etc.) a confirmation button indicated by 2-1-3. Whether or not the user ID and the password are matched is confirmed by checking with a value managed in the user list table, and it is determined whether or not the user is a valid user.

  FIG. 2B shows an example of an SQL sentence for realizing user authentication on the login screen. The SQL statement 2-2 is an SQL statement that selects a row of the user list table where the input value matches the user ID / password. If the selected line exists, it means that the user authentication is successful and login is permitted. If the selected line does not exist, user authentication has failed and login is rejected. Thus, it can be seen that a complicated data manipulation process can be easily described by using the SQL sentence.

  An example of a log list acquisition request screen is shown in FIG. A screen 3-1 is a log list acquisition request screen. An input field 3-1-1 is an input field for allowing an operator to input a user name for displaying a log list. In this example, I want to see a list of operations performed by Mr. Kimura. After the data input is completed, the log list display process is started by selecting (touching) button 3-1-2.

  An example of an SQL sentence for acquiring a log list is shown in FIG. The SQL statement 3-2 is an SQL statement that selects a log table row whose user name matches the input value. The selected line will be displayed as a log list.

  An example of the screen displaying the log list is shown in FIG. A screen 3-3 is a log list screen. In the log list 3-3-1, log information is displayed in a list together with a user ID, a user name, an operation content, and a date. A button 3-3-2 is a confirmation button. When selected (touched), the list display disappears and the log list screen 3-1 is displayed again.

  An example of the SQL injection attack is shown in FIG. An example of an attack that bypasses password authentication on the login screen is shown in FIG. Screen 4-1 shows an example of a login screen under attack. The malicious cracker has entered “17412” as the user ID in the input field 4-1-1 and “’ OR’A ”=“ A ”as the password in the input field 4-1-2. When this input is mechanically substituted into the corresponding part of the SQL sentence described with reference to FIG. 2, it becomes SQL sentence 4-2, and it can be seen that the logical expression of the password part is always true. That is, this SQL statement outputs a list of rows with the user ID “17412” as a selection result regardless of the password from the user list table. For the login application, this means that the user authentication is successful and the login is permitted, ignoring the password. Crackers are attempting to log in illegally using this technique.

  An example of a log table deletion attack on the log list screen is shown in FIG. A screen 4-3 is a log list screen under attack. The malicious cracker inputs an arbitrary SQL sentence (in this case, deletion of a table) as a user name after “Kimura ';” in the input field 4-3-1. If this input is mechanically substituted into the corresponding part of the SQL statement described in FIG. 3, it becomes SQL statement 4-4, and the row of the specified user name is selected from the log table, and then the counter table You are trying to delete and destroy information. This is a database process that is not assumed at all for the log list display application. In particular, the counter table is an important table that counts up and records a value each time a printing operation or the like is performed with this apparatus, and charges the user according to the value. Crackers are trying to avoid charging by deleting this table.

  An example of the all information acquisition attack on the log list screen is shown in FIG. A screen 4-5 is a log list screen. The malicious cracker has entered “%” as the user name in the input field 4-5-1. If this input is mechanically substituted into the corresponding portion of the SQL statement described with reference to FIG. 3, an SQL statement 4-6 is obtained. That is, this SQL statement selects a row with an arbitrary user name (%) from the log table. “%” Is a so-called wild card, which matches a character string of arbitrary length. For the log list display application, this means that all lines are output as a list regardless of the user name. All data is obtained in the cracker, and information leaks.

  FIG. 5 is a diagram showing the configuration of the user list table, log table, and counter table. Table 5-1 is a user list table. It is a table which memorize | stores the attribute of the user who logs in to this apparatus. Column 5-1-1 stores a user ID for uniquely identifying each user. Used when each user logs in. Column 5-1-2 is a user name, which is the name of each user. Column 5-1-3 is a password. The password required for authentication when each user logs in is stored. Passwords are usually not disclosed to others. Column 5-1-4 is an access level. The level of access authority that the user has is stored. For example, level 1 is the lowest level, and only a very limited table has change authority. Level 5 is the highest level and is usually given to the system administrator and has the authority to modify any table.

  Table 5-2 is a log table. When an operation is performed on this device, the operation history is recorded. A column 5-2-1 is a log ID, and stores information for uniquely identifying each log. Column 5-2-2 is an operator ID, which stores the user ID of the user who has logged in and performed the operation. A column 5-2-3 is an operator name, and stores a user name. Column 5-2-4 is the date and time, and stores the date and time information of the operation. Column 5-2-5 is a place and stores the place where the operation was performed. Columns 5-2-6 are operation types, and the types of operations performed are recorded. Operation types include printing, scanning, copying, and transmission.

  A table 5-3 is a counter table, and records the number of times for each user when a chargeable operation (for example, printing and copying) is performed. Column 5-3-1 is a user ID, and records the user who performed the operation. A column 5-3-2 is a counter value and records the number of operations to be charged.

  FIG. 6 is a diagram showing an example of the grammar of the SQL sentence. The figure is described using BNF (Background Now Form) as a grammar expression format. The grammar described in BNF can be parsed by a known technique (for example, LR method). After the SQL statement is parsed, a parse tree is created.

  FIG. 7A shows an example of a parse tree created by parsing an SQL sentence, and FIGS. 7B and 7C show examples of simplification (which is simplified and also referred to as degeneration). . The SQL statement 7-1 is parsed and a parse tree 7-2 is created. Each node in the figure shows a distinction between an operator node (illustrated by an ellipse) and an operand node (illustrated by a rectangle). The operator node stores the ID of a syntax element (“SELECT”, “WHERE”, “DROP TABLE”, etc.) of the SQL statement, and the operand node stores a value (“1”, etc.) or a variable (“UserID”, etc.). Stored. Of the parse tree shown in FIG. 7A, the subtree corresponding to “1 = 1” is “1” (true) according to the parse tree simplified (degenerate) rule number 1 shown in FIG. ). In FIG. 7C, the subtree corresponding to “UserID = 17411 OR 1” is further reduced (reduced) to “1” (true) in accordance with the parsing tree reduction (degeneration) rule number 3.

  FIG. 8A shows an example of an SQL intermediate language instruction, and FIG. 8B shows an example of conversion from an SQL sentence to an SQL intermediate language. Although the SQL statement cannot be executed by the computer, the SQL intermediate language is an execution format, and the computer can interpret and execute the format as it is. Instruction 8-1 is an example of an SQL intermediate language instruction. Although it is actually expressed by some numerical value, it is described by a character string that becomes a mnemonic (simple memory symbol) for explanation. Some commands have parameters, but they are written in alphabetic characters in parentheses in the drawing. Column 8-2 describes the operation of the instruction.

  The SQL sentence 8-3 is converted into an instruction sequence 8-4 in the SQL intermediate language. In the actual flow, syntax analysis is performed on the SQL statement to generate a parse tree, and SQL intermediate language code is generated while traversing the generated parse tree sequentially from the top node according to a predetermined rule. Become. This is a common technique for generating object code for compilers.

  An example of reduction (simplification) of the SQL intermediate language is shown in FIG. In the figure, the portion surrounded by the rectangle in the instruction sequence which is the description of the intermediate language is sequentially reduced (degenerated) in accordance with the instruction sequence reduction (degeneration) rule described later with reference to FIG. The SQL intermediate language instruction series 9-1 (same as 8-4 in FIG. 8) is reduced (degenerated) as an initial state. The instruction series surrounded by the thick line is reduced (degenerated) to the instruction series 9-2 according to the instruction series reduction (degeneration) rule number 1. The instruction series surrounded by a thick line in the instruction series 9-2 is reduced (degenerated) to the instruction series 9-3 according to the instruction series reduction (degeneration) rule number 3. The instruction series surrounded by a thick line in the instruction series 9-3 is reduced (degenerated) to the instruction series 9-4 according to the instruction series reduction (degeneration) rule numbers 4 and 5. The instruction series surrounded by a thick line in the instruction series 9-4 is reduced (degenerated) to the instruction series 9-5 according to the instruction series reduction (degeneration) rule number 6. Eventually, the instruction sequence 9-5 is equivalent to the SQL statement 9-6.

  FIG. 10A shows a parsing tree reduction (degeneration) rule, and FIG. 10B shows an example of an instruction series reduction (degeneration) rule. Column 10-1-1 is a rule number for uniquely identifying the application rule. Column 10-1-2 shows the condition of the partial parse tree before the rule is applied. Column 10-1-3 shows the state of the reduced (degenerated) partial parsing tree after the rule application. By applying the rules, the partial parse tree is reduced (simplified). Column 10-1-4 is a risk determination item for evaluating the security risk by applying the rule. “High” means that the security risk is high, and “Low” means that the security risk is low. The reduction (degeneration) in which a logical operation can be pre-computed is usually rare because it is rare to describe such an SQL, so it is a high-risk SQL and is set to “high”. On the other hand, since reduction (degeneration) such as normal arithmetic operation that is not a logical operation is a possible process, “low” is set.

  A column 10-2-1 is a rule number for uniquely identifying the application rule. A column 10-2-2 shows the condition of the partial instruction series before the rule is applied. A column 10-2-3 shows a reduced (degenerate) instruction sequence after applying the rule. The command sequence is simplified (simplified) by applying the rules. Column 10-2-4 is a value for evaluating the security risk by applying the rule. “High” means that the security risk is high, and “Low” means that the security risk is low. The instruction sequence for logical judgment can be simplified (degenerate) in advance and the execution result is fixed, so it is usually rare to describe such an instruction sequence, which is a highly dangerous instruction sequence. Therefore, “high” is set. On the other hand, reduction (degeneration) such as normal arithmetic operation that is not logical judgment is a possible process, and thus “low” is set.

  FIG. 11 is a diagram illustrating an example of a high risk list. It is a table that describes syntax elements in a parse tree that should be judged to have a high security risk, SQL intermediate language instructions, and character string patterns in parameters. Column 11-1 is a type, and indicates whether the check target is a syntax element in the parse tree, an instruction in the SQL intermediate language, or a parameter in the SQL intermediate language. In the present embodiment, the parameters in the high risk list are described as risk parameters, and the other parameters are described as risk nodes. Column 11-2 is a syntax element ID (explained by a syntax element name in the figure) if it is a syntax element, a hexadecimal code of the instruction (explained by mnemonic in the figure) if it is an instruction, and a character included if it is a parameter Indicates a column.

  The presence / absence of a true instruction can be checked depending on whether the high risk rule of FIG. 10 is applied. In FIG. 11, in addition to this, it is checked whether there is a DROP command that destroys the database or a wild card “%”.

  The above operation will be described with reference to a flowchart.

  FIG. 12 is a flowchart showing the operation of the data processing apparatus of this embodiment, more specifically, the processing procedure of the microprocessor CPU1-1. Step S12-1 is a system initialization process that initializes various parameters, displays an initial screen, and the like. Step S12-2 is a process in which the microprocessor CPU1-1 waits for an event to occur from the input unit 1-2 such as a touch panel. When an event occurs, in step S12-3, the microprocessor CPU1-1 discriminates this event and branches to various processes according to the type of event. A plurality of branch destination processes corresponding to various events are collectively expressed in the form of step S12-4. The login process described in detail in FIG. 13 and the log list display process described in detail in FIG. 14 are part of this branch destination.

  Other processes include processes such as logout processing, document copy processing, document printing processing, scanning processing, and document data management processing, although details are not described. Step S12-5 is a process of notifying the result of each process and the end of the process, and displaying the screen according to the instruction of each process. This is a process that is usually performed widely, such as displaying an error when there is an error and reflecting it on the screen display when normal processing is performed.

  FIG. 13 is a detailed flowchart of the login process that is a part of step S12-4. In step S13-1, variables and tables that need to be initialized are initialized. In step S13-2, a login screen is displayed on the liquid crystal screen. In step S13-3, as shown in the example of FIG. 2A, the operator is allowed to input a user ID and a password. In step S13-4, a query for the database is generated in order to perform user authentication in accordance with operator input data (user ID, password). In the first embodiment, an SQL statement for database inquiry as shown in the example of FIG. 2B is generated. In step S13-5, the generated query is passed to the database processing detailed in FIG. 15, and the query is executed. In step S13-6, the error code from the database process is determined. If "execution inhibition" is detected, the process branches to step S13-10, performs the process of login authentication impossibility, and returns. The processing for which login authentication is impossible not only does not accept login, but also includes processing such as warning message display, voice warning alarm, and notification to the administrator by e-mail.

  In step S13-6, if it is not “execution inhibition”, it is verified in step S13-7 whether it is an “error” such as a user name or password not being input, and if it is “error”, step S13. Branch to -8. In step S13-8, a message requesting re-input of user data is displayed on the screen, and the process loops to step S13-3. If it is not “error” in step S13-7, it is determined that the processing can be normally performed. Therefore, in step S13-9, the login is successfully performed and the login such as the access level is performed. Get information and return.

  FIG. 14 is a detailed flowchart of the log list display process that is a part of step S12-4. In step S14-1, variables and tables that need to be initialized are initialized. In step S14-2, a log list display screen is displayed on the liquid crystal screen. In step S14-3, as shown in the example of FIG. 3A, the operator inputs a display user name. In step S14-4, a query for the database is generated in order to obtain a corresponding log list according to the operator input data (display user name). In the first embodiment, an SQL statement for database inquiry as shown in the example of FIG. 3B is generated. In step S14-5, the generated query is passed to the database processing detailed in FIG. 15, and the query is executed. In step S14-6, the error code from the database process is determined, and when "execution suppression" is detected, the process branches to step S14-11, performs a process of disabling the log list, and returns. The log list disabling process not only does not accept the login, but also includes a restriction process such as a warning message display, a voice warning alarm, and a mail notification to the administrator.

  In step S14-6, if it is not “execution inhibition”, whether or not it is “error” is verified in step S14-7, and if it is “error”, the process branches to step S14-8. In step S14-8, a message requesting re-input of user data is displayed on the screen, and the process loops to step S14-3. If it is not “error” in step S14-7, it is determined that the processing can be normally performed. Therefore, in step S14-9, the log list is normally created, and step S14-10 is performed. Display the log list at, and return.

  FIG. 15 is a flowchart illustrating an example of a processing procedure of database processing according to the first embodiment. In step S15-1, the input SQL sentence is parsed to generate a parse tree as shown in the example of FIG. In step S15-2, each node in the generated parse tree is examined, and it is checked whether or not the risk node described in the high risk list of FIG. 11 is included. Assess the risk by inspection. In step S15-3, if a dangerous node is included, it should not be executed, so the process branches to step S15-11. If a dangerous node is not included, the process proceeds to step S15-4.

  In step S15-4, the parse tree is reduced (degenerate) by applying the parse tree reduction (degenerate) rule shown in FIG. 10A, and the reduction of the risk “high” during the reduction (degenerate) ( Check whether the (degenerate) rule has been applied. As a result, it can be checked whether there is a conditional expression in the parse tree, and the risk can be evaluated. In step S15-5, if there is a true conditional expression, there is a risk and it must not be executed, so the process branches to step S15-11, and if there is no true conditional expression, the process proceeds to step S15-6.

  In step S15-6, the reduced (degenerated) parse tree is converted into an SQL intermediate language to generate an instruction sequence. The reason for converting to the SQL intermediate language in step S15-6 is to make it into a format that can be interpreted and executed by the computer, and the instruction sequence is not reduced (degenerated). In step S15-7, the access authority of the currently logged-in user is confirmed. If the authority is higher than a predetermined level, the risk parameter check is avoided and the process branches to step S15-10. If the access authority is lower than the predetermined level, the process proceeds to step S15-8, the high risk list shown in FIG. 11 is searched, whether or not there is a risk parameter in the instruction sequence, and the risk is evaluated. To do. There is a possibility that dangerous parameters such as wild card search may be left in the parse tree in which the truth condition expression is reduced (degenerate). Such commands are checked here because they should only be granted to users with administrator-level access rights. In step S15-9, if a dangerous parameter is included, it is considered dangerous, and the process branches to step S15-11. If no dangerous parameter exists, the process proceeds to step S15-10.

  In step S15-10, since it has been confirmed that there is no danger or that the user has sufficient access authority, the generated instruction sequence is executed, and "normal end" or an error occurred during execution. When it returns, return with "error". Step S15-11 is a process in a situation where execution is to be suppressed, and the query is not executed, and execution returns with “execution suppression”.

<Embodiment 2>
In the embodiments described so far, the input to the database process is always an SQL sentence, and the SQL sentence is converted into the SQL intermediate language in the database process. On the other hand, when the system is constructed, the SQL sentence is converted into the SQL intermediate language in advance outside the device, and only the link information (ID etc.) to the intermediate language is retained in the program in the device, which is used for database processing. An embodiment of passing and executing is conceivable.

  FIG. 16 is a diagram showing an example of the configuration of an externally generated intermediate language table according to the second embodiment. The externally generated intermediate language table is a table that holds an instruction sequence of an intermediate language configured at the time of system construction. A column 16-1 is an instruction sequence ID, and uniquely identifies the held intermediate language instruction series. Column 16-2 is an intermediate language instruction sequence.

  In order to execute such an intermediate language, the method of invoking database processing is slightly different from that of the first embodiment. Changes in the login process of FIG. 13 and the log list display process of FIG. 14 will be described. In step S13-4 in FIG. 13 and “DB query generation” in step S14-4 in FIG. 14, the SQL statement is generated in the first embodiment. In the second embodiment, the necessary intermediate language instruction sequence is acquired from the externally generated intermediate language table. At that time, an instruction string ID of a query required at each location is held, and an intermediate language instruction string is acquired by specifying the instruction string ID.

  Further, the processing flow of database processing is changed from FIG. 15 of the first embodiment to FIG. 17 in the second embodiment.

  FIG. 17 is a flowchart illustrating an example of a processing procedure of database processing according to the second embodiment. In step S17-1, each instruction in the designated SQL intermediate language instruction sequence is examined, whether or not an instruction described in the high risk list of FIG. 11 is included, and the risk is evaluated. In step S17-2, if a dangerous instruction is included, it must not be executed, so the process branches to step S17-9. If a dangerous instruction is not included, the process proceeds to step S17-3.

  In step S17-3, the instruction sequence is reduced (degenerate) by applying the instruction sequence reduction (degeneration) rule of FIG. 10B to the instruction sequence, and the reduction (degeneration) rule of the risk “high” during the reduction (degeneration). Inspect whether the has been applied. As a result, it is possible to inspect whether there is an instruction sequence that is true in the instruction sequence, and the risk can be evaluated. In step S17-4, if there is a true instruction sequence, there is a risk and it must not be executed, so the process branches to step S17-9, and if there is no true instruction sequence, the process proceeds to step S17-5.

  In step S17-5, the access authority of the currently logged-in user is confirmed. If the authority is higher than a predetermined level, the risk parameter check is avoided and the process branches to step S17-8. If the access authority is lower than the predetermined level, the process proceeds to step S17-6, where the high risk list shown in FIG. 11 is searched to check whether a risk parameter exists in the instruction sequence, and the risk is evaluated. To do. There is a possibility that dangerous parameters such as wild card search may be left in the intermediate language instruction series in which the true instruction series is reduced (degenerated). Such commands are checked here because they should only be granted to users with administrator-level access rights. In step S17-7, when a dangerous parameter is included, it is considered dangerous, and the process branches to step S17-9. If no dangerous parameter exists, the process proceeds to step S17-8. In step S17-8, it can be confirmed that there is no risk or that the user has sufficient access authority, so the generated instruction sequence is executed, and "normal end" or an error occurs during execution. Returns “error”. Step S17-9 is a process in a situation where execution should be suppressed. Return is made with “execution suppressed” without executing the query.

  With this configuration, it is not necessary to store processes such as “SQL syntax analysis” and “intermediate language instruction sequence generation” in the apparatus, so that a smaller and less expensive apparatus can be realized.

<Embodiment 3>
In the embodiments described so far, as the database query, the SQL statement is used in the first embodiment, and the SQL intermediate language is used in the second embodiment. It was. On the other hand, an embodiment is considered in which the risk can be determined for both forms of the SQL sentence and the SQL intermediate language, and the risk level is determined to be different between the two.

  The SQL statement can be generated freely in the processing within the application, but on the other hand, since there is a high security risk, a strict inspection is performed in the database processing as will be described later. In this case, since it is not possible to perform free data processing such as wanting to DROP the table properly, in that case, an SQL intermediate language instruction sequence is used instead of an SQL statement. As will be described later, the database processing safety check for the SQL intermediate language is gradual, and the processing can be freely described. This is because the intermediate language is prepared in advance at the time of system construction and can be checked in advance, so that it can be composed of only a safe instruction sequence without the possibility of SQL injection.

  In the third embodiment, the database process calling method (login process in FIG. 13 and log list display process in FIG. 14) is slightly different from the first and second embodiments. In “DB query generation” in step S13-4 in FIG. 13, since the login process is an important process for security, the inspection is made more strict and the necessary intermediate language instruction sequence is acquired from the externally generated intermediate language table.

In the “DB query generation” in step S14-4 of FIG. 14 in the log list process, this is considered to be a relatively safe process compared to the login process, and in the third embodiment, a SQL sentence is generated.
FIG. 18 is a flowchart illustrating an example of a processing procedure of database processing according to the third embodiment. In step S18-1, it is determined whether the input is a SQL statement or a SQL intermediate language instruction sequence, and if it is an intermediate language, the conversion to the intermediate language and the risk check of the SQL statement are skipped. Branch to S18-8. As described above, in the case of the intermediate language, the risk check that is normally performed for the SQL sentence is exceptionally skipped.

  When the SQL statement is input, the process proceeds to step S18-2. In step S18-2, the input SQL statement is parsed to generate a parse tree as shown in the example of FIG. In step S18-3, each node in the generated parse tree is examined, whether or not the dangerous node described in the high risk list of FIG. 11 is included, and the risk is evaluated. In step S18-4, if a dangerous node is included, it must not be executed, so the process branches to step S18-12. If a dangerous node is not included, the process proceeds to step S18-5.

  In step S18-5, the parse tree is converted into an SQL intermediate language to generate an instruction sequence. In step S18-6, the instruction sequence is reduced (degenerate) by applying the instruction sequence reduction (degeneration) rule shown in FIG. 10B to the instruction sequence, and the reduction (degeneration) of the risk “high” is performed during the reduction (degeneration). ) Check whether the rules have been applied. As a result, it is possible to inspect whether there is an instruction sequence that is true in the instruction sequence, and the risk can be evaluated. In step S18-6, the parse tree of the SQL sentence is reduced (degenerate) by applying the parse tree reduction (degenerate) rule shown in FIG. 10A, and the risk “high” during the reduction (degenerate). It may be checked whether or not the simplified (degenerate) rule is applied.

  In step S18-7, if there is a true instruction sequence, there is a risk and it must not be executed. Therefore, the process branches to step S18-12, and if there is no true instruction sequence, the process proceeds to step S18-8.

  In step S18-8, the access authority of the currently logged-in user is confirmed. If the authority is higher than a predetermined level, the risk parameter check is avoided and the process branches to step S18-11. If the access authority is lower than the predetermined level, the process proceeds to step S18-9, the high risk list shown in FIG. 11 is searched, whether or not there is a risk parameter in the instruction sequence, and the risk is evaluated. To do. In step S18-10, when a dangerous parameter is included, it is considered dangerous, and the process branches to step S18-12. If no dangerous parameter exists, the process proceeds to step S18-11.

  In step S18-11, since it has been confirmed that there is no danger or that the user has sufficient access authority, the generated instruction sequence is executed, and "normal end" or an error occurs during execution. When it returns, return with "error". Step S18-12 is a process in a situation where execution is to be suppressed. The query is not executed, and execution returns with “execution suppression”.

  As described above, in the third embodiment, a query that is indispensable for processing but can be regarded as dangerous is executed by a pre-prepared SQL intermediate language instruction sequence, and a query described by a normal SQL statement has no danger at all. Be sure to limit to queries that are allowed to execute. By constructing in this way, it is possible to realize a safe and flexible device by excluding sophisticated queries that can be interpreted as dangerous while excluding dangerous queries from the security aspect at the time of system construction. it can.

  Although the embodiment has been described in detail above, the present invention is not limited to the above-described embodiment, and can be appropriately changed without departing from the gist of the present invention.

  The present invention can take the form of, for example, a system, apparatus, method, program, or storage medium. Specifically, the present invention may be applied to a system composed of a plurality of devices, or may be applied to an apparatus composed of a single device.

  The present invention can also be realized by executing the following processing. That is, software (program) that realizes the functions of the above-described embodiments is supplied to a system or apparatus via a network or various storage media, and a computer (or CPU, MPU, or the like) of the system or apparatus reads the program. It is a process to be executed.

CPU Microprocessor BUS Bus ROM Read-only nonvolatile memory RAM Read / write random access memory HDD Hard disk

Claims (8)

A receiving means for receiving a data operation command for performing a data operation on the database;
Holding means for holding a reduction rule for reducing the data operation instruction, and a determination item for risk of the data operation instruction using the reduction rule;
A reduction means for reducing the data operation instruction received by the reception means using the reduction rule;
An information processing apparatus comprising: a restriction unit that restricts the data operation when the reduction rule having a risk is used in the reduction unit.   The holding means holds that the danger exists when the condition of the data operation instruction becomes true by the reduction of the data operation instruction using the reduction rule. The information processing apparatus described.   The information processing apparatus according to claim 1, wherein the data operation instruction is expressed in SQL.   The information processing apparatus according to claim 1, wherein the data operation instruction is expressed in an intermediate language that is a computer-executable format.   The information processing apparatus according to claim 4, wherein the intermediate language is created in advance by an external device.   And further comprising a discriminating unit for discriminating a type of the data operation command received by the receiving unit, and when it is determined that the data operation command is expressed in an intermediate language, the data operation is executed without performing the reduction. The information processing apparatus according to claim 1, wherein permission is granted. A reception process for receiving a data operation instruction for performing data operation on the database;
With reference to a holding means for holding a reduction rule for reducing the data operation instruction and a risk determination item of the data operation instruction using the reduction rule, the data operation instruction received in the reception step is changed to the reduction rule. A reduction process that uses and reduces,
An information processing method comprising: a restriction step of restricting the data operation when the reduction rule that is dangerous in the reduction step is used. Computer
A receiving means for receiving a data operation command for performing a data operation on the database;
Holding means for holding a reduction rule for reducing the data operation instruction, and a determination item for risk of the data operation instruction using the reduction rule;
A reduction means for reducing the data operation instruction received by the reception means using the reduction rule;
A program for functioning as a restricting means for restricting the data operation when the reduction rules that are dangerous in the reducing means are used.

Images