ป้องกันการถูกโจมตีของ API OTP

หากสคริปต์ยิงคำขอส่ง OTP ซ้ำๆ ผู้ใช้จะได้รับรหัสที่ไม่เกี่ยวข้องจำนวนมาก ยอดเงินถูกใช้เร็ว และชื่อเสียงของช่องทางอาจลดลง EngageLab OTP สามารถจำกัดความถี่และปริมาณฝั่งการส่งได้ แต่ไม่สามารถหยุด API «ขอรหัสยืนยัน» ที่ไม่มีการยืนยันตัวตนในระบบธุรกิจของคุณ

บทความนี้อธิบายวิธีใช้ความสามารถของแพลตฟอร์มร่วมกับการป้องกันฝั่งธุรกิจ เพื่อลดความเสี่ยงที่ API จะถูกโจมตี

สถาปัตยกรรมที่ถูกต้อง

ต้องเรียก EngageLab OTP API จากเซิร์ฟเวอร์ของคุณเท่านั้น ห้ามเรียกโดยตรงจากเบราว์เซอร์ ไคลเอนต์ App หรือมินิโปรแกรม

              
              ผู้ใช้ → ฟรอนต์เอนด์ของคุณ (เข้าสู่ระบบ / ลงทะเบียน / รีเซ็ตรหัสผ่าน)
     → แบ็กเอนด์ของคุณ (ตรวจเซสชัน, CAPTCHA, จำกัดอัตราฝั่งธุรกิจ)
     → EngageLab OTP API (พร้อม API Key และ end_user_ip)

            

• เก็บ dev_key และ dev_secret ไว้ที่เซิร์ฟเวอร์เท่านั้น ห้ามใส่ในโค้ดฟรอนต์เอนด์ แพ็กเกจแอป หรือคลังสาธารณะ
• ฟรอนต์เอนด์ควรเรียกเฉพาะ API «ขอรหัสยืนยัน» ของคุณเอง ห้ามเชื่อมตรงไปที่ https://otp.api.engagelab.cc
• แนะนำให้ตั้งอนุกรม IP ของผู้เรียกสำหรับ API Key ฝั่งโปรดักชัน ดู API Key

อย่าปะปน IP สองประเภท

หลังจากเปิดการจำกัด «ตามที่อยู่ IP» ใน ศูนย์ความปลอดภัย แล้ว ต้องส่ง end_user_ip ในคำขอ การส่งรหัส OTP การจำกัดจึงจะมีผล ส่ง IP สาธารณะของอุปกรณ์ผู้ใช้ ไม่ใช่ IP ของเซิร์ฟเวอร์คุณ

การป้องกันฝั่งแพลตฟอร์ม

ตั้งค่าต่อไปนี้ในคอนโซล OTP เพื่อจำกัดความเสียหายหากฝั่งการส่งถูกโจมตี

หากต้องการรับการแจ้งเมื่อถึงค่าเตือนหรือโควตา ให้ตั้งค่าอีเวนต์คอลแบ็กใน Webhook ก่อน

การป้องกันฝั่งธุรกิจ

การจำกัดของแพลตฟอร์มทดแทนการป้องกัน API «ขอรหัสยืนยัน» ของคุณไม่ได้ ควรตรวจต่อไปนี้ก่อนเรียก EngageLab

• ทำ human verification (เช่น CAPTCHA รูปภาพ หรือ Turnstile / reCAPTCHA) ก่อนส่งรหัส และตรวจผลที่เซิร์ฟเวอร์
• ตั้งช่วงเวลาก่อนส่งซ้ำสำหรับเบอร์เดียวกัน (เช่น 60 วินาที) และแสดงนับถอยหลังที่ฟรอนต์เอนด์
• จำกัดคำขอต่อบัญชี อุปกรณ์ และ IP ตามนาที ชั่วโมง และวันตามปฏิทิน นับคำขอที่ล้มเหลวด้วย
• «ขอรหัสยืนยัน» ต้องมีสถานะเข้าสู่ระบบ หรือเซสชันที่ถูกต้องในกรณีที่ยังไม่เข้าสู่ระบบ ห้ามเปิดช่องส่งสาธารณะที่ไม่มีบริบท
• จำกัดจำนวนครั้งที่ลองรหัสเดียวกัน และทำให้รหัสหมดอายุทันทีเมื่อตรวจผ่าน EngageLab OTP ไม่รองรับการตรวจรหัสที่ตรวจผ่านแล้วซ้ำอีก

ใช้รหัสข้อผิดพลาดเป็นสัญญาณการถูกโจมตี

การส่งรหัส OTP อาจส่งคืนข้อผิดพลาดต่อไปนี้ในขั้นตรวจก่อนส่ง หากพบ ให้ชะลอการลองใหม่ และตรวจว่ามีการยิงคำขอรวมศูนย์หรือไม่

เมื่อได้รับ HTTP 429 ห้ามลองใหม่ถี่ทันที หากยังเกิดต่อเนื่อง ให้ตรวจที่ศูนย์ความปลอดภัยก่อนว่าถึงโควตาปริมาณหรือหยุดฉุกเฉินหรือไม่ แล้วค่อยติดต่อฝ่ายสนับสนุน

เมื่อ secret รั่วไหล

1. ในคอนโซล OTP ปิดใช้งานหรือหมุนเวียน API Key
2. ใน ศูนย์ความปลอดภัย ใช้การหยุดฉุกเฉินเพื่อหยุดการส่ง SMS
3. ตรวจการส่งที่ผิดปกติใน ประวัติ และคอลแบ็ก
4. รัดรายการอนุญาต IP ของ API Key และตรวจว่าโควตารายวัน / รายเดือนเหมาะสมหรือไม่
5. กลับมาส่งอีกครั้งเมื่อความเสี่ยงหมดไปเท่านั้น

รายการตรวจก่อนเปิดใช้งานจริง

• เรียก API จากเซิร์ฟเวอร์เท่านั้น dev_secret ไม่อยู่ในฟรอนต์เอนด์ แอป หรือคลังสาธารณะ
• API Key โปรดักชันตั้งรายการอนุญาต IP ขาออกของเซิร์ฟเวอร์แล้ว
• ศูนย์ความปลอดภัยเปิดจำกัดความถี่ตามเบอร์แล้ว หากต้องการจำกัดตาม IP คำขอส่งมี end_user_ip
• ตั้งโควตารายวัน / รายเดือนแล้ว และตั้งคอลแบ็กที่เกี่ยวกับปริมาณแล้ว
• API «ขอรหัสยืนยัน» ทำ CAPTCHA และจำกัดอัตราฝั่งธุรกิจก่อนเรียก EngageLab
• ทราบลำดับรับมือเมื่อถูกโจมตีแล้ว: ปิด Key → หยุดฉุกเฉิน → ตรวจบันทึกการส่ง