Các vấn đề an ninh trong giao thức HTTP.

Tóm tắt
Bài viết này trình bày một số vấn đề về bảo mật trong giao thức HTTP, được nêu ra trong hai tài liệu RFC 7230 và RFC 7231. Các ví dụ trong bài viết về các lỗi cụ thể được tham khảo từ OWASP. Bài viết gồm 8 mục, sẽ được chia thành 2 phần.

1. Rủi ro từ các yếu tố trung gian
HTTP cho phép sử dụng các yếu tố trung gian để đáp ứng các request thông qua một chuỗi các kết nối. Có 3 yếu tố trung gian phổ biến, đó là proxy, gateway và tunnel.


Hình trên biểu diễn 3 yếu tố trung gian (A, B và C) giữa user agent và server. Một request hay response sẽ phải đi qua điểm A, B và C này. Chúng có thể truy cập vào các thông tin nhạy cảm được truyền đi, chẳng hạn thông tin cá nhân của người dùng hay tổ chức. Việc các yếu tố trung gian không được chú trọng đến vấn đề bảo mật và tính riêng tư có thể dẫn đến một loạt các cuộc tấn công tiềm năng.
Các nhà triển khai, xây dựng hệ thống nên xem xét các yếu tố riêng tư và bảo mật, trong quá trình thiết kế, code và triển khai hệ thống.
Người dùng cần ý thức được những mối nguy hiểm từ việc sử dụng các proxy hay gateway không tin cậy.

2. Response Splitting
Response splitting (a.k.a CRLF injection) là một kỹ thuật khai thác web phổ biến. Kẻ tấn công gửi đi dữ liệu được encode, nằm trong một vài tham số của request, dữ liệu này sau đó được decode và lặp lại trong một trường nào đó của response header. Nếu dữ liệu này là một ký hiệu thể hiện sự kết thúc của response, và một response tiếp theo được bắt đầu, response ban đầu sẽ bị chia tách thành hai và nội dung của response thứ hai sẽ bị điều khiển bởi kẻ tấn công. Kẻ tấn công sau đó có thể tạo một request khác trong cùng một kết nối liên tục, và lừa người nhận (bao gồm cả các yếu tố trung gian) tin rằng response thứ hai này là để trả lời cho request thứ hai.
Ví dụ, đoạn code sau lấy tên tác giả từ một một HTTP request và điền nó vào cookie header của HTTP response.


Giả sử một chuỗi “Jane Smith” được gửi lên trong request, HTTP response sẽ chứa cookie như sau:


Tuy nhiên, do giá trị của cookie phụ thuộc vào việc nội dung của request gửi lên như thế nào (cụ thể là giá trị của biến AUTHOR_PARAM), nên đây chính là điểm yếu của ứng dụng. Nếu kẻ tấn công gửi lên một chuỗi độc hại, chẳng hạn "Wiley Hacker
HTTP/1.1 200 OK
...", HTTP response sẽ bị chia thành 2 response như sau:



Rõ ràng, response thứ hai sẽ hoàn toàn bị kẻ tấn công điều khiển.

3. Request Smuggling
Request smuggling là kỹ thuật khai thác sự khác nhau trong việc xử lý các request của các loại server khác nhau để giấu đi những request được gắn thêm vào request ban đầu tưởng như vô hại.
Chúng ta cùng xem xét ví dụ sau đây:
Giả sử một POST request chứa hai trường “Content-length” trong header với hai giá trị khác nhau. Một số server sẽ từ chối request này (IIS và Apache), nhưng những server khác lại không. Chẳng hạn, SunONE W/S 6.1 sử dụng trường Content-length đầu tiên, trong khi sunONE Proxy 3.6 lại lấy trường Content-length thứ hai.
Giả sử SITE là DNS của một SunONE W/S, đặt phía sau một SunONE Proxy, có một file poison.html nằm trên SunONE W/S. Đây là cách khai thác HTTP Request Suggling dựa trên sự không nhất quán trong cách xử lý giữa hai server:


[Chú ý rằng mỗi dòng đều kết thúc với một CRLF (“
”), ngoại trừ dòng 10]
Hãy xem xét chuyện gì sẽ xảy ra khi request được gửi đến W/S thông qua Proxy server. Đầu tiên, proxy sẽ phân tích request từ dòng 1 đến dòng 7 (màu xanh) và gặp phải 2 trường Content-Length. Như đã nói ở trên, nó sẽ bỏ qua trường đầu tiên và hiểu là request body có độ dài 44 byte. Do đó, nó xử lý dữ liệu từ dòng 8 đến dòng 10 như request body đầu tiên (từ dòng 8 đến 10, dữ liệu có độ dài chính xác 44 byte). Proxy sau đó sẽ phân tích tích tiếp từ dòng 11 đến 14 (màu đỏ) như là request thứ hai của client. Bây giờ, hãy xem W/S diễn giải như thế nào với dữ liệu ở trên, khi nó được chuyển tiếp đến từ proxy. Không như proxy, W/S sẽ sử dụng trường Content-Length đầu tiên và hiểu như sau: request đầu tiên không có body, và request thứ hai bắt đầu từ dòng thứ 8 (lưu ý rằng W/S sẽ phân tích từ dòng 11 trở đi như là giá trị của trường Bla). Tóm lại, đây là cách dữ liệu được xử lý ở 2 server:


Tiếp theo, hãy xem response trả về client như thế nào. Request mà W/S hiểu là “POST /foobar.html” (từ dòng 1) và “GET /poison.html” (từ dòng 8), vì thế nó sẽ gửi về cho client 2 response với nội dung của trang foobar.html và poison.html. Còn proxy lại hiểu 2 response này ứng với 2 request là “POST /foobar.html” (từ dòng 1) và “GET /page_to_poison.html” (dòng 11). Proxy sẽ lưu cache nội dung của trang poison.html tương ứng với URL “page_to_poison.html” (cache poisoning). Từ đó, khi nào client request đến “page_to_poison.html” sẽ nhận được nội dung của trang poison.html.

4. Tấn công dựa vào đường dẫn file
Các web server thường xuyên sử dụng hệ thống file cục bộ của chúng để quản lý việc ánh xạ tên file trong URI đến tài nguyên thật trên server. Hầu hết các file hệ thống không được thiết kế để chống lại các đường dẫn file độc hại. Do đó, server cần tránh truy cập vào các file quan trọng của hệ thống.
Ví dụ, UNIX, Microsoft Windows, và một vài hệ điều hành khác sử dụng “..” như là một thành phần đường dẫn để biểu diễn thư mục cấp bên trên so với file/thư mục hiện tại. Nếu không kiểm soát đầu vào và phân quyền hợp lý, các file/thư mục nhạy cảm của hệ thống đều có thể bị truy cập bằng cách nhập vào các đường dẫn trỏ đến các file/thư mục này.

Trong bài tiếp theo, tôi sẽ trình bày nốt 4 (hoặc có thể hơn) vấn đề bảo mật nữa liên quan đến HTTP

Happy hacking