การพลาดเช็คที่อาจทำให้คุณเสียค่าใช้จ่าย: Requests.get และแบบฟอร์มขออนุมัติจาก Flask
ลองนึกภาพดู: นักพัฒนาซอฟต์แวร์ระดับจูเนียร์กำลังทำงานภายใต้ความกดดันเพื่อส่งมอบฟีเจอร์ใหม่ พวกเขาเปิดแอป Flask เพิ่มเส้นทางใหม่ ดึงพารามิเตอร์การค้นหา แล้วก็ไปต่อ
มองเผินๆ การใช้งาน Flask request นี้ดูเหมือนจะไม่มีปัญหา แต่ให้ละเว้น ประเภท = จำนวนเต็ม และคุณเปิดประตูเข้าไป การโจมตีแบบฉีดเข้าเส้นเลือด นี่คือความเสี่ยงประเภทที่มักหลุดรอดการตรวจสอบโค้ดไปได้ เพราะคิดว่า "มันก็แค่การดึงค่ามาเท่านั้น"
ความเสี่ยงซ่อนอยู่ที่ไหน Fคำขอ lask และ Fแบบฟอร์มขอข้อมูล
ทั้งสอง แฟลสค์.รีเควสต์ และ แบบฟอร์มขอ Flask เป็นจุดเข้าใช้งานที่ไม่น่าเชื่อถือ ค่าทุกค่าที่ส่งกลับมานั้นมาจากฝั่งไคลเอ็นต์โดยตรง และควรได้รับการพิจารณาว่าเป็นสิ่งที่อาจเป็นอันตรายได้
การไม่ตรวจสอบความถูกต้องหรือกรองข้อมูลนี้อาจนำไปสู่ปัญหาด้านความปลอดภัยที่ร้ายแรง รวมถึง:
ความเสี่ยงเหล่านี้ไม่ได้จำกัดอยู่แค่ฐานข้อมูลหรือการแสดงผลส่วนหน้าเท่านั้น ผู้โจมตีอาจใช้ประโยชน์จากข้อมูลที่ใช้ในเทมเพลตหรือข้อมูลที่ส่งไปยังกระบวนการย่อยได้เช่นกัน
รูปแบบรหัสเทียมที่ปลอดภัย:
ป้องกัน CI/CD การบังคับใช้:
แม้ว่าไวยากรณ์จะดูปลอดภัย แต่การใช้ค่าดิบหรือค่าที่ไม่ได้ตรวจสอบในเทมเพลตหรือคำสั่งระบบอาจกลายเป็นช่องทางโจมตีที่ร้ายแรงได้
กระบวนการฉีดสารแบบปฏิบัติจริง (การจำลองอย่างปลอดภัย)
ต่อไปนี้คือตัวอย่างสถานการณ์จำลองที่ปลอดภัย ซึ่งแสดงให้เห็นถึงข้อบกพร่องในการฉีดโค้ดโดยทั่วไป:
- ผู้ใช้ส่งพารามิเตอร์คำค้นหาที่สร้างขึ้นเองไปยังแอปพลิเคชัน
- แอปจะอ่านค่าโดยใช้ ขออาร์กิวเมนต์.รับ() โดยไม่มีการตรวจสอบความถูกต้อง
- ค่าดังกล่าวจะถูกนำไปต่อเข้ากับคำสั่ง SQL, สตริงแม่แบบ หรือคำสั่งเชลล์โดยตรง
- ระบบจะดำเนินการตามตรรกะนั้น โดยไม่รับรู้ถึงเนื้อหาที่ถูกแทรกเข้าไป
รหัสเทียม (ไม่ปลอดภัย ใช้เป็นตัวอย่างเท่านั้น):
บันทึกการทำงานสมมติ:
แม้ว่าตัวอย่างนี้จะใช้ตัวแทน (placeholder) แต่ก็สะท้อนให้เห็นว่าความผิดพลาดเล็กน้อยในการจัดการข้อมูลนำเข้าอาจนำไปสู่ช่องโหว่ที่ร้ายแรงได้อย่างไร
การทดสอบอัตโนมัติอาจพลาดจุดนี้ไป เพราะโดยปกติแล้วจะทดสอบเฉพาะประเภทข้อมูลขาเข้าที่ถูกต้อง ไม่ใช่ประเภทข้อมูลที่ผิดรูปหรือเป็นอันตราย
ความเสี่ยงที่ซ่อนอยู่ในการพึ่งพาอาศัยกันโดยใช้ คำขอขวด และ แบบฟอร์มขอรับขวด
โค้ดของคุณอาจดูสะอาดตา แต่แพ็กเกจจากภายนอกก็อาจทำให้เกิดปัญหาได้
ปลั๊กอินหรือไลบรารีบางตัวของ Flask เรียกใช้คำสั่ง `flask request` หรือ `flask request form` ภายในโดยไม่มีการตรวจสอบความถูกต้อง
ตัวอย่างการใช้แพ็กเกจสมมติ:
In CI/CDการอัปเดตการพึ่งพาอัตโนมัติอาจทำให้เกิดการเรียกใช้ requests.get ที่ไม่ปลอดภัย หรือรูปแบบการจัดการอินพุตที่เสี่ยงต่อช่องโหว่โดยไม่รู้ตัว
ไม่ปลอดภัยแค่ไหน คำขอขวด การใช้งานหลุดรอดการตรวจสอบรหัส
ในสภาพแวดล้อมที่เปลี่ยนแปลงอย่างรวดเร็ว ความผิดพลาดเล็กๆ แต่ร้ายแรงมักจะไม่ถูกสังเกต โดยเฉพาะอย่างยิ่งเมื่อการเปลี่ยนแปลงนั้นดูเหมือนจะไม่เป็นอันตราย
ตัวอย่าง pull request ความแตกต่าง:
ความคิดเห็นของผู้รีวิว:
“ดูเหมือนจะไม่มีปัญหาอะไร แค่กำลังหาค่าพารามิเตอร์อยู่”
การมองข้ามในลักษณะนี้เกิดขึ้นได้บ่อยเนื่องจาก:
- อคติทางปัญญาผู้ตรวจสอบอาจสันนิษฐานว่า request.args.get() ปลอดภัยโดยค่าเริ่มต้น
- ความดันเวลาเมื่อใกล้ถึงกำหนดส่งงาน การตรวจสอบความปลอดภัยมักถูกละเลยไป
- ความคุ้นเคยที่แตกต่างกันการเปลี่ยนแปลงดูเล็กน้อย จึงไม่ได้รับการตรวจสอบอย่างละเอียดถี่ถ้วน
หากไม่มีกฎเกณฑ์ที่ชัดเจนหรือระบบบังคับใช้แบบอัตโนมัติ ความเสี่ยงที่แฝงอยู่เหล่านี้ก็จะเล็ดลอดเข้าสู่กระบวนการผลิตโดยไม่ทันสังเกตเห็น
การป้องกันที่ได้ผล
เพื่อลดความเสี่ยงจากการฉีดสารต้องห้าม ควรผสานการตรวจสอบความถูกต้องของข้อมูลขาเข้า การสแกนอัตโนมัติ และความครอบคลุมของการทดสอบเข้าด้วยกัน
การตรวจสอบความถูกต้องของข้อมูลขาเข้าด้วยการแปลงประเภทข้อมูลและการอนุญาตพิเศษ:
การแปลงประเภทข้อมูลจะบังคับให้ค่าเป็นประเภทที่ปลอดภัย ในขณะที่การกำหนดรายการที่อนุญาตจะช่วยให้มั่นใจได้ว่าจะมีเพียงค่าที่ถูกต้องเท่านั้นที่ดำเนินการต่อไปได้
การทดสอบความปลอดภัยของแอปพลิเคชันแบบคงที่ (SAST) เข้า CI/CD:
ขั้นตอนนี้ช่วยในการตรวจจับข้อมูลที่ไม่ได้รับการตรวจสอบ ขออาร์กิวเมนต์.รับ() or ขอแบบฟอร์มคำขอ() มีการโทรติดต่อก่อนที่จะถึงขั้นตอนการผลิต
การทดสอบหน่วยเพื่อบังคับใช้การฆ่าเชื้อ:
การทดสอบเหล่านี้ช่วยให้มั่นใจได้ว่าแอปจะปฏิเสธข้อมูลป้อนเข้าที่ไม่ถูกต้องหรือเป็นอันตรายได้อย่างสม่ำเสมอ
การบูรณาการเข้ากับ DevSecOps Pipelines
การบังคับใช้มิดเดิลแวร์:
@app.before_request
สแกนทั้งโค้ดของคุณและไลบรารีภายนอกที่เกี่ยวข้อง ช่วยตรวจจับการใช้งาน requests.get, flask request และ flask request form ที่ไม่ปลอดภัย ก่อนที่จะนำไปใช้งานจริง
ปัญหานี้ไม่ได้จำกัดอยู่แค่ Flask เท่านั้น
การจัดการข้อมูลเข้าที่ไม่ปลอดภัยไม่ใช่เรื่องเฉพาะของ Flask แต่พบได้ในเฟรมเวิร์กเว็บอื่นๆ โชคดีที่วิธีการแก้ไขนั้นสม่ำเสมอ นั่นคือ ตรวจสอบความถูกต้องของข้อมูลเข้าตั้งแต่เนิ่นๆ และอย่างเข้มงวด
Django (รหัสเทียมที่ปลอดภัย):
FastAPI (ปลอดภัยตั้งแต่เริ่มออกแบบโดยใช้คำแนะนำประเภทข้อมูล):
ตัวอย่างทั้งสองบังคับใช้ประเภทและช่วงของข้อมูลขาเข้า เพื่อให้มั่นใจว่าข้อมูลที่เข้ามานั้นเชื่อถือได้ก่อนที่จะเข้าสู่ส่วนตรรกะที่ละเอียดอ่อน
ไม่ว่าจะเป็น Flask, Django หรือ FastAPI พารามิเตอร์คำขอทุกตัวล้วนเป็นจุดที่อาจเกิดการโจมตีได้ หากไม่ได้รับการตรวจสอบอย่างเหมาะสม
การใช้งาน Xygeni สำหรับการตรวจจับใน DevSecOps
ในสภาพแวดล้อม DevSecOps การตรวจสอบด้วยตนเองอย่างเดียวไม่เพียงพอ ไซเกนี ระบบจะตรวจจับคำขอ Flask ที่ไม่ปลอดภัย แบบฟอร์มคำขอ Flask และการใช้งาน requests.get โดยอัตโนมัติ
การประยุกต์ใช้ DevSecOps ในทางปฏิบัติ:
- การสแกนแบบคงที่: ตั้งค่าสถานะใดๆ ขออาร์กิวเมนต์.รับ() ไม่มี พิมพ์ =และการเรียกใช้แบบฟอร์มคำขอ Flask ที่ขาดการตรวจสอบความถูกต้อง
- การวิเคราะห์การพึ่งพา: ตรวจสอบไลบรารีเพื่อหารูปแบบที่ไม่ปลอดภัยซึ่งอาจปรากฏขึ้นผ่านการเรียกใช้ทางอ้อม
- การบล็อกการผสานที่ไม่ปลอดภัย: CI/CD ล้มเหลวหากโค้ดใหม่นำคำขอ requests.get ที่มีความเสี่ยงหรือการเข้าถึงฟอร์มที่ไม่ได้รับการตรวจสอบมาใช้
- การบังคับใช้ขั้นพื้นฐาน: ติดตามการเปลี่ยนแปลงเพื่อป้องกันไม่ให้การโทรที่ปลอดภัยกลายเป็นการโทรที่ไม่ปลอดภัย
การทำให้การตรวจสอบเหล่านี้เป็นไปโดยอัตโนมัติจะช่วยลดความเสี่ยงจากข้อผิดพลาดของมนุษย์ และ รักษาความปลอดภัยอย่างต่อเนื่องโดยไม่ทำให้การส่งมอบล่าช้า
ดังนั้น ตรวจสอบความถูกต้อง ทำความสะอาด และทำให้เป็นระบบอัตโนมัติ
สรุปได้ว่า requests.get, flask request และ flask request form ล้วนเป็น... โดยค่าเริ่มต้นจะไม่น่าเชื่อถือพวกเขาจะส่งข้อมูลที่เป็นอันตรายมาให้คุณอย่างแน่นอน เว้นแต่คุณจะดำเนินการใดๆ
กฎสามข้อของคุณ:
- ตรวจสอบ การป้อนข้อมูลโดยใช้การแคสติ้งและไวท์ลิสต์
- sanitize ก่อนที่ข้อมูลจะเข้าสู่การดำเนินการที่ละเอียดอ่อน
- โดยอัตโนมัติ ตรวจสอบในของคุณ pipeline เพื่อหยุดการทำงานของโค้ดที่ไม่ปลอดภัยก่อนการใช้งานจริง
ข้อผิดพลาดเพียงเล็กน้อย เช่น ตัวจัดการคำขอ Flask ที่ไม่ปลอดภัย ฟิลด์แบบฟอร์มคำขอ Flask ที่ไม่ได้ตรวจสอบ หรือการเรียกใช้ requests.get ที่ไม่มีการป้องกัน ก็อาจทำให้แอปพลิเคชันของคุณถูกโจมตีได้ ควรพิจารณาพารามิเตอร์ทุกตัวว่าอาจเป็นอันตราย และให้ทีม DevSecOps ของคุณจัดการ pipeline บังคับใช้กฎทุกครั้ง
