Second-Order SQL Injection Detection via Database Schema Influence Tracking

Solution Overview

Problem

Existing database query language (SQL) applications are vulnerable to second-order query language injections, which are often undetected by first-order injection detection mechanisms due to the perceived safety of database data.

Innovation Solution

A method and system that track data flows from source variables to sink variables, using taint or escape analysis to identify potential security vulnerabilities by determining writes to and reads from persistent storage, such as database tables, and reporting defects at sink statements influenced by source values.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If first-order query language injection detection mechanisms are used, then first-order vulnerabilities can be detected, but second-order vulnerabilities remain undetected

Engineering Contradiction:

Improvevulnerability detection capabilityVSAvoiddetection mechanism coverage

Core Design Contradiction:

Measurement precisionVSAdaptability or versatility

Solution Approach 1:

The system performs preliminary tracking of data flows from source variables to database storage before the actual query execution. By pre-identifying tainted data paths and storing influence information in the database schema, the system prepares detection capabilities in advance that enable it to recognize second-order injection vulnerabilities when they occur, rather than only detecting first-order injections at the input stage.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The database schema and metadata serve as an intermediary structure that stores influence information about data flows. This intermediary layer connects source variables to sink variables through the database, allowing the system to track and detect vulnerabilities across multiple execution stages. The schema modifications act as a mediator that preserves vulnerability information through database operations.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Productivity

If data from the database is considered safe, then processing efficiency is improved, but second-order vulnerabilities go undetected

Engineering Contradiction:

Improvedata processing efficiencyVSAvoiddata safety assumption

Core Design Contradiction:

ProductivityVSReliability

Solution Approach 1:

The system performs preliminary tracking of data flows from source variables to database storage before the actual query execution. By pre-identifying tainted data paths and storing influence information in the database schema, the system prepares detection capabilities in advance that enable it to recognize second-order injection vulnerabilities when they occur, rather than only detecting first-order injections at the input stage.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The system modifies the database schema to include influence information as an additional parameter or attribute. This parameter change allows the database to carry vulnerability metadata alongside the actual data, enabling the system to maintain efficient data processing while simultaneously tracking safety information needed to detect second-order vulnerabilities.

Inventive Principle:

Principle #35Parameter changes

3Measurement precision

If data flow tracking through persistent storage is implemented, then second-order vulnerabilities can be detected, but analysis complexity increases

Engineering Contradiction:

Improvevulnerability detection accuracyVSAvoidcode analysis system complexity

Core Design Contradiction:

Measurement precisionVSDevice complexity

Solution Approach 1:

The system segments the vulnerability analysis into distinct phases: source variable identification, data flow tracking to database writes, schema influence information storage, and sink variable reading detection. By dividing the complex analysis into manageable segments that operate at different stages of code execution, the system reduces overall complexity while maintaining comprehensive second-order vulnerability detection capability.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The database schema and metadata serve as an intermediary structure that stores influence information about data flows. This intermediary layer connects source variables to sink variables through the database, allowing the system to track and detect vulnerabilities across multiple execution stages. The schema modifications act as a mediator that preserves vulnerability information through database operations.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentEP3924851B1Detecting second-order security vulnerabilities via modelling information flow through persistent storage

Publication Date: 2024.09.04 ORACLE INT CORP

Figure 1A
Figure 1B
Figure 2

AI summary

A method may include determining that a source variable in code receives a source value from a source function specified by a target analysis, determining that a source statement in the code writes, using the source variable, the source value to a column in a table, obtaining, for a sink statement in the code, a set of influenced variables influenced by the source variable, determining that the sink statement reads the source value into a sink variable including an identifier of the column, generating a modified set of influenced variables by adding the sink variable to the set of influenced variables, and reporting a defect at the sink statement.