6.5.1.1 MariaDB
MariaDB has essentially the same architecture as MySQL. When a query is received, it parses, validates, and executes it (see Figure 6.1(a)). The outcome of the parsing and valida- tion phases is the same as in MySQL, alist of stackswhere each stack of the list represents a clause of the query, and each of its nodes contains data about the query element. Moreover, the file that contains the calls to the functions that perform parsing, validation and execution of a query is the same as in MySQL:sql_parser.cc. Therefore, SEPTIC can be imple- mented in MariaDB similarly to how it was in MySQL (Section 6.3.1). The SSLE-generated IDs implemented in the Zend engine can be used without any modification.
6.5.1.2 PostgreSQL
The implementation of SEPTIC in PostgreSQL has some differences but also many sim- ilarities to the MySQL and MariaDB cases. The processing of a query in PostgreSQL involves four phases: parsing/validation, rewriting, planning/optimization, and execution.
Again the SEPTIC module is inserted after the parsing phase, before the rewriting phase.
Similarly to MySQL, a single file has to be modified (postgresql.c), adding essen- tially the same 14 lines of code that were added to MySQL. That file contains the function exec_simple_querythat runs the four processing phases of a query. The code would be inserted after the call to functionpg_parse_querythat parses and validates the query, just before the call to the function that executes the rewriting phase (pg_analyze_and_rewrite).
SEPTIC might also be inserted after the rewriting phase, but the adaptation would be more complicated as rewriting produces a different data structure, a query tree.
The data structure resulting from the parsing phase is slightly different from MySQL’s but still alist of stacks. Again each stack of the list represents a clause of the query (e.g., SELECT, FROM) and its nodes a query element. PostgreSQL tags the query elements with their types and distinguishes the primitive types (e.g., integer, float/real, string). The nodes of the stacks contain this information similarly to what happens in MySQL, but the tags, the structure of the nodes, and the way they are organized in the stack are different from MySQL. Therefore, the data structures used in PostgreSQL and MySQL are similar, but the current implementation of the moduleSEPTIC detectorhas to be modified, specifically: (1) the navigation in thelist of stacks; (2) the identification of the data about the query elements
6.5 Extensions to SEPTIC
in the nodes; and (3) the collection of this data. These modifications are related with the construction of query structure for every query.
Similarly to MariaDB, no changes are needed to the generation of IDs implemented in the Zend engine.
6.5.2 Vulnerability diagnosis
SEPTIC aims to protect web applications transparently from the administrator or program- mer. However, if an attack is successful that means there is a vulnerability in the application and it may be useful to understand where that vulnerability is in the source code.
SEPTIC combined with the SSLE-generated ID presented in Section 6.2.3 can provide this information when an attack is detected. Recall that the SSLE-generated ID we propose contains information about the places in the source code where the query is passed to func- tions as a parameter and eventually sent to the DBMS. These places are identified by the file:linepairs in the ID, as explained in Section 6.2.3. When SEPTIC detects an attack it logs the ID and the query, both in detection and prevention modes.
The administrator/programmer can use this log to diagnose the vulnerability. Moreover, it can use the attack query to understand how the vulnerability was exploited and how it can be removed. Some rules of thumb on how to fix the application are:
• SQLI attack and user inputs are not sanitized: any of the attacks of Table 6.1 may have happened; sanitization and/or validation has to be inserted in the source code;
• SQLI attack and user inputs are sanitized: the attack probably belonged to class A, possibly a case of semantic mismatch; proper sanitization or validation has to be im- plemented to deal with these attacks;
• Second order SQLI attack: the query contains inputs provided by another query, thus introduced earlier in the database; therefore, the inputs provided by the other query have to be sanitized/validated;
• Stored injection: the attack belonged to classes D.2–D.4; the programmer has to de- velop validation routines to apply to the inputs.
6.5.3 Detecting attacks against non-web applications
Despite the chapter has focused on the detection of injection attacks against web applications, the SEPTIC approach (and its implementation in MySQL) also works with non-web appli- cations. DBMSs are mostly oblivious to the type of applications that send them requests.
The SEPTIC module inside the DBMS is also oblivious to the applications, except for query IDs. However, queries do not have to bring an ID as SEPTIC can also useDBMS-generated IDs(see Section 6.2.3).
Attacks coming from non-web applications can be detected by SEPTIC using suchDBMS- generated IDsorIDs generated outside the DBMS and the SSLE. Similarly to what happens with web applications, SEPTIC has to undergo training to learn about the normal queries is- sued by the (non-web) application, in order to build their query models. This training cannot be done with theseptic_trainingmodule, which is specific for web applications, but the idea is the same: to activate all queries with good inputs.
With the goal of demonstrating that SEPTIC also works with non-web applications, we developed a simple Gambas application to manage contacts, i.e., an address book (Gambas, 2015). Gambas is a version of .NET / Visual Basic for Linux. Applications in Gambas can connect to a DBMS and issue requests similarly to what happens in PHP and Java. We trained SEPTIC using the incremental method (Section 6.2.5), i.e., by forcing the application to issue non-malicious queries to the database without putting SEPTIC in training mode. Then, we injected a few attacks that SEPTIC correctly detected.