Runtime Observer for Targeted Application Security Scanning

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Traditional black-box security testing for web applications is time-consuming due to the need to send multiple attacks across the entire attack surface, often resulting in futile attacks and prolonged scan times, especially in large web applications with varying server response times and network lag.

Innovation Solution

Implementing a runtime observer on the application server to provide targeted attack suggestions, which helps the scanner focus on specific input points with higher vulnerability probabilities, reducing unnecessary attacks and optimizing the scanning process by introducing a probe phase between crawl and audit phases.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional black-box security testing sends multiple attacks across the entire attack surface, then comprehensive vulnerability coverage is achieved, but scan time becomes excessively long

Engineering Contradiction:
Improvevulnerability coverageVSAvoidscan time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system implements feedback by having the runtime observer monitor application behavior and send this information back to the scanner. The observer tracks which code paths are executed and which input points are actually used, providing feedback that allows the scanner to dynamically adjust its attack strategy and focus on high-probability targets rather than exhaustively testing all possible input points.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The runtime observer performs preliminary actions by monitoring and analyzing application behavior during normal operation before the scanning phase begins. This preliminary monitoring establishes a baseline understanding of application flow and input usage, enabling the scanner to prioritize attacks based on pre-analyzed vulnerability probabilities rather than starting from scratch.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If the scanner attacks all identified input points extensively, then vulnerability detection completeness is improved, but server load and network traffic increase

Engineering Contradiction:
Improvevulnerability detection completenessVSAvoidserver load and network traffic
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The system applies local quality by concentrating scanning resources on specific high-probability input points identified through runtime observation rather than uniformly attacking all input points. The observer identifies which input parameters are actually used and which code paths are executed, allowing the scanner to focus attacks locally on these critical areas rather than distributing attacks evenly across the entire attack surface.

Inventive Principle:
Principle #3Local quality

3Reliability

If multiple attacks are sent to cover all potential vulnerabilities, then detection thoroughness is improved, but duplicate attacks increase scan time

Engineering Contradiction:
Improvedetection thoroughnessVSAvoidscan efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The runtime observer provides feedback about which code paths have already been executed and which input points have been tested, allowing the scanner to avoid duplicate attacks. The observer tracks the execution flow and communicates this information back to the scanner, enabling it to skip redundant attack vectors and focus on unexplored areas.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS10242199B2Application test using attack suggestions
Publication Date: 2019.03.26 MICRO FOCUS LLC
  • US10242199B2 patent drawing
  • US10242199B2 patent drawing
  • US10242199B2 patent drawing

AI summary

Example embodiments disclosed herein relate to a security test. A crawl of an application under test (AUT) is performed to determine an attack surface using crawl sessions. One or more parameters of the attack surface are probed during the respective crawl sessions. A trace is requested from an observer for the probe of the one or more parameters. Attack suggestions are received from the observer based on the trace of the one or more parameters.