4.1.1 SQL/Protect Overview
4.1.1 SQL/Protect OverviewThis section contains an introduction to the different types of SQL injection attacks and describes how SQL/Protect guards against them.220.127.116.11 Types of SQL Injection AttacksThere are a number of different techniques used to perpetrate SQL injection attacks. Each technique is characterized by a certain signature. SQL/Protect examines queries for the following signatures:While Advanced Server allows administrators to restrict access to relations (tables, views, etc.), many administrators do not perform this tedious task. SQL/Protect provides a learn mode that tracks the relations a user accesses.This allows administrators to examine the workload of an application, and for SQL/Protect to learn which relations an application should be allowed to access for a given user or group of users in a role.When SQL/Protect is switched to either passive or active mode, the incoming queries are checked against the list of learned relations.A common technique used in SQL injection attacks is to run utility commands, which are typically SQL Data Definition Language (DDL) statements. An example is creating a user-defined function that has the ability to access other system resources.SQL/Protect can block the running of all utility commands, which are not normally needed during standard application processing.The most frequent technique used in SQL injection attacks is issuing a tautological WHERE clause condition (that is, using a condition that is always true).Attackers will usually start identifying security weaknesses using this technique. SQL/Protect can block queries that use a tautological conditional clause.A dangerous action taken during SQL injection attacks is the running of unbounded DML statements. These are UPDATE and DELETE statements with no WHERE clause. For example, an attacker may update all users’ passwords to a known value or initiate a denial of service attack by deleting all of the data in a key table.18.104.22.168 Monitoring SQL Injection Attacks22.214.171.124.1 Protected RolesMonitoring for SQL injection attacks involves analyzing SQL statements originating in database sessions where the current user of the session is a protected role. A protected role is an Advanced Server user or group that the database administrator has chosen to monitor using SQL/Protect. (In Advanced Server, users and groups are collectively referred to as roles.)Each protected role can be customized for the types of SQL injection attacks (discussed in Section 126.96.36.199) for which it is to be monitored, thus providing different levels of protection by role and significantly reducing the user maintenance load for DBAs.Note: A role with the superuser privilege cannot be made a protected role. If a protected non-superuser role is subsequently altered to become a superuser, certain behaviors are exhibited whenever an attempt is made by that superuser to issue any command:
• A protected role that has the superuser privilege should either be altered so that it is no longer a superuser, or it should be reverted back to an unprotected role.188.8.131.52.2 Attack Attempt StatisticsEach usage of a command by a protected role that is considered an attack by SQL/Protect is recorded. Statistics are collected by type of SQL injection attack as discussed in Section 184.108.40.206.These statistics are accessible from view edb_sql_protect_stats that can be easily monitored to identify the start of a potential attack.The columns in edb_sql_protect_stats monitor the following:
• username. Name of the protected role.
• relations. Number of SQL statements issued referencing relations that were not learned by a protected role. (That is, relations that are not in a role’s protected relations list.)
• commands. Number of DDL statements issued by a protected role.
• tautology. Number of SQL statements issued by a protected role that contained a tautological condition.
• dml. Number of UPDATE and DELETE statements issued by a protected role that did not contain a WHERE clause.This gives database administrators the opportunity to react proactively in preventing theft of valuable data or other malicious actions.If a role is protected in more than one database, the role’s statistics for attacks in each database are maintained separately and are viewable only when connected to the respective database.Note: SQL/Protect statistics are maintained in memory while the database server is running. When the database server is shut down, the statistics are saved to a binary file named edb_sqlprotect.stat in the data/global subdirectory of the Advanced Server home directory.220.127.116.11.3 Attack Attempt QueriesEach usage of a command by a protected role that is considered an attack by SQL/Protect is recorded in view edb_sql_protect_queries.View edb_sql_protect_queries contains the following columns:
• username. Database user name of the attacker used to log into the database server.
• ip_address. IP address of the machine from which the attack was initiated.
• port. Port number from which the attack originated.
• machine_name. Name of the machine, if known, from which the attack originated.
• date_time. Date and time at which the query was received by the database server. The time is stored to the precision of a minute.
• query. The query string sent by the attacker.The maximum number of offending queries that are saved in edb_sql_protect_queries is controlled by configuration parameter edb_sql_protect.max_queries_to_save.