HTTP vs HTTPS
Đây là các giao thức truy cập web hiện nay. Mặc dù từ lâu, http đã bộc lộ nhiều yếu điểm và dần dần bị thay thế bởi https, nhưng thực tế bây giờ chúng vẫn tồn tại song song với nhau.
HTTP là giao thức dạng plain text, mọi thứ truyền đi gửi về đều ở dạng văn bản rõ ràng. Điều này có nghĩa, chỉ cần kẻ tấn công ngồi ở giữa của kênh trao đổi, hắn có thể đọc được mọi thứ truyền đi gửi nhận lại rất dễ dàng.
HTTPS thì khác. Nó đã tích hợp cơ chế mã hóa thông tin, giúp mọi thứ đều được mã hóa. Bằng cách này, kẻ tấn công không thể giải mã ngược ra thông tin ban đầu được.
Demo: HTTP vs HTTPS
Ta có một trang web bán hàng online. Đầu tiên ta đăng nhập vào nó.
Sau khi đăng nhập thành công, ta xem thử những gì truyền đi trong request của ta lên server. Bạn có thể dùng Burp suite để tạo proxy nhằm bắt các gói tin để phân tích.
Như ta có thể thấy, mọi thông tin đăng nhập của người dùng đều được truyền đi ở dạng văn bản rõ, có thể đọc được dễ dàng.
HTTPS
HTTPS là sự kết hợp giữa HTTP và Transport Layer Protection. Điều này giúp áp dụng các cơ chế mã hóa dữ liệu, đảm bảo dù các gói tin truyền đi có bị bắt ngang thì vẫn không thể đọc được.
Nếu đã từng dùng Wireshark để làm điều này, bạn sẽ thấy rõ vấn đề.
Giao thức bảo mật được HTTPS tích hợp trong nó tiêu biểu là TLS/SSL.
Problems with Transport Layer Protection
Có ba vấn đề chính trong việc sử dụng Transport Layer Protection.
Insecure protocols
Nếu sử dụng SSL 3, bạn có thể bị dẫn đến tình trạng không an toàn trước các cuộc tấn công kiểu POODLE. Kiểu tấn công này giúp cho kẻ tấn công có thể dễ dàng qua mặt cơ chế của SSL 3, sau đó đọc được dữ liệu gốc mà SSL 3 có trách nhiệm mã hóa để gửi đi.
Insecure cipher suites.
Các gói bảo mật được cung cấp sẽ không hẳn an toàn trọn vẹn, nếu bên trong nó có dù chỉ một thành phần không an toàn.
Lấy ví dụ bộ mã hóa TLS_RSA_WITH_RC4_128_SHA. Thì trong đây, chính bộ mã hóa RC4 dẫn đến mất an toàn vì bản thân nó không phải là một cơ chế mã hóa an toàn nhất.
Vulnerabilities in crypto libraries
Tiêu biểu nhất là dẫn đến lỗi Heartbleed nổi tiếng. Nếu bị tấn công, kẻ xấu có thể đọc được bộ nhớ của web server. Bên cạnh đó, các script code có sẵn trên Internet còn có thể dùng để khai thác, từ đó tấn công dạng remote code execution vào hệ thống.
Để kiểm tra các lỗi trên, ta có thể dùng:
https://sslabs.com/ssltest/
Demo: Problems with Transport Layer Protection
Ta truy cập: https://sslabs.com/ssltest/
Sau khi vào được công cụ kiểm tra online này, ta nhập vào địa chỉ ứng dụng web cần kiểm tra.
Sau khi trang web phân tích xong, nó sẽ trả về kết quả cho ta thấy kèm theo các hình thức tấn công có thể xảy ra.
Nếu muốn tìm hiểu về lỗi đó, ta có thể nhấp vào MORE INFO.
Summary
Việc sử dụng HTTPS là cần thiết. Tuy nhiên, cần phải kiểm tra xem các chứng chỉ giao thức bảo mật của nó có còn hiệu lực và an toàn hay không.
Có thể bạn quan tâm:
Bài 1: Web App Hacking: Sensitive Data Exposure (Guideline)
Bài 2: Web App Hacking: Sensitive Data Exposure – Insecure Error Handling
Bài 3: Web App Hacking: Sensitive Data Exposure – Disclosure of Sensitive Files
Bài 4: Web App Hacking: Sensitive Data Exposure – Information Disclosure via Metadata
Bài 5: Web App Hacking: Sensitive Data Exposure – Underestimated Risk: Disclosure of Software Version
Bài 6: Web App Hacking: Sensitive Data Exposure – Insecure Communication Channel
Bài 7: Web App Hacking: Sensitive Data Exposure – Leakage of Cookie with Sensitive Data
Bài 8: Web App Hacking: Sensitive Data Exposure – Leakage of Sensitive Data via Referer Header
