Nếu tôi chỉ sử dụng xác thực dựa trên tên người dùng / mật khẩu, họ sẽ không đủ an toàn?
Không, bởi vì bạn chỉ xác định WHO đang truy cập máy chủ API chứ không phải CÁI GÌ đang truy cập.
Sự khác biệt giữa WHO và WHAT là gì khi truy cập Máy chủ API
Để hiểu rõ hơn về sự khác biệt giữa WHO và WHAT đang truy cập máy chủ API, hãy sử dụng hình ảnh này:
Kênh liên lạc dự định đại diện cho ứng dụng di động đang được sử dụng như bạn mong đợi, bởi một người dùng hợp pháp mà không có bất kỳ ý định độc hại nào, sử dụng phiên bản không được sửa chữa của ứng dụng di động và liên lạc trực tiếp với máy chủ API mà không bị tấn công ở giữa.
Kênh thực tế có thể đại diện cho một số tình huống khác nhau, như một người dùng hợp pháp với mục đích xấu có thể đang sử dụng phiên bản đóng gói lại của ứng dụng di động, một hacker sử dụng phiên bản chính hãng của ứng dụng di động, trong khi người đàn ông ở giữa tấn công nó, để hiểu cách việc liên lạc giữa ứng dụng di động và máy chủ API đang được thực hiện để có thể tự động hóa các cuộc tấn công chống lại API của bạn. Nhiều kịch bản khác là có thể, nhưng chúng tôi sẽ không liệt kê từng cái ở đây.
Tôi hy vọng rằng bây giờ bạn có thể đã có manh mối tại sao WHO và CÁI GÌ không giống nhau, nhưng nếu không nó sẽ trở nên rõ ràng trong giây lát.
Các WHO là người dùng của ứng dụng di động mà chúng tôi có thể xác thực, ủy quyền và xác định bằng nhiều cách, như sử dụng OpenID Connect hoặc OAUTH2 chảy.
OAUTH
Nói chung, OAuth cung cấp cho khách hàng "quyền truy cập được ủy quyền an toàn" vào tài nguyên máy chủ thay mặt cho chủ sở hữu tài nguyên. Nó chỉ định một quy trình cho chủ sở hữu tài nguyên cho phép truy cập của bên thứ ba vào tài nguyên máy chủ của họ mà không chia sẻ thông tin đăng nhập của họ. Được thiết kế đặc biệt để hoạt động với Giao thức truyền siêu văn bản (HTTP), OAuth về cơ bản cho phép mã thông báo truy cập được cấp cho khách hàng bên thứ ba bởi một máy chủ ủy quyền, với sự chấp thuận của chủ sở hữu tài nguyên. Sau đó, bên thứ ba sử dụng mã thông báo truy cập để truy cập các tài nguyên được bảo vệ được lưu trữ bởi máy chủ tài nguyên.
Kết nối OpenID
OpenID Connect 1.0 là lớp nhận dạng đơn giản trên giao thức OAuth 2.0. Nó cho phép Khách hàng xác minh danh tính của Người dùng cuối dựa trên xác thực được thực hiện bởi Máy chủ ủy quyền, cũng như để có được thông tin hồ sơ cơ bản về Người dùng cuối theo cách tương tác và giống như REST.
Trong khi xác thực người dùng có thể để cho các máy chủ API biết WHO đang sử dụng API, nó không thể đảm bảo rằng các yêu cầu có nguồn gốc từ GÌ bạn mong đợi, phiên bản gốc của ứng dụng di động.
Bây giờ chúng ta cần một cách để xác định CÁI GÌ đang gọi máy chủ API và ở đây mọi thứ trở nên khó khăn hơn hầu hết các nhà phát triển có thể nghĩ. Các GÌ là điều đưa ra yêu cầu đến máy chủ API. Đây có thực sự là một phiên bản chính hãng của ứng dụng di động hay là bot, tập lệnh tự động hoặc kẻ tấn công tự chọc vào máy chủ API, sử dụng một công cụ như Postman?
Vì ngạc nhiên, bạn có thể sẽ phát hiện ra rằng Đó có thể là một trong những người dùng hợp pháp sử dụng phiên bản đóng gói lại của ứng dụng di động hoặc tập lệnh tự động đang cố gắng chơi game và tận dụng dịch vụ do ứng dụng cung cấp.
Chà, để xác định CÁI GÌ , các nhà phát triển có xu hướng sử dụng khóa API thường là mã cứng trong mã của ứng dụng di động của họ. Một số nhà phát triển đã đi xa hơn và tính toán khóa trong thời gian chạy trong ứng dụng di động, do đó, nó trở thành một bí mật thời gian chạy trái ngược với cách tiếp cận trước đây khi một bí mật tĩnh được nhúng trong mã.
Bài viết trên được trích từ một bài báo tôi đã viết, có tựa đề TẠI SAO ỨNG DỤNG DI ĐỘNG CỦA BẠN CẦN MỘT API API? và bạn có thể đọc đầy đủ ở đây , đó là bài viết đầu tiên trong một loạt các bài viết về các khóa API.
Lưu trữ dữ liệu nhạy cảm trong thiết bị khách
Và tôi không thể lưu tên người dùng / mật khẩu đó trong thiết bị vì lý do bảo mật? Tôi có nên phát hành GUID cho mọi người dùng khi đăng ký, lưu nó trong thiết bị của họ và truy xuất mỗi lần trong khi yêu cầu API không?
Bất cứ điều gì bạn lưu trong thiết bị, ngay cả khi được mã hóa, đều có thể được thiết kế ngược trong thời gian chạy với các công cụ như Frida hoặc Xposed.
Frida
Tiêm các tập lệnh của riêng bạn vào các quy trình hộp đen. Móc bất kỳ chức năng nào, theo dõi API crypto hoặc theo dõi mã ứng dụng riêng, không cần mã nguồn. Chỉnh sửa, nhấn lưu và xem ngay kết quả. Tất cả không có các bước biên dịch hoặc khởi động lại chương trình.
xPoses
Xposed là một khung cho các mô-đun có thể thay đổi hành vi của hệ thống và ứng dụng mà không cần chạm vào bất kỳ APK nào. Điều đó thật tuyệt bởi vì điều đó có nghĩa là các mô-đun có thể hoạt động cho các phiên bản khác nhau và thậm chí cả ROM mà không có bất kỳ thay đổi nào (miễn là mã gốc
Trong một thiết bị, kẻ tấn công điều khiển anh ta cũng có thể sử dụng proxy để thực hiện Man in the Middle Attack để trích xuất bất kỳ bí mật nào bạn có thể sử dụng để xác định WHAT hoặc WHO như tôi đã trình bày trong bài viết Đánh cắp khóa API đó với Man in the Attack :
Mặc dù chúng ta có thể sử dụng các kỹ thuật nâng cao, như JNI / NDK, để ẩn khóa API trong mã ứng dụng di động, nhưng nó sẽ không cản trở ai đó thực hiện một cuộc tấn công MitM để đánh cắp khóa API. Trên thực tế, một cuộc tấn công MitM rất dễ đến mức nó thậm chí có thể đạt được bởi những người không phải là nhà phát triển.
Vậy bây giờ thì sao ... Tôi có cam chịu đến mức tôi không thể bảo vệ máy chủ API của mình khỏi bị lạm dụng ??? Không yên tĩnh nên ... hy vọng vẫn tồn tại !!!
Phương pháp khả thi
Ai đó có thể cho tôi biết phương pháp nào mà các ứng dụng Android nổi tiếng như Facebook, FourSapes hoặc Twitter sử dụng để xác thực mọi yêu cầu đến từ ứng dụng di động của họ đến máy chủ của họ không?
Xin lỗi nhưng tôi không có đủ kiến thức về ứng dụng này để có thể làm sáng tỏ bạn, nhưng tôi có thể chỉ cho bạn một số cách tiếp cận khác.
Những mẫu nào khác có sẵn và hiệu quả và an toàn nhất, tôi chỉ cần một quy trình xử lý cho nó.
Vì vậy, bất cứ điều gì chạy về phía máy khách và cần một số bí mật để truy cập API đều có thể bị lạm dụng theo các cách khác nhau và bạn có thể tìm hiểu thêm về loạt bài viết này về Kỹ thuật bảo mật API di động. Bài viết này sẽ hướng dẫn bạn cách sử dụng Khóa API, Mã truy cập người dùng, Ghim HMAC và TLS để bảo vệ API và cách chúng có thể được bỏ qua.
Để giải quyết vấn đề WHAT đang truy cập ứng dụng di động của bạn, bạn cần sử dụng một hoặc tất cả các giải pháp được đề cập trong loạt bài viết về Kỹ thuật bảo mật API di động mà tôi đã đề cập ở trên và chấp nhận rằng họ chỉ có thể truy cập trái phép vào máy chủ API của bạn khó hơn bỏ qua nhưng không phải là không thể
Một giải pháp tốt hơn có thể được sử dụng bằng cách sử dụng giải pháp Chứng thực ứng dụng di động sẽ cho phép máy chủ API biết rằng chỉ nhận các yêu cầu từ một ứng dụng di động chính hãng.
Chứng thực ứng dụng di động
Việc sử dụng giải pháp Chứng thực ứng dụng dành cho thiết bị di động sẽ cho phép máy chủ API biết WHAT đang gửi yêu cầu, do đó chỉ cho phép trả lời các yêu cầu từ ứng dụng di động chính hãng trong khi từ chối tất cả các yêu cầu khác từ các nguồn không an toàn.
Vai trò của giải pháp Chứng thực ứng dụng dành cho thiết bị di động là đảm bảo trong thời gian chạy mà ứng dụng di động của bạn không bị giả mạo, không chạy trong thiết bị đã root, không bị khung công cụ như xPoses hoặc Frida, không bị MitM tấn công và điều này đạt được bằng cách chạy SDK trong nền. Dịch vụ chạy trên đám mây sẽ thách thức ứng dụng và dựa trên các phản hồi, nó sẽ chứng thực tính toàn vẹn của ứng dụng và thiết bị di động đang chạy, do đó SDK sẽ không bao giờ chịu trách nhiệm cho bất kỳ quyết định nào.
Khi chứng thực thành công tính toàn vẹn của ứng dụng di động, mã thông báo JWT tồn tại trong thời gian ngắn được phát hành và ký với một bí mật mà chỉ máy chủ API và dịch vụ Chứng thực ứng dụng di động trong đám mây mới biết. Trong trường hợp không thành công trên ứng dụng di động, mã thông báo JWT được ký với một bí mật mà máy chủ API không biết.
Bây giờ, Ứng dụng phải được gửi với mọi API gọi mã thông báo JWT trong các tiêu đề của yêu cầu. Điều này sẽ cho phép máy chủ API chỉ phục vụ các yêu cầu khi nó có thể xác minh chữ ký và thời gian hết hạn trong mã thông báo JWT và từ chối chúng khi không xác minh.
Khi ứng dụng di động không biết đến bí mật mà ứng dụng Di động không thể biết được, bạn không thể đảo ngược nó trong thời gian chạy ngay cả khi Ứng dụng bị giả mạo, chạy trong thiết bị đã root hoặc liên lạc qua kết nối đang là mục tiêu của một người đàn ông trong cuộc tấn công giữa.
Dịch vụ xác nhận ứng dụng di động đã tồn tại dưới dạng giải pháp SAAS tại Approov (tôi làm việc ở đây) cung cấp SDK cho một số nền tảng, bao gồm iOS, Android, React Native và các nền tảng khác. Việc tích hợp cũng sẽ cần một kiểm tra nhỏ trong mã máy chủ API để xác minh mã thông báo JWT do dịch vụ đám mây phát hành. Kiểm tra này là cần thiết để máy chủ API có thể quyết định những yêu cầu nào sẽ phục vụ và những yêu cầu nào cần từ chối.
Phần kết luận
Cuối cùng, giải pháp sử dụng để bảo vệ máy chủ API của bạn phải được chọn theo giá trị của những gì bạn đang cố gắng bảo vệ và các yêu cầu pháp lý cho loại dữ liệu đó, như quy định GDPR ở Châu Âu.
BẠN CÓ MUỐN ĐI EXTRA MILE?
Dự án bảo mật di động OWASP - 10 rủi ro hàng đầu
Dự án bảo mật di động OWASP là một tài nguyên tập trung nhằm cung cấp cho các nhà phát triển và nhóm bảo mật các tài nguyên họ cần để xây dựng và duy trì các ứng dụng di động an toàn. Thông qua dự án, mục tiêu của chúng tôi là phân loại rủi ro bảo mật di động và cung cấp các biện pháp kiểm soát phát triển để giảm tác động hoặc khả năng khai thác của chúng.
