Giao tiếp văn bản thô

Danh mục OWASP: MASVS-NETWORK: Giao tiếp qua mạng

Tổng quan

Việc cho phép giao tiếp mạng dạng văn bản thô trong ứng dụng Android có nghĩa là bất kỳ ai giám sát lưu lượng truy cập mạng đều có thể xem và chỉnh sửa dữ liệu đang được truyền. Đây là lỗ hổng bảo mật nếu dữ liệu được truyền bao gồm thông tin nhạy cảm như mật khẩu, số thẻ tín dụng hoặc thông tin cá nhân khác.

Bất kể bạn có gửi thông tin nhạy cảm hay không, việc sử dụng văn bản thô vẫn có thể là một lỗ hổng bảo mật vì lưu lượng truy cập văn bản thô cũng có thể bị thao túng thông qua các cuộc tấn công mạng như ARP hoặc nhiễm độc DNS, do đó có thể cho phép kẻ tấn công ảnh hưởng đến hành vi của ứng dụng.

Tác động

Khi một ứng dụng Android gửi hoặc nhận dữ liệu ở dạng văn bản thô qua một mạng, bất kỳ ai đang giám sát mạng đều có thể chặn và đọc dữ liệu đó. Nếu dữ liệu này bao gồm thông tin nhạy cảm như mật khẩu, số thẻ tín dụng hoặc tin nhắn cá nhân, thì điều này có thể dẫn đến hành vi đánh cắp danh tính, gian lận tài chính và các vấn đề nghiêm trọng khác.

Ví dụ: một ứng dụng truyền mật khẩu ở dạng văn bản thô có thể tiết lộ thông tin đăng nhập này cho một đối tượng xấu muốn chặn lưu lượng truy cập. Sau đó, dữ liệu này có thể được dùng để truy cập trái phép vào tài khoản của người dùng.

Rủi ro: Kênh liên lạc không được mã hoá

Việc truyền dữ liệu qua các kênh giao tiếp không mã hoá sẽ làm lộ dữ liệu được chia sẻ giữa thiết bị và các điểm cuối của ứng dụng. Dữ liệu nói trên có thể bị kẻ tấn công chặn và có khả năng sửa đổi.

Giải pháp giảm thiểu

Dữ liệu phải được gửi qua các kênh giao tiếp được mã hoá. Bạn nên sử dụng giao thức bảo mật thay thế cho các giao thức không có tính năng mã hoá.

Rủi ro cụ thể

Phần này tổng hợp các rủi ro đòi hỏi chiến lược giảm thiểu không theo chuẩn hoặc được giảm thiểu ở một số cấp độ SDK nhất định và được liệt kê ở đây chỉ để cho đủ.

Rủi ro: HTTP

Hướng dẫn trong phần này chỉ áp dụng cho những ứng dụng nhắm đến Android 8.1 (API cấp 27) trở xuống. Kể từ Android 9 (API cấp 28), các ứng dụng HTTP như URLConnection, Cronet và OkHttp sẽ thực thi việc sử dụng HTTPS, do đó, tính năng hỗ trợ văn bản thô sẽ bị tắt theo mặc định. Tuy nhiên, hãy lưu ý rằng các thư viện Ứng dụng HTTP khác như Ktor có thể ít có khả năng thực thi các hạn chế này đối với văn bản thô, do đó bạn nên sử dụng một cách cẩn thận.

Giải pháp giảm thiểu

Sử dụng tính năng NetworkSecurityConfig.xml để chọn không dùng lưu lượng truy cập qua văn bản thô và thực thi HTTPS cho ứng dụng của bạn, ngoại trừ một số miền cụ thể bắt buộc (thường là cho mục đích gỡ lỗi):

XML

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">debug.domain.com</domain>
    </domain-config>
</network-security-config>

Lựa chọn này giúp ngăn chặn tình trạng hồi quy ngẫu nhiên trong ứng dụng do các thay đổi về URL do các nguồn bên ngoài cung cấp, chẳng hạn như máy chủ phụ trợ.

Rủi ro: FTP

Việc sử dụng giao thức FTP để trao đổi tệp giữa các thiết bị có một số rủi ro, đáng kể nhất là việc thiếu phương thức mã hoá trên kênh giao tiếp. Bạn nên sử dụng các phương án thay thế an toàn hơn như SFTP hoặc HTTPS.

Giải pháp giảm thiểu

Khi triển khai cơ chế trao đổi dữ liệu qua Internet trong ứng dụng, bạn nên sử dụng một giao thức bảo mật như HTTPS. Android cung cấp một bộ API cho phép nhà phát triển tạo logic máy khách-máy chủ. Bạn có thể bảo mật thông tin này bằng cách sử dụng giao thức Bảo mật tầng truyền tải (TLS), đảm bảo rằng quá trình trao đổi dữ liệu giữa hai điểm cuối được mã hoá, do đó ngăn người dùng độc hại nghe trộm thông tin liên lạc và truy xuất dữ liệu nhạy cảm.

Thông thường, cấu trúc máy khách-máy chủ dựa vào các API do nhà phát triển sở hữu. Nếu ứng dụng của bạn phụ thuộc vào một tập hợp các điểm cuối API, hãy đảm bảo bảo mật chuyên sâu bằng cách làm theo các phương pháp bảo mật hay nhất sau đây để bảo vệ hoạt động giao tiếp qua HTTPS:

  • Xác thực – Người dùng phải xác thực chính mình bằng các cơ chế bảo mật như OAuth 2.0. Bạn không nên sử dụng phương thức xác thực cơ bản vì phương thức này không cung cấp cơ chế quản lý phiên và nếu thông tin xác thực được lưu trữ không đúng cách, thì có thể được giải mã từ Base64.
  • Uỷ quyền – Người dùng chỉ được phép truy cập vào các tài nguyên dự kiến theo nguyên tắc đặc quyền tối thiểu. Bạn có thể triển khai việc này bằng cách áp dụng các giải pháp kiểm soát quyền truy cập thận trọng cho các tài sản của ứng dụng.
  • Đảm bảo sử dụng các bộ mật mã mới nhất và phù hợp, tuân theo các phương pháp hay nhất về bảo mật. Ví dụ: hãy cân nhắc hỗ trợ giao thức TLSv1.3 có khả năng tương thích ngược (nếu cần) cho hoạt động giao tiếp qua HTTPS.

Rủi ro: Giao thức giao tiếp tuỳ chỉnh

Việc triển khai giao thức giao tiếp tuỳ chỉnh hoặc cố gắng triển khai các giao thức giao tiếp phổ biến theo cách thủ công có thể gây nguy hiểm.

Mặc dù các giao thức tuỳ chỉnh cho phép nhà phát triển điều chỉnh một giải pháp duy nhất phù hợp với nhu cầu dự kiến, nhưng mọi lỗi trong quá trình phát triển đều có thể dẫn đến lỗ hổng bảo mật. Ví dụ: lỗi trong quá trình phát triển cơ chế xử lý phiên có thể khiến kẻ tấn công có thể nghe trộm thông tin liên lạc và truy xuất thông tin nhạy cảm một cách nhanh chóng.

Mặt khác, việc triển khai các giao thức nổi tiếng như HTTPS mà không sử dụng hệ điều hành hoặc thư viện bên thứ ba được duy trì tốt sẽ làm tăng khả năng xảy ra lỗi lập trình, khiến bạn khó cập nhật giao thức đã triển khai khi cần thiết (nếu không muốn nói là không thể). Ngoài ra, việc này có thể gây ra các lỗ hổng bảo mật tương tự như khi sử dụng giao thức tuỳ chỉnh.

Giải pháp giảm thiểu

Sử dụng các thư viện được duy trì để triển khai các giao thức giao tiếp phổ biến

Để triển khai các giao thức phổ biến như HTTPS trong ứng dụng, bạn nên sử dụng thư viện hệ điều hành hoặc thư viện bên thứ ba được duy trì.

Điều này mang đến cho nhà phát triển khả năng bảo mật khi chọn các giải pháp đã được kiểm thử kỹ lưỡng, cải tiến theo thời gian và liên tục nhận được các bản cập nhật bảo mật để khắc phục các lỗ hổng bảo mật phổ biến.

Ngoài ra, bằng cách chọn các giao thức nổi tiếng, nhà phát triển sẽ được hưởng lợi từ khả năng tương thích rộng trên nhiều hệ thống, nền tảng và IDE, giảm khả năng xảy ra lỗi do con người trong quá trình phát triển.

Sử dụng SFTP

Giao thức này mã hoá dữ liệu trong quá trình chuyển dữ liệu. Bạn nên cân nhắc các biện pháp bổ sung khi sử dụng loại giao thức trao đổi tệp này:

  • SFTP hỗ trợ nhiều loại xác thực. Thay vì xác thực dựa trên mật khẩu, bạn nên sử dụng phương thức xác thực bằng khoá công khai. Bạn nên tạo và lưu trữ các khoá đó một cách an toàn. Bạn nên sử dụng Kho khoá Android cho mục đích này.
  • Đảm bảo rằng các thuật toán mật mã được hỗ trợ tuân thủ các phương pháp hay nhất về bảo mật.

Tài nguyên