เผยแพร่ครั้งแรกเมื่อวันที่ 5 มีนาคม 2019
หากคุณเป็นนักพัฒนาแอปพลิเคชัน ผู้ดูแลระบบฐานข้อมูล (DBA) หรือผู้เชี่ยวชาญด้านเทคโนโลยีใดๆ การใส่โค้ดควรอยู่ในเรดาร์ของคุณ
คุณมีสภาพแวดล้อมระบบคลาวด์ที่ปลอดภัย คุณมีการเข้าถึงฐานข้อมูลถูกล็อค แล้วรหัสแอปพลิเคชันของคุณล่ะ แม้ว่าจะถือว่าปลอดภัยกว่า แต่ ไม่ ใน NoSQLi ไม่ได้หมายความว่าไม่สามารถฉีดได้! NoSQL อาจไวต่อการแทรกโค้ดเหมือนกับโค้ดฐานข้อมูลอื่นๆ การไม่ป้องกันการฉีดโค้ดก็เหมือนกับการมีระบบรักษาความปลอดภัยสำหรับประตูและเปิดหน้าต่างด้านหลังทิ้งไว้
การแทรกโค้ดคืออะไร
การแทรกโค้ดเป็นเพียงข้อมูลที่ ถูกฉีด . ที่ไม่ผ่านการตรวจสอบ (หรือเพิ่มเติม) ลงในโปรแกรมที่มีช่องโหว่ซึ่งทำงานในรูปแบบของรหัสแอปพลิเคชัน ซึ่งมักจะนำไปสู่ผลลัพธ์ที่เลวร้าย
SQLi เป็นหนึ่งในประเภทการฉีดที่พบบ่อยที่สุด และในวัยกว่าทศวรรษก็ยังคงมีความแข็งแกร่ง ปัญหาการแทรกไม่ได้เฉพาะกับภาษาฐานข้อมูลเท่านั้น นอกเหนือจาก SQL และ NoSQL แล้ว การฉีดสามารถเกิดขึ้นได้ใน XPath®, XML Parsers, ส่วนหัวของ SMTP และบริบทอื่นๆ เมื่อความรุนแรงดำเนินไป การฉีดโค้ดก็คล้ายกับการเรียกใช้โค้ดจากระยะไกล (RCE)—theGame Over หน้าจอทดสอบการเจาะ
การตรวจจับและป้องกัน NoSQLi ในแอปพลิเคชันของคุณเป็นสิ่งสำคัญ การอนุญาตให้ใช้เวคเตอร์การฉีดแบบไม่ลดทอนสามารถคุกคามความปลอดภัยของฐานผู้ใช้ของคุณ ซึ่งแสดงถึงการสูญเสียความไว้วางใจทางธุรกิจที่อาจเกิดขึ้นได้ โชคดีที่หลังจากที่คุณเข้าใจกลไกของธีมแล้ว คุณสามารถทำตามขั้นตอนที่เป็นรูปธรรมในการตรวจจับและป้องกันช่องโหว่ของ NoSQLi ในบริการของคุณได้
ตัวอย่าง NoSQLi อย่างง่าย
โดยทั่วไป MongoDB® นำเข้าข้อมูล Binary JSON (BSON) ที่สร้างโดยใช้เครื่องมือสร้างแบบสอบถาม BSON ที่ปลอดภัย แต่ในบางกรณี MongoDB ยังสามารถยอมรับนิพจน์ JSON และ Javascript (JS) ที่ไม่ซีเรียลไลซ์ได้ เช่น $where โอเปอเรเตอร์ เช่นเดียวกับ SQL $where ผู้ปฏิบัติงานมีแนวโน้มที่จะฉีด NoSQL ที่อาจเกิดขึ้น อย่างไรก็ตาม ไม่เหมือนกับใน SQL NoSQL $where แสดงเงื่อนไขใน JS ซึ่งหมายความว่าสามารถใช้พลังการแสดงเต็มที่ของ JS เพื่อสร้างคิวรีแบบฉีดที่เป็นไปได้ แทนที่จะจำกัดเฉพาะสิ่งที่ SQL มีให้
การดูรายการสตริงการแทรก MongoDB ในที่เก็บข้อมูลสาธารณะ เช่น รายการนี้แสดงให้เห็นถึงกลยุทธ์การฉีดทั่วไป ซึ่งเทียบเคียงกับช่องโหว่ที่คล้ายกันใน SQL และภาษาอื่นๆ ตัวอย่างเช่น บางส่วนใช้ 1 == 1 แบบคลาสสิก นิพจน์เพื่อบังคับให้การสืบค้นกลับค่าที่แท้จริงในความพยายามที่จะอ่านทรัพยากรและสิทธิพิเศษที่ซ่อนไว้ (หรือระดับผู้ดูแลระบบ):
$Where: '1 == 1'
ตัวอย่างอื่นๆ จำลองกลยุทธ์การฉีดคนตาบอดโดยใช้sleep() ฟังก์ชันเพื่อชะลอ DB และสร้างผลข้างเคียงที่ร่วมกับตัวกรองที่ออกแบบมาอย่างชาญฉลาด สามารถระบุข้อมูลที่ละเอียดอ่อนได้:
';sleep(5000); ';it=new%20Date();do{pt=new%20Date();}while(pt-it<5000);
และแน่นอนว่ามีการขโมยข้อมูลแบบเก่า ซึ่งคำค้นหาที่ฉีดเข้าไปนั้นพยายามจับคู่และดึงข้อมูลที่สำคัญโดยตรง
' && this.password.match(/.*/)//+%00
หลังจากตัวอย่างแรก อีกสองตัวที่เหลือไม่ใช้ $where โอเปอเรเตอร์ คุณไม่จำเป็นต้องมี JS-flavoredexpression ที่มีประโยชน์เป็นพื้นฐานในการโจมตี NoSQL DB
การป้องกัน NoSQLi
มีกลยุทธ์ทั่วไปหลายประการที่ต้องทำเมื่อพยายามสร้างสถาปัตยกรรมแอปพลิเคชันที่ทนต่อ NoSQLi ไม่แปลกใจเลยที่พวกเขาปฏิบัติตามคำแนะนำในการต่อต้านการฉีดทั่วไป
MongoDB / NoSQLi ก็ไม่มีข้อยกเว้น
บางคนมองว่าการแทรกโค้ดเป็นแบบเฉพาะของ SQL และประเมินความถูกต้องของหลักการการฉีดที่ใช้กับบริบทอื่นๆ ต่ำไป หวังว่าโพสต์นี้จะทำให้คุณมั่นใจว่า NoSQLi คือ จริง. มีการบันทึกไว้อย่างดีในโพสต์ที่คล้ายกับ MongoDB จะไม่ป้องกันการแทรก NoSQL ในแอป Node.js ของคุณ
อย่าเชื่อถือข้อมูลผู้ใช้ที่ไม่ผ่านการตรวจสอบ
ด้วยเหตุผลด้านความปลอดภัย คุณไม่ควรเชื่อถือผู้ใช้!
สิ่งนี้อาจดูเหมือนเป็นความคิดที่เบื่อหูในการรักษาความปลอดภัย แต่คาดว่าทุกข้อมูลที่ป้อนจะถูกตรวจสอบด้วยเจตนาร้าย $whereของเรา ตัวอย่างก่อนหน้านี้แสดงให้เห็นอย่างชัดเจนว่าเหตุใดเราไม่สามารถทำบางสิ่งตาม $where: unvalidated_input —เราอาจคิดว่าเรากำลังเปิดเผยตัวกรองต่อผู้ใช้ ณ จุดนี้ (แย่พอแล้ว!) ความจริงที่ว่าผู้ใช้กำลังแนะนำข้อมูลที่ไม่ผ่านการตรวจสอบลงในข้อความค้นหาที่มีขนาดใหญ่กว่านั้นยังห่างไกลจากแนวทางปฏิบัติที่ดีที่สุด
โปรดระวังภาษาหรือลักษณะเฉพาะของการผสานรวม
แม้ว่า NoSQLi จะไม่พิเศษเมื่อพูดถึงภูมิคุ้มกันต่อการฉีด (และทนทุกข์ทรมานจากการโจมตีประเภทเดียวกันหลายประเภท) นั่นไม่ได้หมายความว่าไม่มีกลยุทธ์เฉพาะสำหรับ NoSQLi หรือแม้แต่ภาษาหรือส่วนประกอบ สร้างขึ้นบน aNoSQL DB ตัวอย่างที่ชัดเจนคือตั้งแต่ $where ถูกจัดรูปแบบในลักษณะที่ส่งผ่านเป็นตัวแปร PHP ฐานข้อมูล NoSQL ที่สร้างขึ้นบนแอปพลิเคชัน PHP ต้องคำนึงถึงสิ่งนี้และสถานการณ์ที่เป็นไปได้ของการฉีดสตริงที่เป็นอันตรายซึ่งจัดเก็บไว้ใน $where .
บทสรุป
อีกครั้ง ไม่ ใน NoSQLi ไม่ได้หมายความว่าไม่สามารถฉีดได้! NoSQL ซึ่งคล้ายกับ SQL, ส่วนหัว SMTP, XML และบริบทอื่น ๆ นั้นไวต่อการแทรกโค้ดและข้อผิดพลาดทั่วไปในการปฏิบัติต่อสิ่งต่างๆ เสมือนแอปพลิเคชันโค้ดที่ไม่ได้เป็นแอปพลิเคชันโค้ดที่ทำให้เกิดปัญหากับเทคโนโลยีอื่นๆ มากมาย
หวังว่าโพสต์นี้จะช่วยให้คุณเข้าใจ NoSQLi มากขึ้นและมีความหมายต่อธุรกิจของคุณอย่างไร ตอนนี้คุณสามารถนำโค้ดของคุณไปสู่กระบวนการที่ทำให้แพร่หลายน้อยลง แพร่หลายน้อยลง และมีผลกระทบน้อยลง หากคุณต้องการคำแนะนำการจัดการ MongoDB เพื่อให้แน่ใจว่าแอปและสภาพแวดล้อมการโฮสต์ของคุณปลอดภัย Rackspace ObjectRocket มีประสบการณ์ DBA ที่สามารถช่วยได้
เรียนรู้เพิ่มเติมเกี่ยวกับ Rackspace DBA Services
ใช้แท็บคำติชมเพื่อแสดงความคิดเห็นหรือถามคำถาม คุณยังสามารถคลิกแชทขาย เพื่อแชทตอนนี้และเริ่มการสนทนา
