การเข้าสู่ระบบด้วย Facebook มาพร้อมกับฟีเจอร์ต่างๆ เช่น โทเค็นการเข้าถึงและสิทธิ์การอนุญาต ซึ่งจะช่วยให้ผู้คนและแอพสามารถใช้การเข้าสู่ระบบดังกล่าวได้อย่างปลอดภัยและได้รับการป้องกัน แต่จะมีขั้นตอนการรักษาความปลอดภัยบางอย่างที่แอพต้องปรับใช้เอง
โปรดทราบว่ารายการด้านล่างนี้เป็นข้อกำหนดขั้นต่ำที่แอพทั้งหมดที่ใช้การเข้าสู่ระบบด้วย Facebook ควรนำมาใช้ แอพของคุณยังมีฟีเจอร์อื่นๆ ที่เป็นแบบเฉพาะตัว และคุณจะต้องคำนึงถึงวิธีที่จะทำให้แอพปลอดภัยให้มากที่สุดอยู่เสมอ แอพที่ไม่ปลอดภัยจะทำให้กลุ่มเป้าหมายไม่ไว้วางใจและผู้คนจะเลิกใช้ไปในที่สุด
ข้อมูลลับของแอพถูกนำมาใช้ในขั้นตอนการเข้าสู่ระบบบางอย่างเพื่อสร้างโทเค็นการเข้าถึง และข้อมูลลับดังกล่าวมีจุดประสงค์เพื่อรักษาความปลอดภัยให้แอพมีการใช้งานโดยบุคคลซึ่งเป็นที่ไว้วางใจได้เท่านั้น คุณสามารถใช้ข้อมูลลับในการสร้างโทเค็นการเข้าถึงแอพได้ง่ายๆ โดยโทเค็นดังกล่าวจะส่งคำขอ API ในนามของผู้ใช้แอพได้ ด้วยเหตุนี้ การดูแลข้อมูลลับของแอพให้ไม่มีผู้ใดบุกรุกจึงเป็นเรื่องสำคัญอย่างยิ่ง
ดังนั้นจึงไม่ควรรวมข้อมูลลับของแอพหรือโทเค็นการเข้าถึงแอพในรหัสใดๆ
เราขอแนะนำให้ใช้โทเค็นการเข้าถึงแอพโดยตรงจากเซิร์ฟเวอร์ของแอพเท่านั้นเพื่อความปลอดภัยสูงสุด สำหรับแอพแบบเนทีฟ เราขอแนะนำให้แอพสื่อสารกับเซิร์ฟเวอร์ของคุณเอง แล้วจากนั้นเซิร์ฟเวอร์จะส่งคำขอ API ไปยัง Facebook โดยใช้โทเค็นการเข้าถึงแอพ ด้วยเหตุนี้ หากมีการตั้งค่า "ประเภทของแอพ" ในส่วนการตั้งค่าขั้นสูงในแดชบอร์ดของแอพเป็น Native/Desktop
เราจะถือว่าแอพแบบเนทีฟของคุณมีข้อมูลลับของแอพหรือโทเค็นการเข้าถึงแอพในไบนารี และเราจะไม่อนุญาตให้การเรียกใช้ที่ลงชื่อด้วยโทเค็นการเข้าถึงแอพดำเนินต่อไป โดย API จะทำงานเสมือนว่าไม่มีโทเค็นการเข้าถึง
appsecret_proof
คุณสามารถลดความเสี่ยงที่จะเผชิญกับมัลแวร์และผู้ส่งสแปมได้โดยกำหนดให้การเรียกระหว่างเซิร์ฟเวอร์ไปยัง API ของ Facebook ต้องมีการลงชื่อด้วยพารามิเตอร์ appsecret_proof
ข้อพิสูจน์ข้อมูลลับของแอพ คือ แฮชแบบ sha256 สำหรับโทเค็นการเข้าถึงของคุณ โดยใช้ข้อมูลลับของแอพเป็นคีย์ ข้อมูลลับของแอพจะอยู่ในแดชบอร์ดของแอพในการตั้งค่า > พื้นฐาน
ตัวอย่างโค้ดต่อไปนี้เป็นลักษณะของการเรียกใช้ในภาษา PHP
$appsecret_proof= hash_hmac('sha256', $access_token.'|'.time(), $app_secret);
ระบบปฏิบัติการบางระบบและภาษาโปรแกรมบางภาษาจะส่งประทับเวลาที่เป็นเลขทศนิยมกลับคืนมา โปรดอย่าลืมแปลงค่าเป็นจำนวนเต็มก่อนที่จะคำนวณข้อพิสูจน์ข้อมูลลับของแอพ ภาษาโปรแกรมบางภาษาจะสร้างแฮชเป็นอ็อบเจ็กต์แบบย่อ โปรดตรวจสอบให้แน่ใจว่าได้ใช้แฮชเป็นอ็อบเจ็กต์เลขฐานสิบหก
คุณสามารถเพิ่มผลลัพธ์ในรูปแบบพารามิเตอร์ appsecret_proof
โดยตั้งค่า appsecret_time
เป็นประทับเวลาที่คุณใช้ขณะแฮชข้อมูลลับของแอพลงในการเรียกใช้แต่ละครั้งของคุณได้ดังนี้
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
ระบบจะถือว่าข้อพิสูจน์ข้อมูลลับของแอพที่ประทับเวลาไว้จะหมดอายุหลังจากผ่านไป 5 นาที เราจึงขอแนะนำให้คุณสร้างข้อพิสูจน์ใหม่เอาไว้ด้วยเมื่อเรียกใช้ API กราฟแต่ละครั้ง
หาต้องการเปิดใช้งานจำเป็นต้องใช้ข้อมูลลับของแอพสำหรับทุกการเรียกใช้ API ของคุณ ให้ไปยังแดชบอร์ดแอพ Meta และคลิกการตั้งค่าแอพ > ขั้นสูงในเมนูด้านข้างทางซ้าย เลื่อนไปยังส่วนการรักษาความปลอดภัย และคลิกปุ่มสลับจำเป็นต้องใช้ข้อมูลลับของแอพ
หากเปิดใช้งานการตั้งค่านี้ การเรียกใช้ที่เริ่มต้นโดยไคลเอ็นต์ทั้งหมดจะต้องผ่านพร็อกซีผ่านหลังบ้านของคุณ ซึ่งสามารถเพิ่มพารามิเตอร์ appsecret_proof
ไปยังคำขอก่อนส่งไปยัง Graph API ไม่เช่นนั้นจะเรียกใช้ไม่สำเร็จ
ในการตั้งค่าบางอย่าง แอพจะใช้โทเค็นระยะยาวซ้ำในหลายไคลเอ็นต์ โปรดอย่ากำหนดค่าเช่นนี้ แต่ขอให้ใช้โทเค็นระยะสั้นที่สร้างด้วยโค้ดโฟลว์แทน ตามที่ระบุในเอกสารประกอบเกี่ยวกับโทเค็นการเข้าถึง
ในการทำความเข้าใจว่าเหตุการณ์เช่นนี้เกิดขึ้นได้อย่างไร ให้นึกถึงแอพ iOS แบบเนทีฟที่ต้องการเรียกใช้ API แต่แทนที่จะทำโดยตรง กลับมีการสื่อสารกับเซิร์ฟเวอร์ของแอพเดียวกันและส่งโทเค็นที่สร้างขึ้นโดยใช้ iOS SDK ไปยังเซิร์ฟเวอร์ดังกล่าว จากนั้นเซิร์ฟเวอร์จะใช้โทเค็นเพื่อเรียกใช้ API
ตำแหน่งข้อมูลที่เซิร์ฟเวอร์ใช้รับโทเค็นอาจไม่ปลอดภัย และทำให้ผู้อื่นสามารถส่งโทเค็นการเข้าถึงสำหรับแอพอื่นไปที่ตำแหน่งข้อมูลนั้นได้ เหตุการณ์เช่นนี้ไม่ปลอดภัยอย่างแน่นอน แต่วิธีหนึ่งในการป้องกันก็คือ คุณไม่ควรสันนิษฐานเอาเองว่าโทเค็นการเข้าถึงมาจากแอพที่ใช้โทเค็นนั้นๆ แต่ให้ตรวจสอบโดยใช้ตำแหน่งข้อมูลในการแก้ไขจุดบกพร่องแทน
หากคุณไม่ได้ใช้ Facebook SDK โปรดตรวจสอบความถูกต้องของโทเค็นการเข้าถึงอย่างสม่ำเสมอ แม้ว่าโทเค็นการเข้าถึงจะมีวันหมดอายุที่กำหนดไว้แล้ว แต่โทเค็นอาจหมดอายุก่อนเวลาได้เนื่องจากเหตุผลด้านความปลอดภัย หากคุณไม่ได้ใช้ Facebook SDK ในแอพ การตรวจสอบความถูกต้องของโทเค็นด้วยตนเองเป็นประจำ (อย่างน้อยวันละครั้ง) จะเป็นเรื่องสำคัญอย่างยิ่ง ทั้งนี้เพื่อให้แน่ใจว่าแอพของคุณไม่ได้ใช้โทเค็นการเข้าถึงที่หมดอายุก่อนเวลาเนื่องจากเหตุผลด้านความปลอดภัย
หากคุณกำลังใช้กล่องการเข้าสู่ระบบของ Facebook บนเว็บไซต์ พารามิเตอร์ state
จะเป็นสตริงที่ไม่ซ้ำกันซึ่งป้องกันแอพพลิเคชั่นของคุณจากการโจมตีแบบFacebook
โหมดเข้มงวดจะรักษาความปลอดภัยของแอพโดยป้องกันไม่ให้ผู้ไม่ประสงค์ดีลักลอบขโมยการเปลี่ยนเส้นทางของคุณ โดยทุกแอพต้องเปิดใช้โหมดเข้มงวด
ก่อนที่จะเปิดโหมดเข้มงวดในแดชบอร์ดของแอพ โปรดตรวจสอบให้แน่ใจว่าการเปลี่ยนเส้นทางปัจจุบันของคุณยังทำงานได้อยู่โดยดำเนินการดังต่อไปนี้ในการตั้งค่าการเข้าสู่ระบบด้วย Facebook:
สำหรับแอพที่มี URI การเปลี่ยนเส้นทางแบบไดนามิก ให้ใช้พารามิเตอร์สถานะเพื่อส่งกลับข้อมูลแบบไดนามิกไปยัง URI การเปลี่ยนเส้นทางที่มีจำนวนจำกัด จากนั้นจึงเพิ่ม URI การเปลี่ยนเส้นทางจำนวนจำกัดแต่ละตัวในรายการ URI การเปลี่ยนเส้นทางของ OAuth ที่ถูกต้อง
สำหรับแอพที่มี URI การเปลี่ยนเส้นทางจำนวนจำกัด ให้เพิ่ม URI แต่ละตัวในรายการ URI การเปลี่ยนเส้นทางของ OAuth ที่ถูกต้อง
หลังจากการดำเนินการเหล่านี้ โปรดตรวจสอบให้แน่ใจว่าได้เปิดใช้งานโหมดเข้มงวดแล้ว
โหมดเข้มงวดจะป้องกันการลักลอบขโมย URI การเปลี่ยนเส้นทางของคุณ โดยกำหนดให้ต้องมีข้อมูลที่ตรงกันทุกประการจากรายการ URI การเปลี่ยนเส้นทางของ OAuth ที่ถูกต้องของคุณ ตัวอย่างเช่น ถ้ารายการของคุณมี www.example.com โหมดเข้มงวดจะไม่อนุญาตให้ www.example.com/token เป็นการเปลี่ยนเส้นทางที่ถูกต้อง และจะไม่อนุญาตให้ใช้พารามิเตอร์การสืบค้นใดๆ เพิ่มเติมที่ไม่ปรากฏอยู่ในรายการ URI การเปลี่ยนเส้นทาง OAuth ที่ถูกต้องของคุณ
ใช้ HTTPS เป็นโปรโตคอลอินเทอร์เน็ตแทน HTTP เพราะมีการใช้งานการเข้ารหัส HTTPS จะทำให้ข้อมูลที่ส่งมีความเป็นส่วนตัวและป้องกันไม่ให้ถูกโจมตีด้วยการแอบดูข้อมูล นอกจากนั้น ยังป้องกันไม่ให้ข้อมูลถูกดัดแปลงระหว่างการส่งข้อมูลอีกด้วย เช่น การใส่โฆษณาหรือโค้ดที่เป็นอันตราย
ตั้งแต่วันที่ 6 ตุลาคม 2018 เป็นต้นไป แอพทั้งหมดจะต้องใช้ HTTPS
เมื่อคุณระบุว่าคุณใช้ JavaScript SDK สำหรับการเข้าสู่ระบบด้วยการตั้งค่าการเข้าสู่ระบบด้วย JavaScript SDK เป็น "ใช่" แล้ว โดเมนของหน้าที่โฮสต์ SDK ต้องตรงกับโดเมนที่อยู่ในรายการโดเมนสำหรับ JavaScript SDK ที่ได้รับอนุญาต การทำเช่นนี้จะช่วยให้แน่ใจว่าระบบจะส่งคืนโทเค็นการเข้าถึงไปยังการเรียกกลับในโดเมนที่ได้รับอนุญาตเท่านั้น การดำเนินการยืนยันตัวตนด้วย Facebook JavaScript SDK จะรองรับเฉพาะหน้าเว็บที่ใช้ https เท่านั้น
สำหรับการผสานการทำงาน JSSDK ที่มีอยู่แล้วที่สร้างขึ้นจนถึงวันที่ 10 สิงหาคม 2021 รายการนี้จะได้รับการเติมค่ากลับตามการใช้งานในปัจจุบัน โดยไม่จำเป็นต้องมีการดำเนินการใดๆ อีก
สำหรับการผสานการทำงานใหม่ที่สร้างขึ้นหลังจากวันที่ 10 สิงหาคม 2021 คุณจะต้องเพิ่มค่าลงในรายการนี้
หากคุณเห็นช่องโดเมน JSSDK ของแอพมี URL ที่เริ่มต้นด้วย *.
โปรดเปลี่ยนแปลงโดยการแทนที่ด้วย URL โดเมนสัมบูรณ์เพื่อเพิ่มความปลอดภัย
การโจมตีแบบ Open Redirect จะเกิดขึ้นเมื่อผู้ไม่ประสงค์ดีระบุพารามิเตอร์ redirect_uri ที่ไม่ได้รับอนุญาตในคำขอเข้าสู่ระบบ ซึ่งส่งผลให้ข้อมูลที่ละเอียดอ่อนต่างๆ เช่น โทเค็นการเข้าถึง มีโอกาสรั่วไหลผ่านสตริงการสืบค้นหรือองค์ประกอบย่อยใน URI การเปลี่ยนเส้นทาง
สำหรับการผสานการทำงานในเว็บแบบกำหนดเอง คุณควรระบุ URI การเปลี่ยนเส้นทางที่ได้รับอนุญาตในการตั้งค่าแอพของคุณเพื่อป้องกันการโจมตีดังกล่าว ในขณะที่ดำเนินการตามคำขอเพื่อเข้าสู่ระบบ พารามิเตอร์ redirect_uri จะได้รับการตรวจสอบโดยเทียบกับข้อมูลในรายการนี้ URI แบบเต็มจะต้องตรงกันทุกประการ รวมถึงพารามิเตอร์ทั้งหมดด้วย ยกเว้นพารามิเตอร์สถานะแบบเลือกระบุได้ ซึ่งค่าของพารามิเตอร์เหล่านั้นจะถูกละเว้น
โดยปกติแล้ว JavaScript SDK มักจะใช้ป๊อปอัพและการเรียกคืนเพื่อให้การเข้าสู่ระบบเสร็จสมบูรณ์ แต่การดำเนินการนี้อาจล้มเหลวกับเบราว์เซอร์ในแอพที่บล็อกป๊อปอัพ เมื่อเกิดเหตุการณ์เช่นนี้ SDK จะพยายามเปลี่ยนเส้นทางไปยังหน้าที่มีการเรียกใช้ด้วยโทเค็นการเข้าถึงโดยอัตโนมัติ ซึ่งจะสามารถดำเนินการเปลี่ยนเส้นทางได้อย่างปลอดภัยก็ต่อเมื่อ URI แบบเต็มของหน้ามีระบุไว้ในรายการ URI การเปลี่ยนเส้นทาง OAuth ที่ถูกต้อง
หากแอพบนเว็บของคุณจำเป็นต้องใช้เบราว์เซอร์ในแอพ คุณควรเพิ่มโดเมนของหน้าเข้าสู่ระบบลงในโดเมนที่ได้รับอนุญาตและเพิ่ม URI แบบเต็ม (รวมถึงพารามิเตอร์เส้นทางและพารามิเตอร์การสืบค้น) ไปยัง URI การเปลี่ยนเส้นทาง OAuth ที่ถูกต้อง หากคุณมี URI หลายรูปแบบสำหรับการเข้าสู่ระบบแอพของคุณ คุณสามารถระบุ fallback_redirect_uri ด้วยตนเองให้เป็นตัวเลือกในการเรียกใช้ FB.login() ได้ เพื่อให้คุณสามารถเพิ่มเฉพาะรายการนั้นในรายการ URI การเปลี่ยนเส้นทาง OAuth ที่ถูกต้อง
เปิดและ/หรือปิดใช้งานขั้นตอนการยืนยันตัวตนที่แอพไม่ได้ใช้เพื่อลดช่องโหว่ให้เหลือน้อยที่สุด
ใช้โทเค็นการเข้าถึงระยะสั้นที่สร้างจากโค้ดในไคลเอ็นต์แทนโทเค็นที่สร้างจากไคลเอ็นต์หรือโทเค็นระยะยาวที่ได้มาจากเซิร์ฟเวอร์ ขั้นตอนของโทเค็นการเข้าถึงระยะสั้นที่สร้างจากโค้ดกำหนดให้เซิร์ฟเวอร์ของแอพแลกเปลี่ยนโค้ดเพื่อรับโทเค็น ซึ่งปลอดภัยกว่าการรับโทเค็นในเบราว์เซอร์ แอพควรใช้ขั้นตอนนี้เมื่อทำได้เพื่อเสริมความปลอดภัยให้รัดกุมยิ่งขึ้น หากแอพเปิดใช้งานเพียงขั้นตอนนี้เท่านั้น มัลแวร์ที่ทำงานในคอมพิวเตอร์ของผู้ใช้ก็จะไม่สามารถรับโทเค็นการเข้าถึงเพื่อนำไปใช้งานในทางที่ไม่เหมาะสม โปรดเรียนรู้เพิ่มเติมในเอกสารประกอบเกี่ยวกับโทเค็นการเข้าถึงของเรา
ปิดใช้งานการเข้าสู่ระบบ OAuth ของไคลเอ็นต์หากแอพของคุณไม่ได้ใช้งาน การเข้าสู่ระบบ OAuth ของไคลเอ็นต์เป็นสวิตช์เปิดปิดส่วนกลางสำหรับการใช้ขั้นตอนโทเค็นของไคลเอ็นต์ OAuth หากแอพไม่ใช้ขั้นตอน OAuth ของไคลเอ็นต์ใดๆ ซึ่งรวมถึง SDK การเข้าสู่ระบบด้วย Facebook คุณควรปิดการใช้ขั้นตอนนี้ ทั้งนี้ โปรดทราบว่าคุณไม่สามารถขอสิทธิ์การอนุญาตสำหรับโทเค็นการเข้าถึงได้ หากคุณปิดใช้งานการเข้าสู่ระบบด้วย OAuth ของไคลเอ็นต์ไว้ โปรดดูการตั้งค่านี้ในส่วนผลิตภัณฑ์ > การเข้าสู่ระบบด้วย Facebook > การตั้งค่าของแดชบอร์ดของแอพ
ปิดใช้งานขั้นตอน OAuth ของเว็บหรือระบุรายการที่อนุญาตในการเปลี่ยนเส้นทาง การตั้งค่าการเข้าสู่ระบบ OAuth ของเว็บจะเปิดใช้งานขั้นตอนสำหรับโทเค็นของไคลเอ็นต์ OAuth ที่ใช้กล่องการเข้าสู่ระบบบนเว็บด้วย Facebook ในการคืนโทเค็นไปยังเว็บไซต์ของคุณเอง การตั้งค่านี้อยู่ในส่วนผลิตภัณฑ์ > การเข้าสู่ระบบด้วย Facebook > การตั้งค่าของแดชบอร์ดของแอพ ให้ปิดใช้งานการตั้งค่านี้ หากคุณไม่ได้สร้างขั้นตอนการเข้าสู่ระบบเว็บแบบกำหนดเองหรือใช้ SDK การเข้าสู่ระบบด้วย Facebook ในเว็บ
ใช้ HTTPS การตั้งค่านี้จะกำหนดให้ใช้ HTTPS สำหรับการเปลี่ยนเส้นทาง OAuth รวมถึงการเรียกใช้ Facebook JavaScript SDK ที่ส่งคืนหรือใช้โทเค็นการเข้าถึงจากหน้า HTTPS เท่านั้น แอพใหม่ทั้งหมดที่สร้างในเดือนมีนาคม 2018 จะมีการตั้งค่านี้เป็นค่าเริ่มต้น และคุณควรวางแผนย้ายแอพที่มีอยู่ไปใช้เฉพาะ HTTPS URL ภายในวันที่ 6 ตุลาคม 2018 โฮสต์แอพพลิเคชั่นบนระบบคลาวด์รายหลักส่วนใหญ่มักจะให้บริการกำหนดค่าใบรับรอง TLS สำหรับแอพพลิเคชั่นของคุณแบบอัตโนมัติโดยไม่คิดค่าใช้จ่าย หากคุณโฮสต์แอพเองหรือบริการโฮสติ้งของคุณไม่มี HTTPS ตามค่าเริ่มต้น คุณสามารถขอรับใบรับรองสำหรับโดเมนของคุณจาก Let's Encrypt ได้ฟรี
ปิดใช้งานขั้นตอน OAuth ในเบราว์เซอร์แบบฝังหากแอพของคุณไม่ได้ใช้งานขั้นตอนดังกล่าว แอพแบบเนทีฟบนมือถือและบนเดสก์ท็อปบางแอพจะยืนยันตัวตนผู้ใช้โดยใช้ขั้นตอนไคลเอ็นต์ OAuth ภายในตัวแสดงหน้าเว็บที่ฝังเอาไว้ หากแอพของคุณไม่ทำขั้นตอนนี้ โปรดปิดใช้งานการตั้งค่าในส่วนผลิตภัณฑ์ > การเข้าสู่ระบบด้วย Facebook > การตั้งค่าของแดชบอร์ดของแอพ
ปิดใช้งานขั้นตอนการลงชื่อเข้าใช้ครั้งเดียวบนมือถือ หากแอพของคุณไม่ได้ใช้ขั้นตอนนี้ หากแอพของคุณไม่ได้ใช้การเข้าสู่ระบบบน iOS หรือ Android ให้ปิดใช้งานการตั้งค่า "การลงชื่อเข้าใช้ครั้งเดียว" ในส่วน iOS และ Android ที่การตั้งค่า > พื้นฐาน
แดชบอร์ดของแอพมีการตั้งค่าเพิ่มเติมหลายอย่างที่ช่วยให้ผู้พัฒนาปิดช่องโหว่ต่างๆ ที่อาจนำไปสู่ปัญหาด้านความปลอดภัยได้ดังนี้
Native/Desktop
เพื่อป้องกันไม่ให้แอพถูกแยกส่วนและหลีกเลี่ยงการขโมยข้อมูลลับของแอพ