Tiếng Việt: Security vulnerability scanning and penetration test planning

Khi nói đến security testing, phần lớn QA engineer vẫn coi đây là "sân chơi" riêng của security team hoặc pentester chuyên nghiệp. Nhưng thực tế tại nhiều công ty vừa và nhỏ, QA chính là người viết ra phần lớn test case liên quan đến security - đơn giản vì không có đủ ngân sách để thuê pentest (penetration test - kiểm thử xâm nhập) cho mọi sprint. Vấn đề là: viết security test case đòi hỏi kiến thức chuyên sâu về attack vector, và một QA giỏi về functional testing chưa chắc biết cách nghĩ như một attacker.

Đây chính là chỗ AI phát huy giá trị. LLM (Large Language Model) được train trên khối lượng khổng lồ tài liệu về OWASP, CVE (Common Vulnerabilities and Exposures - danh mục lỗ hổng đã biết công khai), security advisory, penetration test report... nên nó có thể đóng vai "cố vấn security" giúp QA sinh ra test case có chất lượng gần với chuyên gia. Nhưng cũng chính vì tính "biết tuốt" đó mà AI dễ sinh ra false positive (kết quả báo sai), hoặc worse - tạo cảm giác an toàn giả khi test case chỉ mang tính hình thức. Bài này sẽ đi từ việc dùng AI sinh test case theo OWASP Top 10, xác định vùng rủi ro trong scope test, threat modeling (mô hình hóa mối đe dọa) với STRIDE, đến việc review lại chính output của AI để tránh rơi vào cái bẫy "AI nói sao tin vậy".

Cách Dùng AI Sinh Test Case Bảo Mật Dựa Trên OWASP Top 10?

Vấn đề chuyển đổi: từ framework sang test case

OWASP Top 10 là danh sách 10 rủi ro bảo mật phổ biến nhất cho ứng dụng web, được cập nhật định kỳ bởi tổ chức OWASP (Open Worldwide Application Security Project). Phiên bản 2021 gồm: A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable and Outdated Components, A07 Identification and Authentication Failures, A08 Software and Data Integrity Failures, A09 Security Logging and Monitoring Failures, A10 Server-Side Request Forgery (SSRF).

Vấn đề là OWASP Top 10 mô tả loại rủi ro, không phải test case cụ thể. Ví dụ A03 Injection nói "ứng dụng dễ bị injection khi dữ liệu không được validate/sanitize trước khi đưa vào interpreter" - đó là một nguyên lý, không phải một bước test. Để biến nguyên lý này thành test case chạy được, QA phải tự map nó vào từng endpoint, từng input field cụ thể của hệ thống mình đang test. Đây là bước tốn thời gian nhất, và cũng là bước AI hỗ trợ tốt nhất - miễn là bạn cho AI đủ context về API, data model, và business logic.

Nếu chỉ hỏi AI "cho tôi test case OWASP Top 10", bạn sẽ nhận về danh sách chung chung, không gắn với hệ thống thật. Chìa khóa là feed cho AI OpenAPI spec, mô tả nghiệp vụ, và role/permission model của ứng dụng.

Prompt mẫu để sinh test case theo OWASP

Dưới đây là prompt template thực tế, có thể copy và điền context vào để dùng ngay:

Bạn là một Security QA Engineer có kinh nghiệm thực hiện penetration testing
cho ứng dụng web B2B SaaS. Dựa trên thông tin dưới đây, hãy sinh test case
bảo mật cho endpoint được cung cấp, map theo từng nhóm rủi ro OWASP Top 10
2021 có liên quan.

## Application Context
- Ứng dụng: Nền tảng quản lý đơn hàng B2B, phục vụ 3 role: admin,
  sales_rep, viewer.
- Authentication: JWT bearer token, hết hạn sau 30 phút, có refresh token.
- Database: PostgreSQL, dùng ORM (Sequelize), không viết raw SQL trong code
  ứng dụng (nhưng có 2 report endpoint dùng raw query).
- Ứng dụng deploy trên AWS, phía sau ALB + WAF (AWS WAF managed rules).

## Relevant Endpoints (from OpenAPI spec)
POST /api/v1/orders
  - Body: { "customer_id": int, "items": [{sku, qty, unit_price}],
            "discount_code": string, "notes": string }
  - Auth: Bearer token, role sales_rep hoặc admin
  - Response 201: { order_id, status, total }

GET /api/v1/orders/{order_id}
  - Auth: Bearer token (mọi role đã login)
  - Response 200: chi tiết đơn hàng bao gồm customer info, payment status

GET /api/v1/reports/revenue?from={date}&to={date}&customer_id={id}
  - Auth: Bearer token, role admin
  - Implementation: dùng raw SQL query để aggregate theo customer_id

Với mỗi endpoint trên, hãy:
1. Xác định các nhóm OWASP Top 10 có khả năng áp dụng, giải thích ngắn vì sao.
2. Với mỗi nhóm rủi ro áp dụng được, viết ít nhất 1 test case theo format
   Given/When/Then, ghi rõ input độc hại cụ thể sẽ dùng để test.
3. Đánh mức độ ưu tiên (Critical/High/Medium/Low) dựa trên khả năng khai thác
   và tác động nếu bị khai thác thành công.
4. Không bịa ra hành vi hệ thống - nếu thiếu thông tin để xác định chắc chắn,
   hãy ghi rõ "cần xác nhận thêm: <câu hỏi>".

Điểm quan trọng trong prompt này: mục 4 yêu cầu AI thừa nhận thiếu thông tin thay vì tự suy diễn. Đây là kỹ thuật giảm hallucination khá hiệu quả với security test case, vì AI rất dễ "đoán" hành vi validate mà code thực tế không có.

Sinh test case cho OWASP A03: Injection

Với endpoint GET /api/v1/reports/revenue dùng raw SQL query, đây là ví dụ AI thường sinh ra (và là test case đáng để chạy thật, không phải chỉ để trang trí report):

Feature: SQL Injection trên report endpoint

  Scenario: Injection qua param customer_id dạng UNION-based
    Given tôi có JWT token hợp lệ với role "admin"
    When tôi gửi GET request đến
      "/api/v1/reports/revenue?from=2026-01-01&to=2026-07-01&customer_id=1 UNION SELECT username,password,null,null FROM users--"
    Then response không được trả về dữ liệu từ bảng users
    And response status phải là 400 (invalid input) hoặc 200 với kết quả
      rỗng/đúng logic nghiệp vụ, KHÔNG được là 500 kèm SQL error message
    And log server không chứa raw SQL query kèm input chưa qua xử lý

  Scenario: Injection qua param date dạng boolean-based blind
    Given tôi có JWT token hợp lệ với role "admin"
    When tôi gửi GET request với from="2026-01-01' OR '1'='1"
    Then thời gian phản hồi không được chênh lệch bất thường so với baseline
      (loại trừ time-based blind injection)
    And dữ liệu trả về không được bao gồm toàn bộ record ngoài phạm vi
      customer_id được chỉ định

Lưu ý: test case thứ hai (time-based blind) là loại rất dễ bị AI generate chung chung mà không tính đến baseline response time - khi review lại, QA cần bổ sung bước đo baseline trước khi so sánh.

Mẹo: Đừng bao giờ paste toàn bộ OpenAPI spec + toàn bộ database schema vào một prompt duy nhất rồi hỏi "tìm hết lỗ hổng đi". AI sẽ trả lời hời hợt vì phải rải attention cho quá nhiều context. Chia nhỏ theo từng endpoint hoặc từng nhóm chức năng (auth, payment, report...) trong từng lượt prompt riêng, kèm câu hỏi cụ thể (ví dụ chỉ hỏi về injection) sẽ cho test case sâu và chính xác hơn nhiều.

Cách Xác Định Rủi Ro Injection, Auth, và Data Exposure Trong Scope Test Với AI?

Xây dựng attack surface map từ API spec

Attack surface (bề mặt tấn công) là tập hợp toàn bộ điểm mà attacker có thể tương tác với hệ thống: mọi endpoint, mọi input field, mọi nơi có thể truyền dữ liệu vào (query param, header, cookie, file upload, webhook callback...). Trước khi viết test case chi tiết, QA nên yêu cầu AI dựng một bản đồ attack surface từ OpenAPI spec, phân loại theo mức độ nhạy cảm.

Từ OpenAPI spec dưới đây, hãy tạo một bảng attack surface gồm các cột:
Endpoint | Method | Input Points (params/body/header) | Yêu cầu Auth |
Dữ liệu nhạy cảm liên quan | Rủi ro chính (injection/IDOR/auth bypass/
data exposure) | Mức ưu tiên test.

Ưu tiên các endpoint: (1) không yêu cầu auth hoặc auth yếu, (2) có tham số
dạng ID trực tiếp (order_id, user_id, invoice_id...), (3) trả về dữ liệu
cá nhân hoặc tài chính, (4) nhận input dùng để build query/command/file path.

[dán OpenAPI spec ở đây]

Kết quả bảng này trở thành input trực tiếp cho bước phân loại rủi ro injection/auth/data exposure ở phần sau, và cũng chính là tài liệu để trace coverage khi report cho stakeholder.

Nhận diện rủi ro IDOR (Insecure Direct Object Reference)

IDOR (Insecure Direct Object Reference - tham chiếu trực tiếp đối tượng không kiểm soát) xảy ra khi ứng dụng dùng ID do client gửi lên (order_id, invoice_id, user_id...) để truy xuất dữ liệu mà không kiểm tra người gọi có quyền sở hữu/truy cập đối tượng đó hay không. Đây là lỗi thuộc nhóm A01 Broken Access Control, và là một trong những lỗi phổ biến nhất trong thực tế vì rất dễ code sai (chỉ cần quên một dòng kiểm tra WHERE user_id = current_user.id).

Với endpoint GET /api/v1/orders/{order_id} ở ví dụ trên, test case IDOR điển hình:

Feature: IDOR trên order detail endpoint

  Scenario: User A truy cập được order của User B qua đổi order_id
    Given User A (role viewer, thuộc company X) đã login và có order_id
      hợp lệ là "1001" thuộc company X
    And tồn tại order_id "1002" thuộc company Y (không liên quan đến User A)
    When User A gửi GET request đến "/api/v1/orders/1002" bằng token của mình
    Then response phải trả về 403 Forbidden hoặc 404 Not Found
    And response KHÔNG được trả về chi tiết order 1002
      (customer info, payment status...)

  Scenario: Duyệt tuần tự order_id để dò dữ liệu (ID enumeration)
    Given User A có token hợp lệ với quyền viewer
    When tôi gửi 20 request liên tiếp với order_id tăng dần từ 1000 đến 1020
    Then hệ thống chỉ trả 200 cho các order thuộc quyền của User A
    And các request bị chặn không rò rỉ thông tin qua response time hoặc
      error message khác biệt (tránh information disclosure gián tiếp)

Điểm hay bị bỏ qua: nhiều team chỉ test "đổi ID sang của người khác thì bị chặn không", nhưng quên test trường hợp enumeration (dò một loạt ID) - đây là cách attacker thật sự khai thác IDOR ở quy mô lớn, và cũng là lúc rate limiting/logging phải phát huy tác dụng.

Nhận diện rủi ro authentication bypass

Authentication bypass thuộc nhóm A07 (Identification and Authentication Failures). Các dạng phổ biến: quên revoke token sau logout, JWT không verify signature đúng cách (chấp nhận alg=none), session không hết hạn, hoặc endpoint "quên" áp middleware auth. AI khá hữu ích để rà soát danh sách endpoint và gợi ý những chỗ có khả năng bị bỏ sót auth middleware, nhưng bước xác minh cuối cùng luôn phải làm bằng tay qua request thật.

Ví dụ verify bằng tay một finding "endpoint thiếu auth check" bằng curl:

curl -i -X GET https://api.example.com/api/v1/orders/1001


curl -i -X GET https://api.example.com/api/v1/orders/1001 \
  -H "Authorization: Bearer <expired_or_revoked_token>"


curl -i -X GET https://api.example.com/api/v1/orders/1001 \
  -H "Authorization: Bearer eyJhbGciOiJub25lIn0.eyJyb2xlIjoiYWRtaW4ifQ."

Nhận diện rủi ro sensitive data exposure

Data exposure (rò rỉ/lộ dữ liệu nhạy cảm - thuộc A02 Cryptographic Failures khi liên quan đến mã hóa, hoặc A01/A05 khi do lỗi access control/misconfiguration) thường ẩn trong những chỗ ít ai ngờ: response body trả dư field không cần thiết (ví dụ trả cả password_hash trong object user), error message tiết lộ stack trace/version library, log file ghi lại full request body chứa credit card number, hay file upload public S3 bucket không cần signed URL.

AI hỗ trợ tốt việc rà soát response schema để phát hiện field "over-exposure" - so sánh field nào thực sự cần thiết cho use case của client với field mà API đang trả về. Nhưng AI không tự biết log server ghi gì, S3 bucket policy ra sao - những thứ này cần QA tự kiểm tra qua log thật hoặc cấu hình infra thật.

Mẹo: Khi AI liệt kê rủi ro IDOR/auth/data exposure, luôn yêu cầu nó chỉ rõ "test case này cần role nào, cần bao nhiêu account test để so sánh chéo (cross-account testing)". Rất nhiều rủi ro access control chỉ lộ ra khi so sánh hành vi giữa 2-3 account có quyền khác nhau - nếu AI chỉ đưa ra test case với 1 account duy nhất, khả năng cao nó đang bỏ sót phần quan trọng nhất của IDOR/broken access control.

AI Hỗ Trợ Threat Modeling và Xây Dựng Attack Surface Map Như Thế Nào?

Framework STRIDE và AI

STRIDE là mô hình threat modeling do Microsoft phát triển, chia rủi ro thành 6 nhóm: Spoofing (giả mạo danh tính), Tampering (thay đổi dữ liệu trái phép), Repudiation (chối bỏ hành vi đã thực hiện), Information Disclosure (rò rỉ thông tin), Denial of Service (từ chối dịch vụ), và Elevation of Privilege (leo thang đặc quyền). Đây là công cụ threat modeling kinh điển, thường được áp dụng ở giai đoạn design review trước khi code, nhưng QA cũng dùng được ở giai đoạn test planning để đảm bảo không bỏ sót nhóm rủi ro nào.

Prompt để AI hỗ trợ threat modeling theo STRIDE:

Bạn là security architect. Dựa trên mô tả hệ thống dưới đây, hãy áp dụng
framework STRIDE để xác định threat cho từng thành phần chính. Với mỗi
threat, ghi rõ: thành phần bị ảnh hưởng, kịch bản khai thác cụ thể, mức độ
tác động (impact), và biện pháp giảm thiểu hiện có (nếu biết) hoặc đề xuất.

## System Description
Hệ thống thanh toán nội bộ cho B2B order platform:
- Client (web app React) gọi API Gateway qua HTTPS.
- API Gateway xác thực JWT, forward request đến Order Service.
- Order Service gọi Payment Service (internal, không expose public) qua
  gRPC để trừ tiền từ ví khách hàng.
- Payment Service ghi transaction log vào một bảng audit_log riêng,
  không có cơ chế ký số (signing) cho log entry.
- Webhook callback từ payment gateway bên thứ 3 (ví dụ Stripe-like) gọi
  ngược vào Order Service để cập nhật trạng thái thanh toán, endpoint
  webhook hiện không verify signature của bên gửi.

Hãy trình bày kết quả dưới dạng bảng STRIDE.

Ví dụ bảng STRIDE mà AI (sau khi tinh chỉnh, review lại) có thể sinh ra cho tính năng webhook thanh toán này:

Phân tích data flow diagram để tìm lỗ hổng

Sau khi có bảng STRIDE, bước tiếp theo là vẽ (hoặc để AI mô tả bằng text/mermaid) data flow diagram (DFD - sơ đồ luồng dữ liệu) thể hiện luồng dữ liệu giữa các thành phần, đánh dấu "trust boundary" - đường biên nơi dữ liệu đi từ vùng tin cậy thấp sang vùng tin cậy cao (ví dụ: từ internet vào internal network, từ user input vào database). Phần lớn lỗ hổng nghiêm trọng nằm ngay tại các trust boundary này - đúng như ví dụ webhook ở trên: request đi từ bên thứ 3 (không tin cậy) trực tiếp vào Order Service (tin cậy) mà không qua bước verify.

Có thể yêu cầu AI generate DFD dạng mermaid để dễ visualize và review cùng team:

Hãy vẽ data flow diagram dạng mermaid cho hệ thống mô tả ở trên, đánh dấu
rõ trust boundary bằng subgraph riêng, chú thích tại mỗi boundary dữ liệu
nào đi qua và cơ chế kiểm soát hiện có/còn thiếu.

Sinh tài liệu phạm vi penetration test

Từ attack surface map và bảng STRIDE, AI có thể hỗ trợ soạn draft "Penetration Test Scope Document" - tài liệu xác định rõ: hệ thống nào trong scope, hệ thống nào ngoài scope (ví dụ third-party payment gateway thường ngoài scope vì QA không được phép pentest hạ tầng của bên thứ 3), khung thời gian test, loại test được phép (black-box/gray-box/white-box), và điều kiện dừng test (rules of engagement) để tránh gây downtime cho production.

Mẹo: Threat modeling là bước dễ bị AI "vẽ đẹp nhưng sai thực tế" nhất trong cả quy trình, vì AI không biết kiến trúc thật của hệ thống bạn - nó chỉ suy luận từ mô tả bạn cung cấp. Luôn tổ chức một buổi review threat model cùng dev/architect thực tế trước khi biến nó thành test case chính thức, đừng để bảng STRIDE do AI sinh ra trở thành "tài liệu cho có" chỉ vì nhìn chuyên nghiệp.

Cách Review Test Case Bảo Mật Do AI Sinh Để Tránh False Positive?

Các nhóm false positive thường gặp trong test case bảo mật do AI sinh

False positive - test case cho rằng có lỗ hổng nhưng thực chất không phải, hoặc lỗ hổng không khả thi để khai thác - là vấn đề lớn nhất khi dùng AI sinh security test case ở quy mô lớn. Một số nhóm phổ biến:

1. Giả định thiếu control đã tồn tại: AI đề xuất test SQL injection cho endpoint dùng ORM parameterized query (đã an toàn với injection cơ bản), vì nó không biết code thực tế đã dùng ORM.
2. Đánh giá sai severity vì thiếu context về network/infra: AI gắn "Critical" cho một endpoint internal chỉ accessible qua VPN, trong khi thực tế attack surface bị giảm đáng kể do đã có network-level control.
3. Lỗi test case do hiểu sai business logic: AI đề xuất test case "user không nên xem được order của công ty khác" nhưng thực ra tính năng đó là share order giữa các công ty partner theo thiết kế (không phải bug).
4. Trùng lặp/generic test case không gắn với endpoint cụ thể: test case kiểu "kiểm tra XSS trên mọi input field" mà không chỉ rõ input field nào, payload nào, dễ tạo cảm giác coverage cao nhưng thực chất rỗng.
5. Đề xuất kiểm tra công cụ/hạ tầng nằm ngoài khả năng kiểm soát của team (ví dụ yêu cầu test lỗ hổng ở tầng CDN/WAF của bên thứ 3 mà team không có quyền chỉnh sửa).

Prompt để review lại test case bảo mật đã sinh

Bạn là Security Lead đang review một bộ test case bảo mật do một AI khác
sinh ra, mục tiêu là loại bỏ false positive trước khi đưa vào test plan
chính thức. Với mỗi test case dưới đây, hãy đánh giá:
1. Test case này có phù hợp với kiến trúc/control thực tế đã mô tả không?
2. Severity gán có hợp lý không, dựa trên control hiện có?
3. Test case có đủ cụ thể để một QA khác thực thi được ngay không
   (input rõ, bước rõ, kết quả mong đợi rõ)?
4. Nếu là false positive hoặc cần chỉnh sửa, hãy nêu rõ vì sao và sửa lại
   test case cho chính xác.

## Application Context
- Toàn bộ query đến DB đi qua ORM (Sequelize) với parameterized query,
  KHÔNG có raw SQL ở bất kỳ endpoint public nào (raw SQL chỉ tồn tại ở
  1 endpoint report, đã whitelist input là số nguyên qua schema validation).
- Mọi endpoint internal-only (prefix /internal/*) chỉ accessible qua VPC,
  không expose qua internet, có network policy chặn từ ngoài.
- Order sharing giữa company partner là tính năng hợp lệ, được cấu hình
  qua bảng order_shares - không phải bug nếu User A xem được order đã
  share cho company của họ.

## Generated Test Cases to Review
1. [Injection - Critical] Test SQL injection trên endpoint
   POST /api/v1/orders bằng payload "'; DROP TABLE orders;--" trong field
   notes.
2. [Access Control - Critical] Test truy cập endpoint
   GET /internal/admin/users từ một máy ngoài mạng công ty mà không có VPN,
   kỳ vọng phải bị chặn ở network layer.
3. [Access Control - High] Test User A (company X) xem order thuộc
   company Y khi order đó đã được share qua order_shares, kỳ vọng phải bị
   từ chối truy cập.
4. [XSS - Medium] Kiểm tra mọi input field trong ứng dụng có bị XSS không.

Với input này, một reviewer (người hoặc AI đóng vai reviewer) sẽ chỉ ra: test case 1 vẫn nên giữ nhưng hạ severity xuống Medium (vì ORM đã chặn hầu hết injection cổ điển, chỉ còn rủi ro ORM bị dùng sai như raw query/sequelize.literal), test case 2 hợp lệ nhưng nên tách rõ đây là network-level test, không phải application-level; test case 3 là false positive rõ ràng vì đây là hành vi thiết kế đúng, cần sửa lại thành test case kiểm tra "order KHÔNG thuộc order_shares" mới đúng mục tiêu; test case 4 quá chung, cần liệt kê cụ thể field nào, payload nào, và context output (reflected trong HTML, JSON API, hay email template).

Xây dựng checklist review test case bảo mật

Một checklist review nhanh, dùng trước khi đưa bất kỳ test case bảo mật do AI sinh vào test plan chính thức:

• [ ] Test case có gắn với endpoint/component cụ thể, không generic mơ hồ?
• [ ] Input độc hại (payload) được ghi rõ ràng, có thể copy-paste chạy lại được?
• [ ] Severity có tính đến control đã tồn tại (ORM, WAF, network policy, input validation)?
• [ ] Test case có phân biệt được giữa "hành vi thiết kế đúng" và "lỗ hổng thật" không?
• [ ] Expected result có đo lường được (status code, response field, response time), không mơ hồ kiểu "phải an toàn"?
• [ ] Test case nằm trong phạm vi (scope) mà team có quyền thực thi, không đụng vào hạ tầng bên thứ 3 ngoài quyền kiểm soát?
• [ ] Đã cross-check với dev/architect về giả định kiến trúc mà AI đưa ra chưa?
• [ ] Có test case nào bị trùng lặp về bản chất (chỉ khác cách diễn đạt) cần gộp lại?

Điều chỉnh AI theo thời gian

False positive không tự nhiên biến mất - nó giảm dần khi bạn đầu tư thời gian "dạy" AI hiểu rõ hơn về hệ thống của mình. Cách thực tế nhất: mỗi lần phát hiện false positive, ghi lại lý do vào một tài liệu "known false positive patterns" và feed lại đoạn đó vào system prompt hoặc project context (ví dụ CLAUDE.md, hoặc context file riêng cho security testing) cho những lần generate sau. Theo thời gian, tỷ lệ false positive sẽ giảm đáng kể vì AI dần "nhớ" được các control đặc thù của hệ thống (ORM nào đang dùng, network model ra sao, tính năng share nào là hợp lệ).

Ngoài ra, nên theo dõi một vài chỉ số đơn giản qua từng sprint: tỷ lệ test case bị loại bỏ sau review / tổng test case AI sinh, và tỷ lệ lỗ hổng thật được phát hiện qua test case AI sinh / tổng lỗ hổng phát hiện được (bao gồm cả cách khác như manual pentest, bug bounty). Nếu tỷ lệ false positive không giảm sau vài sprint dù đã update context liên tục, đó là dấu hiệu cần xem lại chất lượng prompt hoặc cần con người kiểm soát chặt hơn ở bước review, không nên phó hoàn toàn cho AI.

Mẹo: Đừng review test case bảo mật do AI sinh một mình. Cách hiệu quả nhất là đưa batch test case cho một AI session khác (hoặc một mô hình khác) đóng vai "adversarial reviewer" (người rà soát phản biện) như prompt ví dụ trên, sau đó con người chỉ cần xử lý phần AI đã lọc ra là nghi vấn/không chắc chắn - việc này giảm đáng kể effort review thủ công mà vẫn giữ được lớp kiểm soát con người ở quyết định cuối cùng.