Với các tính năng của phương thức Đăng nhập bằng Facebook như mã truy cập và quyền, mọi người và ứng dụng có thể sử dụng một cách an toàn và bảo mật. Tuy nhiên, có một số bước bảo mật mà ứng dụng cần tự triển khai.
Danh sách dưới đây nên được xem là mức tối thiểu tuyệt đối mà tất cả các ứng dụng dùng phương thức Đăng nhập bằng Facebook phải triển khai. Các tính năng khác sẽ là duy nhất đối với ứng dụng của bạn và bạn phải luôn nghĩ cách khiến ứng dụng bảo mật nhất có thể. Ứng dụng không bảo mật sẽ làm mất lòng tin của đối tượng và mọi người sẽ ngừng sử dụng các ứng dụng đó.
Khóa bí mật của ứng dụng được dùng trong một số quy trình Đăng nhập nhằm tạo mã truy cập. Bản thân Khóa bí mật cũng được dùng để đảm bảo chỉ những người được tin cậy mới có thể dùng Ứng dụng của bạn. Khóa bí mật có thể được dùng để dễ dàng tạo Mã truy cập ứng dụng. Mã này có thể gửi yêu cầu API thay cho bất kỳ người dùng ứng dụng nào, cho nên đảm bảo Khóa bí mật của ứng dụng không bị xâm phạm là việc cực kỳ quan trọng.
Do đó, Khóa bí mật của ứng dụng hoặc Mã truy cập ứng dụng không được nằm trong mã nào.
Bạn chỉ nên dùng trực tiếp Mã truy cập ứng dụng từ máy chủ của ứng dụng để cung cấp phương thức bảo mật tốt nhất. Đối với ứng dụng gốc, bạn chỉ nên kết nối ứng dụng với máy chủ của chính mình, sau đó máy chủ gửi yêu cầu API đến Facebook bằng Mã truy cập ứng dụng. Vì lý do này, nếu "Loại ứng dụng" trong phần Cài đặt nâng cao của Bảng điều khiển ứng dụng được đặt thành Native/Desktop
, chúng tôi sẽ giả định rằng ứng dụng gốc của bạn chứa Khóa bí mật của ứng dụng hoặc Mã truy cập ứng dụng trong file nhị phân, đồng thời không cho phép các lệnh gọi được ký bằng Mã truy cập ứng dụng tiếp tục. API sẽ hoạt động như thể không được cung cấp mã truy cập.
appsecret_proof
Bạn có thể giảm khả năng bị spam và nhiễm phần mềm độc hại bằng cách yêu cầu lệnh gọi giữa các máy chủ đến API của Facebook phải được ký bằng thông số appsecret_proof
. Bằng chứng khóa bí mật của ứng dụng là một hash sha256 của mã truy cập, sử dụng khóa bí mật của ứng dụng làm khóa. Bạn có thể tìm thấy khóa bí mật của ứng dụng trong bảng điều khiển ứng dụng ở phần Cài đặt > Cơ bản.
Lệnh gọi trong PHP sẽ có dạng như mã mẫu dưới đây:
$appsecret_proof= hash_hmac('sha256', $access_token.'|'.time(), $app_secret);
Một số Hệ điều hành và ngôn ngữ lập trình sẽ trả về nhãn thời gian là float (số thực). Hãy nhớ chuyển đổi thành giá trị số nguyên trước khi tính toán bằng chứng khóa bí mật của ứng dụng. Một số ngôn ngữ lập trình tạo hàm băm ở dạng đối tượng thông báo. Hãy nhớ biểu thị hàm băm ở dạng đối tượng thập lục phân.
Bạn thêm kết quả dưới dạng thông số appsecret_proof
với appsecret_time
được đặt thành nhãn thời gian được dùng khi băm khóa bí mật của ứng dụng cho mỗi lệnh gọi mà bạn thực hiện:
curl \ -F 'access_token=ACCESS-TOKEN' \ -F 'appsecret_proof=APP-SECRET-PROOF' \ -F 'appsecret_time=APP-SECRET-TIME' \ -F 'batch=[{"method":"GET", "relative_url":"me"},{"method":"GET", "relative_url":"me/accounts"}]' \ https://graph.facebook.com
Bằng chứng khóa bí mật của ứng dụng có nhãn thời gian sẽ được xem là hết hạn sau 5 phút. Vì vậy, bạn nên tạo một bằng chứng mới trực tiếp khi thực hiện từng lệnh gọi API Đồ thị.
Để bật cài đặt Yêu cầu khóa bí mật của ứng dụng cho tất cả lệnh gọi API của bạn, hãy truy cập Bảng điều khiển ứng dụng trên Meta rồi nhấp vào Cài đặt ứng dụng > Nâng cao trong menu bên trái. Cuộn đến phần Bảo mật rồi nhấp vào nút chuyển Yêu cầu khóa bí mật của ứng dụng.
Nếu bạn bật cài đặt này, tất cả lệnh gọi do ứng dụng bắt đầu đều phải được ủy quyền qua môi trường phụ trợ cho phép thêm thông số appsecret_proof
vào yêu cầu trước khi gửi yêu cầu đến API Đồ thị. Nếu không, lệnh gọi sẽ không thành công.
Trong một số cấu hình, các ứng dụng sẽ tái sử dụng mã dài hạn trên nhiều ứng dụng. Bạn không nên làm điều này. Thay vào đó, hãy dùng mã ngắn hạn được tạo bằng quy trình lấy mã như mô tả trong tài liệu về mã truy cập của chúng tôi.
Để hiểu cách vấn đề này xảy ra, hãy tưởng tượng một ứng dụng gốc chạy trên iOS muốn thực hiện lệnh gọi API, nhưng thay vì gọi trực tiếp lại kết nối với máy chủ thuộc sở hữu của chính ứng dụng đó và chuyển cho máy chủ đó một mã được tạo bằng iOS SDK. Sau đó, máy chủ sẽ dùng mã này để thực hiện lệnh gọi API.
Điểm cuối mà máy chủ dùng để nhận mã có thể bị xâm phạm và người khác có thể chuyển mã truy cập cho ứng dụng hoàn toàn khác vào điểm cuối đó. Điều này rõ ràng là không an toàn, nhưng có một cách để tránh, đó là tuyệt đối không giả định rằng mã truy cập đến từ ứng dụng đang dùng mã đó. Thay vào đó, bạn nên kiểm tra bằng cách sử dụng điểm cuối gỡ lỗi.
Nếu bạn không dùng Facebook SDK, hãy thường xuyên kiểm tra xem mã truy cập có hợp lệ không. Mặc dù mã truy cập hết hạn theo lịch, nhưng các mã có thể bị hết hạn sớm vì các lý do bảo mật. Nếu không sử dụng Facebook SDK trong ứng dụng, bạn nên thường xuyên kiểm tra tính hợp lệ của mã theo cách thủ công – ít nhất là hàng ngày – để đảm bảo rằng ứng dụng của bạn không dựa vào một mã đã hết hạn sớm vì lý do bảo mật.
Nếu bạn đang sử dụng hộp thoại đăng nhập của Facebook trên trang web của mình, thông số state
sẽ là chuỗi duy nhất bảo vệ ứng dụng của bạn khỏi các cuộc tấn công Giả mạo yêu cầu trên nhiều trang web.
Chế độ nghiêm ngặt giữ an toàn cho các ứng dụng bằng cách ngăn chặn kẻ xấu tấn công quá trình chuyển hướng của bạn. Mọi ứng dụng đều phải bật Chế độ nghiêm ngặt.
Trước khi bật Chế độ nghiêm ngặt trong Bảng điều khiển ứng dụng, hãy đảm bảo lưu lượng truy cập chuyển hướng hiện tại của bạn vẫn hoạt động bằng cách thực hiện các hành động sau trong phần cài đặt phương thức Đăng nhập bằng Facebook:
Đối với các ứng dụng có URI chuyển hướng động, hãy dùng thông số state để chuyển thông tin động trở lại một số URI chuyển hướng giới hạn. Sau đó, thêm từng URI chuyển hướng giới hạn vào danh sách URI chuyển hướng OAuth hợp lệ.
Đối với các ứng dụng có một số URI chuyển hướng giới hạn, hãy thêm từng URI đó vào danh sách URI chuyển hướng OAuth hợp lệ.
Sau khi thực hiện những hành động này, bạn hãy nhớ bật chế độ nghiêm ngặt.
Chế độ nghiêm ngặt ngăn chặn việc tấn công URI chuyển hướng của bạn bằng cách yêu cầu khớp chính xác trong danh sách URI chuyển hướng OAuth hợp lệ. Ví dụ: nếu danh sách của bạn chứa www.example.com, Chế độ nghiêm ngặt sẽ không cho phép www.example.com/token là chuyển hướng hợp lệ. Chế độ này cũng sẽ không cho phép bất kỳ thông số truy vấn bổ sung nào không có trong danh sách URI chuyển hướng OAuth hợp lệ.
Sử dụng HTTPS - thay cho HTTP - làm giao thức Internet, vì giao thức này sử dụng phương thức mã hóa. HTTPS giữ sự riêng tư cho dữ liệu được truyền tải và bảo vệ khỏi các hành vi nghe trộm. Giao thức này cũng ngăn chặn việc giả mạo dữ liệu trong quá trình truyền tải bằng cách thêm quảng cáo hoặc mã độc hại chẳng hạn.
Kể từ ngày 06/10/2018, tất cả ứng dụng đều phải sử dụng HTTPS.
Khi cho biết rằng bạn sẽ dùng JavaScript SDK để đăng nhập bằng cách đặt nút chuyển Đăng nhập bằng JavaScript SDK thành "có", miền của trang lưu trữ SDK phải khớp với một trong các mục trong danh sách Miền được phép cho JavaScript SDK. Điều này đảm bảo rằng mã truy cập chỉ được trả về cho những lệnh gọi lại trong các miền được ủy quyền. Chỉ hỗ trợ các trang https cho những hành động xác thực với Facebook JavaScript SDK.
Đối với các tiện ích tích hợp JSSDK hiện có được tạo cho đến ngày 10/08/2021, danh sách này sẽ lấy các giá trị dự phòng dựa trên việc sử dụng hiện tại. Bạn không cần phải hành động gì thêm.
Đối với các tiện ích tích hợp mới được tạo sau ngày 10/08/2021, bạn phải thêm các giá trị vào danh sách này.
Nếu bạn thấy trường miền JSSDK của Ứng dụng chứa các url bắt đầu bằng *.
, vui lòng thay đổi sao cho trường đó được thay thế bằng các url miền tuyệt đối để tăng cường bảo mật.
Các cuộc tấn công chuyển hướng mở xảy ra khi kẻ xấu cung cấp thông số redirect_uri trái phép trong yêu cầu đăng nhập, dẫn đến khả năng thông tin nhạy cảm như mã truy cập bị rò rỉ qua chuỗi truy vấn hoặc phân đoạn trong URI chuyển hướng.
Đối với tiện ích tích hợp web tùy chỉnh, bạn nên cung cấp URI chuyển hướng được ủy quyền trong phần cài đặt ứng dụng để ngăn chặn các cuộc tấn công như vậy. Trong khi thực hiện yêu cầu đăng nhập, thông số redirect_uri sẽ được kiểm tra với các mục trong danh sách này. URI đầy đủ phải khớp chính xác, bao gồm tất cả các thông số, ngoại trừ thông số state không bắt buộc, giá trị của thông số này bị bỏ qua.
JavaScript SDK thường dựa vào cửa sổ bật lên và lệnh gọi lại để hoàn tất Đăng nhập. Đối với một số trình duyệt trong ứng dụng chặn cửa sổ bật lên, cách này có thể không thành công. Khi điều này xảy ra, SDK sẽ tự động cố gắng chuyển hướng đến trang đã gọi với mã truy cập. SDK chỉ có thể thực hiện chuyển hướng an toàn nếu URI đầy đủ của trang có trong danh sách URI chuyển hướng OAuth hợp lệ.
Nếu các tình huống trình duyệt trong ứng dụng quan trọng với ứng dụng web của bạn, bạn nên thêm miền của trang đăng nhập vào Miền được phép, đồng thời thêm URI đầy đủ của trang đăng nhập (bao gồm thông số đường dẫn và truy vấn) vào URI chuyển hướng OAuth hợp lệ. Nếu có nhiều biến thể trong các URI nơi diễn ra hoạt động Đăng nhập cho ứng dụng, bạn có thể tự mình chỉ định fallback_redirect_uri làm tùy chọn trong lệnh gọi FB.login(). Nhờ vậy, bạn chỉ cần thêm một mục đó vào danh sách URI chuyển hướng OAuth hợp lệ của mình.
Bật và/hoặc tắt mọi quy trình xác thực mà ứng dụng không dùng để giảm thiểu khu vực bề mặt tấn công.
Sử dụng mã truy cập ngắn hạn do mã tạo cho ứng dụng thay vì mã do ứng dụng tạo hoặc mã dài hạn do máy chủ cung cấp. Quy trình lấy mã truy cập ngắn hạn do mã tạo yêu cầu máy chủ ứng dụng đổi mã lấy mã truy cập. Điều đó an toàn hơn lấy mã truy cập trong trình duyệt. Các ứng dụng nên ưu tiên sử dụng quy trình này bất cứ khi nào có thể để an toàn hơn. Nếu một ứng dụng chỉ bật quy trình này, phần mềm độc hại chạy trên máy tính của người dùng sẽ không thể lấy mã truy cập để sử dụng sai mục đích. Hãy tìm hiểu thêm trong tài liệu về mã truy cập của chúng tôi.
Tắt phương thức Đăng nhập OAuth ứng dụng nếu ứng dụng của bạn không dùng. Đăng nhập OAuth ứng dụng là nút chuyển bật tắt chung để dùng quy trình lấy mã ứng dụng OAuth. Nếu ứng dụng của bạn không dùng bất kỳ quy trình OAuth ứng dụng nào, bao gồm SDK Đăng nhập bằng Facebook, bạn nên tắt quy trình này. Tuy nhiên, lưu ý rằng bạn không thể yêu cầu quyền cho mã truy cập nếu đã tắt phương thức Đăng nhập OAuth ứng dụng. Cài đặt này nằm trong phần Sản phẩm > Đăng nhập bằng Facebook > Cài đặt của Bảng điều khiển ứng dụng.
Tắt quy trình OAuth trên web hoặc chỉ định danh sách cho phép chuyển hướng. Với cài đặt phương thức Đăng nhập bằng OAuth trên web, bất kỳ quy trình lấy mã ứng dụng OAuth nào dùng hộp thoại đăng nhập trên web của Facebook đều có thể trả về mã cho trang web của riêng bạn. Cài đặt này nằm trong phần Sản phẩm > Đăng nhập bằng Facebook > Cài đặt của Bảng điều khiển ứng dụng. Hãy tắt cài đặt này nếu bạn không tạo quy trình đăng nhập tùy chỉnh trên web hoặc sử dụng SDK Đăng nhập bằng Facebook trên web.
Thực thi HTTPS. Cài đặt này yêu cầu HTTPS đối với Chuyển hướng OAuth, đồng thời yêu cầu lệnh gọi Facebook JavaScript SDK trả về hoặc yêu cầu mã truy cập chỉ từ các trang HTTPS. Tất cả các ứng dụng mới được tạo kể từ tháng 03/2018 đều có cài đặt này theo mặc định. Bạn nên có kế hoạch chuyển mọi ứng dụng hiện có sang chỉ dùng URL HTTPS chậm nhất vào ngày 06/10/2018. Hầu hết các máy chủ ứng dụng đám mây lớn đều cung cấp cấu hình của chứng chỉ TLS tự động và miễn phí cho ứng dụng của bạn. Nếu tự lưu trữ ứng dụng hoặc dịch vụ lưu trữ của bạn không cung cấp HTTPS theo mặc định, bạn có thể lấy chứng chỉ miễn phí cho (các) miền của mình từ Let's Encrypt.
Tắt quy trình OAuth trên trình duyệt đã nhúng nếu ứng dụng của bạn không dùng. Một số ứng dụng gốc trên máy tính và di động xác thực người dùng bằng cách thực hiện quy trình ứng dụng OAuth trong chế độ xem web được nhúng. Nếu ứng dụng của bạn không làm vậy, hãy tắt cài đặt này trong phần Sản phẩm > Đăng nhập bằng Facebook > Cài đặt trong Bảng điều khiển ứng dụng.
Tắt quy trình đăng nhập một lần trên di động nếu ứng dụng không dùng. Nếu ứng dụng của bạn không sử dụng phương thức Đăng nhập bằng iOS hoặc Android, hãy tắt cài đặt "Đăng nhập một lần" trong phần iOS và Android của Cài đặt > Cơ bản.
Với nhiều cài đặt bổ sung trong Bảng điều khiển ứng dụng, nhà phát triển có thể tắt các khu vực bị tấn công, nếu không có thể dẫn đến vấn đề bảo mật:
Native/Desktop
để bảo vệ ứng dụng khỏi bị giải mã và khóa bí mật của ứng dụng khỏi bị đánh cắp.