Daftar Periksa Keamanan

Daftar di bawah ini harus dianggap sebagai minimum absolut yang harus diterapkan oleh semua aplikasi yang menggunakan Facebook Login. Fitur lain akan unik bagi aplikasi Anda dan Anda harus selalu memikirkan cara membuat aplikasi Anda seaman mungkin. Aplikasi yang tidak aman akan kehilangan kepercayaan dari pemirsanya dan orang-orang akan berhenti menggunakannya.

Rahasia Aplikasi

Rahasia Aplikasi digunakan di beberapa alur Login untuk menghasilkan token akses dan Rahasia itu sendiri dimaksudkan untuk mengamankan penggunaan Aplikasi Anda hanya untuk mereka yang dipercaya. Rahasia tersebut bisa digunakan agar mudah membuat Token Akses Aplikasi yang dapat membuat permintaan API atas nama setiap pengguna aplikasi, yang membuatnya sangat penting bahwa Rahasia Aplikasi tidak bocor.

Oleh karena itu, Rahasia Aplikasi atau token Akses Aplikasi tidak boleh disertakan dalam kode apa pun.

Kami rekomendasikan agar Token Akses Aplikasi hanya boleh digunakan langsung dari server aplikasi Anda untuk memberikan keamanan terbaik. Untuk aplikasi native, kami sarankan agar aplikasi tersebut berkomunikasi dengan server Anda sendiri dan server kemudian membuat permintaan API ke Facebook menggunakan Token Akses Aplikasi. Untuk alasan ini, jika 'Jenis Aplikasi' Anda di bawah Pengaturan Lanjutan di Aplikasi Dasbor diatur ke Native/Desktop, kami berasumsi bahwa aplikasi native Anda berisi Rahasia Aplikasi atau Token Akses Aplikasi dalam biner, dan kami tidak mengizinkan panggilan yang ditandatangani dengan Token Akses Aplikasi untuk melanjutkan. API akan berperilaku seolah-olah tidak ada token akses yang diberikan.

Mengamankan Panggilan Sisi Server dengan appsecret_proof

Anda dapat mengurangi eksposur Anda terhadap malware dan spammer dengan mengharuskan panggilan server ke server ke API Facebook ditandatangani dengan parameter appsecret_proof. Bukti kunci rahasia aplikasi merupakan hash sha256 dari token akses Anda, yang menggunakan rahasia aplikasi Anda sebagai kunci. Rahasia aplikasi dapat ditemukan di dasbor aplikasi Anda di Pengaturan > Dasar.

Membuat Bukti

Contoh kode berikut adalah tampilan panggilan di PHP:

$appsecret_proof= hash_hmac('sha256', $access_token.'|'.time(), $app_secret); 

Beberapa Sistem Operasi dan bahasa pemrograman akan menampilkan cap waktu yang berupa float. Pastikan untuk mengubah ke nilai bilangan bulat sebelum menghitung bukti rahasia aplikasi. Beberapa bahasa pemrograman membuat hash sebagai objek digest. Pastikan untuk mengekspresikan hash sebagai objek heksadesimal.

Menambahkan Bukti

Anda menambahkan hasilnya sebagai parameter appsecret_proof dengan appsecret_time yang diatur ke cap waktu yang Anda gunakan saat hashing rahasia aplikasi untuk setiap panggilan yang Anda buat:

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

Bukti rahasia aplikasi bercap waktu akan dianggap kedaluwarsa setelah 5 menit, jadi direkomendasikan agar Anda membuat bukti baru secara in-line setiap melakukan panggilan Graph API.

Memerlukan Bukti

Untuk mengaktifkan Memerlukan Rahasia Aplikasi untuk semua panggilan API Anda, buka Dasbor Aplikasi Meta dan klik Pengaturan Aplikasi > Lanjutan di menu sisi kiri. Gulir ke bagian Keamanan, lalu klik tombol Memerlukan Rahasia Aplikasi.

Jika pengaturan ini diaktifkan, semua panggilan yang dimulai oleh klien harus diproksi melalui backend Anda tempat parameter appsecret_proof dapat ditambahkan ke permintaan sebelum mengirimkannya ke Graph API, atau panggilan akan gagal.

Amankan Panggilan Sisi Klien dengan Token Jangka Pendek dan Aliran Kode

Pada beberapa konfigurasi, aplikasi akan menggunakan kembali token berdurasi lama di beberapa klien. Jangan lakukan ini. Sebagai gantinya, gunakan token berdurasi singkat yang dihasilkan dengan alur kode, seperti yang dijelaskan di dokumentasi token akses kami.

Pembajakan Token

Untuk memahami bagaimana hal ini terjadi, bayangkan aplikasi iOS native yang ingin melakukan panggilan API, tetapi alih-alih melakukannya secara langsung, malah berkomunikasi dengan server milik aplikasi yang sama dan meneruskan token yang dibuat menggunakan iOS SDK ke server tersebut. Server kemudian akan menggunakan token tersebut untuk melakukan panggilan API.

Endpoint yang digunakan server untuk menerima token dapat disusupi dan yang lain dapat meneruskan token akses untuk aplikasi yang benar-benar berbeda. Ini jelas tidak aman, tetapi ada cara untuk melindunginya - token akses tidak boleh dianggap berasal dari aplikasi yang menggunakannya, melainkan harus diperiksa menggunakan endpoint debugging.

Periksa Validitas Token Akses Secara Rutin

Jika Anda tidak menggunakan Facebook SDK, periksa secara berkala apakah token akses valid. Token akses memiliki jadwal penghentian masa berlaku, tetapi token dapat dibuat berakhir lebih awal untuk alasan keamanan. Jika Anda tidak menggunakan Facebook SDK di aplikasi, Anda harus sering memeriksa validitas token secara manual — minimal tiap hari — untuk memastikan bahwa aplikasi tidak bergantung pada token yang telah berakhir masa berlakunya lebih awal untuk alasan keamanan.

Parameter Status

Jika Anda menggunakan dialog login Facebook di situs web Anda, parameter state adalah string unik yang melindungi aplikasi Anda dari serangan Pemalsuan Permintaan Lintas Situs.

Mengaktifkan Mode Ketat

Mode Ketat menjaga keamanan aplikasi dengan mencegah pelaku kejahatan membajak pengalihan Anda. Mengaktifkan Mode Ketat wajib bagi semua aplikasi.

Sebelum mengaktifkan Mode Ketat di Dasbor Aplikasi, pastikan lalu lintas pengalihan Anda saat ini masih berfungsi dengan melakukan tindakan berikut di pengaturan Facebook Login:

  • Untuk aplikasi dengan URI pengalihan dinamis, gunakan parameter satus untuk meneruskan kembali informasi dinamis ke URI pengalihan dalam jumlah terbatas. Kemudian tambahkan setiap URI pengalihan terbatas ini ke daftarURI pengalihan OAuth valid.

  • Untuk aplikasi dengan URI pengalihan dalam jumlah terbatas, tambahkan masing-masing ke daftar URI pengalihan OAuth valid list.

  • Untuk aplikasi yang hanya menggunakan Facebook SDK for Javascript, traffic pengalihan sudah dilindungi. Tidak diperlukan tindakan lebih lanjut.

Setelah mengambil tindakan ini, pastikan untuk mengaktifkan mode ketat.

Cara Kerja Mode Ketat

Mode yang ketat mencegah pembajakan URI pengalihan Anda dengan meminta pencocokan persis dari daftar URI pengalihan OAuth valid. Contoh: jika daftar Anda berisi www.example.com, maka Mode Ketat tidak akan mengizinkan www.example.com/token sebagai pengalihan valid. Mode Ketat juga tidak akan mengizinkan parameter kueri tambahan yang tidak ada di daftar URI pengalihan OAuth valid.

Gunakan HTTPS

Gunakan HTTPS, bukan HTTP, sebagai protokol internet, karena HTTPS menggunakan enkripsi. HTTPS menjaga kerahasiaan data yang dikirimkan dan melindungi dari serangan penyadapan. Ini juga mencegah data dirusak selama transmisi dengan, contoh: memasukkan iklan atau kode berbahaya.

Mulai 6 Oktober 2018, semua aplikasi harus menggunakan HTTPS.

Mengaktifkan JavaScript SDK untuk Facebook Login

Jika Anda menunjukkan bahwa Anda menggunakan JavaScript SDK untuk login dengan menetapkan tombol Login dengan JavaScript SDK sebagai "ya", domain halaman Anda yang meng-hosting SDK harus sesuai dengan salah satu entri dalam daftar Domain Diizinkan untuk JavaScript SDK. Hal ini untuk memastikan bahwa token akses hanya diberikan ke panggilan balik dalam domain yang diotorisasi. Hanya halaman https yang didukung untuk tindakan autentikasi dengan Facebook SDK for JavaScript.

Untuk integrasi JavaScript SDK yang ada, yang dibuat sampai 10 Agustus 2021, daftar ini sedang di-backfill dengan nilai berdasarkan penggunaan terakhir. Tidak diperlukan tindakan lebih lanjut.

Untuk integrasi baru yang dibuat setelah 10 Agustus 2021, Anda harus menambahkan nilai ke daftar ini.

Jika Anda melihat kolom domain JavaScript SDK Aplikasi Anda berisi URL yang diawali dengan *., ubah sedemikian rupa dengan URL domain yang absolut untuk keamanan ekstra.

Cara Kerja Pemeriksaan URI Pengalihan

Serangan pengalihan terbuka terjadi saat pelaku kejahatan memberikan parameter redirect_uri yang tidak sah dalam permintaan login, sehingga informasi sensitif seperti token akses bisa bocor lewat string kueri atau fragmen di URI pengalihan.

Untuk integrasi web khusus, Anda harus memberi URI pengalihan resmi dalam pengaturan aplikasi agar mencegah serangan serupa. Ketika memenuhi permintaan login, parameter redirect_uri akan diperiksa dengan entri dalam daftar ini. URI lengkap harus sama persis, berisi semua parameter, kecuali parameter status opsional yang nilainya diabaikan.

Browser dalam Aplikasi dan JavaScript SDK

JavaScript SDK biasanya bergantung pada pop-up dan panggilan balik untuk menyelesaikan suatu Login. Untuk beberapa browser dalam aplikasi yang menahan pop-up, penyelesaian bisa gagal. Jika ini terjadi, SDK akan otomatis mencoba mengalihkan dengan token akses ke halaman yang memanggilnya. SDK hanya melakukan pengalihan ini dengan aman jika URI lengkap halaman terdaftar dalam URI Pengalihan OAuth Valid.

Jika skenario browser dalam aplikasi untuk aplikasi web merupakan hal penting, Anda harus menambahkan domain halaman login ke Domain yang Diizinkan dan URI lengkapnya (termasuk parameter jalur dan kueri) ke URI Pengalihan OAuth yang Valid. Jika memiliki banyak variasi dalam URI tempat Login aplikasi, Anda bisa secara manual menentukan fallback_redirect_uri sebagai opsi di panggilan FB.login(), sehingga Anda hanya perlu menambahkan satu entri itu ke daftar URI Pengalihan OAuth yang Valid.

Kunci Pengaturan Aplikasi Facebook Anda

Mengaktifkan dan/atau menonaktifkan alur autentikasi yang tidak digunakan aplikasi untuk meminimalkan area permukaan serangan.

  • Gunakan token akses berdurasi singkat yang dihasilkan kode di klien dan bukan token yang dibuat klien atau token berdurasi lama yang disediakan server. Alur token akses jangka pendek yang dihasilkan kode mengharuskan server aplikasi untuk menukar kode dengan token, yang lebih aman daripada mendapatkan token di browser. Aplikasi sebaiknya memilih menggunakan alur ini jika memungkinkan agar lebih aman. Jika aplikasi hanya mengaktifkan alur ini, malware yang berjalan di komputer pengguna tidak dapat memperoleh token akses untuk disalahgunakan. Pelajari selengkapnya di dokumentasi token akses.

  • Nonaktifkan Login OAuth Klien jika aplikasi Anda tidak menggunakannya. Klien OAuth Login adalah tombol nyala-mati global untuk menggunakan alur token klien OAuth. Jika aplikasi Anda tidak menggunakan alur OAuth klien apa pun, yang mencakup Facebook Login SDK, Anda harus menonaktifkan alur ini. Namun, perhatikan bahwa Anda tidak dapat meminta izin untuk token akses jika Anda menonaktifkan Login OAuth Klien. Pengaturan ini ada di bagian Produk > Facebook Login > Pengaturan pada Dasbor Aplikasi.

  • Nonaktifkan Alur OAuth Web atau Tentukan Daftar Diizinkan untuk Pengalihan. Pengaturan Login OAuth Web memungkinkan alur token klien OAuth apa pun yang menggunakan dialog login web Facebook untuk mengembalikan token ke situs web Anda sendiri. Pengaturan ini ada di bagian Produk > Facebook Login > Pengaturan pada Dasbor Aplikasi. Nonaktifkan pengaturan ini jika Anda tidak membuat alur login web khusus atau menggunakan Facebook Login SDK di web.

  • Wajibkan HTTPS. Pengaturan ini memerlukan HTTPS untuk Pengalihan OAuth, dan memerlukan serta panggilan Facebook SDK for Javascript yang mengembalikan atau memerlukan token akses hanya dari halaman HTTPS. Semua aplikasi baru yang dibuat mulai Maret 2018 mengaktifkan pengaturan ini secara default, dan Anda harus merencanakan untuk memigrasi aplikasi apa pun yang ada untuk hanya menggunakan URL HTTPS sebelum 6 Oktober 2018. Sebagian besar host aplikasi cloud utama menyediakan konfigurasi sertifikat TLS gratis dan otomatis untuk aplikasi Anda. Jika Anda menghosting sendiri aplikasi Anda atau layanan hosting Anda tidak menawarkan HTTPS secara default, Anda dapat memperoleh sertifikat gratis untuk domain Anda dari Let's Encrypt.

  • Nonaktifkan alur OAuth browser tersemat jika aplikasi Anda tidak menggunakannya. Beberapa aplikasi native desktop dan seluler mengautentikasi pengguna dengan melakukan alur klien OAuth di dalam tampilan web tersemat. Jika aplikasi Anda tidak melakukan hal ini, nonaktifkan pengaturan di bagian Produk > Facebook Login > Pengaturan pada Dasbor Aplikasi.

  • Nonaktifkan alur SSO seluler jika aplikasi Anda tidak menggunakannya. Jika aplikasi Anda tidak menggunakan Login iOS atau Android, nonaktifkan pengaturan ‘Single Sign On’ di bagian iOS dan Android dari Pengaturan > Dasar .

Dasbor Aplikasi berisi sejumlah pengaturan tambahan yang memungkinkan developer untuk menutup area serangan yang mungkin menyebabkan isu keamanan:

  • Dasar > Rahasia Aplikasi jika rahasia aplikasi Anda pernah bocor, Anda dapat mengatur ulang di sini.
  • Dasar > Domain Aplikasi gunakan ini untuk mengunci domain dan subdomain yang dapat digunakan untuk melakukan Facebook Login atas nama aplikasi Anda.
  • Lanjutan > Jenis Aplikasi saat Anda membuat aplikasi native untuk seluler atau desktop dan menyertakan rahasia aplikasi di dalamnya, atur ini ke Native/Desktop untuk melindungi aplikasi Anda dari dekompilasi dan pencurian rahasia aplikasi Anda.
  • Lanjutan > Daftar Diizinkan untuk IP Server menentukan daftar alamat IP tempat panggilan Graph API dapat dibuat dengan rahasia aplikasi Anda. Panggilan Graph API yang dibuat dengan rahasia aplikasi Anda dari luar rentang ini akan gagal. Panggilan yang dilakukan dengan token akses pengguna tidak terpengaruh oleh pengaturan ini.
  • Lanjutan > Perbarui Daftar Diizinkan untuk IP Pengaturan mengunci alamat IP yang darinya seseorang dapat mengubah pengaturan aplikasi ini ke rentang tertentu. Berhati-hatilah saat mengatur daftar diizinkan untuk IP pada broadband perumahan. Jika alamat IP Anda berubah, Anda akan kehilangan kemampuan untuk mengedit pengaturan aplikasi Anda.
  • Lanjutan > Perbarui Email Notifikasi memberi tahu alamat email setiap kali pengaturan aplikasi apa pun diubah di Dasbor Aplikasi.
  • Lanjutan> Keamanan URL postingan aliran ini akan menghentikan aplikasi Anda dari menerbitkan URL apa pun yang tidak mengarah kembali ke domain yang dimilikinya. Ini tidak selalu berguna, khususnya jika Anda tahu aplikasi Anda akan menerbitkan tautan ke situs lain.