การพึ่งพาการสืบค้นแบบ Parametrized เป็นวิธีเดียวที่จะป้องกันการฉีด SQL หรือไม่

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

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

1. ไม่มีไคลเอ็นต์ / แอปพลิเคชันเข้าถึงตารางฐานข้อมูลโดยตรง
2. การเข้าถึงตารางทั้งหมดทั้งหมดผ่านมุมมอง (และการอัปเดตทั้งหมดไปยังตารางฐานถูกทำผ่านทริกเกอร์)
3. รายการข้อมูลทั้งหมดมีโดเมนที่ระบุ
4. ไม่มีรายการข้อมูลที่ได้รับอนุญาตให้เป็นโมฆะ - นี่เป็นนัยที่ DBAs บดฟันของพวกเขาในบางครั้ง; แต่ถูกบังคับใช้
5. บทบาทและการอนุญาตได้รับการตั้งค่าอย่างเหมาะสม - ตัวอย่างเช่นบทบาทที่ถูก จำกัด ให้สิทธิ์ในการดูข้อมูลเท่านั้น

ดังนั้นชุดของกฎ (บังคับ) เช่นนี้ (แม้ว่าไม่จำเป็นต้องเป็นชุดนี้โดยเฉพาะ) เป็นทางเลือกที่เหมาะสมในการค้นหาแบบ parametrized ในการป้องกันการโจมตี SQL injection? ถ้าไม่ทำไมล่ะ สามารถรักษาความปลอดภัยฐานข้อมูลจากการโจมตีดังกล่าวด้วยฐานข้อมูล (เฉพาะ) มาตรการเฉพาะได้หรือไม่?

แก้ไข

การเน้นของคำถามเปลี่ยนไปเล็กน้อยในแง่ของการตอบสนองเริ่มต้นที่ได้รับ คำถามพื้นฐานไม่เปลี่ยนแปลง

EDIT2

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

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

http://database-programmer.blogspot.com

http://thehelsinkideclaration.blogspot.com

คุณสมบัติหลักที่ฉันนำมาจากแหล่งข้อมูลเหล่านี้คือ:

1. พจนานุกรมข้อมูลที่กว้างขวางผนวกกับพจนานุกรมข้อมูลความปลอดภัยที่ครอบคลุม
2. การสร้างทริกเกอร์แบบสอบถามและข้อ จำกัด จากพจนานุกรมข้อมูล
3. ย่อเล็กสุดรหัสและเพิ่มข้อมูล

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

Procs ที่เก็บไว้จะไม่ป้องกันการฉีดโดยอัตโนมัติ เกี่ยวกับสิ่งนี้

CREATE PROC proc
  @id VARCHAR(5)
AS
BEGIN
  EXEC("SELECT * FROM Client WHERE ClientId = " + @id);
END

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

ดังนั้นชุดของกฎ (บังคับใช้) เช่นนี้เป็นทางเลือกที่เหมาะสมในการจัดเก็บในการป้องกันการโจมตี SQL injection หรือไม่ ถ้าไม่ทำไมล่ะ

ไม่เพราะพวกเขาทำดาเมจค่อนข้างหนักกับนักพัฒนา การแยกย่อยต่อรายการ:

1. ไม่มีไคลเอ็นต์ / แอปพลิเคชันเข้าถึงตารางฐานข้อมูลโดยตรง

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

2. การเข้าถึงตารางทั้งหมดนั้นผ่านมุมมอง

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

3. รายการข้อมูลทั้งหมดมีโดเมนที่ระบุ

อาจเป็นงานที่ต้องดูแลรักษามากมายและอาจจะทำให้เป็นมาตรฐานในตารางแยก

4. ไม่อนุญาตให้รายการข้อมูลใดถูกโมฆะ - สิ่งนี้มีความหมายว่า DBAs บดฟันของพวกเขาในบางโอกาส แต่ถูกบังคับใช้

นั่นเป็นเพียงความผิดธรรมดา หากนักพัฒนาซอฟต์แวร์ไม่สามารถจัดการกับNULLคุณได้คุณจะพบปัญหาใหญ่

สามารถรักษาความปลอดภัยฐานข้อมูลจากการโจมตีดังกล่าวด้วยฐานข้อมูล (เฉพาะ) มาตรการเฉพาะได้หรือไม่?

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

ฉันไม่แน่ใจว่ากฎของคุณปกป้องคุณอย่างสมบูรณ์

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

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

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

(ในแง่ของการอัปเดตทั้งหมดที่ทำผ่านทริกเกอร์ฉันจะพูดสองสิ่ง: (1) เมื่อฉันอ่านสิ่งนี้ฉันรู้สึกป่วยเล็กน้อยในปากและ (b) คุณไม่ชอบวิธีการจัดเก็บเพราะ ' re "บำรุงรักษาได้น้อยลงทดสอบได้น้อยกว่าเชื่อมโยงกันอย่างมากและล็อคระบบไว้ในผู้ขายรายเดียว" แต่คุณใช้ทริกเกอร์ซึ่งสิ่งเดียวกันสามารถพูดได้โดยทั่วไป)

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

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

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