จะหลีกเลี่ยงการใช้ API โดยไม่ได้รับอนุญาตได้อย่างไร

ฉันต้องออกแบบ "วิดเจ็ต" สคริปต์ที่พันธมิตรจะฝังไว้ในเว็บไซต์ของพวกเขาเพื่อแสดง UI และโทรหา API ของเรา

โดยพื้นฐานแล้วมันจะแสดงข้อมูลของเราในเว็บไซต์เหล่านี้โดยอ้างอิงจาก ID บางรหัสที่พวกเขาให้ไว้ในการเรียก API สิ่งที่เราต้องการหลีกเลี่ยงคือมีคนใช้ API ในทางที่ผิดและใช้ขูดแคตตาล็อกทั้งหมดของเรา

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

<script src="//initrode.com/widget/loader.js?key=xxxx"></script>

ด้วยวิธีนี้คำขอสำหรับสคริปต์สามารถใช้ในการลงทะเบียนคู่ของคีย์ / แหล่งที่มา IP และตอบรับการเรียก API ที่ตามมาเฉพาะในกรณีที่คู่คีย์ / IP ตรงกับคู่ที่ลงทะเบียนแล้ว (มีอายุการใช้งาน จำกัด และ จำกัด คำขอต่อวัน)

ฉันไม่แน่ใจว่าเป็นความคิดที่ดีเพราะเห็นได้ชัดว่าการรักษาความปลอดภัยด้วยการทำให้งงงวย (มีคนโหลดสคริปต์จะข้ามมันอย่างสมบูรณ์); แต่ฉันไม่เห็นวิธีอื่น ๆ ในการ จำกัด การเข้าถึง ฉันไม่สามารถให้รหัสที่ไม่ซ้ำกับผู้ใช้ทุกคนเฉพาะกับพันธมิตร ฉันไม่สามารถใช้ระบบกุญแจส่วนตัวได้เนื่องจากทุกรหัสจะมีให้สำหรับทุกคน โดยทั่วไปจะ จำกัด การเข้าถึง API สาธารณะเช่นขัดแย้งกับคำจำกัดความ

คุณคิดอย่างไรกับวิธีนี้และคุณจะทำอย่างไรกับข้อ จำกัด เหล่านี้

คุณต้องการการป้องกันหลายประเภท

ประการแรกคุณต้องป้องกันไม่ให้มีการใช้คีย์ของไซต์ A บนไซต์ B

ในทางทฤษฎีหากคีย์ถูกผูกไว้กับโดเมนคุณจะไม่สามารถพึ่งพาrefererส่วนหัวได้ แต่เนื่องจากไคลเอนต์ของคุณกำลังฝังสคริปต์โดยตรงคุณสามารถพึ่งพาที่document.locationอยู่ฝั่งไคลเอ็นต์ได้อย่างสมเหตุสมผล การส่งตำแหน่งนั้น (หรือบางส่วน) ไปยังเซิร์ฟเวอร์โดยตรงนั้นไม่น่าเชื่อถือ แต่คุณสามารถใช้มันเพื่อสร้างกุญแจเซสชั่น:

1. ไคลเอ็นต์ฝังclient_keyร้องขอไลบรารี API
2. เซิร์ฟเวอร์กำหนดโฮสต์ที่สามารถเข้าถึง API ได้หากมี
3. เซิร์ฟเวอร์เลือก "เกลือ" สำหรับคีย์เซสชันและส่งไปยังไคลเอ็นต์พร้อมกับไลบรารี [หรือเป็นส่วนหนึ่งของการแลกเปลี่ยนการตรวจสอบล่วงหน้าอีกครั้ง]
4. ไคลเอ็นต์คำนวณโดยใช้session_keyhash(document.location.host + session_salt)
5. ลูกค้าใช้session_key+ client_keyสำหรับการโทร API
6. เซิร์ฟเวอร์ตรวจสอบการโทรโดยค้นหาclient_keyโฮสต์และ "เกลือ" ในเซสชันคำนวณแฮชและเปรียบเทียบกับที่ให้client_keyไว้

ประการที่สองคุณต้องขัดขวาง Hacker Hank จากการเปิดคอนโซลการดีบักหรือใช้ไคลเอนต์ที่ได้รับการแก้ไขบนไซต์ A เพื่อทำสิ่งที่เขาต้องการด้วย API ของคุณ

โปรดทราบว่ามันเป็นเรื่องยากมากหากไม่เป็นไปไม่ได้ที่จะป้องกันไม่ให้ Hacker Hank ใช้ API อย่างไม่เหมาะสม แต่คุณสามารถทำให้มันยากขึ้น และวิธีที่สมเหตุสมผลที่สุดในการขัดขวางแฮงค์ที่ฉันตระหนักถึงคือการ จำกัด อัตรา

• จำกัด จำนวนการร้องขอ / วินาที / เซสชันและคำขอ / ชั่วโมง / เซสชัน (Spikes ในกิจกรรมน่าจะสมเหตุสมผล แต่ไม่ได้รับการรับส่งข้อมูลสูงกว่าค่าเฉลี่ยจากลูกค้ารายเดียว)
• จำกัด จำนวนเซสชัน / IP / ชั่วโมง
• จำกัด จำนวนการร้องขอ / IP / ชั่วโมง อนุญาตให้แหลม แต่ไม่ยั่งยืนจราจรหนาแน่นจาก IP เดียว

ประการที่สามตามที่คุณน่าจะทำอยู่: เข้ารหัสการรับส่งข้อมูล แน่นอนว่า NSA จะเห็นมัน แต่แฮ็กเกอร์แฮงค์มีโอกาสน้อยกว่า

ดูเหมือนว่าคุณกำลังทำที่นี่ทำให้ไฟล์ javascript ของคุณเป็นทรัพยากรที่มีการป้องกัน และการรวมเข้ากับรุ่นโทเค็นในเวลาเดียวกัน นั่นดูน่าสนใจ.

ผู้รักษาความปลอดภัยที่ฉันทำงานด้วยมักเลิกใช้ที่อยู่ IP พ้นมือเพราะ IP นั้นเป็นของปลอมแปลงได้ แต่ถ้าคุณใช้การ จำกัด IP รวมกับ SSL นั่นก็มักจะเป็นการหลอกลวง

แต่คุณต้อง "บัญชีขาว" ที่อยู่ IP มิฉะนั้นแฮ็กเกอร์ใด ๆ ก็สามารถเข้ามาอยู่ข้างหน้าได้

ฉันสงสัย แต่จริงๆแล้วฉันคิดว่าแผนการของคุณใช้ได้ดี ถ้า 1) ไฟล์. js และการเรียก API ที่ตามมาทำด้วย TLS (เช่น SSL หรือ https) และ 2) IP นั้นอยู่ในรายการที่อนุญาต จากนั้นฉันก็จะออกแถลงการณ์อย่างกล้าหาญและบอกว่าฉันคิดว่าคุณจะผ่านการตรวจสอบความปลอดภัยแม้กระทั่งสำหรับการโต้ตอบ PCI (บัตรเครดิต)

IMHO ... แต่ถ้าคุณเพียงแค่พยายามปกป้องข้อมูลที่เป็นกรรมสิทธิ์ของ บริษัท แทนบัตรเครดิต (PCI) หรือข้อมูลส่วนตัว / ส่วนตัว (PII) นี่อาจเป็นสิ่งที่ดีแม้ว่าจะไม่มี SSL ขึ้นอยู่กับว่าคุณมีจำนวนเท่าใด ยินดีที่เสี่ยงที่จะเปิดเผยแคตตาล็อกของคุณ

หรือใช้วิธีนี้: กับ SSL แฮ็กเกอร์เฉพาะไม่สามารถรับแคตตาล็อกของคุณ (เว้นเสียแต่ว่าพวกเขาจะทำลาย SSL แต่ก็สามารถทำลาย Amazon ได้เช่นกัน) หากไม่มี SSL แฮ็กเกอร์ที่ทุ่มเทสามารถดมสายของคุณหลอก IP และดึงแคตตาล็อกของคุณ ดังนั้นมันเป็นการตัดสินใจที่เสี่ยง

ฉันกำลังพยายามคิดหาวิธีที่จะจ่ายให้กับรายการ IP ที่อนุญาตเพราะนั่นเป็นความเจ็บปวดในการจัดการ;) โดยไม่ต้องใช้ OAuth แบบเต็มเป่า ฉันจะทำก๋วยเตี๋ยว