ลองใช้ API แบบ จำกัด อัตราของเราเอง

ข้อมูลทั่วไป:

บริษัท ของฉันได้พัฒนา API แบบ จำกัด อัตรา เป้าหมายของเราคือสองเท่า:

• ตอบ: สร้างระบบนิเวศของนักพัฒนาที่แข็งแกร่งรอบ ๆ ผลิตภัณฑ์ของเรา
• B: แสดงให้เห็นถึงพลังของ API ของเราโดยใช้เพื่อขับเคลื่อนแอปพลิเคชันของเราเอง

คำชี้แจง: ทำไมต้อง จำกัด อัตราเลย?

เราให้คะแนน API ของเรา จำกัด เนื่องจากเราขายเป็นส่วนเสริมให้กับผลิตภัณฑ์ของเรา การเข้าถึง API ของเราแบบไม่ระบุตัวตนมีเกณฑ์ต่ำมากสำหรับการเรียก API ต่อชั่วโมงในขณะที่ลูกค้าแบบชำระเงินของเราได้รับอนุญาตให้โทรได้มากกว่า 1,000 ครั้งต่อชั่วโมงขึ้นไป

ปัญหา:

API แบบ จำกัด อัตราของเรานั้นยอดเยี่ยมสำหรับอีโคซิสเต็มของนักพัฒนา แต่เพื่อให้เราลองใช้เราไม่สามารถอนุญาตให้ จำกัด การ จำกัด อัตราเดียวกันได้ ส่วนหน้าของ API ของเราคือ JavaScript ทั้งหมดทำการเรียก Ajax โดยตรงไปยัง API

ดังนั้นคำถามคือ:

คุณจะรักษาความปลอดภัย API ได้อย่างไรเพื่อให้สามารถลบการ จำกัด อัตราได้โดยที่ในกระบวนการลบการ จำกัด อัตราดังกล่าวไม่สามารถปลอมแปลงได้ง่าย?

โซลูชันที่สำรวจ (และเหตุใดจึงไม่ได้ผล)

1. ตรวจสอบผู้อ้างอิงกับส่วนหัวของโฮสต์ - มีข้อบกพร่องเนื่องจากผู้อ้างอิงถูกแกล้งได้ง่าย

2. ใช้HMACเพื่อสร้างลายเซ็นตามคำขอและความลับที่แชร์จากนั้นตรวจสอบคำขอบนเซิร์ฟเวอร์ - มีข้อบกพร่องเนื่องจากความลับและอัลกอริทึมสามารถกำหนดได้ง่ายโดยดูที่ JavaScript ส่วนหน้า

3. พร็อกซีคำขอและลงนามในคำขอในพร็อกซี - ยังคงมีข้อบกพร่องเนื่องจากพร็อกซีเองเปิดเผย API

คำถาม:

ฉันต้องการความคิดที่ยอดเยี่ยมใน Stack Overflow เพื่อนำเสนอโซลูชันอื่น คุณจะแก้ปัญหานี้อย่างไร?

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

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

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

หากสิ่งนี้ทำให้คุณเกิดปัญหาก็จะทำให้ระบบนิเวศของนักพัฒนาซอฟต์แวร์ของคุณมีปัญหา (เช่นเมื่อพวกเขาพยายามพัฒนา UI ทางเลือกอื่น) หากคุณกำลังกินอาหารสุนัขของคุณเองจริงๆให้ API (และการ จำกัด อัตรา) ใช้ได้กับแอปพลิเคชันของคุณ คำแนะนำบางประการมีดังนี้

• อย่า จำกัด อัตราตามที่อยู่ IP แต่ จำกัด อัตราโดยสิ่งที่เกี่ยวข้องกับผู้ใช้เช่น ID ผู้ใช้ของพวกเขา ใช้การ จำกัด อัตราในขั้นตอนการรับรองความถูกต้อง

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

• ออกแบบเว็บแอปของคุณด้วยข้อ จำกัด เดียวกันกับที่คุณคาดหวังว่าระบบนิเวศของนักพัฒนาของคุณจะมีนั่นคือตรวจสอบให้แน่ใจว่าคุณสามารถออกแบบได้ภายในอัตราการควบคุมที่เหมาะสม

• ตรวจสอบให้แน่ใจว่าส่วนหลังของคุณสามารถปรับขนาดได้ (ควรเป็นแนวนอน) ดังนั้นคุณไม่จำเป็นต้องกำหนดให้มีการควบคุมปริมาณที่ระดับต่ำจนทำให้เกิดปัญหากับ UI

• ตรวจสอบให้แน่ใจว่าการควบคุมปริมาณของคุณมีความสามารถในการรับมือกับการระเบิดรวมทั้ง จำกัด การละเมิดในระยะยาว

• ตรวจสอบให้แน่ใจว่าการควบคุมปริมาณของคุณดำเนินการอย่างสมเหตุสมผลโดยปรับให้เหมาะกับการละเมิดที่คุณต้องการนำออก ตัวอย่างเช่นพิจารณาการเข้าคิวหรือชะลอผู้ใช้ที่ไม่เหมาะสมแทนที่จะปฏิเสธการเชื่อมต่อ ส่วนหน้าของเว็บส่วนใหญ่จะเปิดการเชื่อมต่อพร้อมกันสี่ครั้งเท่านั้น หากคุณชะลอความพยายามในการเปิดหนึ่งในห้าคุณจะเข้าสู่กรณีที่พวกเขาใช้ CLI พร้อมกันกับเว็บไคลเอ็นต์เท่านั้น (บนเว็บไคลเอ็นต์สองตัว) หากคุณชะลอการเรียก n-th API โดยไม่มีช่องว่างแทนที่จะล้มเหลวผู้ใช้ปลายทางจะเห็นว่าสิ่งต่างๆช้าลงแทนที่จะหยุดพัก หากคุณรวมสิ่งนี้เข้ากับการเรียก N API ที่เข้าคิวพร้อมกันเพียงครั้งเดียวคุณจะตีเฉพาะผู้ที่ใช้การเรียก API จำนวนมากแบบขนานซึ่งอาจไม่ใช่พฤติกรรมที่คุณต้องการเช่นการเรียก API พร้อมกัน 100 ครั้งช่องว่างเป็นเวลาหนึ่งชั่วโมงตามปกติ แย่กว่าการเรียก API ตามลำดับ 100 ครั้งในเวลาหนึ่งชั่วโมง

สิ่งนี้ไม่ตอบคำถามของคุณหรือไม่? ถ้าคุณต้องการทำในสิ่งที่คุณต้องการจริงๆให้ จำกัด อัตราในขั้นตอนการรับรองความถูกต้องและใช้การ จำกัด อัตราที่แตกต่างกันตามกลุ่มที่ผู้ใช้ของคุณเหมาะสม หากคุณใช้ข้อมูลรับรองชุดเดียว (ใช้โดยทีม devs และ QA ของคุณ) คุณจะได้รับการ จำกัด อัตราที่สูงขึ้น แต่คุณสามารถเห็นได้ทันทีว่าเหตุใดสิ่งนี้จึงนำคุณไปสู่ระบบนิเวศของคุณอย่างหลีกเลี่ยงไม่ได้เมื่อเห็นปัญหาที่ทีม dev และ QA ของคุณไม่เห็น

ซื้อผลิตภัณฑ์ของคุณ มาเป็นลูกค้าชำระเงินของคุณเอง

"การเข้าถึง API ของเราแบบไม่ระบุตัวตนมีเกณฑ์ต่ำมากสำหรับการเรียก API ต่อชั่วโมงในขณะที่ลูกค้าที่ชำระเงินของเราได้รับอนุญาตให้โทรได้มากกว่า 1,000 ครั้งต่อชั่วโมงขึ้นไป"

นอกจากนี้ยังช่วยทดสอบระบบจากมุมมองของลูกค้า

น่าเสียดายที่ไม่มีโซลูชันที่สมบูรณ์แบบสำหรับสิ่งนี้

โดยทั่วไปวิธีการทั่วไปคือให้ข้อมูลที่ปลอมแปลงได้วิธีสำหรับลูกค้าในการระบุตัวตน (เช่นตัวระบุเวอร์ชันและคีย์ API - เป็นต้น) สำหรับลูกค้าในการลงทะเบียนข้อมูลเกี่ยวกับตัวเองที่สามารถใช้เพื่อ จำกัด การเข้าถึง (เช่นไคลเอนต์เป็นเซิร์ฟเวอร์ในช่วงที่อยู่ IP ที่กำหนด ดังนั้นอนุญาตให้เฉพาะผู้โทรในช่วงนั้นเช่นไคลเอนต์คือ JavaScript แต่ส่งไปยังเบราว์เซอร์หมวดหมู่เฉพาะเท่านั้นดังนั้นอนุญาตให้เข้าถึงคำขอ HTTP ที่ระบุสตริงตัวแทนผู้ใช้บางรายการเท่านั้น ฯลฯ ) จากนั้นจึงใช้การเรียนรู้ของเครื่อง / รูปแบบ การรับรู้เพื่อตรวจจับการใช้งานที่ผิดปกติซึ่งน่าจะเป็นลูกค้าที่ปลอมแปลงแล้วปฏิเสธการรับส่งข้อมูลจากลูกค้าที่ปลอมแปลงเหล่านี้ (หรือยืนยันกับลูกค้าว่าการใช้งานเหล่านี้ไม่ได้มาจากไคลเอนต์ที่ถูกต้องตามกฎหมายแทนที่ข้อมูลรับรองที่ปลอมแปลงได้จากนั้นไม่อนุญาตให้มีการรับส่งข้อมูลเพิ่มเติมโดยใช้รุ่นเก่า ข้อมูลรับรองที่ปลอมแปลง)

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

สมมติว่าแอปที่เป็นปัญหาต้องเปิดแบบสาธารณะคุณไม่มีทางเลือกมากนัก:

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

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

ปรับการ จำกัด อัตราเพื่อให้แอปของคุณทำงานและลงทุนในการเพิ่มประสิทธิภาพเพื่อรองรับการโหลด

และใช่มี API หลักที่ปราศจากการเค้นตั้งแต่แรกและเก็บไว้ในเครือข่ายส่วนตัว เค้นในชั้นที่เข้าถึงได้แบบสาธารณะแยกต่างหาก

คุณสามารถใช้อินสแตนซ์ที่แยกจากกันของ UI และ API ที่ไม่ต้องใช้เค้นแล้ว จำกัด การเข้าถึงที่อยู่ IP ที่มาจากองค์กรของคุณได้หรือไม่

เช่นปรับใช้ทุกอย่างหลังไฟร์วอลล์ขององค์กรของคุณและแนบแอปพลิเคชันเข้ากับฐานข้อมูลเดียวกับอินสแตนซ์ที่เปิดเผยต่อสาธารณะหากคุณต้องการแชร์ข้อมูลระหว่างอินสแตนซ์

คุณสามารถลองสร้างรหัสเซสชันที่ไม่ซ้ำกันโดยผูกไว้กับที่อยู่ IP / ผู้ใช้บางรายและมีเวลา จำกัด ในการใช้งาน เมื่อผู้ใช้ดาวน์โหลดแอปพลิเคชันของคุณโค้ด JavaScript ส่วนหน้าให้ใส่รหัสเซสชันที่สร้างขึ้นในซอร์สโค้ด JavaScript รหัสเซสชันจะแนบไปกับทุกคำขอไปยัง API ของคุณและขีด จำกัด อัตราจะถูกยกเลิก

ไม่สามารถคัดลอก ID เพื่อการปลอมแปลงได้เนื่องจากใช้ได้กับที่อยู่ IP เดียวผู้ใช้และระยะเวลาที่ จำกัด ดังนั้นฝ่ายตรงข้ามจะต้องเรียกเพจของคุณและกรองคีย์ออกจากแหล่ง JavaScript ของคุณหรือจากการสกัดกั้นคำขอ Ajax ทุกครั้งที่ผู้ใช้ใหม่ต้องการใช้

ตัวเลือกอื่น:

ตั้งค่าพร็อกซีสำหรับแอปพลิเคชันของคุณเองและใช้การทำให้สับสน Ajax ร้องขอไปยังพร็อกซีใช้ชื่อที่แตกต่างจากการเรียก API จริงและพร็อกซีจะแปลกลับ ดังนั้นแอปพลิเคชันของคุณจะไม่เรียกgetDocumentใช้ API จริงของคุณ แต่จะเรียกgetFELSUFDSKJEใช้พร็อกซีของคุณ พร็อกซีจะแปลการเรียกนี้กลับไปที่ getDocument และส่งต่อไปยัง API ที่ จำกัด อัตราจริง

API จริงของคุณจะไม่ จำกัด อัตราคำขอโดยพร็อกซี

และเพื่อไม่ให้คนอื่นใช้พร็อกซีของคุณสำหรับแอปพลิเคชันของตนเองคุณจึงเปลี่ยนรูปแบบการทำให้สับสนทุกวัน ชื่อเรียกที่สับสนสามารถสร้างขึ้นโดยอัตโนมัติในซอร์สโค้ด JavaScript ของคุณและกำหนดค่าในพร็อกซี

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

• ที่อยู่ IP ต้นทางในรายการที่อนุญาต
• ใช้VPN , VPN ที่อนุญาตพิเศษสมาชิก
• โซลูชันพร็อกซีหรือส่วนเสริมเบราว์เซอร์ที่เพิ่มส่วนหัว HTTP น่าจะใช้ได้หากคุณสามารถรักษาความปลอดภัยพร็อกซีและไม่กังวลเกี่ยวกับการโจมตีของMITM ที่รบกวนการรับส่งข้อมูล
• วิธีการแก้ปัญหาใด ๆ ที่เกี่ยวข้องกับความลับสามารถลดผลกระทบของการรั่วไหลได้โดยการหมุนเวียนความลับเป็นประจำทุกวัน

ตั้งค่าบัญชีหลายบัญชีและเลือกหนึ่งในนั้นแบบสุ่มตามคำขอทุกครั้งหรือเปลี่ยนบัญชีที่คุณใช้ทุกชั่วโมงหรือมากกว่านั้น ด้วยวิธีนี้คุณสามารถกระจายภาระไปยังnบัญชีต่างๆทำให้คุณnมีขีด จำกัด ที่สูงขึ้นหลายเท่า

ระวังการปิดตัวเองโดยไม่ได้ตั้งใจหากคุณพยายามหาผู้ใช้รายอื่นทำเช่นนี้หากลูกค้าไม่ได้รับอนุญาต