Deploying OpenRASP IAST at Ctrip: Architecture, Challenges, and Data‑Pollution Prevention via Bytecode Instrumentation

The author, a senior development engineer at Ctrip, focuses on application security and penetration‑testing techniques, particularly the adoption of Baidu's OpenRASP for service‑level vulnerability scanning.

The article begins with a brief overview of IAST (Interactive Application Security Testing), DAST (Dynamic Application Security Testing), and RASP (Runtime Application Self‑Protection), highlighting IAST's near‑real‑time detection, low false‑positive rate, and code‑level visibility.

Key challenges identified include: (1) traffic replay from IAST agents being re‑injected by DAST tools, causing data pollution in the tested services; (2) the massive scale of Ctrip's environment (thousands of applications and tens of thousands of servers) making large‑scale deployment difficult; and (3) the variety of downstream storage components (relational databases, Redis, Elasticsearch, Kafka, etc.) that could persist polluted data.

To address these issues, the team investigated the data‑flow path of storage components, hypothesizing that they use Java socket I/O for network transmission. By tracing method calls, they confirmed the use of Socket and SocketOutputStream in these components.

The proposed solution leverages the JDK Instrumentation API and the Byte Buddy bytecode manipulation library to inject custom code before the write method of SocketOutputStream . The injected logic checks whether the traffic originates from a replay scenario and, if so, redirects or blocks the write operation, preventing dirty data from being stored.

The overall IAST deployment architecture consists of four parts: (1) an IAST agent embedded in Docker containers that hooks Tomcat internals and forwards HTTP traffic to a Kafka queue; (2) an IAST management console for agent control and vulnerability reporting; (3) a Kafka message queue that aggregates traffic from agents, crawlers, Chrome extensions, and test‑platform APIs; and (4) a distributed scanner that de‑duplicates URLs and performs vulnerability scans.

This architecture yields high scan coverage, high vulnerability detection rates, and low false‑positive rates. During early gray‑scale rollout, previously undiscovered generic vulnerabilities were identified, enhancing Ctrip's internal security posture.

The article concludes that bytecode instrumentation is a versatile technique applicable beyond security, such as in IDE debugging and hot deployment, and that intercepting socket‑based I/O effectively isolates test‑environment data pollution without disrupting normal testing workflows.