Runtime Injection Attack Detection via API Baseline Validation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current methods for detecting and preventing injection attacks on web applications powered by dynamic languages are inefficient, relying on complex firewalls, heuristics, and subjective RASP solutions that can lead to false positives, performance bottlenecks, and scalability issues, and require prior knowledge of vulnerabilities.

Innovation Solution

A method that monitors and validates API calls executed by dynamic language code by scanning for API calls, inserting hooks for monitoring, and applying dynamic validation to ensure conformity with predefined rules, eliminating the need for prior knowledge or heuristics, and differentiating between malicious and legitimate activities without user input.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of manufacture

If web applications use dynamic languages with runtime interpretation for rapid development, then ease of development and adaptability are improved, but security vulnerabilities and reliability deteriorate due to lack of strict type checking

Engineering Contradiction:
Improveease of developmentVSAvoidsecurity reliability
Core Design Contradiction:
Ease of manufactureVSReliability

Solution Approach 1:

The patent applies preliminary action by performing static analysis on dynamic language code during the development phase to generate a baseline model of expected API calls. This baseline is established before runtime execution, allowing the system to pre-determine what constitutes normal behavior. The hooks are also inserted in advance to enable monitoring without interfering with the ease of development that dynamic languages provide.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces an intermediary validation layer that sits between the dynamic language interpreter and the underlying system APIs. This intermediary monitors API calls made by interpreted code, compares them against the baseline model, and blocks suspicious calls. This mediator approach maintains the flexibility of dynamic languages while adding security without requiring changes to the language itself.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If traditional firewall approaches are used to sanitize malicious input, then attack prevention is improved, but device complexity and performance deteriorate due to complex heuristics and training requirements

Engineering Contradiction:
Improveattack preventionVSAvoidfirewall complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent applies self-service by enabling the web application to generate its own security baseline model through static analysis of its source code. The application essentially creates its own security policy by analyzing its own API call patterns, eliminating the need for external firewall systems to learn and adapt to application-specific behavior. This self-generated baseline serves as a custom security policy that is inherently tailored to the application's legitimate operations.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent extracts the security validation function from traditional firewall systems and integrates it directly into the web application runtime environment. By embedding hooks within the application's execution context rather than relying on external firewall infrastructure, the system removes the complexity of external heuristic-based firewalls while maintaining effective attack prevention through application-specific baseline comparison.

Inventive Principle:
Principle #2Taking out (Extraction)

3Measurement precision

If RASP solutions are deployed for runtime monitoring, then attack detection capability is improved, but productivity and performance deteriorate due to false positives and significant performance penalties

Engineering Contradiction:
Improveattack detection precisionVSAvoidapplication performance
Core Design Contradiction:
Measurement precisionVSProductivity

Solution Approach 1:

The patent performs preliminary static analysis to create a baseline model of expected API calls before runtime monitoring begins. This pre-computed baseline eliminates the need for runtime learning and heuristic analysis, allowing the system to make deterministic comparisons between observed and expected behavior. The baseline generation happens once during deployment, not continuously during execution, minimizing runtime overhead.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

Instead of allowing RASP solutions to learn normal behavior through continuous monitoring and then detecting deviations, the patent inverts the approach by determining normal behavior through static analysis first, then using that knowledge to filter runtime observations. This inversion eliminates false positives caused by heuristic uncertainty and reduces runtime processing to simple pattern matching against the pre-established baseline.

Inventive Principle:
Principle #13The other way round (Inversion)

Data Source

PatentUS11363061B2Runtime detection of injection attacks on web applications via static and dynamic analysis
Publication Date: 2022.06.14 NEW RELIC INC
  • US11363061B2 patent drawing
  • US11363061B2 patent drawing
  • US11363061B2 patent drawing

AI summary

In one aspect, a method for preventing attacks on a web application server by monitoring and validating the API calls executed by the dynamic language code of web application is provided. The method includes the step of scanning the computer system for web applications and the location of dynamic language code or script files used by the web applications. The method includes the step of parsing all script files to identify API calls, the location of API calls, and arguments used in the API calls and storing them as rules.