OWASP cho engineer: threat theo luồng dữ liệu (không checklist rỗng)

OWASP Top 10 hữu ích như bản đồ rủi ro phổ biến, nhưng khi triển khai feature, engineer cần một cách suy nghĩ theo luồng dữ liệu: dữ liệu không tin cậy đi vào đâu, quyền được kiểm tra ở đâu, và attacker có khả năng gì tại từng lớp.

Phạm vi: web/API service điển hình. Không: pentest methodology đầy đủ, không deep crypto.

Tham chiếu mạng/TLS: HTTP, TLS, HTTP/2/3, Debug mạng checklist.

1. Luồng dữ liệu và trust boundary (ASCII)

Ví dụ đơn giản hoá:

[Browser/Mobile] --TLS--> [Ingress/LB] --> [API Service] --> [DB]
                untrusted              policy          trusted-ish

• Trust boundary: ranh giới bạn không tin input (user, webhook partner, header từ client).
• Mỗi lần dữ liệu cắt qua boundary, phải có validate + authn/z rõ ràng — “tin middleware” mà không biết middleware làm gì là lỗ hổng quy trình.

2. STRIDE rút gọn (dùng như checklist có trọng số)

STRIDE không phải để “đánh dấu đủ ô”; nó để bắt quên ở boundary.

3. Bốn họ lỗ hổng hay gặp theo điểm giao cắt

3.1. Injection (SQL/NoSQL/command/template)

• Giao cắt: mọi chỗ ghép string vào query/shell/template.
• Tối thiểu: parameterized query, allow-list input, không eval dữ liệu user.

3.2. SSRF

• Giao cắt: URL do user cung cấp → server fetch nội bộ.
• Tối thiểu: allow-list domain, chặn metadata IP, network policy egress — xem thêm VPC/cloud.

3.3. Broken authorization

• Giao cắt: mọi handler đọc/ghi resource theo tenantId / orderId.
• Tối thiểu: authz ở server theo resource, không tin client role flag.

3.4. Deserialization / gadget chain

• Giao cắt: nhận blob phức tạp từ không tin cậy.
• Tối thiểu: format đơn giản (JSON schema), version, giới hạn kích thước.

4. Defense-in-depth “đủ mức rủi ro”

Không phải service nội bộ nhỏ cũng cần WAF enterprise + HSM. Chiến lược hợp lý:

• Rủi ro thấp + attack surface nhỏ: validate chặt, authz, logging, dependency update.
• Rủi ro cao (PII, tiền): thêm rate limit, WAF rule có mục tiêu, secret rotation, pentest định kỳ.

5. Test tối thiểu: authz matrix

Tạo bảng nhỏ:

Viết ít nhất một test tự động cho mỗi ô “deny” quan trọng. Đây là nơi bug “đọc được đơn người khác” thường lọt.

Khi không nên formal threat model nặng

• Spike nội bộ < 48h: vẫn nên boundary + injection checklist ngắn.
• Khi team đã có security champion review theo risk tier — tránh paperwork không dẫn tới test.

6. Luồng chi tiết hơn: webhook từ đối tác

Partner gửi POST /webhooks/partner với JSON ký HMAC. Trust boundary:

1. TLS terminate ở ingress — kiểm tra cert, cipher phù hợp (xem TLS).
2. Verify signature với clock skew có giới hạn — chống replay (nonce hoặc timestamp).
3. Authz: webhook này được phép map tới tenant_id nào — đừng tin field tenant_id trong body nếu không có registry secret per tenant.
4. Handler: idempotent theo event_id đối tác — tránh xử lý trùng khi partner retry.

Giải thích thêm: mỗi bước là một cơ hội “fail closed” hoặc “fail open”; chọn sai kiểu (ví dụ bỏ verify khi load cao) là chấp nhận rủi ro có chủ đích — phải ghi lại.

7. Bảng: rủi ro vs kiểm soát tối thiểu (tier)

ASVS gợi ý “level” tương tự — bạn không cần Level 3 cho mọi endpoint.

8. SSRF sâu hơn một lớp: metadata cloud

Kể cả khi chặn 169.254.169.254 trong URL literal, attacker có thể dùng redirect chain, DNS rebinding, hoặc parser URL khác nhau giữa validator và HTTP client. Tầng bổ sung: egress NetworkPolicy, proxy egress có allow-list, disable follow redirect hoặc giới hạn hop.

Tham chiếu: VPC / cloud networking.

9. Supply chain và dependency

Threat modeling hiện đại không thể bỏ qua npm/pip/maven — một package nhỏ trong graph có thể là điểm vào. Kiểm soát tối thiểu:

• Lockfile + CI verify checksum.
• Dependabot/Renovate có policy SLA merge.
• Không chạy postinstall tùy tiện trong CI secret context.

10. Viết yêu cầu bảo mật cho ticket (template)

- Dữ liệu nhạy cảm tier: T0/T1/T2
- Trust boundary mới: (mô tả)
- Authn: … / Authz: resource nào, role nào
- Input: schema + max size
- Log/PII: redact gì
- Abuse case: rate limit / quota

Nếu ticket không điền được các mục trên, review security sẽ đoán — đó là nguồn bug.

Bài tập ngẫu

Chọn một endpoint POST /imports nhận file URL: liệt kê 5 threat theo luồng (spoofing URL, SSRF, virus size, authz tenant, log leak).

Mở rộng: Với mỗi threat, ghi một test hoặc một control cụ thể (không chỉ “validate”).

11. Mass assignment và “hidden fields”

Framework cho phép bind JSON → object có thể vô tình cho phép user set role: admin. Threat: tampering ở lớp ORM. Kiểm soát: allow-list field, DTO riêng cho public API, tách schema “admin update” khỏi “user self-service”.

12. Rate limit như một phần của threat model

Abuse không chỉ DDoS volumetric; có thể là credential stuffing, scraping, hoặc brute OTP. Rate limit theo IP + user + device fingerprint (tuỳ privacy policy). Giải thích cho PM: limit là chi phí cho attacker, không phải chắn chắn chặn được mọi người.

13. File upload: đường đi tin cậy giảm dần

Khi file đi qua: browser → API → object storage → antivirus worker, mỗi bước có MIME sniffing, path traversal, và quota storage khác nhau. Vẽ trust boundary theo từng bước thay vì một hộp “upload”.

14. Bảo mật log: ví dụ tường minh

{ "msg": "login failed", "user": "[email protected]", "ip": "1.2.3.4" }

Có thể cần cho fraud; nhưng retention dài + search rộng → rủi ro GDPR. Policy: hash user id, rotate IP partial, retention 30 ngày cho log loại này.

15. Threat model “một trang” (template)

System: …
Assets: …
Adversaries: …
Entry points: …
Top 5 risks: …
Controls mapped: …
Test plan: …
Reviewers: …

Một trang buộc bạn ưu tiên; mười trang dễ thành shelfware.

Tóm tắt cho người vội

• Vẽ luồng + boundary trước khi học thuộc OWASP.
• STRIDE là checklist nhớ quên, không thay thế authz matrix.
• Tier hoá kiểm soát theo dữ liệu; tránh “max security mọi nơi”.

Đọc thêm

• OWASP Top 10 (bản mới nhất)
• OWASP ASVS (mức độ kiểm soát theo tier)
• TLS & SNI, Debug mạng
• HTTP, TLS, HTTP/2/3
• CWE/SANS Top 25 (bổ sung góc developer)