Intercepting Dirty Data in Active IAST Replay Requests
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing active Interactive Application Security Testing (IAST) technologies fail to effectively intercept and prevent dirty data from being written into databases during replay requests, leading to user request failures and improper execution of SQL queries.
Innovation Solution
A method and system that intercept dirty data by starting a vulnerability detection task, loading the application program and underlying database communication code, editing detection logic code, and triggering an underlying detection code to examine replay requests and prevent dirty data from being written into the database.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If active IAST constructs vulnerabilities on replay request verification, then vulnerability detection capability is improved, but dirty data is written into the database causing data contamination
Solution Approach 1:
The patent introduces an intermediary component (detection code embedded in underlying code) between the replay request processing and database operations. This intermediary intercepts data streams, analyzes SQL statements, and prevents dirty data from reaching the database while allowing legitimate vulnerability detection to proceed.
Solution Approach 2:
The system implements feedback mechanisms where the detection code monitors replay requests, identifies potential dirty data through SQL statement analysis, and provides feedback to stop the writing process. The system uses buffer data results and execution results as feedback signals to control whether data should be written to the database.
2Measurement precision
If exception is thrown to identify replay request, then replay request identification is improved, but user request fails when database connection is exhausted
Solution Approach 1:
Instead of throwing exceptions for all replay requests (excessive action), the patent applies partial action by only intercepting and analyzing specific SQL statement types (CREATE, DROP, ALTER) that pose data contamination risks. Normal SQL operations continue without interruption, maintaining user request execution while still providing security detection.
3Measurement precision
If socket underlying function is used to identify replay request, then replay detection is improved, but type querying SQL cannot execute properly
Solution Approach 1:
The patent applies local quality by treating different SQL statements differently. Type querying SQL (SELECT, INSERT, UPDATE, DELETE) is allowed to execute normally, while data definition language statements (CREATE, DROP, ALTER) are intercepted and blocked. This localized approach ensures that security-critical operations are prevented while normal database operations continue uninterrupted.
Data Source
AI summary
A method and a system for intercepting dirty data is disclosed, the method includes: starting a vulnerability detection task and loading an application and an underlying code for communication between the application and a database; acquiring the underlying code and editing the detection logic code to obtain an underlying detection code; acquiring an original request of an application and initiating a replay request through an active IAST so that the application obtains a data stream in response to the replay request; communicating, by the application, with the database through a network to trigger the underlying detection code to start; examining a type of a structured query language of the data stream according to the underlying detection code; constructing and sending an exception structured query language to the database; and returning, by the database, error information to the application and stopping writing the data stream into the database.