คุณควรป้องกันค่าที่ไม่คาดคิดจาก API ภายนอกหรือไม่

ช่วยบอกว่าคุณมีการเข้ารหัสฟังก์ชั่นที่ต้องใช้ข้อมูลจาก MyAPIAPI ที่ภายนอก

ที่ภายนอก API MyAPIมีสัญญาที่ระบุว่ามันจะกลับมาได้หรือstringnumber

มันคือการแนะนำเพื่อป้องกันสิ่งที่ชอบnull, undefined, booleanฯลฯ แม้ว่ามันจะไม่ได้เป็นส่วนหนึ่งของ API ของMyAPI? โดยเฉพาะอย่างยิ่งเนื่องจากคุณไม่สามารถควบคุม API นั้นคุณไม่สามารถรับประกันผ่านการวิเคราะห์ประเภทแบบคงที่ดังนั้นจะปลอดภัยกว่าขออภัยหรือไม่

ฉันกำลังคิดเกี่ยวกับหลักการความแข็งแกร่ง

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

การไม่ทำเช่นนั้นจะทำให้คุณมีข้อมูลขยะที่ดีที่สุดที่คุณต้องทำความสะอาดในภายหลัง แต่ที่แย่ที่สุดคุณจะทิ้งโอกาสในการหาช่องโหว่ที่เป็นอันตรายหากบริการอัปสตรีมได้รับการโจมตีในบางลักษณะ (qv the Target hack) ช่วงของปัญหาระหว่างนั้นรวมถึงการทำให้แอปพลิเคชันของคุณอยู่ในสภาพที่ไม่สามารถกู้คืนได้

จากความคิดเห็นที่ฉันเห็นว่าบางทีคำตอบของฉันอาจใช้การขยายตัวเล็กน้อย

โดย "ไม่ไว้วางใจอินพุต" หมายความว่าคุณไม่สามารถสันนิษฐานได้ว่าคุณจะได้รับข้อมูลที่ถูกต้องและเชื่อถือได้จากระบบต้นน้ำหรือปลายน้ำเสมอและดังนั้นคุณควรจะฆ่าเชื้ออินพุตนั้นให้ดีที่สุดเท่าที่จะทำได้หรือปฏิเสธ มัน.

มีการโต้แย้งหนึ่งเรื่องในความคิดเห็นที่ฉันจะกล่าวถึงในตัวอย่าง ในขณะที่ใช่คุณต้องเชื่อใจระบบปฏิบัติการของคุณในระดับหนึ่ง แต่ก็ไม่มีเหตุผลที่จะปฏิเสธผลของตัวสร้างตัวเลขสุ่มหากคุณขอตัวเลขระหว่าง 1 ถึง 10 และตอบกลับด้วย "bob"

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

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

ใช่แน่นอน แต่อะไรทำให้คุณคิดว่าคำตอบอาจแตกต่างกันไป

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

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

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

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

The Robustness Principle - โดยเฉพาะอย่างยิ่ง "จงใจกว้างในสิ่งที่คุณยอมรับ" ครึ่งหนึ่งของแนวคิด - เป็นแนวคิดที่ไม่ดีอย่างมากในซอฟต์แวร์ เดิมได้รับการพัฒนาในบริบทของฮาร์ดแวร์ซึ่งข้อ จำกัด ทางกายภาพทำให้ความคลาดเคลื่อนทางวิศวกรรมมีความสำคัญมาก แต่ในซอฟต์แวร์เมื่อมีคนส่งข้อมูลที่ไม่ถูกต้องหรือมีรูปแบบที่ไม่เหมาะสมเข้ามาคุณมีสองทางเลือก คุณสามารถปฏิเสธมันได้ (ควรอธิบายด้วยสิ่งที่ผิดพลาด) หรือคุณสามารถลองคิดดูว่ามันควรจะหมายถึงอะไร

แก้ไข:ปรากฎว่าฉันถูกเข้าใจผิดในคำสั่งข้างต้น ทนทานหลักการไม่ได้มาจากโลกของฮาร์ดแวร์ แต่จากสถาปัตยกรรมอินเทอร์เน็ตโดยเฉพาะRFC 1958 มันระบุว่า:

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

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

ดูที่กระดาษ IETF ผลที่เป็นอันตรายของหลักการความทนทานสำหรับรายละเอียดเพิ่มเติมในประเด็นนี้

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

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

นี่คือเหตุผลที่มีหลักการล้มเหลวที่รวดเร็ว; บันทึกทุกคนที่เกี่ยวข้องกับอาการปวดหัวด้วยการใช้กับ API ของคุณ

โดยทั่วไปรหัสควรถูกสร้างขึ้นเพื่อรักษาข้อ จำกัด ต่อไปนี้อย่างน้อยทุกครั้งที่ใช้งานได้จริง:

1. เมื่อรับอินพุตที่ถูกต้องให้สร้างเอาต์พุตที่ถูกต้อง

2. เมื่อได้รับอินพุตที่ถูกต้อง (ที่อาจหรืออาจไม่ถูกต้อง) ให้สร้างเอาต์พุตที่ถูกต้อง (เช่นเดียวกัน)

3. เมื่อได้รับการป้อนข้อมูลที่ไม่ถูกต้องให้ดำเนินการโดยไม่มีผลข้างเคียงใด ๆ นอกเหนือจากที่เกิดจากการป้อนข้อมูลปกติหรือที่กำหนดไว้เป็นการส่งสัญญาณข้อผิดพลาด

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

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

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

ลองเปรียบเทียบทั้งสองสถานการณ์และลองสรุป

สถานการณ์ 1 ใบสมัครของเราถือว่า API ภายนอกจะทำงานตามข้อตกลง

สถานการณ์ที่ 2 แอปพลิเคชันของเราถือว่า API ภายนอกสามารถทำงานผิดปกติได้ดังนั้นจึงเพิ่มข้อควรระวัง

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

หากโปรแกรมของเราเขียนขึ้นโดยสมมติว่า API ภายนอกจะปฏิบัติตามข้อตกลงและหลีกเลี่ยงการเพิ่มข้อควรระวังใด ๆ ใครจะเป็นฝ่ายเผชิญปัญหา มันจะเป็นเราคนที่ได้เขียนรหัสบูรณาการ

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

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

คุณควรตรวจสอบข้อมูลที่เข้ามา - ผู้ใช้ป้อนหรืออื่น ๆ - ดังนั้นคุณควรมีกระบวนการในการจัดการเมื่อข้อมูลที่ดึงมาจาก API ภายนอกนี้ไม่ถูกต้อง

โดยทั่วไปแล้วรอยต่อใด ๆ ที่พบกับระบบเสริมพิเศษต้องมีการรับรองความถูกต้องการอนุญาต (ถ้าไม่ได้กำหนดโดยการพิสูจน์ตัวตน) และการตรวจสอบความถูกต้อง

โดยทั่วไปแล้วคุณต้องป้องกันอินพุตที่มีข้อบกพร่องเสมอ แต่ขึ้นอยู่กับชนิดของ API "Guard" หมายถึงสิ่งต่าง ๆ

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

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

หากต้องการให้ความเห็นที่แตกต่างออกไปเล็กน้อย: ฉันคิดว่าเป็นที่ยอมรับได้เพียงแค่ทำงานกับข้อมูลที่คุณได้รับแม้ว่ามันจะเป็นการละเมิดสัญญาก็ตาม ขึ้นอยู่กับการใช้งาน: มันเป็นสิ่งที่ต้องเป็นสตริงสำหรับคุณหรือเป็นสิ่งที่คุณเพิ่งแสดง / ไม่ได้ใช้ ฯลฯ ในกรณีหลังให้ยอมรับมัน ฉันมี API ซึ่งต้องการเพียง 1% ของข้อมูลที่ส่งโดย API อื่น ฉันไม่สนหรอกว่าข้อมูลประเภทใดที่อยู่ใน 99% ดังนั้นฉันจะไม่ตรวจสอบเลย

จะต้องมีความสมดุลระหว่าง "การมีข้อผิดพลาดเพราะฉันไม่ได้ตรวจสอบอินพุตของฉันเพียงพอ" และ "ฉันปฏิเสธข้อมูลที่ถูกต้องเพราะฉันเข้มงวดเกินไป"

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

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

ข้อยกเว้นสำหรับการทดสอบทุกอย่างในโลกของฉันคือ:

1. ประสิทธิภาพหลังจากการวัดประสิทธิภาพอย่างระมัดระวัง:

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

2. เมื่อคุณไม่มีเงื่อนงำจะทำอย่างไรกับข้อผิดพลาด

   • มีหลายครั้งที่ไม่บ่อยนักเมื่อการออกแบบของคุณไม่อนุญาตให้จัดการกับข้อผิดพลาดชนิดที่คุณพบ บางทีสิ่งที่คุณควรทำคือบันทึกข้อผิดพลาด แต่ไม่มีการบันทึกข้อผิดพลาดในระบบ มันเกือบจะเป็นไปได้ที่จะหาวิธีที่จะ "จำ" ข้อผิดพลาดที่ช่วยให้คุณอย่างน้อยในฐานะนักพัฒนาเพื่อตรวจสอบในภายหลัง ตัวนับข้อผิดพลาดเป็นสิ่งที่ดีที่มีในระบบแม้ว่าคุณจะเลือกที่จะไม่มีการบันทึก

วิธีการตรวจสอบค่าอินพุต / คืนอย่างระมัดระวังเป็นคำถามที่สำคัญ ตัวอย่างเช่นถ้ามีการบอกว่า API ส่งคืนสตริงฉันจะตรวจสอบว่า:

• ชนิดข้อมูล actully เป็นสตริง

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

• ควรตรวจสอบสตริงบางตัวสำหรับอักขระหรือเนื้อหา "ผิดกฎหมาย" เมื่อเกี่ยวข้อง หากโปรแกรมของคุณอาจส่งสตริงเพื่อบอกว่าฐานข้อมูลในภายหลังมันเป็นความคิดที่ดีที่จะตรวจสอบการโจมตีฐานข้อมูล (ค้นหาการฉีด SQL) การทดสอบเหล่านี้ทำได้ดีที่สุดในขอบเขตของระบบของฉันซึ่งฉันสามารถระบุตำแหน่งที่การโจมตีมาจากและฉันสามารถล้มเหลวก่อน การทำแบบทดสอบการฉีด SQL แบบเต็มอาจเป็นเรื่องยากเมื่อมีการรวมสตริงเข้าด้วยกันในภายหลังดังนั้นการทดสอบนั้นควรทำก่อนที่จะเรียกฐานข้อมูล

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