Chương 12 — Kiểm thử xâm nhập & Đánh giá lỗ hổng

Tổng quan

Lỗ hổng bị bỏ sót không tự biến mất — nó nằm im chờ ai đó tìm ra trước, và câu hỏi luôn là ai tìm ra trước: đội mình hay kẻ tấn công. Đó là lý do mình học chương này: nắm cho được hai cách chủ động đi tìm điểm yếu của hệ thống (web, máy chủ, mạng) trước khi nó gây rò rỉ dữ liệu — vì một lỗ hổng bỏ sót là đủ để lộ toàn bộ dữ liệu người dùng.

Chương mở đầu bằng việc tách bạch quét lỗ hổng (vulnerability scanning) — tự động so khớp dấu hiệu hệ thống với cơ sở dữ liệu lỗ hổng đã biết, rộng và nông, chỉ phát hiện chứ không khai thác — với kiểm thử xâm nhập (pentest), nơi con người mô phỏng tấn công thật, khai thác thật để chứng minh tác động, sâu và hẹp hơn nhưng dựa nhiều vào suy luận. Từ phân biệt đó, chương đi theo quy trình kiểm thử web chuẩn OWASP (WSTG): recon, mapping, testing, exploit, report — rồi vào chi tiết cơ chế ba công cụ chủ lực. Burp Suite là intercepting proxy đứng giữa trình duyệt và server để xem, sửa từng request/response; Acunetix là DAST scanner thương mại tự crawl-audit-report, bổ sung chứ không thay Burp; Nmap lập bản đồ mạng ở mức host discovery, port scanning, version/OS detection. Chương khép lại bằng phần scope và pháp lý — ranh giới được phép kiểm thử phải ghi rõ trong văn bản uỷ quyền, vì chạy ngoài scope là truy cập trái phép dù mục đích tốt tới đâu.

Mục tiêu xuyên suốt: hiểu cơ chế tới từng gói tin, có lệnh chạy được thật cho mỗi công cụ, chứ không dừng ở lý thuyết.

12.1. Phân biệt Vulnerability Scanning và Penetration Testing

12.1.1. Định nghĩa và bản chất

Vulnerability Scanning (quét lỗ hổng) là quá trình tự động phát hiện các điểm yếu đã biết (known vulnerabilities) trên hệ thống bằng cách so khớp dấu hiệu (signature/fingerprint) với một cơ sở dữ liệu lỗ hổng (vulnerability database) như NVD (National Vulnerability Database), CVE feed, hoặc database riêng của nhà cung cấp. Bản chất là breadth-first (rộng, nông): quét nhiều mục tiêu, kiểm tra nhiều dấu hiệu, nhưng KHÔNG khai thác.

Penetration Testing (kiểm thử xâm nhập) là quá trình mô phỏng tấn công có chủ đích, trong đó người (hoặc người + công cụ) cố gắng khai thác thật lỗ hổng để chứng minh tác động (impact), chuỗi tấn công (kill chain), và mức độ truy cập đạt được. Bản chất là depth-first (sâu, hẹp): tập trung vào mục tiêu cụ thể, kết hợp lỗ hổng, vận dụng logic nghiệp vụ.

12.1.2. Bảng so sánh chi tiết

12.1.3. Vì sao cần cả hai

Vulnerability scanning trả lời câu hỏi "có bao nhiêu cánh cửa khả nghi?" trong khi pentest trả lời "kẻ tấn công thật sự vào được tới đâu và làm được gì?". Một scanner báo "port 443 chạy OpenSSL có CVE-2014-0160 (Heartbleed)" — nhưng chỉ pentest mới chứng minh được rằng kéo được private key ra khỏi RAM. Trong mô hình DevSecOps, scanning được nhúng vào pipeline (shift-left, liên tục), còn pentest là kiểm chứng định kỳ ở mức sâu hơn. Scanning là điều kiện cần (nhanh, rẻ, rộng) nhưng không đủ; pentest cung cấp ngữ cảnh khai thác và mức độ rủi ro thực để ưu tiên khắc phục.

12.2. Quy trình kiểm thử web theo OWASP

OWASP WSTG (Web Security Testing Guide) chia quá trình thành các pha. Dưới đây là vòng đời thực tế áp dụng cho pentest web:

+-------------+    +-------------+    +-------------+    +--------------+    +-------------+
|  1. Recon   | -> | 2. Mapping  | -> | 3. Testing  | -> | 4. Exploit   | -> | 5. Report   |
| (thu thập)  |    | (lập bản đồ)|    | (kiểm thử)  |    | (khai thác)  |    | (báo cáo)   |
+-------------+    +-------------+    +-------------+    +--------------+    +-------------+
       ^                                                                          |
       |__________________________ (lặp lại khi tìm thấy bề mặt mới) _____________|

12.2.1. Pha 1 — Reconnaissance (thu thập thông tin)

Chia làm passive (không chạm mục tiêu) và active (gửi gói tin tới mục tiêu).

Passive recon — không tạo lưu lượng tới mục tiêu, dùng nguồn công khai: - DNS records, certificate transparency logs (crt.sh) để liệt kê subdomain. - WHOIS, Shodan, Censys, Google dorking (site:, inurl:, filetype:). - Tìm secret rò rỉ trên GitHub, Wayback Machine (archive.org).

Ví dụ liệt kê subdomain qua Certificate Transparency:

# Truy vấn crt.sh, lọc subdomain duy nhất
curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[].name_value' \
  | sed 's/\*\.//g' | sort -u

Active recon — port scan (Nmap, mục 12.5), banner grabbing, fingerprint công nghệ:

# Nhận diện công nghệ web (header Server, X-Powered-By, cookie)
curl -sI https://example.com | grep -iE 'server|x-powered-by|set-cookie'
whatweb https://example.com

12.2.2. Pha 2 — Mapping (lập bản đồ ứng dụng)

Mục tiêu: dựng site map đầy đủ các endpoint, tham số, công nghệ. Đây là lúc Burp Suite Proxy + Target site map vào cuộc (mục 12.3.4). Các kỹ thuật: - Spidering/Crawling: tự động đi theo link. - Forced browsing / content discovery: đoán đường dẫn ẩn (/admin, /.git/, /backup.zip) bằng ffuf, gobuster, dirsearch. - Phân tích robots.txt, sitemap.xml, JS bundle để tìm API endpoint.

# Content discovery với ffuf
ffuf -u https://example.com/FUZZ -w /usr/share/wordlists/dirb/common.txt \
     -mc 200,204,301,302,307,401,403 -fs 0
# -u : URL với từ khóa FUZZ được thay thế bằng từng dòng wordlist
# -w : wordlist
# -mc: match HTTP status code (chỉ hiện response có code này)
# -fs: filter theo kích thước response (loại trang rác cùng kích thước)

12.2.3. Pha 3 — Testing (kiểm thử lỗ hổng)

Đối chiếu với OWASP Top 10 và WSTG. Mỗi nhóm test có checklist: - Injection (SQLi, NoSQLi, command injection, LDAPi). - Broken Access Control (IDOR, privilege escalation, path traversal). - Authentication & Session (brute force, session fixation, token entropy yếu). - XSS (reflected, stored, DOM-based). - SSRF, XXE, deserialization, business logic.

12.2.4. Pha 4 — Exploitation (khai thác)

Chứng minh tác động: trích xuất dữ liệu, leo quyền, RCE. Chỉ chạy trong scope — xem 12.6. Ghi lại request/response làm bằng chứng. Tránh hành vi phá hủy trừ khi RoE cho phép.

12.2.5. Pha 5 — Reporting (báo cáo)

Báo cáo gồm: Executive Summary (cho lãnh đạo), kỹ thuật chi tiết (cho engineer), mỗi finding có: mô tả, mức độ (CVSS), bằng chứng (PoC, screenshot, request/response), tác động, và khuyến nghị khắc phục cụ thể.

CVSS v3.1 — Base Score vector (cần nắm để chấm điểm severity):

Ví dụ vector chuỗi: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 (Critical) — điển hình cho RCE unauthenticated qua mạng.

CVSS 4.0 (cần biết): FIRST đã phát hành CVSS v4.0 (chuỗi bắt đầu CVSS:4.0/...), bỏ metric Scope, tách nhóm Base thành Exploitability + Vulnerable/Subsequent System Impact, và bổ sung metric bảo mật con người (Safety) cùng nhóm Supplemental/Threat/Environmental. Nhiều nguồn hiện còn dùng song song v3.1, nên khi trích điểm phải ghi rõ phiên bản. (số phiên bản/độ phổ biến cần kiểm chứng theo thời điểm)

Đừng vá theo mỗi CVSS Base. Base score chỉ nói lỗ hổng "nặng tới đâu về lý thuyết", không nói nó có bị khai thác thật hay có với tới được trong hệ thống của bạn không. Thực tế nên ưu tiên vá theo tổ hợp: (a) reachability — thành phần dính CVE có thực sự nằm trên đường thực thi / có phơi ra ngoài không (lib nằm trong image nhưng không bao giờ gọi tới thì rủi ro thấp); (b) EPSS (Exploit Prediction Scoring System của FIRST) — xác suất bị khai thác trong 30 ngày tới; (c) CISA KEV (Known Exploited Vulnerabilities) — danh mục CVE đang bị khai thác ngoài thực địa, gần như luôn phải vá trước. Một CVE 9.8 không nằm trên code path và không có trong KEV thường xếp sau một CVE 7.5 đã có trong KEV + EPSS cao.

12.3. Burp Suite — phân tích chi tiết

Burp Suite (PortSwigger) là công cụ chủ lực để test web thủ công. Có ba phiên bản: Community (miễn phí, giới hạn, Intruder bị throttle, không có Scanner), Professional (có Scanner, Intruder đầy đủ), Enterprise (CI/CD, quét tự động quy mô lớn). Burp viết bằng Java, chạy trên JVM.

12.3.1. Kiến trúc Proxy MITM

Burp hoạt động như một intercepting proxy (man-in-the-middle) đặt giữa browser và server. Luồng dữ liệu:

+---------+        +------------------+        +-----------+
| Browser | <----> |  Burp Proxy      | <----> |  Server   |
| (client)| HTTP/S |  127.0.0.1:8080  | HTTP/S |  (target) |
+---------+        +------------------+        +-----------+
                   |  - Intercept     |
                   |  - Re-issue cert |
                   |  - Log site map  |
                   +------------------+

Mặc định Burp lắng nghe tại 127.0.0.1:8080. Browser cấu hình proxy trỏ tới đây. Burp nhận request, có thể tạm dừng (intercept), sửa, rồi chuyển tiếp tới server. Khi server trả về, Burp lại có thể sửa response trước khi giao cho browser.

Vì sao cần cài CA certificate

Với HTTP plaintext, MITM dễ — Burp đọc thẳng. Nhưng với HTTPS, TLS mã hóa toàn bộ. Để đọc/sửa được, Burp phải terminate TLS ở phía mình: nó thực hiện hai phiên TLS riêng biệt — một với browser, một với server.

Khi browser gửi CONNECT example.com:443, Burp: 1. Sinh động (on-the-fly) một certificate cho example.com, ký bằng CA root của Burp (mặc định tên PortSwigger CA). 2. Trình certificate giả này cho browser. 3. Browser kiểm tra chuỗi tin cậy. Nếu CA root của Burp đã được cài vào trust store của hệ điều hành/trình duyệt → hợp lệ → không cảnh báo. Nếu chưa cài → cảnh báo NET::ERR_CERT_AUTHORITY_INVALID.

Đây chính là lý do phải cài CA cert của Burp: để browser tin tưởng cert do Burp sinh ra, cho phép MITM HTTPS mà không cảnh báo, đồng thời giữ phiên TLS với server vẫn hợp lệ thật.

Lấy và cài CA cert:

1. Cấu hình browser proxy 127.0.0.1:8080
2. Truy cập http://burp  (hoặc http://burpsuite)
3. Bấm "CA Certificate" -> tải file cacert.der
4. Cài vào trust store:
   - Linux: chuyển DER->PEM rồi đưa vào /usr/local/share/ca-certificates/
   - Firefox: Settings -> Privacy & Security -> Certificates -> Import
     (đánh dấu "Trust to identify websites")

# Chuyển DER sang PEM và xem nội dung cert
openssl x509 -inform der -in cacert.der -out burp-ca.pem
openssl x509 -in burp-ca.pem -noout -text | grep -A2 'Subject:'
# Linux system-wide:
sudo cp burp-ca.pem /usr/local/share/ca-certificates/burp.crt
sudo update-ca-certificates

Lưu ý bảo mật: Burp CA private key được lưu trong cấu hình người dùng. Nếu key này rò rỉ, kẻ tấn công có thể MITM bất kỳ máy nào đã cài CA đó. Mỗi lần cài Burp sinh CA riêng — KHÔNG dùng chung. Gỡ CA khỏi trust store sau khi test xong trên máy không chuyên dụng.

12.3.2. Cấu trúc HTTP Request mà Burp thao tác

Burp hiển thị raw HTTP request theo đúng định dạng RFC 7230. Hiểu từng phần là điều kiện để sửa chính xác.

POST /api/v1/login HTTP/1.1\r\n          <- Request line: METHOD SP URI SP VERSION CRLF
Host: example.com\r\n                    <- Header
User-Agent: Mozilla/5.0\r\n
Content-Type: application/json\r\n
Content-Length: 41\r\n
Cookie: session=abc123\r\n
\r\n                                      <- Dòng trống (CRLF) phân tách header và body
{"username":"admin","password":"secret"} <- Message body (dài Content-Length byte)

Bảng cấu trúc từng phần của HTTP/1.1 request:

Vì sao: Content-Length PHẢI khớp số byte body thực tế. Khi sửa body trong Repeater, nếu không cập nhật Content-Length, server có thể chặn đứng (chờ thêm byte) hoặc cắt body. Burp Repeater có tùy chọn "Update Content-Length" tự động. Lỗ hổng HTTP Request Smuggling khai thác chính sự bất nhất giữa Content-Length và Transfer-Encoding: chunked mà front-end và back-end diễn giải khác nhau.

12.3.3. Module Proxy

Chức năng: Intercept (chặn), HTTP history (lịch sử), Match & Replace, WebSockets history.

Intercept on/off: Khi bật, mỗi request bị tạm dừng tại Burp, hiển thị để bạn sửa. Bấm "Forward" để gửi tiếp, "Drop" để hủy.

Match & Replace — luật tự động thay thế trên mọi request/response. Cấu trúc một rule:

Ví dụ thực tế: thêm X-Forwarded-For: 127.0.0.1 vào mọi request để test bypass IP allowlist:

Type:    Request header
Match:   (để trống - thêm header mới)
Replace: X-Forwarded-For: 127.0.0.1

Scope filtering: History có thể rất lớn. Nên giới hạn theo scope (mục sau) để chỉ log mục tiêu hợp pháp, tránh log lưu lượng cá nhân và tránh chạm host ngoài phạm vi.

12.3.4. Target — Site Map và Scope

Site Map là cây phân cấp host → thư mục → endpoint, tích lũy từ mọi request đi qua Burp (proxy, repeater, scanner). Mỗi node lưu request/response đã thấy.

Scope định nghĩa "mục tiêu hợp pháp". Cấu hình tại Target → Scope. Có hai chế độ: - Include in scope: danh sách host/URL được phép. - Exclude from scope: loại trừ (ví dụ trang logout, trang đăng xuất khỏi SSO).

Scope ảnh hưởng đến: Proxy có log không, Scanner có quét không, Intruder/Repeater có cảnh báo không. Định nghĩa scope nâng cao:

Include:
  Protocol: HTTPS
  Host:     ^.*\.example\.com$
  Port:     ^443$
  File:     ^/api/.*$

Vì sao (pháp lý): Scope là ranh giới pháp lý. Quét/khai thác ngoài scope = truy cập trái phép = vi phạm pháp luật (xem 12.6). Tùy chọn "Drop all out-of-scope traffic" trong Proxy options ngăn vô tình gửi request tới host ngoài phạm vi.

12.3.5. Repeater — gửi lại và sửa request

Repeater cho phép gửi một request nhiều lần với chỉnh sửa thủ công, xem response tức thì. Đây là công cụ chính để xác minh và tinh chỉnh lỗ hổng. Gửi request từ bất kỳ đâu vào Repeater bằng chuột phải → "Send to Repeater" (Ctrl+R).

Ví dụ test IDOR (Insecure Direct Object Reference)

IDOR: ứng dụng cho phép truy cập đối tượng của người khác chỉ bằng cách đổi ID, do thiếu kiểm tra authorization phía server.

Request gốc (của user A, id=1001):

GET /api/v1/orders/1001 HTTP/1.1
Host: shop.example.com
Cookie: session=eyJ1c2VyIjoiYWxpY2UifQ
Accept: application/json

Response: đơn hàng của Alice (200 OK).

Bước test: đổi 1001 → 1002 (đơn của người khác), gửi lại trong Repeater:

GET /api/v1/orders/1002 HTTP/1.1
Host: shop.example.com
Cookie: session=eyJ1c2VyIjoiYWxpY2UifQ
Accept: application/json

• Nếu response trả về đơn hàng của user khác (200 + dữ liệu) → IDOR xác nhận. Alice xem được đơn của người khác dù session vẫn là của Alice.
• Nếu trả 403 Forbidden / 404 → kiểm soát truy cập hoạt động đúng.

Phòng thủ: kiểm tra authorization phía server (object-level access control), so khớp resource.owner_id == session.user_id; UUID khó đoán giúp nhưng KHÔNG thay thế authorization.

Ví dụ test SQL Injection

Request gốc:

POST /api/v1/search HTTP/1.1
Host: shop.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

q=keyboard

Test 1 — phát hiện lỗi cú pháp (error-based): chèn một dấu nháy đơn:

q=keyboard'

Nếu response trả 500 kèm thông báo SQL syntax error near ''' → backend ghép chuỗi SQL không tham số hóa → khả năng SQLi.

Test 2 — boolean-based: so sánh hai điều kiện:

q=keyboard' AND '1'='1   -> trả kết quả bình thường (TRUE)
q=keyboard' AND '1'='2   -> trả rỗng (FALSE)

Hành vi khác nhau giữa TRUE/FALSE xác nhận injection.

Test 3 — UNION-based trích dữ liệu (sau khi xác định số cột):

q=keyboard' UNION SELECT username,password,NULL FROM users-- -

Dấu -- - comment phần SQL còn lại. Nếu kết quả trả về username/password → trích xuất dữ liệu thành công.

Lưu ý: luôn cập nhật Content-Length khi sửa body. URL-encode ký tự đặc biệt khi cần (' → %27, dấu cách → + hoặc %20) tùy Content-Type.

Phòng thủ: prepared statements / parameterized queries, ORM an toàn, least privilege cho DB account, WAF như lớp phòng thủ bổ sung (không thay thế fix gốc).

12.3.6. Intruder — tự động hóa tấn công có tham số

Intruder gửi nhiều request, thay payload vào các vị trí đánh dấu (ký hiệu §). Có 4 kiểu tấn công (attack types):

Cách đánh dấu vị trí payload

Burp đặt cặp ký tự § quanh giá trị cần fuzz:

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 29

username=§admin§&password=§x§

Ở đây có 2 vị trí. Với Cluster bomb + set1 (usernames) 10 phần tử, set2 (passwords) 100 phần tử → 1000 request.

Ví dụ brute force đăng nhập (Cluster bomb)

Attack type: Cluster bomb
Position 1 (username): payload = Simple list [admin, root, user, test]
Position 2 (password): payload = Runtime file / wordlist (rockyou rút gọn)

Phân tích kết quả: sắp xếp theo cột Status và Length. Đăng nhập sai thường trả 200 + body "Invalid credentials" có độ dài cố định; đăng nhập đúng có thể trả 302 (redirect) hoặc body khác độ dài. Dùng cột Length để lọc anomaly. Thêm Grep-Match rule (ví dụ tìm chuỗi "Welcome") để đánh dấu request thành công.

Ví dụ fuzzing tham số (Sniper) tìm SQLi/XSS

Attack type: Sniper
Position: §value§ trong q=§test§
Payload set: SQLi fuzz list  (', '', ", `, ;, ' OR '1'='1, <script>...)
Payload processing: URL-encode all characters
Grep - Match: "SQL syntax", "ORA-", "ODBC"

Payload types trong Intruder:

Lưu ý bảo mật & vận hành: Intruder Community Edition bị throttle (làm chậm). Brute force tạo lưu lượng lớn — có thể bị account lockout, WAF chặn, hoặc DoS vô tình. Luôn trong scope. Dùng "Resource pool" để giới hạn concurrent request, đặt delay tránh khóa tài khoản.

12.3.7. Decoder

Chuyển đổi và giải mã dữ liệu. Hỗ trợ: URL, HTML entity, Base64, ASCII hex, Octal, Binary, Gzip, và Hash (MD5, SHA...). Chế độ "Smart decode" tự đoán encoding.

Ví dụ giải JWT (3 phần header.payload.signature ngăn bởi dấu .):

Input:  eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWRtaW4ifQ.<sig>
Decode as Base64 (phần 1): {"alg":"HS256"}
Decode as Base64 (phần 2): {"user":"admin"}

JWT dùng Base64URL (thay +→-, /→_, bỏ padding =). Burp Base64 decoder xử lý được; lưu ý thêm padding = nếu cần.

12.3.8. Comparer

So sánh hai mẩu dữ liệu theo word hoặc byte, tô màu khác biệt. Dùng để: so sánh response của tài khoản admin vs user thường (tìm chênh lệch trong access control), so sánh response TRUE vs FALSE trong blind SQLi, so sánh hai token để phân tích cấu trúc.

12.3.9. Sequencer — phân tích entropy của token

Sequencer kiểm tra tính ngẫu nhiên (randomness) của session token / CSRF token / reset token. Token đoán được = lỗ hổng nghiêm trọng (session hijacking).

Cơ chế: thu thập một lượng lớn token (lý tưởng nhiều nghìn mẫu), rồi chạy các bài kiểm định thống kê chuẩn FIPS 140-2 và các test riêng của Burp:

Kết quả tính bằng bits of effective entropy ở mức significance (mặc định 1%). Token "tốt" cần entropy cao. Token sinh từ thời gian (timestamp) hoặc counter tăng dần → entropy thấp → đoán được.

Lưu ý: entropy cao không đảm bảo an toàn nếu thuật toán sinh (PRNG) không phải CSPRNG. Sequencer chỉ phát hiện pattern thống kê, không kiểm tra thuật toán nguồn.

12.3.10. Scanner (chỉ Professional)

Scanner của Burp gồm passive (phân tích lưu lượng đã thấy, không gửi thêm request — phát hiện cookie thiếu Secure/HttpOnly, thông tin nhạy cảm) và active (gửi payload thăm dò — phát hiện SQLi, XSS, SSRF...). Cấu hình qua "Scan configuration": chọn audit checks, crawl strategy, độ sâu.

Cảnh báo: Active scan gửi payload tấn công thật (có thể tạo dữ liệu rác, kích hoạt email, sửa state). KHÔNG active scan trên production nhạy cảm khi chưa được phép rõ ràng.

12.3.11. Workflow hoàn chỉnh test một lỗ hổng bằng Burp

Ví dụ: test và xác nhận một Reflected XSS từ đầu đến cuối.

Bước 1 (Recon/Mapping): Bật Proxy, duyệt ứng dụng bình thường.
        Site map tích lũy endpoint /search?q=...
Bước 2 (Phát hiện điểm vào): Trong Proxy History, thấy giá trị `q`
        được phản chiếu vào HTML response.
Bước 3 (Send to Repeater): Ctrl+R request /search?q=test
Bước 4 (Thăm dò): Gửi q=<b>test</b>.
        - Xem response: nếu trả về `<b>test</b>` chưa escape -> reflect HTML.
Bước 5 (Chứng minh thực thi JS):
        q=<script>alert(document.domain)</script>
        URL-encode: q=%3Cscript%3Ealert(document.domain)%3C%2Fscript%3E
        - Nếu response chứa <script>...</script> nguyên vẹn (không bị HTML-encode)
          -> payload sẽ thực thi trong browser.
Bước 6 (Xác minh ngữ cảnh): Dùng Comparer so sánh response benign vs payload
        để xác định chính xác điểm reflect và bộ lọc (filter) nào áp dụng.
Bước 7 (Bypass filter nếu có): nếu < bị lọc, thử biến thể:
        - sự kiện: q="><img src=x onerror=alert(1)>
        - thoát context attribute
Bước 8 (Bằng chứng): chụp request/response, build PoC URL hoàn chỉnh.
Bước 9 (Report): mô tả, CVSS, PoC, khuyến nghị (output encoding theo ngữ cảnh,
        CSP, đặt HttpOnly cookie).

Phòng thủ XSS: output encoding theo ngữ cảnh (HTML, attribute, JS, URL), Content-Security-Policy, framework auto-escaping (React, Angular), HttpOnly cookie để JS không đọc được session.

12.4. Acunetix — DAST tự động

12.4.1. DAST là gì và vị trí của Acunetix

DAST (Dynamic Application Security Testing) kiểm thử ứng dụng đang chạy từ bên ngoài (black-box), không cần mã nguồn — đối lập với SAST (Static, phân tích mã nguồn) và IAST (Interactive, có agent bên trong ứng dụng). Acunetix là một DAST scanner thương mại, tự động hóa cao: tự crawl, tự audit, tự sinh báo cáo.

Khác biệt cốt lõi Acunetix vs Burp:

Hai công cụ bổ sung nhau: Acunetix quét rộng tìm low-hanging fruit, Burp đào sâu xác minh và khai thác logic.

12.4.2. Cấu hình một scan

Acunetix gọi mục tiêu là Target. Quy trình tạo scan:

1. Add Target: nhập URL gốc (https://app.example.com)
   - Description, Business Criticality (mức quan trọng để ưu tiên)
2. Target Settings:
   - Scan Speed: Slow/Moderate/Fast/Sequential (đánh đổi tốc độ vs tải server)
   - Site Login:
       * Automatic (cung cấp username/password, Acunetix tự login)
       * Recorded login sequence (ghi lại chuỗi thao tác login phức tạp)
   - Authentication: HTTP Basic/NTLM/header tùy chỉnh
   - Custom headers / cookies (ví dụ Authorization: Bearer ...)
   - Excluded paths (ví dụ /logout, /admin/delete-all)
   - Allowed hosts (giới hạn scope sang subdomain)
3. Scan Profile (Scan Type):
   - Full Scan / High Risk / Cross-site Scripting / SQL Injection /
     Weak Passwords / Crawl Only
4. Schedule: chạy ngay hoặc lịch định kỳ (cron-like)
5. Launch Scan

Recorded login sequence quan trọng vì nhiều endpoint nằm sau authentication. Acunetix dùng AcuSensor (agent IAST tùy chọn cài trên server PHP/.NET/Java) để tăng độ chính xác và phát hiện sâu hơn (gray-box), giảm false positive.

12.4.3. Cơ chế Crawl + Audit

Acunetix chạy 2 giai đoạn:

Giai đoạn 1 — Crawl (DeepScan): dùng engine duyệt như trình duyệt thật, thực thi JavaScript (hỗ trợ SPA, AJAX), khám phá mọi link, form, API endpoint, và tham số. Kết quả: danh sách "locations" và "inputs".

Giai đoạn 2 — Audit: với mỗi input phát hiện được, Acunetix gửi payload thăm dò và phân tích response: - SQLi: chèn payload, quan sát lỗi DB, độ trễ (time-based: SLEEP(5)), hoặc khác biệt boolean. - XSS: chèn marker script, kiểm tra reflect chưa escape. - SSRF, XXE, LFI/RFI, command injection: payload tương ứng. - Misconfiguration: header bảo mật thiếu, directory listing, file backup.

Time-based blind SQLi minh họa payload:

'; IF(1=1) WAITFOR DELAY '0:0:5'--      (MSSQL)
' OR SLEEP(5)-- -                        (MySQL)
' || pg_sleep(5)--                       (PostgreSQL)

Acunetix đo thời gian response: nếu response chậm đúng ~5s khi inject SLEEP(5) nhưng nhanh khi SLEEP(0) → xác nhận injection (blind, time-based).

12.4.4. Đọc báo cáo Acunetix

Báo cáo phân loại theo severity: High / Medium / Low / Informational. Mỗi finding gồm:

Các mẫu báo cáo chuẩn: Developer, Executive Summary, Compliance (PCI DSS, ISO 27001, HIPAA, OWASP Top 10).

12.4.5. False positive và xác minh

DAST tự động dễ báo false positive (báo có nhưng thực ra không khai thác được) và false negative (bỏ sót). Quy trình xác minh: 1. Lấy request PoC từ báo cáo. 2. Tái hiện thủ công bằng Burp Repeater hoặc curl. 3. Quan sát có đúng dấu hiệu khai thác không (ví dụ độ trễ time-based có ổn định không, hay chỉ do mạng). 4. Đánh dấu false positive trong Acunetix để lần scan sau bỏ qua.

Ví dụ kiểm chứng time-based SQLi bằng curl:

# Đo thời gian response giữa SLEEP(0) và SLEEP(5)
time curl -s "https://app.example.com/item?id=1' OR SLEEP(0)-- -" >/dev/null
time curl -s "https://app.example.com/item?id=1' OR SLEEP(5)-- -" >/dev/null
# Nếu lần 2 chậm hơn ~5s một cách ổn định -> SQLi thật, không phải false positive

Lưu ý: một báo cáo "Informational" (vd phiên bản server lộ trong header) có thể là mảnh ghép cho recon — đừng bỏ qua hoàn toàn. Ngược lại, không phải mọi "High" đều khai thác được trong ngữ cảnh thực; cần xác minh.

12.5. Nmap — phân tích tới mức gói tin

Nmap (Network Mapper) là công cụ host discovery, port scanning, version/OS detection, và chạy script (NSE). Hiểu Nmap đòi hỏi hiểu TCP 3-way handshake và cờ TCP, vì hầu hết scan thao tác trực tiếp các cờ này.

12.5.1. Nền tảng — TCP header và các cờ (flags)

TCP segment header (RFC 793/9293). Sơ đồ byte-by-byte:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data | Res |N|C|E|U|A|P|R|S|F|                               |
| Offset|     |S|W|C|R|C|S|S|Y|I|            Window             |
|       |     | |R|E|G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options (nếu Data Offset > 5)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Bảng trường TCP header:

Các cờ điều khiển (control flags) — mỗi cờ 1 bit:

TCP 3-way handshake (thiết lập kết nối):

Client                         Server
  | --- SYN (seq=x) ----------> |     state: SYN_SENT -> server SYN_RECV
  | <-- SYN,ACK (seq=y,ack=x+1) |
  | --- ACK (ack=y+1) --------> |     state: ESTABLISHED cả hai phía

Nmap khai thác hành vi này: server mở port trả SYN/ACK, server đóng port trả RST.

12.5.2. -sS — SYN scan (half-open / stealth)

Cơ chế: Nmap gửi SYN, KHÔNG hoàn tất handshake.

Port MỞ:
  Nmap --- SYN ------------> Target
  Nmap <-- SYN/ACK -------- Target
  Nmap --- RST -----------> Target   (Nmap chủ động cắt, không gửi ACK)
  => kết luận: open

Port ĐÓNG:
  Nmap --- SYN ------------> Target
  Nmap <-- RST ------------ Target
  => kết luận: closed

Port LỌC (firewall drop):
  Nmap --- SYN ------------> Target
  (không hồi đáp, gửi lại vài lần vẫn im)
  => kết luận: filtered

Vì sao "stealth": vì không hoàn tất handshake (không tới ESTABLISHED), nhiều ứng dụng/log cũ không ghi lại kết nối (chúng chỉ log sau khi accept()). Tuy nhiên IDS/IPS hiện đại phát hiện dễ dàng. SYN scan cần quyền raw socket (root/CAP_NET_RAW) vì Nmap tự tạo gói TCP, không qua connect() của OS.

sudo nmap -sS -p 1-1000 192.168.1.10

Output mẫu:

PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   open     http
443/tcp  open     https
3306/tcp filtered mysql

12.5.3. -sT — TCP Connect scan

Cơ chế: Nmap gọi syscall connect() của OS, hoàn tất đủ 3-way handshake, rồi đóng (gửi FIN hoặc RST).

Nmap --- SYN -------> Target
Nmap <-- SYN/ACK ---- Target
Nmap --- ACK -------> Target    (ESTABLISHED đầy đủ)
Nmap --- RST/FIN ---> Target    (đóng)

Khi nào dùng: khi không có quyền root (không raw socket). Đánh đổi: tạo kết nối đầy đủ → ứng dụng log lại → ít stealth hơn, chậm hơn.

nmap -sT -p 22,80,443 192.168.1.10   # không cần sudo

12.5.4. -sU — UDP scan

UDP không có handshake (connectionless). Cơ chế suy luận:

Port ĐÓNG:
  Nmap --- UDP packet ----> Target
  Nmap <-- ICMP Port Unreachable (type 3, code 3) -- Target
  => closed

Port MỞ:
  Nmap --- UDP packet ----> Target
  - Nếu dịch vụ UDP trả về dữ liệu => open
  - Nếu KHÔNG hồi đáp gì => open|filtered (mơ hồ)

Port LỌC:
  Nmap --- UDP ----> Target
  Nmap <-- ICMP type 3 code 1,2,9,10,13 (admin prohibited...) => filtered

Vì sao UDP scan chậm: vì không có RST khẳng định "closed", Nmap dựa vào ICMP Port Unreachable; nhưng RFC 1812 giới hạn tốc độ phát ICMP (rate limiting), nên Nmap phải đợi và gửi lại → rất chậm. Để chính xác hơn cho port phổ biến, Nmap gửi payload đặc thù dịch vụ (DNS query tới 53, SNMP tới 161).

sudo nmap -sU --top-ports 20 192.168.1.10   # quét 20 cổng UDP phổ biến

12.5.5. -sN / -sF / -sX — Null, FIN, Xmas scan

Ba scan này lợi dụng quy định RFC 793: nếu một gói TCP đến port đóng mà KHÔNG có cờ SYN/RST/ACK → server phải trả RST; nếu port mở → server bỏ qua (không hồi đáp).

Port MỞ hoặc LỌC:
  Nmap --- (FIN/Null/Xmas) ---> Target
  (không hồi đáp)  => open|filtered

Port ĐÓNG:
  Nmap --- (FIN/Null/Xmas) ---> Target
  Nmap <-- RST ---------------- Target  => closed

Vì sao dùng: có thể vượt qua firewall stateless chỉ lọc gói SYN. Hạn chế quan trọng: Windows (và nhiều thiết bị) KHÔNG tuân thủ RFC chuẩn này — luôn trả RST bất kể port mở/đóng → mọi port hiện "closed" → scan vô dụng trên Windows. Chỉ hiệu quả với hệ tuân thủ RFC (nhiều Unix-like).

sudo nmap -sX -p 1-100 192.168.1.10

12.5.6. -sn — Host Discovery (ping scan, không quét port)

-sn (trước đây -sP) chỉ xác định host nào "sống" mà không scan port. Cơ chế mặc định (khi chạy với quyền root) gửi tổ hợp thăm dò:

Trên LAN, Nmap dùng ARP (lớp 2) vì host buộc phải trả ARP reply nếu tồn tại — bỏ qua firewall lớp 3.

sudo nmap -sn 192.168.1.0/24      # liệt kê host sống trong subnet /24

Output:

Nmap scan report for 192.168.1.1
Host is up (0.0012s latency).
MAC Address: AA:BB:CC:DD:EE:FF (Vendor)
Nmap scan report for 192.168.1.10
Host is up (0.0023s latency).
Nmap done: 256 IP addresses (2 hosts up) scanned in 2.34 seconds

-Pn (no ping) bỏ qua host discovery, coi mọi host là sống — dùng khi mục tiêu chặn ICMP.

12.5.7. -sV — Version detection

Sau khi xác định port mở, -sV xác định dịch vụ và phiên bản chạy trên đó. Cơ chế: 1. Kết nối tới port mở. 2. Nếu dịch vụ tự gửi banner (vd SSH, SMTP) → đọc và so khớp với nmap-service-probes. 3. Nếu im lặng → Nmap gửi một loạt probe (chuỗi byte đặc thù giao thức) và so khớp response với hàng nghìn signature regex trong nmap-service-probes.

--version-intensity 0-9 điều chỉnh số probe gửi (0 = ít/nhanh, 9 = đầy đủ).

sudo nmap -sV -p 22,80,443 192.168.1.10

Output:

PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 8.9p1 Ubuntu 3ubuntu0.4 (Ubuntu Linux; protocol 2.0)
80/tcp  open  http     nginx 1.18.0 (Ubuntu)
443/tcp open  ssl/http nginx 1.18.0

Version chính xác → tra cứu CVE tương ứng (nền tảng cho vulnerability scanning).

12.5.8. -O — OS detection

-O đoán hệ điều hành qua TCP/IP stack fingerprinting: gửi nhiều probe được thiết kế đặc biệt và phân tích các đặc trưng phản hồi mà mỗi OS thực thi khác nhau:

Nmap so khớp fingerprint với nmap-os-db. Cần ≥1 port mở VÀ ≥1 port đóng để chính xác.

sudo nmap -O 192.168.1.10

Output:

Running: Linux 5.X
OS CPE: cpe:/o:linux:linux_kernel:5
OS details: Linux 5.0 - 5.14
Network Distance: 2 hops

12.5.9. -p — chỉ định port và -F

12.5.10. -T — Timing templates

-T0 đến -T5 điều chỉnh tốc độ qua nhiều tham số (delay giữa probe, parallelism, timeout):

-T4 là lựa chọn phổ biến trên mạng tốt. Có thể tinh chỉnh chi tiết: --min-rate, --max-rate (packet/s), --max-retries, --host-timeout.

12.5.11. NSE — Nmap Scripting Engine

NSE chạy script Lua để mở rộng Nmap: phát hiện lỗ hổng, brute force, thu thập thông tin. Script ở /usr/share/nmap/scripts/, phân theo category:

# Chạy script mặc định + version
sudo nmap -sC -sV 192.168.1.10

# Quét lỗ hổng đã biết
sudo nmap --script vuln -p 80,443 192.168.1.10

# Một script cụ thể
sudo nmap --script http-title,http-headers -p 80 192.168.1.10
sudo nmap --script smb-vuln-ms17-010 -p 445 192.168.1.10   # phát hiện EternalBlue
sudo nmap --script ssl-enum-ciphers -p 443 192.168.1.10    # liệt kê cipher TLS

Output mẫu --script vuln:

PORT   STATE SERVICE
80/tcp open  http
| http-slowloris-check:
|   VULNERABLE:
|   Slowloris DoS attack
|     State: LIKELY VULNERABLE
|     IDs:  CVE:CVE-2007-6750

Truyền tham số script (--script-args):

sudo nmap --script http-brute --script-args \
  http-brute.path=/login,userdb=users.txt,passdb=pass.txt -p 80 target

12.5.12. Tổng hợp lệnh quét toàn diện và output

sudo nmap -sS -sV -O -p- -T4 --script default,vuln -oA fullscan 192.168.1.10
# -sS  : SYN scan
# -sV  : version detection
# -O   : OS detection
# -p-  : toàn bộ 65535 port
# -T4  : timing aggressive
# --script default,vuln : NSE
# -oA fullscan : xuất 3 định dạng (.nmap, .gnmap, .xml) tên fullscan

Các định dạng output:

Phân tích nhanh greppable:

grep "open" fullscan.gnmap | awk '{print $2}'   # liệt kê IP có port mở

12.5.13. Đọc trạng thái port

Nmap phân biệt 6 trạng thái:

12.6. Lưu ý pháp lý và phạm vi (Scope & Legal)

Đây là phần KHÔNG được xem nhẹ — kiểm thử ngoài phạm vi cho phép là hành vi truy cập trái phép hệ thống máy tính, có thể bị xử lý hình sự.

12.6.1. Cơ sở pháp lý

• Việt Nam: Bộ luật Hình sự 2015 (sửa đổi, bổ sung 2017), Điều 289 (truy cập trái phép mạng máy tính, mạng viễn thông), Điều 287 (cản trở/gây rối loạn hoạt động mạng); Luật An ninh mạng 2018; Luật An toàn thông tin mạng 2015. (Người đọc nên kiểm chứng số điều luật cập nhật tại thời điểm áp dụng — quy định có thể được sửa đổi.)
• Quốc tế tham khảo: Computer Fraud and Abuse Act (CFAA — Hoa Kỳ), Computer Misuse Act (Anh).

Quét port hay gửi payload tới hệ thống KHÔNG có sự cho phép = vi phạm, bất kể có gây hại thật hay không.

12.6.2. Văn bản bắt buộc trước khi test

12.6.3. Nguyên tắc vận hành an toàn

• KHÔNG quét/khai thác ngoài danh sách IP/domain trong scope. Trong Burp: bật "Drop all out-of-scope traffic".
• Tránh kỹ thuật phá hủy (--script dos, brute gây lockout) trừ khi được cho phép rõ ràng và có cửa sổ bảo trì.
• Cẩn trọng với cloud assets: AWS/GCP/Azure yêu cầu tuân thủ chính sách pen-test riêng; một số dịch vụ quản lý (managed) bị cấm test.
• Lưu log mọi hành động (timestamp) làm bằng chứng phạm vi và phục vụ điều tra nếu có sự cố.
• Dữ liệu nhạy cảm trích xuất trong quá trình test phải được lưu trữ mã hóa và xóa an toàn sau khi kết thúc theo NDA.

12.7. Tổng kết chương

Chương này đã đi từ phân biệt khái niệm (scanning vs pentest), qua quy trình OWASP 5 pha, tới ba công cụ trụ cột với chi tiết tới mức gói tin/trường/bước và ví dụ chạy được:

• Burp Suite — kiểm soát thủ công sâu: kiến trúc MITM với CA cert, Proxy, Target/Scope, Repeater (IDOR, SQLi), Intruder (4 attack type), Decoder, Comparer, Sequencer, Scanner; workflow XSS đầu-cuối.
• Acunetix — DAST tự động: crawl + audit, cấu hình scan, đọc báo cáo, xác minh false positive; bổ sung chứ không thay thế Burp.
• Nmap — bản đồ mạng tới mức cờ TCP: -sS/-sT/-sU/-sN/-sF/-sX, -sn host discovery, -sV/-O fingerprinting, -p/-T tuning, NSE (--script vuln), đọc trạng thái và xuất kết quả.

Nguyên tắc xuyên suốt: hiểu cơ chế tới gốc, luôn xác minh thủ công kết quả tự động, và tuyệt đối tôn trọng phạm vi pháp lý.

Ghi chú của mình

Khu vực ghi chú cá nhân: những điểm từng hiểu sai, phần còn đang tìm hiểu, hoặc kinh nghiệm rút ra khi thực hành — cập nhật dần.