Giao thức HTTP dưới lăng kính an toàn và bảo mật phần mềm

TL;DR: Giao thức HTTP là ngôn ngữ giao tiếp của toàn bộ thế giới web, nhưng các lập trình viên thường phó mặc nó cho framework mà ít khi nhìn sâu vào từng dòng raw headers. Dưới lăng kính bảo mật, mỗi trường header từ Host, User-Agent, Authorization đến Content-Length đều là một bề mặt tấn công tiềm năng. Sự khác biệt về định dạng văn bản thô của HTTP/1.1 và luồng nhị phân ghép kênh của HTTP/2 tạo ra những đặc tính kiểm thử hoàn toàn khác biệt. Hiểu rõ cấu trúc request line, status code và cơ chế trao đổi header là nền móng bắt buộc trước khi bước vào bất kỳ bài phân tích lỗ hổng hay kiểm thử xâm nhập nào.

Một đội ngũ kỹ sư vận hành hệ thống thanh toán gặp sự cố kỳ lạ: các request gửi từ một số máy khách di động bất ngờ bị rò rỉ session token sang tài khoản của người dùng khác. Kiểm tra log ứng dụng ở tầng backend Node.js thì thấy mọi logic xử lý token đều nguyên vẹn. Chỉ đến khi bật chế độ bắt gói tin raw trên reverse proxy Nginx, họ mới phát hiện ra nguyên nhân: một client gửi header mang ký tự xuống dòng bất thường, khiến proxy hiểu thành hai request riêng biệt. Lỗi này bắt nguồn từ sự bất đồng bộ trong cách đọc ranh giới gói tin HTTP thuần văn bản.

1. Gói tin HTTP thô có cấu trúc thế nào?

Khi trình duyệt hoặc một công cụ như cURL gửi một HTTP request, toàn bộ dữ liệu đi qua socket TCP thực chất chỉ là một mảng byte văn bản ASCII (trong chuẩn HTTP/1.1). Một request hợp lệ được phân tách thành 4 phần rõ ràng:

1. Request Line: Chứa phương thức (Method), đường dẫn tài nguyên (Path) và phiên bản giao thức (HTTP Version).
2. Headers Block: Các cặp key-value ngăn cách bằng dấu hai chấm, mỗi header nằm trên một dòng riêng kết thúc bằng cặp ký tự \r\n.
3. Empty Line (Dòng trống): Chính xác một cặp \r\n đánh dấu kết thúc khối Headers.
4. Message Body (Tùy chọn): Dữ liệu gửi kèm theo độ dài được khai báo qua Content-Length hoặc chia mảnh qua Transfer-Encoding: chunked.

POST /api/v1/checkout HTTP/1.1\r\n
Host: shop.example.com\r\n
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)\r\n
Authorization: Bearer eyJhbGciOiJIUzI1Ni...\r\n
Content-Type: application/json\r\n
Content-Length: 27\r\n
\r\n
{"itemId":101,"quantity":2}

Dưới góc nhìn của một kỹ sư bảo mật, dòng trống \r\n\r\n là ranh giới sống còn. Bất kỳ ký tự xuống dòng nào bị chèn lén lút vào giữa các header đều có thể biến một trường dữ liệu vô hại thành phần thân request (HTTP Request Splitting).

Thử ngẫmNếu một reverse proxy và một backend server sử dụng hai thư viện parser khác nhau để đọc độ dài của Message Body, điều gì sẽ xảy ra khi một request chứa cả hai header Content-Length và Transfer-Encoding?

2. Vì sao HTTP headers trở thành bề mặt tấn công hàng đầu?

Nhiều lập trình viên lầm tưởng rằng các header gửi từ client có thể dùng để định danh hoặc xác thực vị trí an toàn. Trong thực tế, toàn bộ headers phía client gửi lên đều nằm dưới quyền kiểm soát 100% của kẻ tấn công:

• Host Header: Thường bị lợi dụng trong các đòn tấn công Host Header Injection nhằm đầu độc liên kết đặt lại mật khẩu gửi qua email hoặc đầu độc web cache khi proxy sử dụng giá trị này để sinh cache key.
• X-Forwarded-For: Thường bị các hệ thống ngây thơ dùng để lấy địa chỉ IP thật của người dùng. Kẻ tấn công có thể giả mạo header này để vượt qua cơ chế giới hạn tốc độ (rate limit) hoặc vượt qua whitelist IP nội bộ.
• User-Agent & Referer: Thường bị đưa trực tiếp vào log hoặc lưu vào database quản trị mà không qua làm sạch, dẫn tới các lỗi Stored XSS hoặc SQL Injection trong trang dashboard nội bộ.

Sau đây là một bài tập dự đoán phản xạ nhanh về cách bộ xử lý proxy phản ứng khi gặp trường header không chuẩn mực:

3. Ranh giới CRLF và nguy cơ phân tách thông điệp là gì?

Ký tự xuống dòng trong giao thức HTTP/1.1 được quy định bởi cặp byte CR (Carriage Return, mã ASCII 0x0D, ký hiệu \r) và LF (Line Feed, mã ASCII 0x0A, ký hiệu \n).

Khi ứng dụng web nhận input từ người dùng (ví dụ: tên file hoặc tham số chuyển hướng) rồi đưa thẳng vào response header:

String filename = request.getParameter("name");
response.setHeader("Content-Disposition", "attachment; filename=" + filename);

Nếu kẻ tấn công truyền vào tham số:
report.pdf\r\n\r\n<script>alert(document.cookie)</script>

Hệ thống sẽ bị bẻ gãy cú pháp:

1. report.pdf kết thúc giá trị của header Content-Disposition.
2. Cặp ký tự \r\n thứ hai tạo thành dòng trống (\r\n\r\n) đánh dấu kết thúc khối headers.
3. Đoạn mã <script>alert(...)</script> bị biến thành Message Body của response, biến lỗi tiêm header thành một cuộc tấn công Reflected XSS toàn diện.

location /api/ {
  proxy_pass http://backend_upstream;
  # Security bug: blindly trust client-supplied header
  proxy_set_header X-Real-IP $http_x_forwarded_for;
}

4. HTTP/1.1 dạng văn bản khác gì HTTP/2 dạng khung nhị phân?

Sự ra đời của HTTP/2 đã thay đổi căn bản cách thức dữ liệu được mã hóa trên đường truyền. Thay vì gửi văn bản thuần dễ đọc nhưng mơ hồ, HTTP/2 chuyển sang mô hình khung nhị phân (Binary Framing).

Nhờ có độ dài nhị phân định sẵn ở từng khung, HTTP/2 triệt tiêu hoàn toàn lớp lỗ hổng kinh điển do ký tự \r\n gây ra. Tuy nhiên, một hiểm họa mới xuất hiện: HTTP/2 Downgrading. Khi Reverse Proxy giao tiếp với trình duyệt bằng HTTP/2 nhưng lại hạ cấp xuống HTTP/1.1 để gọi các microservices phía sau, sự chuyển đổi ngữ nghĩa giữa khung nhị phân và văn bản thô trở thành mỏ vàng cho kỹ thuật tấn công HTTP Request Smuggling H2.CL và H2.TE.

5. Những security headers nào thiết lập hàng rào phòng thủ sớm?

Security Headers là các chỉ thị do máy chủ trả về trong response nhằm hướng dẫn trình duyệt kích hoạt các cơ chế tự bảo vệ. Dưới đây là 4 headers bắt buộc phải có trong mọi ứng dụng web sản xuất:

1. Strict-Transport-Security (HSTS):
   Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
   Ép trình duyệt luôn dùng HTTPS, triệt tiêu nguy cơ tấn công hạ cấp giao thức SSL Stripping khi người dùng gõ http://.
2. X-Content-Type-Options: nosniff:
   Cấm trình duyệt tự ý đoán định dạng file (MIME-type sniffing). Ngăn chặn việc một file ảnh .jpg chứa mã JavaScript bị trình duyệt thực thi như một script.
3. X-Frame-Options: DENY (hoặc CSP frame-ancestors 'none'):
   Cấm các trang web khác nhúng ứng dụng của bạn vào trong thẻ <iframe>, loại bỏ hoàn toàn nguy cơ tấn công Clickjacking.
4. Referrer-Policy: strict-origin-when-cross-origin:
   Bảo đảm token xác thực hoặc tham số nhạy cảm nằm trên thanh URL không bị rò rỉ sang domain thứ ba khi người dùng bấm vào đường link chuyển trang.

6. Tổng kết & Các nguyên tắc bảo mật cốt lõi

Hiểu thấu đáo giao thức HTTP là bước khởi đầu tách biệt giữa một người quét công cụ tự động và một kỹ sư an toàn thông tin chuyên nghiệp:

• Không bao giờ đặt niềm tin vào bất kỳ byte dữ liệu nào nằm trong request headers.
• Luôn sử dụng thư viện chuẩn để xử lý phân tách gói tin, không tự viết parser phân tích chuỗi HTTP.
• Cấu hình đầy đủ các security headers ngay từ tầng Web Gateway để bảo vệ người dùng trước khi mã ứng dụng chạy.

7. Tự kiểm tra (Self-check)

Hãy tự kiểm tra mức độ nắm bắt các nguyên lý giao thức của bạn qua các câu hỏi truy xuất chủ động dưới đây:

Bài tiếp theo: Thiết lập môi trường thực nghiệm với Burp Suite