How to Automate Logic Vulnerability Detection with DAST, IAST, and API Analysis

1. Background

Logic vulnerabilities include:

Unauthorized access: users bypass authentication to perform operations.

Vertical privilege escalation: users obtain higher‑level permissions.

Horizontal privilege escalation: users access data of other users with the same permission level.

Typical freight‑scenario examples:

Unauthorized: data can be retrieved without any authentication parameters.

Vertical: a regular enterprise user can view data that only administrators should see.

Horizontal: user A can view user B’s orders using A’s token.

As defense‑in‑depth improves, generic vulnerabilities are often blocked by WAFs, but logic flaws remain exploitable and can leak large amounts of sensitive data.

2. Technical Research

SAST

Static Application Security Testing

Analyzes source code syntax, structure, and interfaces to find security bugs; only discovers generic issues and cannot perform full‑stack testing.

IAST

Interactive Application Security Testing

Deploys an agent on the server to monitor runtime function calls and data flow, pinpointing vulnerable code lines, functions, and parameters.

DAST

Dynamic Application Security Testing

Simulates attacker behavior to dynamically probe the application; black‑box scanning can replay API calls with different accounts to identify some logic flaws.

3. Solution Overview

Figure 1 – Vulnerability Detection System‑1

Figure 2 – Vulnerability Detection System‑2

4. Construction Plan

(1) Preparation

API integration: passive traffic capture via Kafka (gateway forwards test‑environment HTTP requests to Kafka, scanner consumes from Kafka) because active crawling cannot bypass login restrictions and misses many APIs.

(2) Authentication Parameter Collection

Collect tokens from URL parameters, request headers, or request bodies; token is used as the unified term for authentication data.

(3) Account Center Integration

Generate tokens per account to test privilege escalation; different business systems may have distinct token generation mechanisms, but a unified account center can produce tokens automatically.

4.1 Echo Similarity Check

When testing horizontal privilege, identical responses may contain timestamps or trace IDs; simple body equality is insufficient. A fuzzy‑hash algorithm (e.g., ssdeep) is used to compare response similarity and set a threshold.

4.2 Same API Definition

API deduplication is crucial for scanning cycles and vulnerability reporting. Examples:

admin/index.php?id=1 and admin/index.php?id=2 are considered the same API.

index.php?_m=index&_a=push and index.php?_m=index&_a=pull are different APIs.

admin/1/push and admin/2/push are the same API.

5. Detection Methods

(1) Unauthorized Access

No authentication parameters: if a request without a token returns sensitive data, it is an unauthorized access vulnerability.

Invalid authentication parameters: replay the request after removing the token; if the response still contains sensitive data, it indicates a missing‑auth vulnerability.

Figure 4 – Invalid Authentication Parameter

(2) Multi‑Account Horizontal Privilege Testing

Replace the original token with a token from another test account and replay the request; if the response similarity exceeds the threshold, a horizontal privilege issue is reported.

Figure 5 – Horizontal Privilege Test

(3) Single‑Account Parameter Cross‑Privilege Testing

Cache the first request parameters in Redis (req0). When a second request (req1) arrives, if it matches the same API but uses a different token, perform cross‑parameter testing. Generate combinations such as id=1&user=b (req2) and id=2&user=a (req3), then compare response structures to identify vulnerable parameters.

Figure 6 – Cross‑Privilege Test

(4) Summary of Findings

Common false positives stem from public APIs (configuration, copy, public data queries). Path‑parameter APIs (e.g., /user/1/push) need special handling. DAST covers simple GET scenarios but struggles with CRUD operations; an API security analysis platform and IAST help identify operation types and success.

6. Improvements

Challenges identified:

Incomplete API coverage – passive traffic may miss zombie APIs; need active triggering or Swagger analysis.

Automation maturity – many scenarios still require manual whitelist configuration; vertical privilege cases are not fully covered.

Complex multi‑API workflows and non‑sensitive privilege bugs are not yet detectable.

7. Public API Identification

Public APIs often have low variance in response size. By calculating the standard deviation of body_bytes_sent over time, APIs with a standard deviation of zero are classified as public.

Figure 7 – Standard Deviation Calculation

8. API Security Analysis Platform

Goal

Build a platform for asset inventory, labeling, and risk assessment; integrate with IAST call stacks for end‑to‑end vulnerability verification.

Figure 8 – Construction Goal Flowchart

Interface Noise Reduction

http.response.code <400
and not (http.response.code == 307)
and not (http.user_agent matches "scaninfo@paloaltonetworks\.com")
and not (http.request.method matches "HEAD|OPTIONS")
and not (http.request.uri.path matches "\.js\.map|\.css|\.png|\.jpg|\.jpeg|\.ico|\.pdf|\.svg|\.bcmap|\.woff|\.ttf|\.xlsx|\?|\*|\.|\.|@|:|;")
and not (http.response.headers["location"] matches "sso.xxx.cn|in-sso.xxxx.com")
and not (http.host matches ".*@.*oastify\.com.*")

Interface Merging

Detect URL‑PATH parameters (e.g., api.example.com/login/238 and api.example.com/login/392) and merge them into a single pattern like api.example.com/login/{id} using prefix‑tree or route‑generation algorithms.

Interface Tagging

Assign tags to APIs (e.g., public, sensitive, CRUD) to support monitoring and risk assessment.

Operations

New API monitoring for immediate risk evaluation.

Zombie API monitoring to identify unused endpoints.

API inventory for cross‑team penetration testing.

Integration with SIEM, signatures, etc.

References

Privilege escalation vulnerability automation practice – https://security.immomo.com/blog/215