Tại sao cơ chế ngăn chặn tiêm SQL phát triển theo hướng sử dụng các truy vấn tham số?

Theo cách tôi thấy, các cuộc tấn công tiêm SQL có thể được ngăn chặn bằng cách:

1. Sàng lọc cẩn thận, lọc, mã hóa đầu vào (trước khi chèn vào SQL)
2. Sử dụng các câu lệnh / truy vấn tham số đã chuẩn bị

Tôi cho rằng có những ưu và nhược điểm đối với từng loại, nhưng tại sao # 2 lại cất cánh và được coi là ít nhiều là cách thực tế để ngăn chặn các cuộc tấn công tiêm chích? Có phải nó chỉ an toàn hơn và ít bị lỗi hơn hoặc có các yếu tố khác?

Theo tôi hiểu, nếu số 1 được sử dụng đúng cách và tất cả các cảnh báo đều được quan tâm, thì nó có thể hiệu quả như số 2.

Vệ sinh, Lọc và Mã hóa

Có một số nhầm lẫn về phía tôi giữa việc vệ sinh , lọc và mã hóa có nghĩa là gì. Tôi sẽ nói rằng vì mục đích của tôi, tất cả những điều trên có thể được xem xét cho tùy chọn 1. Trong trường hợp này tôi hiểu rằng vệ sinh và lọc có khả năng sửa đổi hoặc loại bỏ dữ liệu đầu vào, trong khi mã hóa bảo tồn dữ liệu như hiện tại , nhưng mã hóa nó đúng cách để tránh các cuộc tấn công tiêm. Tôi tin rằng việc thoát dữ liệu có thể được coi là một cách mã hóa nó.

Truy vấn tham số so với thư viện mã hóa

Có câu trả lời trong đó các khái niệm parameterized queriesvà encoding librariesđược điều trị thay thế cho nhau. Sửa lỗi cho tôi nếu tôi sai, nhưng tôi có ấn tượng rằng chúng khác nhau.

Tôi hiểu rằng encoding libraries, dù họ có tiềm năng sửa đổi "Chương trình" SQL tốt đến đâu, bởi vì họ đang thực hiện các thay đổi đối với chính SQL, trước khi nó được gửi đến RDBMS.

Parameterized queries mặt khác, gửi chương trình SQL đến RDBMS, sau đó tối ưu hóa truy vấn, xác định kế hoạch thực hiện truy vấn, chọn các chỉ mục sẽ được sử dụng, v.v., sau đó cắm dữ liệu, là bước cuối cùng bên trong RDBMS Chính nó.

Thư viện mã hóa

  data -> (encoding library)
                  |
                  v
SQL -> (SQL + encoded data) -> RDBMS (execution plan defined) -> execute statement

Truy vấn tham số

                                               data
                                                 |
                                                 v
SQL -> RDBMS (query execution plan defined) -> data -> execute statement

Ý nghĩa lịch sử

Một số câu trả lời đề cập rằng trong lịch sử, các truy vấn được tham số hóa (PQ) đã được tạo vì lý do hiệu suất và trước khi các cuộc tấn công tiêm chích mà các vấn đề mã hóa nhắm mục tiêu trở nên phổ biến. Tại một số điểm, rõ ràng là PQ cũng khá hiệu quả để chống lại các cuộc tấn công tiêm. Để giữ đúng tinh thần của câu hỏi của tôi, tại sao PQ vẫn là phương pháp được lựa chọn và tại sao nó lại phát triển vượt bậc so với hầu hết các phương pháp khác khi nói đến việc ngăn chặn các cuộc tấn công tiêm nhiễm SQL?

Vấn đề là # 1 yêu cầu bạn phân tích và giải thích hiệu quả toàn bộ biến thể SQL mà bạn đang làm việc để bạn biết nếu nó đang làm điều gì đó không nên. Và luôn cập nhật mã đó khi bạn cập nhật cơ sở dữ liệu của mình. Ở mọi nơi bạn chấp nhận đầu vào cho các truy vấn của bạn. Và không vít nó lên.

Vì vậy, có, loại điều đó sẽ ngăn chặn các cuộc tấn công tiêm nhiễm SQL, nhưng việc thực hiện sẽ tốn kém hơn một cách vô lý.

Bởi vì phương án 1 không phải là một giải pháp. Sàng lọc và lọc có nghĩa là từ chối hoặc loại bỏ đầu vào không hợp lệ. Nhưng bất kỳ đầu vào có thể là hợp lệ. Ví dụ, dấu nháy đơn là một ký tự hợp lệ trong tên "O'Malley". Nó chỉ cần được mã hóa chính xác trước khi được sử dụng trong SQL, đây là điều mà các câu lệnh được chuẩn bị thực hiện.

Sau khi bạn thêm ghi chú, có vẻ như về cơ bản bạn đang hỏi tại sao sử dụng chức năng thư viện tiêu chuẩn thay vì viết mã tương tự về chức năng của riêng bạn từ đầu? Bạn nên luôn luôn thích các giải pháp thư viện tiêu chuẩn để viết mã của riêng bạn. Đó là công việc ít hơn và dễ bảo trì hơn. Đây là trường hợp cho bất kỳ chức năng nào , nhưng đặc biệt đối với một thứ nhạy cảm về bảo mật, hoàn toàn không có ý nghĩa để tự mình phát minh lại bánh xe.

Nếu bạn đang cố xử lý chuỗi, thì bạn không thực sự tạo truy vấn SQL. Bạn đang tạo một chuỗi có thể tạo ra một truy vấn SQL. Có một mức độ gián tiếp mở ra rất nhiều chỗ cho các lỗi và lỗi. Thực sự hơi ngạc nhiên, vì trong hầu hết các bối cảnh, chúng tôi rất vui khi được tương tác với một cái gì đó theo chương trình. Ví dụ: nếu chúng tôi có một số cấu trúc danh sách và muốn thêm một mục, chúng tôi thường không làm:

List<Integer> list = /* a list of 1, 2, 3 */
String strList = list.toString();   /* to get "[1, 2, 3]" */
strList = /* manipulate strList to become "[1, 2, 5, 3]" */
list = parseList(strList);

Nếu ai đó đề nghị làm điều đó, bạn sẽ trả lời đúng rằng điều đó khá vô lý, và người đó chỉ nên làm:

List<Integer> list = /* ... */;
list.add(5, position=2);

Điều đó tương tác với cấu trúc dữ liệu ở cấp độ khái niệm của nó. Nó không giới thiệu bất kỳ sự phụ thuộc nào vào cách cấu trúc đó có thể được in hoặc phân tích cú pháp. Đó là những quyết định hoàn toàn trực giao.

Cách tiếp cận đầu tiên của bạn giống như mẫu đầu tiên (chỉ kém hơn một chút): bạn cho rằng có thể xây dựng chuỗi theo cách lập trình sẽ được phân tích cú pháp chính xác như truy vấn mà bạn muốn. Điều đó phụ thuộc vào trình phân tích cú pháp và toàn bộ logic xử lý chuỗi.

Cách tiếp cận thứ hai của việc sử dụng các truy vấn đã chuẩn bị giống như mẫu thứ hai. Khi bạn sử dụng truy vấn đã chuẩn bị, về cơ bản, bạn phân tích cú pháp truy vấn giả hợp pháp nhưng có một số chỗ dành sẵn trong đó, sau đó sử dụng API để thay thế chính xác một số giá trị trong đó. Bạn không còn liên quan đến quá trình phân tích cú pháp và bạn không phải lo lắng về bất kỳ xử lý chuỗi nào.

Nói chung, dễ dàng hơn nhiều và ít xảy ra lỗi hơn khi tương tác với mọi thứ ở cấp độ khái niệm của chúng. Một truy vấn không phải là một chuỗi, một truy vấn là những gì bạn nhận được khi phân tích một chuỗi hoặc xây dựng một chuỗi theo chương trình (hoặc bất kỳ phương thức nào khác cho phép bạn tạo một chuỗi).

Có một sự tương đồng tốt ở đây giữa các macro kiểu C thực hiện thay thế văn bản đơn giản và các macro kiểu Lisp tạo mã tùy ý. Với các macro kiểu C, bạn có thể thay thế văn bản trong mã nguồn và điều đó có nghĩa là bạn có khả năng đưa ra các lỗi cú pháp hoặc hành vi gây hiểu lầm. Với macro Lisp, bạn đang tạo mã ở dạng trình biên dịch xử lý nó (nghĩa là bạn đang trả về các cấu trúc dữ liệu thực tế mà trình biên dịch xử lý, chứ không phải văn bản mà trình đọc phải xử lý trước khi trình biên dịch có thể xử lý nó) . Tuy nhiên, với macro Lisp, bạn không thể tạo ra thứ gì đó có thể là lỗi phân tích cú pháp. Ví dụ: bạn không thể tạo (hãy (ab) a .

Ngay cả với các macro Lisp, bạn vẫn có thể tạo mã xấu, bởi vì bạn không nhất thiết phải nhận thức được cấu trúc được cho là có ở đó. Ví dụ, trong Lisp, (let ((ab)) a) có nghĩa là "thiết lập một ràng buộc từ vựng mới của biến a với giá trị của biến b, và sau đó trả về giá trị của a", và (let (ab) a) có nghĩa là "thiết lập các ràng buộc từ vựng mới của các biến a và b và khởi tạo cả hai cho đến 0 và sau đó trả về giá trị của a." Cả hai đều đúng về mặt cú pháp, nhưng chúng có nghĩa là những thứ khác nhau. Để tránh vấn đề này, bạn có thể sử dụng các hàm nhận biết ngữ nghĩa nhiều hơn và làm một cái gì đó như:

Variable a = new Variable("a");
Variable b = new Variable("b");
Let let = new Let();
let.getBindings().add(new LetBinding(a,b));
let.setBody(a);
return let;

Với những thứ tương tự, không thể trả lại thứ gì đó không hợp lệ về mặt cú pháp và khó có thể trả lại thứ gì đó vô tình không như bạn muốn.

Nó giúp tùy chọn # 2 thường được coi là một cách thực hành tốt nhất vì cơ sở dữ liệu có thể lưu trữ phiên bản truy vấn không được tham số hóa. Các truy vấn được tham số hóa trước vấn đề tiêm SQL vài năm (tôi tin), điều đó xảy ra đến mức bạn có thể giết chết hai con chim bằng một viên đá.

Nói một cách đơn giản: Họ đã không làm thế. Tuyên bố của bạn:

Tại sao cơ chế ngăn chặn SQL Injection phát triển theo hướng sử dụng Truy vấn tham số?

về cơ bản là thiếu sót. Các truy vấn được tham số hóa đã tồn tại cách lâu hơn SQL Injection ít nhất được biết đến rộng rãi. Chúng thường được phát triển như một cách để tránh sự tập trung chuỗi trong chức năng "hình thức tìm kiếm" thông thường mà các ứng dụng LOB (Line of Business) có. Nhiều - NHIỀU - năm sau, ai đó đã tìm thấy một vấn đề bảo mật với thao tác chuỗi đã nói.

Tôi nhớ đã làm SQL 25 năm trước (khi internet KHÔNG được sử dụng rộng rãi - nó mới chỉ bắt đầu) và tôi nhớ đã làm SQL so với IBM DB5 IIRC phiên bản 5 - và điều đó đã có các truy vấn được tham số hóa.

Ngoài ra tất cả các câu trả lời tốt khác:

Lý do tại sao # 2 tốt hơn là vì nó tách dữ liệu của bạn khỏi mã của bạn. Trong số 1, dữ liệu của bạn là một phần của mã của bạn và đó là nơi tất cả những điều xấu xuất phát. Với # 1, bạn nhận được truy vấn của mình và cần thực hiện các bước bổ sung để đảm bảo truy vấn của bạn hiểu dữ liệu của bạn dưới dạng dữ liệu trong khi ở # 2 bạn nhận được mã của mình và đó là mã và dữ liệu của bạn là dữ liệu.

Các truy vấn được tham số hóa, ngoài việc cung cấp bảo vệ tiêm SQL, thường có một lợi ích bổ sung là chỉ được biên dịch một lần, sau đó được thực thi nhiều lần với các tham số khác nhau.

Từ quan điểm cơ sở dữ liệu SQL select * from employees where last_name = 'Smith'và select * from employees where last_name = 'Fisher'khác biệt rõ ràng và do đó yêu cầu phân tích, biên dịch và tối ưu hóa riêng biệt. Chúng cũng sẽ chiếm các vị trí riêng biệt trong vùng nhớ dành riêng cho việc lưu trữ các câu lệnh được biên dịch. Trong một hệ thống được tải nặng với một số lượng lớn các truy vấn tương tự có tính toán tham số khác nhau và chi phí bộ nhớ có thể là đáng kể.

Sau đó, sử dụng các truy vấn tham số thường cung cấp các lợi thế hiệu suất lớn.

Chờ nhưng tại sao?

Tùy chọn 1 có nghĩa là bạn phải viết các thói quen vệ sinh cho từng loại đầu vào trong khi tùy chọn 2 ít bị lỗi hơn và ít mã hơn để bạn viết / kiểm tra / bảo trì.

Hầu như chắc chắn "chăm sóc tất cả các cảnh báo" có thể phức tạp hơn bạn nghĩ và ngôn ngữ của bạn (ví dụ Java PreparedStatement) có nhiều thứ hơn bạn nghĩ.

Các câu lệnh được chuẩn bị hoặc các truy vấn tham số được biên dịch sẵn trong máy chủ cơ sở dữ liệu, do đó, khi các tham số được đặt, không có phép nối SQL nào được thực hiện do truy vấn không còn là chuỗi SQL. Một lợi thế về mặt quảng cáo là RDBMS lưu trữ truy vấn và các cuộc gọi tiếp theo được coi là cùng một SQL ngay cả khi các giá trị tham số khác nhau, trong khi với SQL được nối mỗi khi truy vấn được chạy với các giá trị khác nhau thì truy vấn khác nhau và RDBMS phải phân tích cú pháp , tạo lại kế hoạch thực hiện, v.v.

Chúng ta hãy tưởng tượng một cách tiếp cận "vệ sinh, lọc và mã hóa" lý tưởng sẽ như thế nào.

Vệ sinh và lọc có thể có ý nghĩa trong ngữ cảnh của một ứng dụng cụ thể, nhưng cuối cùng cả hai đều sôi sục khi nói rằng "bạn không thể đưa dữ liệu này vào cơ sở dữ liệu". Đối với ứng dụng của bạn, đó có thể là một ý tưởng tốt, nhưng đó không phải là thứ bạn có thể đề xuất như một giải pháp chung, vì sẽ có những ứng dụng cần có khả năng lưu trữ các ký tự tùy ý trong cơ sở dữ liệu.

Vì vậy mà lá mã hóa. Bạn có thể bắt đầu bằng cách có một chức năng mã hóa chuỗi bằng cách thêm các ký tự thoát, để bạn có thể thay thế chúng trong chính mình. Vì các cơ sở dữ liệu khác nhau cần các ký tự thoát khác nhau (trong một số cơ sở dữ liệu, cả hai \'và ''là các chuỗi thoát hợp lệ cho ', nhưng không phải trong các cơ sở dữ liệu khác), nên chức năng này cần được cung cấp bởi nhà cung cấp cơ sở dữ liệu.

Nhưng không phải tất cả các biến là chuỗi. Đôi khi bạn cần thay thế bằng một số nguyên hoặc một ngày. Chúng được biểu diễn khác nhau cho các chuỗi, vì vậy bạn cần các phương thức mã hóa khác nhau (một lần nữa, chúng cần phải cụ thể cho nhà cung cấp cơ sở dữ liệu) và bạn cần thay thế chúng vào truy vấn theo các cách khác nhau.

Vì vậy, có thể mọi thứ sẽ dễ dàng hơn nếu cơ sở dữ liệu xử lý thay thế cho bạn - nó đã biết loại truy vấn mong đợi và cách mã hóa dữ liệu an toàn và cách thay thế chúng vào truy vấn của bạn một cách an toàn, vì vậy bạn không cần phải lo lắng về nó trong mã của bạn.

Tại thời điểm này, chúng tôi vừa phát minh lại các truy vấn được tham số hóa.

Và một khi các truy vấn được tham số hóa, nó sẽ mở ra các cơ hội mới, chẳng hạn như tối ưu hóa hiệu suất và giám sát đơn giản hóa.

Mã hóa là khó thực hiện đúng và mã hóa-thực hiện-quyền không thể phân biệt với tham số hóa.

Nếu bạn thực sự thích nội suy chuỗi như một cách xây dựng truy vấn, có một số ngôn ngữ (Scala và ES2015 xuất hiện) có nội suy chuỗi có thể cắm, do đó, có những thư viện cho phép bạn viết các truy vấn được tham số hóa trông giống như nội suy chuỗi, nhưng an toàn khỏi SQL tiêm - vì vậy trong cú pháp ES2015:

import {sql} from 'cool-sql-library'

let result = sql`select *
    from users
    where user_id = ${user_id}
      and password_hash = ${password_hash}`.execute()

console.log(result)

Trong tùy chọn 1, bạn đang làm việc với một bộ đầu vào có kích thước = vô cực mà bạn đang cố ánh xạ tới kích thước đầu ra rất lớn. Trong tùy chọn 2, bạn đã giới hạn đầu vào của mình cho bất cứ điều gì bạn chọn. Nói cách khác:

1. Sàng lọc và lọc cẩn thận [ vô cực ] cho [ tất cả các truy vấn SQL an toàn ]
2. Sử dụng [ kịch bản được xem xét trước giới hạn trong phạm vi của bạn ]

Theo các câu trả lời khác, dường như cũng có một số lợi ích về hiệu suất từ ​​việc giới hạn phạm vi của bạn khỏi vô cực và hướng tới một cái gì đó có thể quản lý được.

Một mô hình tinh thần hữu ích của SQL (đặc biệt là phương ngữ hiện đại) là mỗi câu lệnh hoặc truy vấn SQL là một chương trình. Trong một chương trình thực thi nhị phân riêng, các loại lỗ hổng bảo mật nguy hiểm nhất sẽ tràn ra nơi kẻ tấn công có thể ghi đè hoặc sửa đổi mã chương trình bằng các hướng dẫn khác nhau.

Lỗ hổng SQL tiêm là đẳng cấu với tràn bộ đệm trong ngôn ngữ như C. Lịch sử đã chỉ ra rằng tràn bộ đệm là cực kỳ khó ngăn chặn - ngay cả đối tượng mã cực kỳ quan trọng để xem xét mở thường chứa các lỗ hổng như vậy.

Một khía cạnh quan trọng của phương pháp hiện đại để giải quyết các lỗ hổng tràn là sử dụng các cơ chế phần cứng và hệ điều hành để đánh dấu các phần cụ thể của bộ nhớ là không thể thực thi và đánh dấu các phần khác của bộ nhớ là chỉ đọc. (Xem bài viết Wikipedia về bảo vệ không gian thực thi , chẳng hạn.) Theo cách đó, ngay cả khi kẻ tấn công có thể sửa đổi dữ liệu, kẻ tấn công không thể khiến dữ liệu được tiêm của chúng được coi là mã.

Vì vậy, nếu lỗ hổng SQL tiêm tương đương với lỗi tràn bộ đệm, thì SQL tương đương với bit NX hay các trang bộ nhớ chỉ đọc là gì? Câu trả lời là: các câu lệnh được chuẩn bị , bao gồm các truy vấn được tham số hóa cộng với các cơ chế tương tự cho các yêu cầu không truy vấn. Câu lệnh đã chuẩn bị được biên dịch với một số phần nhất định được đánh dấu chỉ đọc, vì vậy kẻ tấn công không thể thay đổi các phần đó của chương trình và các phần khác được đánh dấu là dữ liệu không thể thực thi (các tham số của câu lệnh đã chuẩn bị) mà kẻ tấn công có thể đưa dữ liệu vào nhưng mà sẽ không bao giờ được coi là mã chương trình, do đó loại bỏ hầu hết các khả năng lạm dụng.

Chắc chắn, vệ sinh đầu vào của người dùng là tốt, nhưng để thực sự an toàn, bạn cần phải hoang tưởng (hoặc, tương đương, để suy nghĩ như một kẻ tấn công). Bề mặt điều khiển bên ngoài văn bản chương trình là cách để thực hiện điều đó và các câu lệnh được chuẩn bị cung cấp bề mặt điều khiển đó cho SQL. Vì vậy, không có gì ngạc nhiên khi các câu lệnh được chuẩn bị, và do đó các truy vấn được tham số hóa, là cách tiếp cận mà đại đa số các chuyên gia bảo mật khuyên dùng.

Tôi alredy viết về điều này ở đây: https://stackoverflow.com/questions/6786034/can-parameterized-statement-stop-all-sql-injection/33033576#33033576

Nhưng, chỉ để giữ cho nó đơn giản:

Cách các truy vấn được tham số hóa hoạt động, là sqlQuery được gửi dưới dạng truy vấn và cơ sở dữ liệu biết chính xác truy vấn này sẽ làm gì và chỉ sau đó nó mới chèn tên người dùng và mật khẩu làm giá trị. Điều này có nghĩa là họ không thể thực hiện truy vấn, vì cơ sở dữ liệu đã biết truy vấn sẽ làm gì. Vì vậy, trong trường hợp này, nó sẽ tìm tên người dùng "Không ai HOẶC 1 = 1 '-" và mật khẩu trống, sẽ xuất hiện sai.

Tuy nhiên, đây không phải là một giải pháp hoàn chỉnh và việc xác thực đầu vào vẫn cần phải được thực hiện, vì điều này sẽ không ảnh hưởng đến các vấn đề khác, như các cuộc tấn công XSS, vì bạn vẫn có thể đưa javascript vào cơ sở dữ liệu. Sau đó, nếu điều này được đọc ra trên một trang, nó sẽ hiển thị nó dưới dạng javascript bình thường, tùy thuộc vào bất kỳ xác thực đầu ra nào. Vì vậy, điều thực sự tốt nhất vẫn là sử dụng xác thực đầu vào, nhưng sử dụng các truy vấn được tham số hóa hoặc các thủ tục được lưu trữ để ngăn chặn mọi cuộc tấn công SQL

Tôi chưa bao giờ sử dụng SQL. Nhưng rõ ràng bạn nghe về những vấn đề mà mọi người gặp phải và các nhà phát triển SQL gặp vấn đề với điều "SQL tiêm" này. Trong một thời gian dài, tôi không thể tìm ra nó. Và sau đó tôi nhận ra rằng những người tạo ra các câu lệnh SQL, các câu lệnh nguồn SQL văn bản thực sự, bằng cách nối các chuỗi, trong đó một số nơi được người dùng nhập vào. Và suy nghĩ đầu tiên của tôi về nhận thức đó là sốc. Tổng sốc. Tôi nghĩ: Làm thế nào có ai có thể ngu ngốc đến thế và tạo ra các câu lệnh trong bất kỳ ngôn ngữ lập trình nào như vậy? Đối với một nhà phát triển C, hoặc C ++ hoặc Java hoặc Swift, đây là điều hoàn toàn điên rồ.

Điều đó nói rằng, không khó để viết một hàm C lấy một chuỗi C làm đối số của nó và tạo ra một chuỗi khác trông giống hệt như một chuỗi ký tự trong mã nguồn C đại diện cho cùng một chuỗi. Ví dụ: hàm đó sẽ dịch abc thành "abc" và "abc" thành "\" abc \ "" và "\" abc \ "" thành "\" \\ "abc \\" \ "". (Chà, nếu điều này có vẻ sai với bạn, đó là html. Nó đúng khi tôi nhập nó vào, nhưng không phải khi nó được hiển thị) Và một khi chức năng C được viết, việc tạo mã nguồn C không khó khăn gì cả văn bản từ trường đầu vào do người dùng cung cấp được chuyển thành chuỗi C bằng chữ. Điều đó không khó để làm cho an toàn. Tại sao các nhà phát triển SQL sẽ không sử dụng cách tiếp cận đó như một cách để tránh việc tiêm SQL nằm ngoài tôi.

"Vệ sinh" là một cách tiếp cận hoàn toàn sai lầm. Lỗ hổng nghiêm trọng là nó làm cho một số người dùng đầu vào bất hợp pháp. Bạn kết thúc với một cơ sở dữ liệu trong đó một trường văn bản chung không thể chứa văn bản như; Thả bảng hoặc bất cứ điều gì bạn sẽ sử dụng trong một SQL tiêm để gây ra thiệt hại. Tôi thấy điều đó khá khó chấp nhận. Nếu một cơ sở dữ liệu lưu trữ văn bản, nó sẽ có thể lưu trữ bất kỳ văn bản nào . Và lỗ hổng thực tế là chất khử trùng dường như không thể hiểu đúng :-(

Tất nhiên, các truy vấn được tham số hóa là điều mà bất kỳ lập trình viên nào sử dụng ngôn ngữ biên dịch sẽ mong đợi. Nó làm cho cuộc sống dễ dàng hơn nhiều: Bạn có một số đầu vào chuỗi và thậm chí bạn không bao giờ bận tâm dịch nó thành một chuỗi SQL, mà chỉ chuyển nó dưới dạng tham số, không có bất kỳ ký tự nào trong chuỗi đó gây ra bất kỳ thiệt hại nào.

Vì vậy, từ quan điểm của một nhà phát triển sử dụng các ngôn ngữ được biên dịch, vệ sinh là điều sẽ không bao giờ xảy ra với tôi. Nhu cầu vệ sinh là điên rồ. Các truy vấn tham số là giải pháp rõ ràng cho vấn đề.

(Tôi thấy câu trả lời của Josip rất thú vị. Về cơ bản, ông nói rằng với các truy vấn được tham số hóa, bạn có thể ngăn chặn mọi cuộc tấn công chống lại SQL, nhưng sau đó bạn có thể có văn bản trong cơ sở dữ liệu của mình được sử dụng để tạo ra một mũi tiêm JavaScript :-( Chà, chúng ta lại gặp vấn đề tương tự và tôi không biết liệu Javascript có giải pháp cho vấn đề đó không.

Vấn đề chính là tin tặc đã tìm ra cách để bao quanh vệ sinh trong khi các truy vấn được tham số hóa là một quy trình hiện có hoạt động hoàn hảo với các lợi ích bổ sung về hiệu suất và bộ nhớ.

Một số người đơn giản hóa vấn đề là "đó chỉ là trích dẫn đơn và trích dẫn kép" nhưng tin tặc đã tìm ra những cách thông minh để tránh bị phát hiện như sử dụng các mã hóa khác nhau hoặc sử dụng các chức năng cơ sở dữ liệu.

Dù sao, bạn chỉ cần quên một chuỗi duy nhất để tạo ra một vi phạm dữ liệu thảm khốc. Tin tặc nơi có thể tự động hóa các tập lệnh để tải xuống cơ sở dữ liệu hoàn chỉnh với một loạt hoặc truy vấn. Nếu phần mềm nổi tiếng như một bộ mã nguồn mở hoặc một bộ kinh doanh nổi tiếng, bạn có thể chỉ cần sử dụng bảng mật khẩu và người dùng.

Mặt khác, chỉ sử dụng các truy vấn được kết nối chỉ là vấn đề học cách sử dụng và làm quen với nó.