[Tuts] Web App Hacking: Sensitive Data Exposure – Insecure Communication Channel

tingameblog

Active Member
Apr 26, 2013
1,216
0
36
30


Mục lục bài viết

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ó.

Capture1-1.jpg


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.

Capture-1.jpg


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:


Demo: Problems with Transport Layer Protection


Ta truy cập: https://sslabs.com/ssltest/

Capture2.jpg


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.

Capture3-2.jpg


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.

Capture4-2.jpg


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

TTTI