Phân tích Kiến trúc: Strix Control Flow qua Caido GraphQL

Ngoc Phan — Sat, 07 Mar 2026 14:02:18 +0000

Dưới đây là tổng hợp toàn bộ các truy vấn GraphQL mà Strix sử dụng để điều khiển Caido, vai trò của từng loại và phân tích lý do tại sao kiến trúc này vượt trội so với việc truy vấn trực tiếp vào một cơ sở dữ liệu SQLite truyền thống.

1. Danh sách các Truy vấn GraphQL chính trong Strix

Strix tập trung toàn bộ logic này trong file proxy_manager.py.

A. Truy vấn Dữ liệu Traffic (Queries)

GetRequests (requestsByOffset):
- Vai trò: Liệt kê và lọc danh sách traffic dựa trên ngôn ngữ HTTPQL.
- Tham số chính: limit, offset, filter (cú pháp HTTPQL), order.
- Dữ liệu lấy về: ID, method, host, path, status code. Strix thường KHÔNG lấy phần raw (content) ở bước này để tiết kiệm RAM và Token.
GetRequest (request(id)):
- Vai trò: Lấy chi tiết toàn bộ nội dung của một Request hoặc Response cụ thể.
- Điểm đặc biệt: Strix sử dụng các query variant để chỉ lấy raw request hoặc raw response tùy theo nhu cầu của Agent.
GetSitemap (sitemapRootEntries / sitemapDescendantEntries):
- Vai trò: Khám phá cấu trúc thư mục/endpoint của ứng dụng mục tiêu theo dạng cây (Hierarchy).

B. Thao tác Cấu hình (Mutations)

CreateScope / UpdateScope / DeleteScope:
- Vai trò: Định nghĩa "vùng an toàn" cho Agent. Giúp Agent chỉ tập trung tấn công vào các domain được phép (Allowlist) và bỏ qua các file rác (Denylist như .png, .css).

2. So sánh: GraphQL của Caido vs. API SQLite truyền thống

Trong các công cụ cũ (hoặc bản cũ của mitmproxy), log traffic thường được lưu vào một file SQLite. Dưới đây là lý do Strix/Caido chọn GraphQL:

Tiêu chí	SQLite API (Truy vấn trực tiếp)	Caido GraphQL API
Độ linh hoạt (Granularity)	Phải `SELECT *` hoặc viết SQL Join phức tạp để lấy thông tin liên quan giữa Request và Response.	Cực cao. Chỉ lấy đúng các trường Agent cần (ví dụ: chỉ lấy Header Authorization). Tiết kiệm 80-90% AI Token.
Khả năng lọc (Filtering)	Phải biết schema bảng, viết các câu lệnh `LIKE '%...%'` chậm và tốn tài nguyên.	HTTPQL. Một ngôn ngữ chuyên dụng cho Pentest (ví dụ: `req.method.eq:"POST"`). Tốc độ xử lý hàng triệu request cực nhanh.
Xử lý dữ liệu Binary	Lưu blob trong DB, Agent khó xử lý trực tiếp, dễ gây crash nếu request quá lớn.	Base64 + Pagination. GraphQL trả về Base64, Strix thực hiện phân trang nội dung (ví dụ: chỉ xem 50 dòng đầu của Response) ngay tại tầng API.
Tính nhất quán (Real-time)	Việc đọc/ghi vào file SQLite khi có hàng nghìn request/giây dễ gây Lock DB hoặc corruption.	Concurrent-safe. Caido (Rust) quản lý việc ghi dữ liệu, GraphQL cung cấp một interface an toàn để đọc dữ liệu mà không làm gián đoạn luồng proxy.
Trải nghiệm Agent AI	SQL quá phức tạp để AI tự tạo ra các query chính xác mà không gặp lỗi cú pháp.	Schema-driven. GraphQL có cơ chế tự gợi ý (Introspection), Agent có thể hiểu rõ các trường dữ liệu có sẵn để đặt câu hỏi chính xác.

3. Tại sao đây là "Điểm mạnh tuyệt đối" của Strix?

Đối với một Agent AI như Strix, Token là tiền bạc và thời gian.

Nếu dùng SQLite truyền thống:

Để quét lỗi XSS, Agent phải tải toàn bộ 1000 request (mỗi request 5KB) = 5MB dữ liệu.
AI sẽ bị "ngộp" và mất dấu vết (Max context length).

Với GraphQL của Caido:

Agent gửi 1 query: "Cho tôi danh sách các request có status:200 và có tham số q".
API chỉ trả về 5 cái ID.
Agent chỉ tải nội dung của 5 cái đó -> Tổng cộng chỉ mất ~10KB dữ liệu.

Kết luận: GraphQL biến Caido từ một "thùng chứa dữ liệu thụ động" thành một Search Engine thông minh, giúp Strix hoạt động cực nhanh và chính xác với chi phí vận hành thấp nhất.

4. Tái Tạo Tấn Công (Attack Replay) Khép Kín: Vulnerability Exploitation Dataflow

Quá trình "Tái tạo và Thử nghiệm Payload" là lúc mà sức mạnh của Proxy thể hiện rõ nhất. Thay vì bắt LLM phải tự viết code Python hay các lệnh curl shell lằng nhằng để gửi HTTP Request, Strix tối ưu hóa điều đó bằng một luồng quy trình (dataflow) thao tác ngay trên các ID Request đã có sẵn.

A. Dataflow: Quá Trình Replay Bằng AI

Khi Agent phát hiện một form POST khả nghi, nó thực hiện quy trình sau:

Tìm kiếm (Search): Dùng httpql_filter (ví dụ req.method.eq:POST) để query danh sách các Request hợp lệ thông qua Caido GraphQL.
Phân tích (Analyze): Gọi view_request(id) để xem raw header và body.
Thao túng (Replay & Modify): Gọi tool repeat_request truyền vào cái request_id cũ kèm theo Dict chứa các sửa đổi (Modifications). Ví dụ đổi tham số "username=admin" thành "username=admin' OR 1=1--".
Băng hình (Relogging): Kể cả request giả mạo (Replay) do Agent tạo ra cũng được đẩy ngược (proxy) qua cổng Caido (127.0.0.1:48080), đồng nghĩa với việc Lịch sử rà quét được bảo toàn 100%.

Dưới đây là sơ đồ Sequence Diagram tổng quan mô tả quá trình AI mô phỏng một cuộc tấn công khép kín từ việc truy vấn log đến việc bắt cờ (detect) lỗ hổng:

sequenceDiagram
    participant Agent as 🤖 AI Agent (LLM)
    participant Proxy as 🛡️ Caido (ProxyManager)
    participant Target as 🎯 Target Server

    rect rgba(199, 213, 226, 1)
    Note over Agent, Proxy: 1. Tìm kiếm rà quét mục tiêu (Search & Analyze)
    Agent->>Proxy: list_requests(filter="req.method.eq:POST")
    Proxy-->>Agent: Mảng [Request IDs]
    Agent->>Proxy: view_request(id="req_123")
    Proxy-->>Agent: Trả về Raw HTTP Headers & Body
    end

    rect rgba(204, 179, 179, 1)
    Note over Agent, Target: 2. Tái tạo & Tấn công (Replay & Modify)
    Agent->>Agent: Suy luận sinh Payload độc hại (ví dụ: SQLi)
    Agent->>Proxy: repeat_request(id="req_123", modifications={"body": payload})
    Proxy->>Proxy: Tái tạo gói tin HTTP hợp lệ từ "req_123" cũ
    Proxy->>Target: Gửi HTTP Request độc hại 
    Target-->>Proxy: Gửi lại HTTP Response
    end

    rect rgba(215, 232, 215, 1)
    Note over Proxy, Agent: 3. Kiểm chứng & Ghi log (Relogging & Detection)
    Proxy->>Proxy: Relogging: Ghi nhận Traffic vào cơ sở dữ liệu Caido
    Proxy-->>Agent: Trả về Response Body / Status (rút gọn nếu quá dài)
    Agent->>Agent: Detect: Phân tích phản hồi để xác nhận lỗ hổng
    end

5. Ví dụ Thực Tế: Quy Trình "Đào Bới" SQL Injection (Step-by-Step)

Để dễ hình dung sức mạnh của cặp đôi Strix + Caido, hãy cùng xem cách AI Agent thực hiện một đợt tấn công dò tìm lỗi SQLi tại API đăng nhập khách hàng:

🚶 Bước 1: Lọc Log để tìm "Con mồi" (Search)

Agent không quét bừa bãi. Nó hỏi Caido: "Cho tôi xem các request POST đã thực hiện thành công (200 OK) tại endpoint có chữ 'login'?"

Lý do: Đây là nơi thường xuyên tương tác với Database.
Dữ liệu Caido trả về: Request ID req_login_001, URL /api/v1/auth/login.

🔍 Bước 2: Khám nghiệm "Thi thể" Request (Analyze)

Agent gọi view_request(id="req_login_001").

Cấu trúc lưu trong Caido: Caido không chỉ lưu chữ. Nó bóc tách sẵn Header (để AI biết Agent cần mang theo Cookie/JWT gì) và Body (dạng JSON: {"user": "ngocp", "pass": "123"}).
Hành động AI: Nó nhận ra tham số user là một input tiềm năng để chèn mã.

💉 Bước 3: Phẫu thuật và Tiêm Payload (Replay & Modify)

Thay vì code Python, Agent gọi:
repeat_request(id="req_login_001", modifications={"body": "{\"user\": \"' OR 1=1 --\", \"pass\": \"123\"}"})

Cơ chế Replay: Caido lấy nguyên bộ khung (Header, User-Agent, Auth) của request cũ, chỉ thay đúng phần Body chứa "độc chất" SQLi rồi bắn đi.

🚩 Bước 4: So sánh Kết quả (Detection)

Caido trả về Response mới cho Agent.

Logic Detect của Agent:
- Lần 1 (Bình thường): Trả về {"status": "fail", "msg": "Invalid pass"}.
- Lần 2 (Tiêm payload): Trả về {"status": "success", "user": "admin"}.
Kết luận: AI so sánh sự khác biệt và xác nhận: "Bingo! Lỗ hổng SQLi tồn tại vì Payload bypass được logic đăng nhập".

📝 Bước 5: Lập Hồ Sơ Bệnh Án (Reporting)

Strix không kết thúc ở đó. Nó tổng hợp dữ liệu từ Caido:

Evidence: Nó trích xuất ID request gốc và ID request tấn công làm bằng chứng.
Deduplication: Nó kiểm tra xem lỗi SQLi ở /api/v1/auth/login này đã có ai báo cáo chưa (Dùng module Dedupe đã nói ở trên) trước khi tạo một Vulnerability Report chính thức cực kỳ chuyên nghiệp cho Senior Dev đọc.

👉 Điểm khác biệt mấu chốt:

Trong khi các tool khác chỉ bắn payload và đọc kết quả (Stateless), Strix dựa vào Caido để duy trì Stateful Pentesting. Nó biết mình đang sửa cái gì dựa trên cái gì, giúp giảm thiểu 90% lỗi sai cú pháp khi AI cố gắng tự giả lập giao thức HTTP.

B. Minh Chứng Bằng Code (Điểm ăn tiền cho Developer)

Một system prompt điển hình dạy AI cách tấn công (được trích xuất từ file python_actions_schema.xml):

# LLM nhận diện Request cũ có ID request_details['id']
body = request_details.get('body', '')
if "select" in body.lower():
    # Thay vì viết code gửi cURL phức tạp, Agent chỉ cần gọi một Tool
    test_payload = repeat_request(request_id, {
        'body': body + "' OR '1'='1" 
    })
    print(f"Test response status: {test_payload.get('status_code')}")

Bên dưới mui xe, hàm Tool này làm gì? Request đi qua module Action (Tầng Middleware):

# Trích xuất đoạn mã nhận lệnh ở proxy_actions.py
@register_tool
def repeat_request(request_id: str, modifications: dict[str, Any] | None = None) -> dict[str, Any]:
    from .proxy_manager import get_proxy_manager
    manager = get_proxy_manager()
    return manager.repeat_request(request_id, modifications or {})

Cuối cùng là màn ảo thuật của ProxyManager ở tầng Core Dữ Liệu (strix/tools/proxy/proxy_manager.py). Đây là cách nó đóng trực tiếp luồng traffic ảo vừa tạo vào Proxy nội bộ:

# Trích xuất từ _send_modified_request() (proxy_manager.py)
def _send_modified_request(self, request_data: dict, request_id: str, modifications: dict):
    # Dùng thư viện request của Python để bắn gói tin mới...
    # ...NHƯNG ép kết nối đi qua cổng self.proxies (Chính là con Caido 127.0.0.1:48080)
    response = requests.request(
        method=request_data["method"],
        url=request_data["url"],
        headers=request_data["headers"],
        data=request_data["body"] or None,
        proxies=self.proxies, # ĐIỂM SÁNG: Ép luồng traffic Replay ghi nhận lại vào Caido
        timeout=30,
        verify=False,
    )
    # Rút gọn response nếu quá dài
    response_body = response.text
    if len(response_body) > 10000:
        response_body = response_body[:10000] + "\n... [truncated]"

    return {
        "status_code": response.status_code,
        "body": response_body
    }

Tại sao Architecture Replay này lại tối ưu?

Chống sai sót cho LLM (Error-Proof): LLM thường sai cú pháp (thiếu Header Authorization, viết sai MIME boundary hoặc quên escape JWT). Khi sử dụng hàm repeat_request(id, modifications), Strix tự động clone 90% kết cấu hợp lệ từ cái ID cũ, LLM chỉ cung cấp nội dung body muốn tiêm vào. Cấu trúc gói tin HTTP luôn đảm bảo 100% hợp lệ.
Audit Logging tuyệt đối: Mọi viên đạn (Payload) mà LLM bắn đi đều được ghi vào Caido Database. Bạn thao tác trên dashboard (Giao diện đồ họa) của Caido cũng có thể kiểm chứng ngay lập tức chuỗi hành vi tấn công của Agent AI đó.

Forem: Ngoc Phan