PaperlayerView exact revision on arXiv

Source-linked AI summary

Anota: Identifying Business Logic Vulnerabilities via Annotation-Based Sanitization

Meng Wang, Philipp Görz, Joschua Schilling, Keno Hassler, Liwei Guo, Thorsten Holz, Ali Abbasi

arXiv:2512.20705v2cs.CR

TL;DR

Business-logic vulnerabilities require application-specific semantic context that automated tools struggle to infer reliably. ANOTA lets users express intended policies through annotations for a runtime monitor; its fuzzer prototype rediscovered 43 known vulnerabilities and found 22 previously unknown ones, 17 assigned CVEs.

  • Problem

    Detecting business-logic flaws requires understanding application-specific rules and workflows, which automated heuristics struggle to capture reliably.

    Source: §I · p. 2

  • Method

    ANOTA uses lightweight annotations to encode application security policies and a runtime monitor to check program behavior against them.

    Source: A. Annotations · p. 5, §VIII · p. 13

  • Results

    ANOTA+FUZZER rediscovered 43 known vulnerabilities and detected 22 previously unknown vulnerabilities, 17 of which had CVE identifiers assigned.

    Source: §VIII · p. 13

  • Takeaways & Limitations

    The annotation-based approach opens new classes of vulnerabilities to semi-automated discovery through dynamic code analysis.

    Source: §VIII · p. 13

    Implementing ANOTA on a DBI framework is practically infeasible because of the semantic gap.

    Source: D. Limitations of Implementing ANOTA… · p. 19

Abstract

from arXiv · show

Detecting business logic vulnerabilities is a critical challenge in software security. These flaws come from mistakes in an application's design or implementation and allow attackers to trigger unintended application behavior. Traditional fuzzing sanitizers for dynamic analysis excel at finding vulnerabilities related to memory safety violations but largely fail to detect business logic vulnerabilities, as these flaws require understanding application-specific semantic context. Recent attempts to infer this context, due to their reliance on heuristics and non-portable language features, are inherently brittle and incomplete. As business logic vulnerabilities constitute a majority (27/40) of the most dangerous software weaknesses in practice, this is a worrying blind spot of existing tools. In this paper, we tackle this challenge with ANOTA, a novel human-in-the-loop sanitizer framework. ANOTA introduces a lightweight, user-friendly annotation system that enables users to directly encode their domain-specific knowledge as lightweight annotations that define an application's intended behavior. A runtime execution monitor then observes program behavior, comparing it against the policies defined by the annotations, thereby identifying deviations that indicate vulnerabilities. To evaluate the effectiveness of ANOTA, we combine ANOTA with a state-of-the-art fuzzer and compare it against other popular bug finding methods compatible with the same targets. The results show that ANOTA+FUZZER outperforms them in terms of effectiveness. More specifically, ANOTA+FUZZER can successfully reproduce 43 known vulnerabilities, and discovered 22 previously unknown vulnerabilities (17 CVEs assigned) during the evaluation. These results demonstrate that ANOTA provides a practical and effective approach for uncovering complex business logic flaws often missed by traditional security testing techniques.

I. INTRODUCTION

Existing sanitizers leave important weaknesses unaddressed or narrowly covered because business-logic detection requires application-specific context that automated tools struggle to infer. ANOTA lets users encode that context as policies for a runtime monitor, and its Python fuzzer prototype found known and previously unknown vulnerabilities.

I. INTRODUCTION

  • Existing sanitizers leave critical weaknesses unaddressed when detection requires application context, including authorization checks against the intended permission model.The CWE Top 40 analysis also identifies weaknesses such as Uncontrolled Search Path Element, which requires knowledge of intended filesystem privileges.Source: §I · p. 1
  • Automated heuristics struggle to distinguish legitimate behavior from security violations because they cannot capture nuanced, application-specific context.For example, hard-coded file-upload checks can miss other dangerous file types, custom functions, and permission-sensitive path traversal.Source: §I · p. 2
  • ANOTA separates policy from mechanism: users encode application-specific semantic rules in lightweight annotations, and a language-agnostic runtime monitor enforces them during execution.The framework is designed to work with existing fuzzers, typically reporting policy violations as crashes.Source: §I · p. 2
  • ANOTA+FUZZER achieved significantly higher precision and recall than unmodified Atheris on benchmark datasets, rediscovered 43 known vulnerabilities, and uncovered 22 new vulnerabilities, 17 assigned CVEs.The authors also report minimal runtime overhead, about 10% in an artificial worst-case setup.Source: §I · p. 2
  • The authors implemented ANOTA for Python and integrated it with Atheris, reporting rediscovery of 43 known vulnerabilities and discovery of 22 previously unknown vulnerabilities in maintained Python projects.Seventeen discoveries had received CVE identifiers at the time of writing.Source: §I · p. 2

A. Limitations of Existing Sanitizers

Existing sanitizers handle universal execution errors well but often miss business-logic flaws requiring application-specific context; existing context-inference approaches can be brittle or impractical. ANOTA's motivating example shows why runtime behavior must be checked against the application's intended policy.

A. Limitations of Existing Sanitizers

  • Critical authorization and authentication weaknesses can be invisible to existing sanitizers because detecting them requires application-specific permission context.Generic tools lack the intended permission model needed to determine whether a user's access attempt is unauthorized.Source: A. Limitations of Existing Sanitizers · p. 3
  • Existing approaches can be brittle or impractical, relying on language-specific heuristics, narrow call-site assumptions, or restrictive setup requirements.Examples include PHP-specific tools, a GUI requirement for EDEFuzz, and identical environments plus substantial manual setup for FLOWFUZZ.Source: A. Limitations of Existing Sanitizers · p. 3
  • ANOTA proposes lightweight annotations that embed users' domain knowledge and security intent directly in programs, avoiding reliance on automated context inference.The authors frame difficulty inferring deep, application-specific context as the common source of existing limitations.Source: A. Limitations of Existing Sanitizers · p. 3

B. Motivating Example

  • Whitespace-prefixed URLs bypass the example's blocking logic because Python's urlparse API mistakenly parses URLs beginning with whitespace.The example is identified as CVE-2023-24329.Source: B. Motivating Example · p. 3
  • Detecting the example flaw requires comparing runtime behavior with application-specific semantic rules, since fuzzing may trigger it without crashing or violating existing sanitizer rules.Static analysis can identify the urlopen call but misses the custom filtering policy that defines intended behavior.Source: B. Motivating Example · p. 3

A. Annotations

ANOTA lets developers encode application-specific behavior as runtime policies, then monitors execution for policy violations. Its annotation system covers distinct forms of unintended behavior, while the monitor checks execution at policy-relevant points.

A. Annotations

  • ANOTA annotations encode contextual knowledge as enforceable runtime policies, using either blocklists or allowlists that can be toggled during execution.Users can add annotation types by defining syntax and a corresponding monitor check, without re-engineering the core system.Source: A. Annotations · p. 4
  • Five annotation types address unintended system calls, code execution, variable access, and data flow, with a fifth type for clearing policies.System-call annotations can target specific calls, arguments, resources, or common file and network operations; Data Flow annotations track taint and can specify sanitizers and prohibited sinks.Source: A. Annotations · pp. 4–5
  • Object Access annotations assign read, write, or execute permissions, while WATCH.CON marks an object's execution time for statistical constancy checks.Code Execution annotations restrict code regions unless a condition is met; Annotation Clearing removes one or all policies.Source: A. Annotations · p. 5

B. Policy Monitor

  • The Policy Monitor instruments policy-relevant locations, evaluates runtime context against annotations, and reports discrepancies as security flaws.The Annotation Frontend parses annotations into policies, which the monitor enforces during execution.Source: B. Policy Monitor · p. 5

1) Data Flow Monitor:

ANOTA's monitors apply user-defined policies to data flow and system-call behavior. They track sensitive values through execution and inspect system calls to detect violations such as unintended file access.

1) Data Flow Monitor:

  • Data Flow annotations mark variables for taint tracking, which can detect sensitive values written to a local file while allowing values sanitized by an annotated function.The monitor tracks taint propagation during execution and applies the annotation's sanitization and sink rules.Source: 1) Data Flow Monitor · p. 5

2) System Call Monitor:

  • System-call monitoring can check whether file reads comply with path policies by tracing a read's file descriptor to the corresponding openat call and its path argument.The monitor inspects system-call usage, arguments, and return values; violations such as unintended calls or writes to unintended locations signal a vulnerable state.Source: 2) System Call Monitor · p. 5
  • Annotations can express URL restrictions and file-access rules, including blocking specified URL schemes or hosts and allowing access only to a designated static directory.The paper describes using such policies to detect a URL-filter bypass and a path-traversal vulnerability.Source: 2) System Call Monitor · p. 6

3) Access Control Monitor:

ANOTA's access-control monitor checks whether code regions and objects are accessed with the intended privileges. Its implementation parses annotations into policies and applies custom sanitizers to semantic violations that ordinary crash-based detection misses.

3) Access Control Monitor:

  • Object Access and Code Execution annotations let developers mark protected variables and privileged code so runtime monitoring can detect unauthorized access or execution.The monitor watches reads and writes to annotated variables and checks privileged code execution against the policy.Source: 3) Access Control Monitor · p. 6

IV. IMPLEMENTATION

  • The prototype supports Python, native C/C++ extensions, and system interactions through modified CPython hooks, LLVM instrumentation, and an eBPF-based monitor.The implementation is based on CPython, LLVM, and eBPF; the underlying design is described as language-agnostic.Source: §IV · p. 6

A. Parsing Annotations to Policy

  • In Python, annotations are parsed from standard function calls at the CALL_FUNCTION opcode and converted into runtime policies for subsequent enforcement.This syntax is an implementation convenience; the principle of parsing developer-provided syntax into policies is language-agnostic.Source: A. Parsing Annotations to Policy · p. 6

B. Vulnerability Detection

  • Custom sanitizers use annotations to define and identify high-level policy violations, including business-logic flaws that do not cause program crashes.The paper frames these as vulnerabilities that traditional sanitizers cannot detect because they violate intended semantics without crashing.Source: B. Vulnerability Detection · pp. 6–7

1) Sensitive Information Leakage:

ANOTA applies annotations to sensitive-data flow, access control, and system-call behavior. The evaluation combines ANOTA with Atheris and examines vulnerability rediscovery, new-vulnerability discovery, usability, and runtime overhead.

1) Sensitive Information Leakage:

  • Data Flow annotations mark sensitive sources and sinks for taint tracking, while ANOTA also profiles selected functions across inputs to identify potential timing side channels.Functions can be selected automatically based on sensitive-variable annotations or explicitly with WATCH.CON; timing variation triggers a potential vulnerability report.Source: 1) Sensitive Information Leakage · p. 7

2) Improper Access Control:

  • Object Access and Code Execution annotations support detecting improper access control by monitoring variable operations and identifying execution of code reserved for privileged users.The passages describe watching reads and writes to annotated variables and treating a true Code Execution expression as entry into a region that should not execute.Source: 2) Improper Access Control · p. 7

3) Unintended System Calls:

  • System-call policies target vulnerabilities such as SSRF, path traversal, and unsafe deserialization; composing system-call monitoring with data-flow policies also supports sensitive-file TOCTOU detection.The described TOCTOU checks focus on files containing sensitive information rather than flagging the widely used idiom in general.Source: 3) Unintended System Calls · pp. 7–8

V. EVALUATION

  • The evaluation uses ANOTA with Atheris and includes studies of known-vulnerability rediscovery, new-vulnerability discovery, comparison with Atheris alone, usability, and runtime overhead.Web targets use a custom mutator for request fields such as cookies, query parameters, headers, and URLs; login sessions are retained for authenticated endpoints.Source: §V · p. 8

A. Rediscovering Known Vulnerabilities

ANOTA+FUZZER rediscovered most known vulnerabilities and found previously unknown issues in real-world Python projects. The evaluations also expose limits tied to annotation knowledge, input conditions, and false positives.

A. Rediscovering Known Vulnerabilities

  • In label-studio, the same annotation that detected the vulnerability also uncovered a bypass of the official patch.The patch trusted the remote user to determine file type, allowing an obfuscated extension to bypass its check.Source: A. Rediscovering Known Vulnerabilities · p. 9
  • Four known vulnerabilities were missed for distinct reasons, including missing annotations, insufficient application understanding, complex input preconditions, and a particular configuration.A manually supplied seed could theoretically enable detection of the zenml flaw; ANOTA+FUZZER also finds the nautobot issue under the relevant configuration.Source: A. Rediscovering Known Vulnerabilities · p. 9
  • 43 of 47 known vulnerabilities were rediscovered, using only bug-type and project-documentation knowledge in most cases.The authors note that maintainers may do better because of their deeper understanding of project business logic.Source: A. Rediscovering Known Vulnerabilities · p. 9

B. Finding New Vulnerabilities with ANOTA+FUZZER

  • 22 issues were reported in real-world projects; 17 received CVE IDs and three others received internal tracking identifiers.Annotation and code-analysis effort averaged approximately 60 minutes per application for a user already familiar with ANOTA.Source: B. Finding New Vulnerabilities with… · pp. 9–10
  • Two false-positive sensitive-information-leakage findings arose from limited project understanding, including a revoked token logged before a taint-removing function was added.The other finding involved an authorization token written to a temporary curl configuration file that developers confirmed was intended and destroyed after use.Source: B. Finding New Vulnerabilities with… · p. 10

C. Ablation Study

On a benchmark of 35 business-logic vulnerabilities, ANOTA+FUZZER detected all flaws while baseline Atheris detected none. User studies examined annotation effectiveness and developers’ views of its effort and adoption barriers.

C. Ablation Study

  • 35 of 35 benchmark vulnerabilities were detected by ANOTA+FUZZER, while baseline Atheris detected none, even when given the exact triggering inputs.The comparison isolates ANOTA’s sanitizer contribution to a standard fuzzer.Source: C. Ablation Study · p. 10

1) Annotation Study:

  • 55 of 66 annotation tasks detected the target vulnerability, an 83.3% success rate, with a very low false-positive rate.Seven of 11 participants struggled with one unusually difficult access-control flaw requiring deep, non-local authorization knowledge; four detected it.Source: 1) Annotation Study · p. 11, Table IV · p. 11
  • Users with basic conceptual development knowledge were able to write annotations for vulnerabilities in unfamiliar applications.The authors believe developers using ANOTA on their own projects would need less time and achieve higher detection rates with fewer false positives.Source: 1) Annotation Study · p. 11

2) Real-world Developer Study:

  • All 10 professional participants had encountered business-logic vulnerabilities, and all agreed that about an hour of annotation was a reasonable effort for the security value.They identified learning the annotation language (10/10) and CI/CD integration (6/10) as adoption barriers.Source: 2) Real-world Developer Study · p. 11
  • The user studies show that effective annotations can be created with minimal prior knowledge of ANOTA and the target application, while professional developers consider the annotation effort a reasonable trade-off for its security value.Source: 2) Real-world Developer Study · p. 11

E. Performance Evaluation

ANOTA combines developer-written policies with runtime monitoring to detect application-specific violations. Its discussion contrasts this approach with DBI frameworks and identifies manual annotation and cross-language taint analysis as challenges.

E. Performance Evaluation

  • In the reported measurements, tracing all variables resulted in an average runtime overhead of 10%, whereas tracing all system calls led to an overhead of about 5%.Source: E. Performance Evaluation · p. 12

VI. DISCUSSION AND FUTURE WORK

  • ANOTA’s prototype lets developers express their intuition about program behavior through annotations.The discussion also considers how ANOTA differs from binary analysis frameworks and possible future extensions.Source: §VI · p. 12
  • Cross-language taint analysis remains challenging, and ANOTA’s current practical approach could be made more robust by building on existing language-pair research.Source: §VI · p. 12

1) The Semantic Gap:

  • DBI frameworks observe machine instructions rather than application objects, leaving them without direct access to high-level program logic.ANOTA operates inside CPython and therefore has access to semantic context from an internal perspective.Source: 1) The Semantic Gap · p. 12

2) Target Users:

  • ANOTA is intended for application developers and security analysts, whereas DBI tools require expertise in binary analysis, systems programming, and framework APIs.Source: 2) Target Users · p. 12

3) Performance:

  • DBI memory tracing alone incurs over 5,000% overhead, far above ANOTA’s measured overhead.The passage describes memory tracing as the first step toward implementing ANOTA-like functionality through DBI.Source: 3) Performance · p. 12

B. Integrating Large Language Models (LLMs)

C. Porting to Other Languages

The paper sketches how ANOTA’s components could be ported beyond Python and situates its approach among prior work. It concludes with evaluation results and reports its vulnerability-disclosure practices.

C. Porting to Other Languages

  • Porting ANOTA to PHP or JavaScript is framed as an engineering challenge, with proposed language-specific hooks for annotations and object access.The system-call monitor uses eBPF Linux kernel hooks and is described as reusable without modification across language runtimes.Source: C. Porting to Other Languages · p. 13

VII. RELATED WORK

  • Prior fuzzing frameworks generally target predefined bug patterns, while ANOTA provides a framework for application-specific policy violations.Source: §VII · p. 13
  • ANOTA’s annotation-driven dynamic sanitization is presented as addressing a gap in detecting security-critical business-logic flaws.Source: §VII · p. 13

VIII. CONCLUSION

  • ANOTA’s prototype rediscovered 43 known vulnerabilities and detected 22 previously unknown vulnerabilities, with 17 CVEs assigned at the time of writing.The conclusion also reports that annotation and performance studies found the system easy to use and minimally costly in overhead.Source: §VIII · p. 13

IX. ETHICS CONSIDERATIONS

  • The paper reports that all 22 newly discovered vulnerabilities were disclosed to developers through coordinated disclosure.The authors were also working with developers on vulnerability understanding and proposed fixes.Source: §IX · p. 14

APPENDIX A TARGET VULNERABILITIES

The appendix describes ANOTA’s target weaknesses and compares it with scanners and binary-analysis frameworks. The scanner evaluation reports that ANOTA+FUZZER found all in-scope bugs during the trial.

APPENDIX A TARGET VULNERABILITIES

  • ANOTA supports additional vulnerability classes alongside existing fuzzing technologies, while some classes are unsupported or considered unnecessary to annotate because developers can directly patch them.The passage gives hard-coded credentials and CSRF as examples of issues considered directly patchable with the relevant developer intuition.Source: Appendix A · p. 17

APPENDIX B COMPARISON WITH STATE-OF-THE-ART SCANNERS

  • The scanner comparison used three static tools and two dynamic tools that shared at least three vulnerability types with ANOTA+FUZZER.Tools were configured using their official documentation; extensive manual configuration was not performed.Source: Appendix B · p. 17
  • 35 bugs were reported by ANOTA+FUZZER within 24 hours, compared with 18 by second-place SonarQube and 17 by ZAP.Only SonarQube and ANOTA+FUZZER produced no false-positive reports.Source: Appendix B · p. 17, Table VII · p. 18

A. Fundamental Design Difference

B. Interfaces and Ease of Use

ANOTA exposes high-level annotations for policy definition, unlike DBI frameworks’ low-level instrumentation APIs. The comparison describes a semantic gap and substantial DBI memory-tracing overhead, while noting ANOTA’s performance tradeoff and study setup.

B. Interfaces and Ease of Use

  • ANOTA uses high-level, function-like source annotations so developers define policies without knowing the framework’s internals.DBI users instead implement analysis logic through low-level APIs and need expertise in framework internals.Source: B. Interfaces and Ease of Use · p. 19

C. Vulnerability Detection Capabilities

D. Limitations of Implementing ANOTA Using DBI Frameworks

  • DBI tools see CPython machine code rather than application objects, so reproducing ANOTA’s checks would require reverse-engineering runtime memory layout.A DBI-based taint tracker also lacks developer-provided intent about which values are sensitive and which operations are dangerous sinks.Source: D. Limitations of Implementing ANOTA… · p. 19

E. Performance Overhead and Design Tradeoffs

  • Monitoring all memory accesses incurred 5,417% overhead with DynamoRIO and 5,513% with Valgrind Memcheck.A slimmed-down Valgrind Lackey-based memory tracer incurred 8,756% overhead; these measurements address the cost of monitoring needed to map memory to runtime objects.Source: E. Performance Overhead and Design… · p. 19
  • ANOTA trades generality for performance and semantic awareness, with targeted mechanisms activated when specific events occur.The passage reports about 10% overhead for ANOTA and says DBI’s performance penalty makes it impractical for repeated-execution tasks such as fuzzing.Source: E. Performance Overhead and Design… · pp. 19–20

APPENDIX D ANNOTATION STUDY DETAILS

  • The annotation study included 11 participants, each assigned six randomly selected vulnerable applications to annotate.Participants had varied application-development and security experience and no prior familiarity with ANOTA or the target code bases.Source: Appendix D · p. 20

A. Preparation

Participants found ANOTA usable, though annotating unfamiliar applications raised concerns about missed locations. Experienced developers saw value in the approach but identified learning and integration as adoption hurdles.

A. Preparation

  • Before annotation, participants received application-purpose guidance, syntax instructions, vulnerability examples, and advice to inspect security-critical trust boundaries.They were directed to use documentation or API specifications to check whether behavior was intended, without receiving application-specific knowledge or vulnerability details.Source: A. Preparation · p. 20

B. Participant Feedback

  • All participants found ANOTA’s syntax straightforward to learn, while nine worried they might overlook critical annotation locations and spent extra time checking.The nine participants lacked detailed application knowledge, a concern the authors say is unlikely for developers familiar with their codebases.Source: B. Participant Feedback · p. 20

C. Failure Cases

  • Ten of 11 participants detected each of three reported vulnerabilities; failures involved missed credential documentation, restricting the wrong path, or misunderstanding SSRF.Two annotation placements for cmdb were semantically equivalent despite one approach using more annotations.Source: C. Failure Cases · pp. 20–21

D. False Positives

  • False positives were low and commonly involved system-call or data-flow annotations; developers could iteratively understand and resolve them.Participants tended to annotate explicit developer intent and preferred blocklists, which were less likely to cause false positives.Source: D. False Positives · p. 21

APPENDIX E FEEDBACK FROM REAL-WORLD DEVELOPERS

  • All 10 experienced developers reported encountering business-logic vulnerabilities, and all were willing to spend about an hour annotating, with 4 saying they would definitely use ANOTA.The remaining six said they would apply it depending on project importance; integration difficulty concerned 6/10, and all cited a learning curve.Source: Appendix E · pp. 21–22
  • Experienced developers relied mainly on manual code review (10/10) and external penetration testing (9/10); only 1/10 had used static analysis for these flaws.Their adoption concerns included learning effort, framework and CI/CD integration, and possible code-readability effects.Source: Appendix E · pp. 21–22

APPENDIX F EXTENDED DISCUSSION

ANOTA makes implicit security intent machine-verifiable, including when developers treat APIs as black boxes. Its measured overhead was low on average in extreme tracking setups, while application eligibility depended on practical constraints.

APPENDIX F EXTENDED DISCUSSION

  • Annotating security intent can expose vulnerabilities caused by API misuse or underlying library bugs, including when deep dependency introspection is infeasible.The paper reports that ANOTA detected zero-day vulnerabilities in audited projects such as Home Assistant.Source: Appendix F · p. 22

APPENDIX G PERFORMANCE EVALUATION

  • 5% average Monitor Syscall overhead and 10% average Trace All overhead were reported; ANOTA’s performance impact was lower than DynaPyt’s reported 1.2×–16× overhead.These were extreme tracking-everything setups; pool benchmarks had around 35% system-call overhead, tornado_http 44%, and logging_simple and logging_format 29% and 118%, versus 1% for logging_silent.Source: Appendix G · p. 22, Table IX · p. 22

APPENDIX H SKIPPED APPLICATIONS

  • Applications were excluded when analysis required unavailable domain knowledge, dependencies or environments were unsatisfied, unsupported languages were involved, or user-facing entry points were unclear.Examples included GPU requirements and packages functioning mainly as libraries or plugins.Source: Appendix H · p. 23
Loading 2512.20705v2…