คำถามติดแท็ก sql-injection

7
คุณได้รับการว่าจ้างให้แก้ไขข้อบกพร่องเล็ก ๆ สำหรับไซต์ที่เน้นเรื่องความปลอดภัย ดูที่รหัสนั้นเต็มไปด้วยช่องโหว่ความปลอดภัย คุณทำอะไร? [ปิด]
ฉันได้รับการว่าจ้างจากใครบางคนที่จะทำงานเล็ก ๆ บนเว็บไซต์ มันเป็นเว็บไซต์สำหรับ บริษัท ขนาดใหญ่ มันมีข้อมูลที่ละเอียดอ่อนมากดังนั้นการรักษาความปลอดภัยจึงมีความสำคัญมาก เมื่อวิเคราะห์รหัสฉันพบว่ามันเต็มไปด้วยช่องโหว่ด้านความปลอดภัย - อ่านไฟล์ PHP จำนวนมากที่ส่งผู้ใช้รับ / โพสต์เข้าสู่คำขอ mysql และคำสั่งของระบบโดยตรง ปัญหาคือคนที่สร้างเว็บไซต์ให้เขาเป็นโปรแกรมเมอร์กับครอบครัวและเด็ก ๆ ที่ต้องพึ่งพางานนั้น ฉันไม่สามารถพูดได้ว่า: "เว็บไซต์ของคุณเป็นสวนสนุกตัวเล็กสคริปต์ให้ฉันทำซ้ำสำหรับคุณและคุณจะดี" คุณจะทำอะไรในสถานการณ์นี้ ปรับปรุง: ฉันทำตามคำแนะนำที่ดีที่นี่และรายงานอย่างสุภาพต่อผู้พัฒนาว่าฉันพบข้อบกพร่องด้านความปลอดภัยที่เป็นไปได้ในไซต์ ฉันชี้ให้เห็นสายและบอกว่าอาจมีช่องโหว่ที่เป็นไปได้สำหรับการโจมตีการฉีด SQL ที่นั่นและถามว่าเขารู้เกี่ยวกับเรื่องนี้หรือไม่ เขาตอบว่า: "แน่ใจ แต่ผมคิดว่าการที่จะใช้ประโยชน์จากมันโจมตีควรมีข้อมูลเกี่ยวกับโครงสร้างของฐานข้อมูลนั้นฉันต้องเข้าใจดีกว่า" อัปเดต 2: ฉันบอกว่านั่นไม่ใช่กรณีเสมอไปและแนะนำให้เขาติดตามลิงก์คำถาม Stack Overflow นี้เพื่อจัดการกับมันอย่างถูกต้อง: จะป้องกัน SQL injection ใน PHP ได้อย่างไร? เขาบอกว่าเขาจะศึกษาและขอบคุณฉันที่บอกเขามาก่อน ฉันคิดว่าส่วนของฉันเสร็จแล้วขอบคุณพวกคุณ

14
ทำไมกลไกการป้องกันการฉีด SQL ถึงวิวัฒนาการไปในทิศทางของการใช้คิวรีแบบพารามิเตอร์
วิธีที่ฉันเห็นการโจมตีด้วยการฉีด SQL สามารถป้องกันได้โดย: คัดกรองกรองเข้ารหัสการป้อนข้อมูลอย่างระมัดระวัง (ก่อนแทรกลงใน SQL) การใช้คำสั่งที่เตรียมไว้ / แบบสอบถามแบบใช้พารามิเตอร์ ฉันคิดว่ามีข้อดีข้อเสียสำหรับแต่ละข้อ แต่เหตุใด # 2 จึงถูกถอดออกและได้รับการพิจารณาว่ามีวิธีการป้องกันการฉีดยามากหรือน้อย มันปลอดภัยกว่าและมีแนวโน้มที่จะเกิดข้อผิดพลาดน้อยลงหรือมีปัจจัยอื่น ๆ อีกหรือไม่? ตามที่ฉันเข้าใจถ้าใช้ # 1 อย่างถูกต้องและข้อควรระวังทั้งหมดได้รับการดูแลมันจะมีประสิทธิภาพเท่ากับ # 2 ฆ่าเชื้อโรคกรองและเข้ารหัส มีความสับสนในส่วนของฉันระหว่างสิ่งที่เป็นฆ่าเชื้อ , การกรองและการเข้ารหัสความหมาย ฉันจะบอกว่าสำหรับวัตถุประสงค์ของฉันทั้งหมดข้างต้นสามารถพิจารณาตัวเลือก 1. ในกรณีนี้ผมเข้าใจว่าการฆ่าเชื้อและการกรองมีศักยภาพในการแก้ไขหรือยกเลิกการป้อนข้อมูลในขณะที่การเข้ารหัสจะเก็บรักษาข้อมูลตามที่เป็นแต่ถอดรหัส อย่างถูกต้องเพื่อหลีกเลี่ยงการโจมตีของการฉีด ฉันเชื่อว่าการหลีกเลี่ยงข้อมูลถือได้ว่าเป็นวิธีการเข้ารหัส พารามิเตอร์การสืบค้นเทียบกับการเข้ารหัสห้องสมุด มีคำตอบที่แนวคิดของparameterized queriesและencoding librariesที่ได้รับการปฏิบัติแทนกันได้ แก้ไขฉันถ้าฉันผิด แต่ฉันรู้สึกว่าแตกต่างกัน ความเข้าใจของฉันคือว่าencoding librariesไม่ว่าพวกเขาจะมีศักยภาพในการปรับเปลี่ยน SQL "โปรแกรม" ได้ดีเพียงใดเพราะพวกเขากำลังทำการเปลี่ยนแปลง SQL เองก่อนที่มันจะถูกส่งไปยัง RDBMS Parameterized queries ในอีกทางหนึ่งส่งโปรแกรม SQL …

3
การพึ่งพาการสืบค้นแบบ Parametrized เป็นวิธีเดียวที่จะป้องกันการฉีด SQL หรือไม่
สิ่งที่ฉันได้เห็นจากการโจมตีด้วยการฉีด SQL ดูเหมือนว่าจะแนะนำว่าการสืบค้นแบบ parametrized โดยเฉพาะอย่างยิ่งในขั้นตอนการจัดเก็บเป็นวิธีเดียวที่จะป้องกันการโจมตีดังกล่าว ในขณะที่ฉันกำลังทำงาน (ย้อนกลับไปในยุคมืด) ขั้นตอนการจัดเก็บถูกมองว่าเป็นการปฏิบัติที่ไม่ดีส่วนใหญ่เป็นเพราะพวกเขาเห็นว่าบำรุงรักษาได้น้อยลง ทดสอบได้น้อยลง คู่อย่างมาก และล็อคระบบเป็นผู้ขายรายเดียว ( คำถามนี้ครอบคลุมเหตุผลอื่น ๆ ) แม้ว่าเมื่อฉันกำลังทำงานอยู่โครงการต่าง ๆ แทบไม่รู้ตัวถึงความเป็นไปได้ของการโจมตีดังกล่าว มีการนำกฎต่างๆมาใช้เพื่อรักษาความปลอดภัยของฐานข้อมูลต่อการทุจริตในหลาย ๆ ประเภท กฎเหล่านี้สามารถสรุปได้ดังนี้: ไม่มีไคลเอ็นต์ / แอปพลิเคชันเข้าถึงตารางฐานข้อมูลโดยตรง การเข้าถึงตารางทั้งหมดทั้งหมดผ่านมุมมอง (และการอัปเดตทั้งหมดไปยังตารางฐานถูกทำผ่านทริกเกอร์) รายการข้อมูลทั้งหมดมีโดเมนที่ระบุ ไม่มีรายการข้อมูลที่ได้รับอนุญาตให้เป็นโมฆะ - นี่เป็นนัยที่ DBAs บดฟันของพวกเขาในบางครั้ง; แต่ถูกบังคับใช้ บทบาทและการอนุญาตได้รับการตั้งค่าอย่างเหมาะสม - ตัวอย่างเช่นบทบาทที่ถูก จำกัด ให้สิทธิ์ในการดูข้อมูลเท่านั้น ดังนั้นชุดของกฎ (บังคับ) เช่นนี้ (แม้ว่าไม่จำเป็นต้องเป็นชุดนี้โดยเฉพาะ) เป็นทางเลือกที่เหมาะสมในการค้นหาแบบ parametrized ในการป้องกันการโจมตี SQL injection? ถ้าไม่ทำไมล่ะ สามารถรักษาความปลอดภัยฐานข้อมูลจากการโจมตีดังกล่าวด้วยฐานข้อมูล …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.