5 câu hỏi bảo mật dành cho các lập trình viên ứng dụng di động

110

Ứng dụng di động của bạn được bảo mật như thế nào?

Hãy hỏi các nhà lập trình mobile doanh nghiệp và câu trả lời sẽ là bảo mật chính là ưu tiên hàng đầu. Nhưng các phòng ban IT nên đặt nhiều câu hỏi hơn thế và các dev phải trong tư thế sẵn sàng trả lời chúng.

App của bạn chỉ mã hóa dữ liệu thôi là chưa đủ.

Để các tổ chức đánh giá chính xác liệu ứng dụng đã đáp ứng được yêu cầu bảo mật hay chưa, bạn có thể trình bày về thời điểm, địa điểm, cách thức và thời gian sử dụng mã hóa. Ngoài ra, bạn cũng nên đề cập đến hình thức mã hóa và độ chắc chắn của nó.

Tuy nhiên, đây chỉ là sự khởi đầu. Khi các doanh nghiệp ngày càng quan tâm đến bảo mật di động, họ sẽ liệt kê 1 loạt các câu hỏi khó dành cho các lập trình viên của mình. Dưới đây là tổng hợp 5 câu hỏi có thể có trong danh sách đó:

Dữ liệu có thể được mã hóa ở bất kì đâu và bất kì thời điểm nào mà dữ liệu được lưu trữ?

Bảo mật hệ điều hành di động built-in chỉ đáng tin cậy trong các thiết bị không root, không bẻ khóa vì người dùng đã thiết lập 1 mã code.

no

Các lập trình viên nên sử dụng các thư viện như Common Crypto và javax.crypto để mã hóa chính các dữ liệu nhạy cảm – gồm các thông tin nhận dạng cá nhân, thông tin sức khỏe, mật khẩu, token, cookies, các tập tin.. Và điều này không chỉ áp dụng cho dữ liệu được viết trong filesystem. Đối với những người mới bắt đầu, xuất dữ liệu từ dữ liệu SQLite của thiết bị là không đáng kể, nên bất kì nội dung gì được viết trong filesystem cũng nên được mã hóa bằng công cụ tương tự như SQLCipher. Để việc mã hóa đạt hiệu quả, nó cần có tính lan tỏa và không có kẻ hở nào mà kẻ tấn công có thể lẻn vào.

Liệu app có sử dụng mã hóa HTTPS và bắt buộc sử dụng nó?

Chúng ta rất dễ trở nên tự mãn về các vấn đề liên quan đến bảo mật mạng lưới truyền thông.

Chuyển sang HTTPS là bước đi đúng đắn đầu tiên, nhưng không nên dừng lại ở đó. Các ứng dụng luôn phê chuẩn chứng nhận SSL, và để tăng thêm niềm tin, các lập trình viên hoặc là nhấn mạnh chứng nhận của server trong ứng dụng hoặc sử dụng xác thực SSL 2 chiều.

Ngược lại, các lập trình viên backend có trách nhiệm đảm bảo server chỉ hỗ trợ các protocols và ciphers (mã khối) mạnh và không thể hỗ trợ các protocols, ciphers kém bảo mật hơn.

Các ứng dụng nhị phân đã được loại bỏ các thông tin nhạy cảm chưa?

Các ứng dụng nhị phân không phải là các hộp đen. Chúng có thể được tích hợp lại, được thiết kế đảo ngược, được phân tích trong thời gian tĩnh lẫn thời gian khởi động và được mổ xẻ bằng phần mềm pháp lý di động. Các lập trình viên nên giả thuyết rằng bất kì thông tin nhạy cảm nào được code cứng, như mật khẩu và chìa khóa mã hóa có thể được hồi phục từ nhị phân và không cần những ứng dụng nhị phân nữa.

data security privacy encryptiondata security privacy encryptionCác chìa khóa được sản xuất tự động (như thông qua PBKDF2) nên được ưu tiên hơn các chìa khóa tĩnh, được code cứng và khi không còn sự lựa chọn nào khác, bạn có thể áp dụng công nghệ White Box Cryptography.

Bạn đã ngăn chặn kỹ thuật và phân tích đảo ngược?

Các ứng dụng sẽ khó bị nhận diện hơn nếu dev lấy hết hoặc đổi tên các biểu tượng, code và dữ liệu hoặc mã hóa các strings. Một ứng dụng sẽ cố gắng xác nhận các tài nguyên của ứng dụng đó, đảm bảo các tài nguyên chưa bị làm giả.

Tuy thường bị bỏ qua, nhưng các tính toán trên có thể khiến khả năng tấn công ứng dụng trên bề mặt gặp khó khăn, trong khi hầu như không ảnh hưởng gì đến hiệu suất hoạt động của app.

Liệu mobile backend có an toàn như chính ứng dụng hay không?

Một điểm khác cũng hay bị lãng quên là tính bảo mật của di động không chỉ dừng lại ở chính ứng dụng đó. Các backend API có thể dẫn đến những nguy cơ tấn công, vì vậy các dev nên kiểm tra kỹ mỗi backend API – các backend API này phải xác thực được sự có mặt, độ dài, phạm vi, loại và format của tất cả các inputs. Chúng phải giải quyết tốt các input sai chức năng, gồm các cặp chìa khóa/ giá trị phụ thêm. Và các dev phải đảm bảo rằng nếu không có lý do thuyết phục nào khác để backend API mở, thì chỉ có các ứng dụng của dev mới tiếp cận được với các backend APIs này.

shutterstock_426846721

Đáp ứng tất cả những điều này – thậm chí còn nhiều thứ khác nữa – có vẻ như là 1 nhiệm vụ bất khả thi.

Các ứng dụng di động hiện đại thường được xây dựng bởi các đội ngũ đa nguồn, không chỉ gồm các dev trong nội bộ doanh nghiệp và nhân viên kinh doanh mà còn có các bên thứ ba. Các doanh nghiệp cần phải thiết lập và thi hành các tiêu chuẩn bảo mật dành cho mỗi teams, lên kế hoạch review và cập nhật các tiêu chuẩn đó khi các mối đe dọa đến di động tăng cao.

Các vấn đề phức tạp hơn là các mobile apps HTML5 và các app hỗn hợp được lập trình với các frameworks dựa trên Apache Cordova, trong khi các frameworks nổi tiếng lại không thể chỉ cung cấp tất cả cơ chế bảo mật và riêng tư.

Các công cụ và giải pháp hiện đại hơn như Kony Mobility Platform có thể hỗ trợ các dev xây dựng tính bảo mật cao cho ứng dụng của mình. Nhưng các dev vẫn cần chú ý đến các vấn đề có thể xảy ra và nên đặt ra cho bản thân những câu hỏi đúng để đối đáp với các tổ chức, doanh nghiệp sử dụng apps.

Hãy nhớ rằng, dữ liệu là mạch sống của kinh doanh. Khi ngày càng có nhiều dữ liệu và khối lượng công việc của doanh nghiệp di chuyển từ trung tâm dữ liệu đến các thiết bị, thì chỉ có các ứng dụng đảm bảo sự an toàn mới được xem là các ứng dụng thành công.

Nguồn: ADG Vietnam via TheNextWeb