ฉันอ่าน / ดูเนื้อหา Robert C. Martin มากมาย ฉันเจอเขาแล้วบอกว่า SQL นั้นไม่จำเป็นเพราะโซลิดสเตตไดรฟ์ เมื่อฉันค้นหาแหล่งข้อมูลอื่น ๆ เพื่อสำรองสิ่งนี้ฉันได้รับบทความสุ่มจำนวนมากที่อธิบายถึงความแตกต่างของประสิทธิภาพการทำงานของ SQL ระหว่างฮาร์ดไดรฟ์และโซลิดสเตทไดรฟ์ (ซึ่งเกี่ยวข้อง แต่ไม่ใช่สิ่งที่ฉันพยายามค้นคว้า)

ท้ายที่สุดฉันไม่เข้าใจสิ่งที่เขาพยายามทำ เขากำลังพูดแทนที่ SQL ด้วยเทคโนโลยี No-SQL หรือไม่ เขาบอกว่าเก็บข้อมูลในไฟล์ในระบบไฟล์หรือไม่? หรือเขาต้องการให้คนหยุดใช้ SQL / ฐานข้อมูลเชิงสัมพันธ์เนื่องจากการโจมตีของ SQLi ฉันกลัวว่าฉันพลาดจุดที่เขาพยายามจะทำ

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

1. Bobby Tables
2. การบรรยายสถาปัตยกรรมที่สะอาด

อันดับแรกเขาระบุว่าควรลบ SQL ออกจากระบบทั้งหมด

การแก้ไขปัญหา. ทางออกเดียว คือการกำจัด SQL ออกจากระบบทั้งหมด หากไม่มีเอ็นจิ้น SQL จะไม่มีการโจมตี SQLi

และแม้ว่าเขาจะพูดถึงการแทนที่ SQL ด้วย API แต่ฉันไม่คิดว่าเขาหมายถึงการวาง SQL ไว้ด้านหลัง API เนื่องจากการอ้างอิงก่อนหน้านั้นและสิ่งที่เขาพูดก่อนหน้านี้ในบทความ

กรอบไม่สามารถจัดการกับปัญหา; ...

ด้านหมายเหตุ: ในการพูด SQL ฉันค่อนข้างมั่นใจว่า Robert หมายถึงฐานข้อมูลเชิงสัมพันธ์ส่วนใหญ่ อาจจะไม่ทั้งหมด แต่ส่วนใหญ่ ไม่ว่าในกรณีใดคนส่วนใหญ่ใช้ SQL อย่างไรก็ตาม ดังนั้น...

ถ้า SQL ไม่ได้ถูกใช้เพื่อเก็บข้อมูลเราก็ควรใช้อะไร?

ก่อนที่จะตอบว่าฉันควรทราบด้วย Robert เน้นว่าไดรฟ์โซลิดสเตทควรเปลี่ยนเครื่องมือที่เราใช้เพื่อคงอยู่ของข้อมูล คำตอบของSøren D. Ptæusชี้ให้เห็นสิ่งนี้

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

ฉันไม่พบคำถามที่ครอบคลุมทั้งหมดนี้ ฉันเดาว่าฉันกำลังมองหาทางเลือกที่ตรงกับแนวทางของโรเบิร์ต Datomic เป็นหนึ่งเดียว แต่มันคืออะไร? ตัวเลือกอื่น ๆ ที่ตรงกับหลักเกณฑ์เหล่านี้? และพวกเขาจะทำงานได้ดีขึ้นกับไดรฟ์สถานะของแข็ง?

บ็อบมาร์ตินพูดเกินจริงอย่างเห็นได้ชัดเพื่อทำให้ประเด็นของเขาชัดเจนยิ่งขึ้น แต่ประเด็นของเขาคืออะไร?

เขาต้องการให้คนหยุดใช้ SQL / ฐานข้อมูลเชิงสัมพันธ์เนื่องจากการโจมตีของ SQLi หรือไม่?

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

SQL เป็นภาษาที่ทรงพลังอย่างยิ่งและเป็นมาตรฐานในระดับหนึ่ง ช่วยให้สามารถสร้างคิวรีและคำสั่งที่ซับซ้อนได้อย่างกระชับในรูปแบบที่อ่านเข้าใจง่ายและเรียนรู้ได้ง่าย มันไม่ได้ขึ้นอยู่กับภาษาการเขียนโปรแกรมอื่นดังนั้นจึงสามารถใช้งานได้กับโปรแกรมเมอร์แอปพลิเคชันส่วนใหญ่ไม่ว่าพวกเขาจะชอบ Java, C, C ++, C #, Python, Ruby, JavaScript, Basic, Go, Perl, PHP หรืออย่างอื่น

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

ปัญหาไม่ใช่เรื่องใหม่และมี API ที่ปลอดภัยกว่า SQL มาตรฐานเพื่อเข้าถึงฐานข้อมูลเชิงสัมพันธ์ ตัวอย่างเช่นผู้ทำแผนที่ OR ทั้งหมดที่ฉันรู้จักกำลังพยายามจัดทำ API ดังกล่าว (แม้ว่าโดยทั่วไปแล้วพวกเขาจะได้รับการออกแบบมาเพื่อเป้าหมายหลักอื่น ๆ ) ตัวแปร SQL แบบคงทำให้ยากต่อการสร้างแบบสอบถามแบบไดนามิกใด ๆ กับข้อมูลอินพุต unsanitized (และนั่นไม่ใช่สิ่งประดิษฐ์ใหม่: SQL ฝังตัวซึ่งมักใช้ SQL แบบคงที่มีอายุประมาณ 30 ปี)

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

ความคิดเห็นของบ็อบมาร์ตินเป็นเช่นนั้น ความคิดเห็นของชายคนหนึ่ง

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

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

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

เราไม่ได้ห้ามมีดทำครัวเพราะมีคนเคราะห์ร้ายไม่กี่คนที่จะตัดนิ้วของพวกเขาโดยบังเอิญ

เขากำลังพูดอะไรจริงๆ

เขากำลังพูดแทนที่ SQL ด้วยเทคโนโลยี No-SQL หรือไม่

TL; DR: ใช่ (เรียงลำดับ)

ในการพูดคุยครั้งล่าสุดมากกว่าที่คุณเชื่อมโยงโดยทั่วไปในหัวข้อเดียวกันเขาพูดว่า: "ฐานข้อมูลเป็นรายละเอียดทำไมเราถึงมีฐานข้อมูล" .

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

เขาคาดการณ์ว่าฐานข้อมูลเชิงสัมพันธ์โดยรวมจะหายไปอย่างมากเนื่องจากการแข่งขันครั้งใหม่ของพวกเขา

ถ้าฉันเป็น Oracle ฉันจะค่อนข้างกลัวเพราะเหตุผลที่มีอยู่ของฉันระเหยจากใต้ฉัน [... ] เหตุผลสำหรับฐานข้อมูลที่มีอยู่จะหายไป

อาจจะมีตารางเชิงสัมพันธ์ที่อยู่รอด แต่ตอนนี้มีการแข่งขันที่ดี

ดังนั้นไม่ใช่สำหรับเขามันไม่เพียง แต่เกี่ยวกับการฉีด SQL แม้ว่าเขา opines SQL จะมีข้อบกพร่องโดยกำเนิดในเรื่องนี้

หมายเหตุผู้เขียน:

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

SQL เป็นรายละเอียด ความรู้เกี่ยวกับรายละเอียดไม่ควรแพร่กระจาย

เมื่อมีการใช้ SQL ในสถานที่ต่าง ๆ ในรหัสของคุณรหัสของคุณจะมากขึ้นและขึ้นอยู่กับมัน

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

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

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

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

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

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

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

คำพูดจากคำพูดแรกของคุณคือ (ฉันเน้น)

การแก้ไขปัญหา. ทางออกเดียว คือการกำจัด SQL ออกจากระบบทั้งหมด หากไม่มีเอนจิ้น SQL จะไม่มีการโจมตี SQLi

อะไรจะมาแทนที่ SQL? API แน่นอน! และไม่ใช่ API ที่ใช้ภาษาที่เป็นข้อความ API ที่ใช้ชุดโครงสร้างข้อมูลที่เหมาะสมและการเรียกใช้ฟังก์ชันเพื่อเข้าถึงข้อมูลที่จำเป็นแทน

การพูดจาโผงผางเป็นการต่อต้านการให้แอปพลิเคชันโปรแกรมเมอร์ใช้ SQL

การแก้ไขที่แนะนำคือให้พวกเขาใช้ API แทน: ซึ่งไม่ใช่ SQL และไม่อนุญาตการฉีด

IMO ตัวอย่างของ API ดังกล่าวอาจรวมถึง:

• http://bobby-tables.com/csharpชี้ให้เห็นว่าโปรแกรมเมอร์ C # สามารถใช้ ADO.NET API ได้

  ที่ไม่เป็นตัวอย่างที่สมบูรณ์แบบเพราะ ADO.NET เป็นกว้างหรือลึก (เช่นที่มีประสิทธิภาพหรือวัตถุประสงค์ทั่วไป) API ซึ่งนอกจากนี้ยังช่วยให้ผู้ใช้ป้อนข้อมูลดิบ (หรือดิบ ish) SQL

• ผู้พัฒนา SQL หรือผู้ดูแลระบบฐานข้อมูลบางคนแนะนำว่าควรกำหนดค่าฐานข้อมูลเพื่ออนุญาตการเข้าถึงผ่าน (จำนวน จำกัด ของการเขียนอย่างเชี่ยวชาญ) ขั้นตอนการจัดเก็บและผู้พัฒนาโปรแกรมประยุกต์ไม่ควรได้รับอนุญาตให้เขียนแบบสอบถาม SQL ของตนเอง (อันตราย)

• อีกวิธีในการ "กำจัด SQL ออกจากระบบ" คือการวางฐานข้อมูล (ซึ่งแสดงถึง SQL) ในระบบอื่น ๆซึ่งเข้าถึงผ่าน REST API หรือคล้ายกัน

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

ความต้องการของ rant นั้นเป็นจริงหาก SQL API ของฐานข้อมูลถูกซ่อนไว้จากผู้พัฒนาแอปพลิเคชั่นซึ่งอยู่เบื้องหลัง API อื่น ๆ (เช่น ADO, บางที ORM, เว็บเซอร์วิสหรืออะไรก็ตาม)

โดยทั่วไปฉันคิดว่าหมายถึงการมี DAL เฉพาะแอปพลิเคชัน ("data access layer" หรือ "abstraction layer ฐานข้อมูล") DAL จะป้องกันแอปพลิเคชันจากรายละเอียดว่าเก็บข้อมูลและ / หรือดึงข้อมูลอย่างไรและที่ไหน DAL อาจนำไปใช้หรือไม่ใช้โดยใช้ฐานข้อมูล SQL

ทุกคนดูเหมือนจะตอบคำถามนี้จากมุมมองความปลอดภัยหรือด้วยเลนส์ SQL

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

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

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

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

    my $sql="select a from b where a=$ui_val;";
    prepare($sql)
    execute($sql)

ตรงข้ามกับ

    my $sql="select a from b where a=?;";
    prepare($sql)
    execute($sql,$ui_val);

นี่คือ DBI perl ที่เป็นตัวอย่างสำหรับ ruby ​​on Rails code รหัสรางที่เขาให้นั้นง่ายต่อการสับสนระหว่างตู้นิรภัยกับที่ไม่ปลอดภัย เช่นเดียวกับ ORMs จำนวนมากซ่อนสิ่งที่ SQL อยู่ด้านล่างและบ่อยครั้งที่คุณจัดการกับอินเทอร์เฟซที่สร้างและดำเนินการ sql สำหรับคุณ เสียงนี้ไม่เหมือนกับสิ่งที่ API จะทำเพื่อคุณใช่ไหม

การตีความการอ้างอิงแรกของฉันคือเขาแนะนำว่าเราควรแทนที่ปัญหาที่รู้จักกันดีซึ่งมีวิธีแก้ปัญหาที่รู้จักกันดี

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

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

ใช่ดิสก์หมุนเป็นเรื่องของอดีตและตอนนี้เราใช้ SSD ดิสก์ทำงานกับประมาณ 10 มิลลิวินาทีต่อการถ่ายโอนข้อมูล SSD ทำงานกับเวลาในการเข้าถึงข้อมูลประมาณ ~ 0.5 มิลลิวินาที (500 ไมโครวินาที) หน่วยความจำอยู่ในคำสั่งของ 100 นาโนวินาทีตัวประมวลผลทำงานบนอีก 100 วินาทีของ pico วินาที นี่คือเหตุผลว่าทำไมเราจึงต้องการฐานข้อมูล ฐานข้อมูลจัดการการถ่ายโอนข้อมูลระหว่างดิสก์หมุนหรือ SSD กับหน่วยความจำหลัก การถือกำเนิดของ SSD ไม่ได้ขจัดความต้องการฐานข้อมูล

ตอบ

เขาต้องการให้คนหยุดใช้ SQL / ฐานข้อมูลเชิงสัมพันธ์เนื่องจากการโจมตีของ SQLi หรือไม่?

บทความ 'Bobby Tables' ดูเหมือนจะแนะนำว่าสิ่งนี้มันและตัวของมันเองเป็นเหตุผลที่ไม่ใช้ SQL:

การแก้ไขปัญหา. ทางออกเดียว คือการกำจัด SQL ออกจากระบบทั้งหมด หากไม่มีเอ็นจิ้น SQL จะไม่มีการโจมตี SQLi

เขาอาจมีเหตุผลอื่นที่เขาพูดถึงที่อื่น ฉันไม่รู้เพราะฉันไม่ได้อ่านเรื่องของเขามากนัก

การพูดนอกเรื่อง

ส่วนนี้ไม่ใช่คำตอบจริงๆ แต่ฉันคิดว่าคำถามเกี่ยวกับคุณค่าของ SQL นั้นน่าสนใจกว่ามาก (เช่นเดียวกับคนอื่น ๆ )

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

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

ฉันคิดว่านักพัฒนาซอฟต์แวร์ทุกคนควรดูวิดีโอชื่อ "วันศุกร์ที่ 13: โจมตี JSON - Alvaro Muñoz & Oleksandr Mirosh - AppSecUSA 2017"

หากคุณไม่มีเวลาหรือความชอบในการรับชมนี่เป็นส่วนสำคัญ: ไลบรารีการดีซีเรียลไลเซชั่น JSON จำนวนมากมีช่องโหว่ในการเรียกใช้โค้ดจากระยะไกล หากคุณใช้ XML คุณจะต้องกังวลมากขึ้น การห้าม SQL จากสถาปัตยกรรมของคุณจะไม่ทำให้ระบบของคุณปลอดภัย

ฉันต้องการที่จะอยู่เพียงคำสั่งสั้น ๆ :

หรือเขาต้องการให้คนหยุดใช้ SQL / ฐานข้อมูลเชิงสัมพันธ์เนื่องจากการโจมตีของ SQLi

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

ปัญหาของ Martin นั้นอยู่ที่โปรแกรมเมอร์ที่สร้าง SQL แบบไดนามิกโดยตรงจากอินพุตของผู้ใช้สิ่งที่ต้องการ (ยกโทษให้ฉันฉันเป็นโปรแกรมเมอร์ C และ C ++ เป็นหลัก):

sprintf( query, "select foo from bar where %s;", user_input );

ซึ่งเป็นสูตรสำหรับอิจฉาริษยาอย่างแน่นอน (ดังนั้นBobby Tables strip) โปรแกรมเมอร์ที่ใส่โค้ดแบบนั้นในระบบที่ใช้งานจริงสมควรได้รับ paddlin '

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

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

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

แหล่งที่มาสองแห่งที่คุณเชื่อมโยงถ่ายทอดข้อความที่แตกต่างกัน:

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

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

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

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

มีทางเลือกอื่นอีกหรือไม่?

การเขียนตรรกะการเข้าถึงข้อมูลโดยไม่มีสตริงเป็นไปได้ทั้งหมด ใน Java land คุณอาจใช้QueryDSLโดยที่การสืบค้นจะได้รับการอธิบายโดยใช้ API ประเภท fluent-safe ที่สร้างจากสคีมาฐานข้อมูลของคุณ แบบสอบถามดังกล่าวอาจมีลักษณะดังนี้:

JPAQuery<?> query = new JPAQuery<Void>(entityManager);
Customer bob = query.select(customer)
  .from(customer)
  .where(customer.firstName.eq("Bob"))
  .fetchOne();

อย่างที่คุณเห็นตรรกะแบบสอบถามไม่แสดงเป็นสตริงแยกโครงสร้างที่เชื่อถือได้ของแบบสอบถามอย่างชัดเจนจากพารามิเตอร์ที่ไม่น่าเชื่อถือ (และแน่นอน QueryDSL ไม่รวมพารามิเตอร์ลงในข้อความแบบสอบถาม แต่ใช้คำสั่งที่เตรียมไว้เพื่อแยกแบบสอบถาม สำหรับพารามิเตอร์ที่ระดับ JDBC) เพื่อให้การฉีด SQL ด้วย QueryDSL คุณต้องเขียน parser ของคุณเองเพื่อวิเคราะห์สตริงและแปลมันลงในแผนผังต้นไม้และแม้ว่าคุณจะทำเช่นนั้นคุณอาจจะไม่เพิ่มการสนับสนุนสำหรับสิ่งที่น่ารังเกียจเช่นselect ... into fileนั้น ในระยะสั้น QueryDSL ทำให้ SQL injection neighbour เป็นไปไม่ได้และยังช่วยเพิ่มประสิทธิภาพการทำงานของโปรแกรมเมอร์และเพิ่มความปลอดภัยในการรีแฟคเตอร์ ป้องกันความเสี่ยงที่ใหญ่ที่สุดในการรักษาความปลอดภัยเว็บแอปพลิเคชันซึ่งมีมานานพอที่จะวางไข่มุขตลกและเพิ่มประสิทธิภาพการทำงานของนักพัฒนา? ฉันกล้าพูดว่าถ้าคุณยังเขียนแบบสอบถามเป็นสตริงคุณกำลังทำผิด

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