23 คะแนน โดย GN⁺ 2024-05-29 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • TL;DR : สำหรับการเรียก API แทนที่จะรีไดเร็กต์จาก HTTP ไป HTTPS ควรทำให้คำขอล้มเหลว ให้ปิดการใช้งาน HTTP ไปเลยทั้งหมด หรือส่งคืน HTTP error response ที่ชัดเจน และเพิกถอน API key ที่ถูกส่งผ่านการเชื่อมต่อที่ไม่เข้ารหัส น่าเสียดายที่ปัจจุบันผู้ให้บริการ API ชื่อดังหลายรายยังไม่ทำเช่นนั้น

ภูมิหลัง

  • เมื่อเว็บเบราว์เซอร์เข้าถึง URL แบบ HTTP บริการมักจะรีไดเร็กต์คำขอนั้นไปยังหน้า HTTPS
  • ทราฟฟิก HTTP เริ่มต้นไม่ได้ถูกเข้ารหัส จึงเสี่ยงต่อการโจมตีแบบ man-in-the-middle (MITM)
  • มีการนำเทคโนโลยีอย่าง HSTS (HTTP Strict Transport Security) มาใช้เพื่อเสริมความปลอดภัย

ความเสี่ยงจากการพิมพ์ผิดเล็กน้อย

  • ระหว่างทำงานรวมระบบกับ API ของบุคคลที่สาม ได้พิมพ์ base URL ของ API ผิดเป็น http:// แทน https://
  • fetch ของ Node.js ตามการรีไดเร็กต์ไปยัง HTTPS แบบเงียบ ๆ
  • API key จึงอาจถูกส่งออกไปแบบ plaintext และก่อให้เกิดความเสี่ยงด้านความปลอดภัย
  • พบข้อผิดพลาดระหว่าง code review และแก้ไขปัญหาได้

หลักการ fail fast

  • หาก API รีไดเร็กต์คำขอ HTTP ไปยัง HTTPS ก็อาจมองข้ามการพิมพ์ผิดได้ง่าย
  • ควรยึดหลัก fail fast: การเรียก API ที่ไม่เข้ารหัสต้องล้มเหลวอย่างชัดเจน
  • ทางที่ดีควรปิดใช้งาน HTTP interface ของเซิร์ฟเวอร์ API หรือส่งคืนข้อความผิดพลาดสำหรับคำขอ HTTP

กรณีศึกษาของ API อื่น ๆ

  • API ชื่อดังหลายตัวส่งคืนข้อความผิดพลาด 403 สำหรับคำขอ HTTP หรือปิดการใช้งาน HTTP interface ไปเลย
  • แต่อีกบาง API ก็ยังคงรีไดเร็กต์จาก HTTP ไป HTTPS

ความจำเป็นของแนวปฏิบัติที่ดี

  • สำหรับแอปพลิเคชันที่ผู้ใช้ใช้งานโดยตรง การรีไดเร็กต์จาก HTTP ไป HTTPS เป็นเรื่องปกติ
  • แต่ในกรณีของ API การรีไดเร็กต์จาก HTTP ไป HTTPS อาจเป็นผลเสียมากกว่า
  • โครงการด้านความปลอดภัยอย่าง OWASP ควรมีแนวทางที่ชัดเจนสำหรับ API

บทสรุป

  • API ไม่ควรรีไดเร็กต์จาก HTTP ไป HTTPS แต่ควรทำให้คำขอที่ไม่เข้ารหัสล้มเหลวอย่างชัดเจน
  • หาก API key ถูกส่งผ่านการเชื่อมต่อที่ไม่เข้ารหัส ควรถูกเพิกถอนทันที
  • ควรอัปเดตแนวปฏิบัติด้านความปลอดภัยของ API เพื่อให้มีคำแนะนำที่ชัดเจน

ความเห็นของ GN⁺

  • ความจำเป็นในการเสริมความปลอดภัย: ความปลอดภัยของ API มีความสำคัญมาก และการรีไดเร็กต์จาก HTTP ไป HTTPS อาจสร้างช่องโหว่ด้านความปลอดภัยได้
  • หลักการ fail fast: การยึดหลัก fail fast เป็นสิ่งสำคัญ เพื่อให้สามารถพบและแก้ไขข้อผิดพลาดได้ตั้งแต่ช่วงต้นของการพัฒนา
  • การอัปเดตแนวปฏิบัติที่ดี: โครงการด้านความปลอดภัยอย่าง OWASP ควรจัดทำแนวทางที่ชัดเจนเกี่ยวกับความปลอดภัยของ API
  • การเพิกถอนคีย์แบบอัตโนมัติ: API key ที่ถูกส่งผ่านการเชื่อมต่อที่ไม่เข้ารหัสควรถูกเพิกถอนโดยอัตโนมัติ
  • อ้างอิงกรณีของ API อื่น ๆ: ควรศึกษากรณีด้านความปลอดภัยของ API อื่น ๆ เพื่อนำมาเสริมความปลอดภัยให้กับ API ของตนเอง

5 ความคิดเห็น

 
wkang586 2024-06-03

ดูเหมือนว่าเป็นประเด็นที่ควรถูกกำกับด้วยกฎหมาย
อย่างแรกเลย จดไว้ก่อน... ห้ามทำ https redirect ใน API

 
koxel 2024-05-31

ในทางเทคนิคแล้วก็ถูกต้อง
แต่ลูกค้าองค์กรส่วนใหญ่มักมีแนวปฏิบัติด้านความปลอดภัยให้ส่งรีไดเรกต์ไปที่ https เสมอเมื่อมีการเข้าถึงผ่าน http
อีกทั้งพวกเขายังไม่ค่อยอยากให้ลูกค้าที่ใช้เว็บไซต์ของตัวเองเห็นหน้าจอข้อผิดพลาดด้วย ดังนั้นถ้าไม่ใช่บริการที่ให้บริการเอง สำหรับฝั่งผู้ส่งมอบงานก็คงเป็นเรื่องไกลตัวอยู่เหมือนกัน..

 
thxgeeknews 2024-05-29

ระหว่างทำงานกำลังผสานรวมกับ API ของบุคคลที่สาม แล้วเผลอกรอก URL พื้นฐานของ API เป็น "https://"; แทน "http://"; โดยผิดพลาด
ดูเหมือนว่าจะสลับระหว่าง http <-> https นะครับ

 
xguru 2024-05-29

โอ๊ะ AI ดันพลาดแบบนี้ซะได้ 555 เลยแก้ไว้แล้วครับ

 
GN⁺ 2024-05-29
ความคิดเห็นบน Hacker News
  • มีการอัปเดตให้ OpenAI API ตอบกลับคำขอ HTTP ด้วยข้อผิดพลาด 403
  • Stack Exchange API ใช้วิธีที่ดีกว่า คือเพิกถอนคีย์ API ที่ส่งมาผ่าน HTTP และส่งข้อความแสดงข้อผิดพลาดกลับมา
  • ควรระวังไม่ตั้งค่าให้รีไดเรกต์จาก HTTP ไป HTTPS โดยอัตโนมัติ
  • การที่ค่าเริ่มต้นของ cURL ไม่รีไดเรกต์อัตโนมัตินั้นเป็นความตั้งใจและเป็นค่าเริ่มต้นที่ดี
  • สิ่งสำคัญคือการปิดกั้นการเข้าถึงผ่าน HTTP และให้บริการเฉพาะ HTTPS เท่านั้น
  • น่าประหลาดใจที่ "Provider B" ตอบว่าการโจมตีแบบ MITM อยู่นอกขอบเขตของโปรแกรม
  • มีข้อสงสัยว่าการดักฟัง HTTP ถือเป็นการโจมตีแบบ MITM ชนิดหนึ่งหรือไม่
  • หวังว่า HTTPS และระเบียน DNS แบบ SVCB จะเข้ามาแทนที่การรีไดเรกต์ของเซิร์ฟเวอร์ HTTP แบบดั้งเดิมเมื่อเวลาผ่านไป
  • ผู้ให้บริการ API ควรตรวจสอบบันทึกการเข้าถึง HTTP ในอดีต เพื่อดูว่าการใช้ HTTP แบบข้อความล้วนแพร่หลายมากแค่ไหน
  • API จำนวนมากถูกโฮสต์อยู่หลังเว็บแอปพลิเคชันไฟร์วอลล์ที่ตั้งกฎเริ่มต้นให้รีไดเรกต์ไป HTTPS อัตโนมัติ
  • API ไม่ควรรีไดเรกต์จาก HTTP ไป HTTPS โดยอัตโนมัติ และไลบรารีฝั่งไคลเอนต์ก็ควรไม่ตามการรีไดเรกต์โดยค่าเริ่มต้น
  • การตั้งค่ารีไดเรกต์จาก HTTP ไป HTTPS ช่วยลดทราฟฟิกได้ในระยะยาว
  • ในหลายกรณีมีการตั้งค่ารีไดเรกต์เพื่อแก้ปัญหาอย่างรวดเร็วจากการพิมพ์ URL ผิดในโครงสร้างพื้นฐาน