PaperlayerView exact revision on arXiv

Source-linked AI summary

IDORacle: Template-Guided SQL-Sink Mediation for Object-Level Authorization in Java Applications

Yuewantong Song, Guanhang Shi, Yin Cai, Changhui Wang, Jin Wei, Ping Chen, Lei Shi, Jiangxing Wu

arXiv:2609.12426v1cs.CR

TL;DR

Java applications can separate authenticated identity from SQL operations, while existing detection-oriented work offers limited low-intrusion runtime protection for legacy services. IDORacle mediates SQL executions using reusable template plans and authorization guards; it prevents the tested horizontal violations with low reported guard latency and overhead.

  • Problem

    Detection-oriented approaches identify BOLA vulnerabilities during testing, while retrofitting authorization across legacy services is error-prone and time-consuming, leaving a need for low-intrusion runtime prevention.

    Source: §1 · p. 2

  • Method

    IDORacle propagates trusted subject context to SQL sinks and reuses template-level mediation plans to enforce heterogeneous object-authorization guards at runtime.

    Source: §1 · p. 2

  • Results

    IDORacle prevents tested horizontal object-reference violations while preserving benign accesses; worst-case guard latency was 0.17 ms, with a 90.1% overhead reduction under rewrite-decision caching.

    Source: §10 · p. 14

  • Takeaways & Limitations

    SQL-sink mediation can provide a practical last-mile safety net for legacy Java database applications.

    Source: §10 · p. 14

    Requests through third-party opaque APIs without observable downstream SQL sinks evade interception, and some access paths require manual adapter interventions.

    Source: §8.1 · p. 12

Abstract

from arXiv · show

Insecure Direct Object Reference (IDOR), often modeled as Broken Object-Level Authorization (BOLA), remains prevalent in Java database applications because identity and authorization checks at the controller or service layer are disconnected from SQL execution based on resource identifiers. Existing work largely detects these vulnerabilities but offers limited low-intrusion runtime protection for legacy Java-SQL applications. We present IDORacle, a template-guided SQL-sink interception and rewriting framework for preventing horizontal privilege escalation at runtime. IDORacle propagates authenticated identity context across HTTP requests, asynchronous tasks, and data-access boundaries through a server-side trace identifier. At the MyBatis/JDBC boundary, it extracts SQL templates, computes dual fingerprints, and performs one-time template analysis to generate reusable mediation plans. During execution, it combines subject context, SQL ASTs, table metadata, and cached authorization proofs to permit, rewrite, or block operations. Its guard model supports direct ownership predicates, join-derived ownership, probes for group-owned resources, role-sensitive state transitions, and sensitive-column mediation. A Java-SQL benchmark grounded in real-world CVE reports shows that IDORacle prevents the tested horizontal authorization violations with a worst-case guard latency of 0.17 ms. Redundancy-aware optimization reduces average per-instance overhead by more than 90%, to 0.017 ms for hot SQL templates.

1. Introduction

IDOR/BOLA arises when valid authentication and SQL execution do not ensure that the referenced object is within the subject’s authorized scope. IDORacle adds a reusable, low-intrusion SQL-sink monitor for Java applications, with heterogeneous guards and benchmarked prevention of tested horizontal violations.

1. Introduction

  • IDOR is a semantic authorization flaw: a valid request can access an object outside the authenticated user’s authorized scope despite valid endpoint access and well-formed SQL.The paper frames object-level authorization as an application-specific invariant, not an input-sanitization problem.Source: §1 · p. 1
  • Detection-oriented approaches identify vulnerable endpoints during testing, but legacy services remain difficult to retrofit, motivating low-intrusion runtime prevention.Authorization logic may be interleaved with business SQL in large legacy codebases.Source: §1 · p. 2
  • IDORacle places a reference monitor at the MyBatis/JDBC-style SQL boundary to require object-level evidence while complementing, rather than replacing, framework authentication and role checks.The target is horizontal access to objects outside a user’s authorized scope.Source: §1 · p. 2
  • IDORacle separates reusable template planning from per-execution mediation and supports direct, join-derived, group or tenant, role/state, and sensitive-column authorization guards.The design addresses fragmented authorization evidence, semantics-aware enforcement, runtime cost, and evaluation coverage.Source: §1 · p. 2
  • The benchmark reports prevention of all tested horizontal privilege-escalation attempts with zero false positives, average overhead over 90% lower at 0.017 ms for hot templates, and worst-case latency of 0.17 ms.The benchmark is grounded in real-world CVE reports and evaluates diverse ownership patterns.Source: §1 · p. 2

2. Background

The background scopes IDORacle to object-level authorization, traces Java-SQL IDOR to a separation between identity and database operations, and motivates runtime SQL mediation as a complement to detection and database-level mechanisms.

2.1. Scoping the Defense: BOLA, BFLA, and BOPLA

  • BOLA/IDOR concerns access to a concrete object, while BFLA concerns permission to invoke an endpoint and BOPLA concerns access to particular object properties.The SQL-sink defense primarily targets horizontal object-level authorization and handles function- or property-level cases only when sufficient evidence reaches the SQL boundary.Source: §2.1 · pp. 2–3

2.2. The Architectural Root Cause of Java-SQL IDOR

  • Java applications separate subject identity from SQL execution, and pooled database credentials obscure end-user identity while ownership may require direct predicates, joins, tenant relations, or exceptions.A valid login and valid SQL row selection do not establish that the object belongs to the current user.Source: §2.2 · p. 3

2.3. From Detection to Runtime Enforcement

  • Detection approaches flag vulnerabilities before deployment, while database-level controls may assume one-to-one database and application users and lack Java context across asynchronous boundaries or heterogeneous ownership policies.The resulting design space is a runtime SQL enforcement layer that requires no legacy source-code changes and amortizes policy evaluation through template planning.Source: §2.3 · p. 3

3. Threat Model

The threat model covers authenticated low-privilege users who manipulate request-controlled identifiers to access objects outside their scope, and a defender who controls the application, interception layer, and authorization metadata.

3.1. Attacker Capabilities and Objectives

  • An authenticated low-privilege user can alter request-controlled identifiers to read, update, delete, or trigger state changes on out-of-scope objects.The model includes HTTP or RPC requests and assumes the attacker cannot forge identities or server trace bindings, access database credentials, or modify policy metadata.Source: §3.1 · pp. 3–4

3.2. Defender Capabilities and Assumptions

  • The defender controls deployment, SQL interception, and authorization metadata, and trusts the identity-propagation infrastructure and components in the trusted computing base.The defender can recover authenticated subject context, register table and column policies, and deploy in shadow or enforce mode.Source: §3.2 · p. 4

4. Methodology

IDORacle mediates SQL at the database boundary through a two-phase pipeline: it binds trusted identity and compiles reusable template plans, then evaluates runtime authorization guards before execution.

4.1. Overview

  • The two-phase pipeline intercepts a query at the DAO/JDBC boundary, creates a secured SQL candidate, and evaluates it through guard matching, runtime validation, and redundancy-aware optimization.For the illustrated cross-tenant request, the vanilla path reaches the database without ownership constraints, while mediation can produce zero rows and a safe response.Source: §4.1 · p. 4

4.2. Phase 1: Context-Aware Rewrite

  • Phase 1 binds a trusted TraceID identity context to each SQL execution and forwards a secured SQL candidate for authorization evaluation.Missing or expired context fails closed unless the callsite is registered as a system task.Source: §4.2 · pp. 4–5
  • Phase 1 fingerprints each parameterized SQL template and compiles a cached TemplatePlan from its normalized AST, query structure, parameter positions, and policy metadata.Mapper identifier, parameter mapping, callsite hash, and policy version distinguish plans; parsing, normalization, classification, and policy binding happen once per template.Source: §4.2 · p. 5

4.3. Phase 2: Runtime Authorization Oracle

  • Phase 2 matches each runtime SQL instance to its plan and applies guards for direct ownership, join-derived ownership, group or tenant membership, role/state transitions, and sensitive columns.Ownership may be enforced through AST predicates or EXISTS predicates; unsafe rewrites can fall back to a proof query, while sensitive projections can be blocked, nulled, masked, or audited.Source: §4.3 · p. 6
  • Runtime validation checks role and state conditions before DML and inspects SELECT projections for sensitive columns, applying configured actions such as blocking or masking.High-risk columns such as passwords and tokens are blocked by default unless route and role evidence authorize access.Source: §4.3 · p. 6
  • IDORacle caches guard decisions as short-lived authorization proofs, allowing cache hits to bypass repeated guard evaluation while write operations and policy changes trigger invalidation.Proofs record the decision and supporting authorization data; writes evict affected resource keys on a best-effort basis.Source: §4.3 · p. 6

4.4. Protected Database Access and Enforcement Outcomes

  • The oracle can allow, rewrite, block, or audit operations; an ownership-constrained query returns no unauthorized rows, and outcomes are recorded in an audit log.In shadow mode decisions are recorded without changing behavior; in enforce mode they apply before SQL execution.Source: §4.3 · p. 6, §4.4 · p. 7
  • Critical uncertainty—including missing identity, absent protected-table metadata, failed membership probes, and unauthorized sensitive-column access—is blocked by default.Explicit allow rules cover public tables, system tasks, and administrator-only workflows.Source: §4.4 · p. 7

5. Benchmark Design

The benchmark evaluates SQL-level runtime mediation across Java-SQL authorization scenarios, using paired benign and adversarial traces to assess security behavior and repeated-template performance.

5. Benchmark Design

  • Each benchmark case follows a request through its principal, attacker-controlled field, SQL template, protected-table metadata, and expected database and response outcomes.The design targets runtime prevention when object-level authorization is missing, incomplete, or inconsistently placed in Java application code.Source: §5 · p. 7

5.1. Design Goals

  • The benchmark covers unauthorized reads, updates, deletes, and batches, derived ownership patterns, and repeated SQL templates that stress mediation cost.Its goals include measuring security efficacy and the benefit of redundancy-aware optimization.Source: §5.1 · p. 7

5.2. Principals and Protected Objects

  • The heterogeneous data model uses real-world CVE-grounded scenarios and includes direct, group-derived, and resolver-style ownership patterns across protected tables.Examples include direct ownership through create_by or user_id, group-derived ownership through job_group, and resolver-style ownership for job logs.Source: §5.2 · p. 7

5.3. Paired Benign and Adversarial Traces

  • Each scenario pairs a benign trace using the principal’s own resource with an adversarial trace that changes an identifier, transition target, or batch item to another ownership domain.The pairing tests mitigation without breaking legitimate workflows; the overview example rewrites the query with a trusted create_by predicate.Source: §5.3 · p. 8

5.4. Case Families

  • Case families cover object-level IDOR, derived ownership, policy boundaries, and optimization stress from repeated templates and mapper calls.The suite includes public or administrative access boundaries and retains sensitive-column cases as an extension rather than the central focus.Source: §5.4 · p. 8

5.5. Expected Outcomes

  • Expected outcomes require benign traces to remain allowed or rewritten without changing legitimate results, while adversarial reads expose no unauthorized rows and writes affect zero rows or are blocked.Security correctness is defined at the database layer, with HTTP responses recorded as supporting evidence.Source: §5.5 · p. 8

5.6. Execution Modes and Measurements

  • The three execution modes are NO_GUARD, GUARD_NO_CACHE, and GUARD_WITH_CACHE, and recorded execution data supports security and performance measurements.GUARD_NO_CACHE represents the worst-case protected path; GUARD_WITH_CACHE represents the hot-template path.Source: §5.6 · pp. 8–9

6. Implementation

IDORacle combines a backend policy engine with Java runtime interception to bind identity to SQL and rewrite protected statements before database execution.

Implementation

  • The prototype comprises a backend policy engine and Java agent, with deployment artifacts for a guard server, an in-process MyBatis interceptor, and source-independent external application protection.The system contains approximately 5.8K lines of self-developed Java code, excluding benchmark applications and dependencies.Source: §6 · p. 9
  • The MyBatis interceptor obtains the identity record, parses SQL, detects guarded tables, and injects ownership predicates into SELECT, UPDATE, and DELETE statements.The injected value comes from the server-side identity record rather than attacker-controlled request parameters.Source: §6 · p. 9
  • For external applications, the Java agent instruments JDBC prepareStatement calls and sends matching SQL and identity context to the guard server for ALLOW, REWRITE, or DENY decisions.Missing identity information produces a fail-closed denial; framework-specific hooks bind identities from representative legacy systems.Source: §6 · p. 9
  • A rewrite-decision cache keyed by application, identity record, and normalized-SQL fingerprint avoids repeated parsing and inter-process communication for hot templates.The guard server maintains runtime switches, identity records, decisions, logs, and ownership metadata.Source: §6 · p. 9

7. Evaluation

The evaluation examines IDORacle’s security effectiveness, deployability, micro-level performance, and end-to-end impact. It reports attack prevention and reduced cached guard cost while identifying constraints from complex SQL and upstream authentication.

7.1. Experimental Setup

  • The testbed compares unguarded execution, full per-statement guard processing, and guarded execution with the dual-fingerprint template-plan cache.It uses Spring Boot 2.7, MyBatis 3.5, and MySQL 8.0.Source: §7.1 · p. 10

7.2. RQ1: Security Effectiveness

  • 100% of synthesized attacks were prevented with zero false positives across derived relational scenarios.For direct ownership, IDORacle appends a user-identifier predicate; for derived ownership, it uses subqueries or probe-then-allow validation.Source: §7.2 · p. 10
  • Deeply nested aggregations restrict safe rewrites, so the mediator falls back to standalone validation probes that require throughput optimization.Source: §7.2 · p. 11

7.3. RQ2: Practical Deployability

  • The Java agent integrated with RuoYi, BootDo, and XXL Job without manual business-service or mapper changes and was validated against four CVEs.It hooks JDBC prepareStatement and maps Shiro session identity into downstream trace identifiers.Source: §7.3 · p. 11
  • Deployment depends on an intact upstream authentication tier; compromised JWT or session validation invalidates the trace identity.The authors characterize IDORacle as defense in depth, not a replacement for entry control.Source: §7.3 · p. 11

7.4. RQ3: Micro Level Performance

  • 0.017 ms mean processing cost with GUARD_WITH_CACHE represents a 90% average performance optimization.Without caching, GUARD_NO_CACHE reaches 0.17 ms mean latency while performing full parsing and rewrite generation on every execution.Source: §7.4 · p. 11
  • Cache behavior varies by persistence framework: MyBatis mappings are stable, whereas Hibernate and JPA often generate fragmented, volatile SQL.Source: §7.4 · p. 11

7.5. RQ4: End to End Impact

  • Across evaluated CVEs, blocked or rewritten adversarial requests have lower end-to-end latency than corresponding authorized paths, remaining below 35 ms.Authorized operations incur a marginal latency increase, which caching absorbs in part; cached requests are several milliseconds faster on the average-minimum indicator.Source: Figure 3 · p. 11, §7.5 · p. 12

8. Discussion

IDORacle’s protection is limited to horizontal object-level violations that reach SQL sinks and whose authorization relations can be represented in database metadata or policies. Its JDBC-boundary placement preserves legacy business code and complements earlier checks, with deployment trade-offs and possible integration with policy-inference tools.

8.1. Scope of SQL-Sink Enforcement

  • IDORacle targets horizontal object-level violations realized through Java-SQL operations, when identifiers reach protected sinks and authorization relations map to metadata or policies.The supported representations include table metadata, ownership predicates, and column policies.Source: §8.1 · p. 12
  • Opaque third-party APIs, uninstrumented JDBC paths, unmapped transient business states, and dynamic ORM SQL constrain where SQL-sink enforcement is effective.The discussion suggests HQL or Criteria interception as a mitigation for dynamic ORM SQL, but says framework-specific adapters are beyond the prototype.Source: §8.1 · p. 12
  • Integrating static analysis or authorization-inference tools could generate baseline policy templates and reduce manual configuration for large legacy deployments.The proposed integration would use IDORacle as the runtime enforcement engine for inferred policies.Source: §8.1 · p. 12

8.2. Layer Placement and Deployment Trade-o

  • IDORacle avoids changes to MVC controllers, service methods, or mapper definitions, placing object-level enforcement at the DAO/JDBC boundary for legacy systems.The discussion describes this as a safety net when service-layer checks are absent or incomplete.Source: §8.2 · p. 12
  • JDBC-layer rejection can secure database state but incurs routing, parsing, and business-logic work before denial.Strict RBAC annotations could reject some requests earlier; the paper reports that micro-benchmark and caching results contain the added overhead.Source: §8.2 · p. 12
  • IDORacle chooses a deterministic data-access enforcement point that complements rather than replaces earlier authorization mechanisms.The placement prioritizes unified enforcement at the data-access boundary.Source: §8.2 · p. 13

9. Related Work

Prior work studies web-logic flaws, detects BOLA, and mediates SQL policies, but Java applications separate authenticated identity from SQL execution. IDORacle addresses that gap with complementary object-level enforcement at the MyBatis/JDBC boundary.

9.1. Web Logic Vulnerabilities

  • Web-logic research connects request legitimacy to the authenticated subject, referenced object, and backend operation, while testing systems use stateful crawling, fuzzing, and runtime validation to find flaws.These testing approaches complement IDORacle’s focus on enforcement in deployed Java-SQL applications where vulnerable paths may persist.Source: §9.1 · p. 13

9.2. BOLA Detection and Ownership Analysis

  • BOLA-oriented tools infer ownership models and detect missing checks, while IDORacle shifts from vulnerability discovery to preventing unauthorized object operations at SQL execution.The cited systems include BolaRay and MOCGuard (Huang et al., 2024; Liu et al., 2025a), BACScan and BACFuzz (Liu et al., 2025b; Dharmaadi et al., 2025), and UABScan.Source: §9.2 · p. 13

9.3. SQL-Level Policy Enforcement

  • SQL rewriting, authorization views, and row-level security establish the feasibility of fine-grained database mediation, but typical Java deployments hide end-user identity from the DBMS and require varied object-level policies.The described policies include direct ownership, join-derived ownership, group or tenant membership, role-sensitive transitions, and sensitive-column constraints.Source: §9.3 · p. 13

9.4. Java-SQL Access Control

  • Legacy Java applications distribute authorization across layers, separating subject identity from SQL execution; IDORacle complements upstream checks with reusable plans and per-instance object-level validation at MyBatis/JDBC.The design preserves existing business code and enforces constraints before protected statements reach the database.Source: §9.4 · pp. 13–14

10. Conclusion

IDORacle bridges application identity and SQL-level object operations with reusable mediation plans and object-authorization guards. The evaluation reports prevention of tested horizontal violations, with worst-case guard latency of 0.17 ms and 90.1% overhead reduction under rewrite-decision caching.

10. Conclusion

  • IDORacle propagates trusted subject context, compiles reusable SQL-template plans, and applies ownership, membership, resolver-based, role/state, and sensitive-column guards before protected statements reach the database.The framework targets Java-SQL IDOR vulnerabilities.Source: §10 · p. 14
  • 0.17 ms was the worst-case guard latency, and rewrite-decision caching reduced overhead by 90.1%.The evaluation reports prevention of tested horizontal object-reference violations while preserving benign accesses.Source: §10 · p. 14
  • SQL-sink mediation is presented as a practical last-mile safety net for legacy Java database-backed applications, complementing controller-, service-, and external-API authorization.Source: §10 · p. 14

Funding

The authors report that the research received no specific grant funding.

Funding

  • The research received no specific grant from funding agencies in the public, commercial, or not-for-profit sectors.Source: Funding · p. 14
Loading 2609.12426v1…