SQL injection prevention

• US 8,499,170 B1
• Filed: 10/08/2008
• Issued: 07/30/2013
• Est. Priority Date: 10/08/2008
• Status: Active Grant

• Current Assignee: Trend Micro Inc.
• Original Assignee: Trend Micro Inc.
• Inventors: Tongshu, Li, Jing, Zheng, Jianzheng, Lin
• Primary Examiner(s): HOFFMAN, BRANDON S
• Application Number:
  US12/247,659
• Time in Patent Office: 1,756 Days
• Field of Search: 713/193
• US Class Current: 713/193
• CPC Class Codes: G06F 21/54 by adding security routines or objects to programs
• CPC Class Codes: G06F 21/566 Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
• CPC Class Codes: G06F 21/6218 to a system of files or objects, e.g. local or distributed file system or database

Abstract

Hackers and other malicious users are prevented from injecting harmful SQL into a database and from retrieving confidential data. SQL statements formed by an application in response to user input (e.g., user Id and password), are scanned and compared to patterns of SQL commands and data embodied in one or more anti-SQL injection policies. If there is a match, the SQL statement is in violation of the policy. A severity level of the violation may be checked, for example, it may be determined whether the violation is critical or non-critical (normal). Different actions are taken depending on the severity of the violation. If the violation is critical, the SQL statement is dropped and the administrator is notified immediately and a trace of the violation is provided. If the violation is not critical, the data is retrieved and is compared against data in a confidential data registry. If any of the data is found to be confidential, that data is encrypted and then sent to the hacker. The hacker is not able to use or read the encrypted confidential data.

Claims

1. A method of protecting data in a database utilized by an application that is vulnerable to SQL injection, the method comprising:

receiving a SQL statement at a SQL injection prevention module within the application;

identifying a SQL command sequence within the SQL statement;

comparing the SQL command sequence with a SQL pattern contained in a database security policy, wherein the database security policy includes a violation severity level;

determining that there is a match between the SQL command sequence and the SQL pattern, such that there is a violation of the database security policy by the SQL statement;

determining if the violation severity level of the database security policy is critical or non-critical; and

permitting the SQL command sequence to execute and encrypting a result of the execution of the SQL command sequence when there is a match between the SQL command sequence and the SQL pattern and the violation severity level is non-critical.

2. A method as recited in claim 1 wherein identifying a SQL command sequence further comprises:

scanning the SQL statement.

3. A method as recited in claim 1 further comprising:

ensuring that up-to-date database security policies are loaded into a policies database.

4. A method as recited in claim 1 wherein the violation severity level indicates a level of risk associated with the SQL statement being allowed to access the database associated with the application, wherein the SQL statement is identified as a form of a SQL injection when there is a match between the SQL command sequence and the SQL pattern.

5. A method as recited in claim 1 wherein the SQL pattern is one of a pattern of SQL variables, a pattern of SQL variables and commands, a pattern of SQL variables, commands and conditional logic, and a pattern of SQL variables, commands, conditional logic and parameters, which when identified in a SQL statement is potentially harmful.

6. A method as recited in claim 1 further comprising:

transmitting a data set to the user application, the data set resulting from the SQL statement executing and retrieving data from the database, wherein a portion of the data set is encrypted based on confidential settings in a configuration file specifying which data of said database should be encrypted.

7. A method as recited in claim 1 further comprising:

implementing a visual console by a data registry module, said data registry module being further arranged to scan said database and list all schemas of the database in a visual format in said visual console.

8. A method as recited in claim 1, further comprising:

forbidding the SQL command sequence to execute when there is a match between the SQL command sequence and the SQL pattern and the severity level of the violation of the database security policy is a critical violation.

9. The method of claim 1, wherein the encrypted result is to be decrypted by only a legitimate user of the result.

10. A computing system preventing harmful effects from SQL injection, the system comprising:

a processor;

a SQL injection prevention module for thwarting attempts to cause harm to the computing system through SQL injection;

a SQL scanner module for scanning a SQL statement received from an application executing on the processor;

a logger module for providing one or more SQL injection policies;

a confidential data encryption module for encrypting confidential data retrieved from a database to form a result of executing a SQL statement when it is determined that the SQL statement violates a policy and that the policy violation is a non-critical violation wherein said encrypting uses a feature that is known only to the owner or user of the confidential data; and

a memory storage area storing

one or more SQL injection policies, and

a configuration file identifying said confidential data in the database, said configuration file being generated by a data registry module and wherein said confidential data encryption module uses said configuration file,

wherein the SQL statement is compared with the one or more SQL injection policies to determine whether the SQL statement violates any of the one or more SQL injection policies.

11. A computing system as recited in claim 10 further comprising:

database access drivers which return data to the confidential data encryption module.

12. A computer system as recited in claim 11 wherein database access drivers specifically for the injection prevention module provides application programming interfaces (APIs) and drivers needed by the application to retrieve data from the database and that replace conventional API and drivers normally used by the application.

13. A computing system as recited in claim 10 further comprising:

a maintenance service module that communicates with logger module.

14. A computing system as recited in claim 10 wherein the SQL scanner module examines the one or more SQL injection policies thereby also determining a security violation level.

15. A computing system as recited in claim 10 further comprising:

a confidential user interface component that enables an application developer to enter information on which data stored in a database is confidential.

16. A computer system as recited in claim 10 wherein the data registry module implements a visual console, said data registry module being further arranged to scan said database and list all schemas of the database in a visual format in said visual console.

17. The computing system of claim 10, wherein the encrypted confidential data is to be decrypted by only a legitimate user of the result.

18. The computing system of claim 10, wherein the SQL statement is identified as a form of SQL injection where there is a match between the SQL statement and at least one of the SQL injection policies.

19. A method of blocking SQL injections into a user application that utilizes a database, comprising:

receiving a SQL statement at a SQL injection prevention system in the user application;

comparing the SQL statement against policies relating to SQL injections, said policies containing SQL patterns;

determining whether the SQL statement violates any of the policies; and

allowing the SQL statement to execute and encrypting a result of the execution of the SQL statement when it is determined that there is a violation of a low security level;

wherein the database utilized by the application is protected from malicious SQL statements.

20. A method as recited in claim 19 further comprising:

scanning the SQL statement; and

identifying SQL command sequences within the SQL statement that violate a SQL command pattern in the policies.

21. A method as recited in claim 19 wherein the policies relating to SQL injections include a SQL command pattern.

22. A method as recited in claim 21 wherein the SQL command pattern is one of a pattern of SQL variables, a pattern of SQL variables and commands, a pattern of SQL variables, commands, and conditional logic, and a pattern of SQL variables, commands, conditional logic and parameters, which when identified in a SQL statement is potentially harmful.

23. A method as recited in claim 19 further comprising:

examining a configuration file storing confidential settings to determine whether data retrieved from the database is confidential, said configuration file generated by a data registry module.

24. A method as recited in claim 19 further comprising:

transmitting a data set to the user application, the data set resulting from the SQL statement executing and retrieving data from the database, wherein a portion of the data set is encrypted based on confidential settings in a configuration file specifying which data of said database should be encrypted.

25. A method as recited in claim 24 further comprising:

utilizing a confidential data encryption module for encrypting confidential data in the data set.

26. A method as recited in claim 24 further comprising:

enabling an application developer to select which data in the database is confidential using a visual representation of the database.

27. A method as recited in claim 24 wherein an encryption algorithm to encrypt the data of said database uses a feature local or specific to a legitimate owner or user of the data.

28. A method as recited in claim 19 wherein allowing the SQL statement to execute further comprises:

notifying the administrator that a first security level violation has occurred; and

transmitting a trace of the violation to the administrator.

29. A method as recited in claim 19 further comprising:

loading new policies relating to SQL injections into a policies repository accessed by a SQL scanner.

30. A method as recited in claim 19 further comprising:

enabling the administrator to specify which data is confidential utilizing a confidential data registry interface.

31. A method as recited in claim 19 further comprising:

ensuring that up-to-date policies relating to SQL injections are loaded into a policies database.

32. A method as recited in claim 19, wherein the SQL statement has been identified as a form of SQL injection when the SQL statement is determined to violate at least one of the policies.

33. A method as recited in claim 19 further comprising:

implementing a visual console by a data registry module, said data registry module being further arranged to scan said database and list all schemas of the database in a visual format in said visual console.

34. The method of claim 19, wherein the encrypted result is to be decrypted by only a legitimate user of the result.