Về SQL injection , tôi hoàn toàn hiểu sự cần thiết phải tham số hóa một stringtham số; đó là một trong những thủ thuật lâu đời nhất trong cuốn sách. Nhưng khi nào thì có thể biện minh cho việc không tham số hóa an SqlCommand? Có bất kỳ kiểu dữ liệu nào được coi là "an toàn" để không tham số hóa không?

Ví dụ: Tôi không tự cho mình là ở gần một chuyên gia về SQL, nhưng tôi không thể nghĩ ra bất kỳ trường hợp nào có thể dễ bị tấn công bởi SQL injection để chấp nhận một boolhoặc một intvà chỉ nối nó ngay vào truy vấn.

Giả định của tôi có đúng không hay điều đó có khả năng để lại lỗ hổng bảo mật lớn trong chương trình của tôi?

Để làm rõ, câu hỏi này được gắn thẻ c #vốn là một ngôn ngữ được đánh máy mạnh; khi tôi nói "tham số", hãy nghĩ như thế nào public int Query(int id) .

Tôi nghĩ rằng nó an toàn ... về mặt kỹ thuật , nhưng đó là một thói quen khủng khiếp. Bạn có thực sự muốn viết các truy vấn như thế này không?

var sqlCommand = new SqlCommand("SELECT * FROM People WHERE IsAlive = " + isAlive + 
" AND FirstName = @firstName");

sqlCommand.Parameters.AddWithValue("firstName", "Rob");

Nó cũng khiến bạn dễ bị tổn thương trong trường hợp kiểu thay đổi từ số nguyên thành chuỗi (Hãy nghĩ đến số nhân viên, mặc dù tên của nó - có thể chứa các chữ cái).

Vì vậy, chúng tôi đã thay đổi loại EmployeeNumber từ intthành string, nhưng quên cập nhật các truy vấn sql của chúng tôi. Giáo sư.

Khi sử dụng một nền tảng mạnh mẽ, đánh máy trên một máy tính bạn kiểm soát (như một máy chủ web), bạn có thể ngăn chặn tiêm mã cho các truy vấn với chỉ bool, DateTimehoặc int(và số khác) giá trị. Điều đáng lo ngại là các vấn đề về hiệu suất gây ra bởi việc buộc máy chủ sql phải biên dịch lại mọi truy vấn và bằng cách ngăn nó nhận được số liệu thống kê tốt về những truy vấn được chạy với tần suất nào (điều này ảnh hưởng đến việc quản lý bộ nhớ cache).

Nhưng phần "trên máy tính mà bạn điều khiển" là quan trọng, vì nếu không thì người dùng có thể thay đổi hành vi được hệ thống sử dụng để tạo chuỗi từ các giá trị đó để bao gồm văn bản tùy ý.

Tôi cũng thích suy nghĩ dài hạn. Điều gì sẽ xảy ra khi cơ sở mã được đánh máy mạnh mẽ ngày nay được chuyển qua bản dịch tự động sang ngôn ngữ động mới nổi và bạn đột nhiên mất kiểm tra kiểu, nhưng chưa có tất cả các kiểm tra đơn vị phù hợp cho mã động ?

Thực sự, không có lý do chính đáng nào để không sử dụng các tham số truy vấn cho các giá trị này. Đó là cách đúng đắn để thực hiện điều này. Hãy tiếp tục và nhập các giá trị mã cứng vào chuỗi sql khi chúng thực sự là hằng số, nhưng nếu không, tại sao không chỉ sử dụng một tham số? Nó không giống như nó khó.

Cuối cùng, tôi sẽ không gọi đây là một lỗi , nhưng tôi sẽ gọi nó là một mùi : một thứ gì đó chỉ giống như một lỗi của chính nó, nhưng là một dấu hiệu mạnh mẽ rằng các lỗi đang ở gần hoặc cuối cùng sẽ là. Mã tốt sẽ tránh để lại mùi và bất kỳ công cụ phân tích tĩnh nào tốt sẽ gắn cờ điều này.

Tôi sẽ nói thêm rằng đây không phải là loại tranh luận mà bạn có thể thắng ngay lập tức. Nghe có vẻ như một tình huống mà "đúng" là không còn đủ và việc đồng nghiệp của bạn cố gắng khắc phục vấn đề này không có khả năng thúc đẩy động lực nhóm tốt; cuối cùng nó có thể làm tổn thương nhiều hơn nó giúp. Một cách tiếp cận tốt hơn trong trường hợp này có thể là thúc đẩy việc sử dụng công cụ phân tích tĩnh. Điều đó sẽ mang lại tính hợp pháp và độ tin cậy cho những nỗ lực nhằm mục đích và quay lại và sửa mã hiện có.

Trong một số trường hợp, có thể thực hiện tấn công SQL injection với các biến không được tham số hóa (nối) khác với giá trị chuỗi - xem bài viết này của Jon: http://codeblog.jonskeet.uk/2014/08/08/the-bobbytables -căn hóa / .

Vấn đề là khi ToStringđược gọi, một số nhà cung cấp văn hóa tùy chỉnh có thể chuyển đổi một tham số không phải là chuỗi thành biểu diễn chuỗi của nó để đưa một số SQL vào truy vấn.

Điều này không an toàn ngay cả đối với các loại không phải chuỗi. Luôn sử dụng các tham số. Giai đoạn = Stage.

Hãy xem xét ví dụ mã sau:

var utcNow = DateTime.UtcNow;
var sqlCommand = new SqlCommand("SELECT * FROM People WHERE created_on <= '" + utcNow + "'");

Thoạt nhìn, mã có vẻ an toàn, nhưng mọi thứ sẽ thay đổi nếu bạn thực hiện một số thay đổi trong Cài đặt khu vực của Windows và thêm nội dung ở định dạng ngày ngắn:

Bây giờ văn bản lệnh kết quả trông giống như sau:

SELECT * FROM People WHERE created_on <= '26.09.2015' OR '1'<>' 21:21:43'

Điều tương tự cũng có thể được thực hiện đối với intkiểu vì người dùng có thể xác định dấu phủ định tùy chỉnh có thể dễ dàng thay đổi thành SQL injection.

Người ta có thể tranh luận rằng nên sử dụng văn hóa bất biến thay vì văn hóa hiện tại, nhưng tôi đã thấy các đoạn nối chuỗi như thế này rất nhiều lần và khá dễ dàng bỏ sót khi nối các chuỗi với các đối tượng đang sử dụng +.

"CHỌN * TỪ Table1 WHERE Id =" + intVariable.ToString ()

Bảo mật
Nó được.
Những kẻ tấn công không thể đưa bất cứ thứ gì vào biến int đã nhập của bạn.

Hiệu suất
không ổn.

Tốt hơn là sử dụng các tham số, vì vậy truy vấn sẽ được biên dịch một lần và được lưu vào bộ nhớ cache để sử dụng tiếp theo. Lần tới, ngay cả với các giá trị tham số khác nhau, truy vấn được lưu vào bộ nhớ cache và không cần biên dịch trong máy chủ cơ sở dữ liệu.

Coding Style
Thực hành không tốt.

• Các thông số dễ đọc hơn
• Có thể nó khiến bạn quen với các truy vấn không có tham số, sau đó có thể bạn đã mắc lỗi một lần và sử dụng giá trị chuỗi theo cách này và sau đó bạn có thể nên tạm biệt dữ liệu của mình. Thói quen xấu!

"CHỌN * TỪ Sản phẩm WHERE Id =" + TextBox1.Text

Mặc dù nó không phải là câu hỏi của bạn, nhưng có thể hữu ích cho những người đọc trong tương lai:

Thảm họa an ninh !
Ngay cả khi Idtrường là số nguyên, truy vấn của bạn có thể bị SQL Injection. Giả sử bạn có một truy vấn trong ứng dụng của mình "SELECT * FROM Table1 WHERE Id=" + TextBox1.Text, Kẻ tấn công có thể chèn vào hộp văn bản 1; DELETE Table1và truy vấn sẽ là:

"SELECT * FROM Table1 WHERE Id=1; DELETE Table1"

Nếu bạn không muốn sử dụng truy vấn được tham số hóa ở đây, bạn nên sử dụng các giá trị đã nhập:

string.Format("SELECT * FROM Table1 WHERE Id={0}", int.Parse(TextBox1.Text))

Câu hỏi của bạn

Câu hỏi của tôi nảy sinh vì một đồng nghiệp đã viết một loạt các truy vấn nối các giá trị số nguyên và tôi đang tự hỏi liệu có lãng phí thời gian của mình để xem qua và sửa tất cả chúng hay không.

Tôi nghĩ rằng việc thay đổi những mã đó không lãng phí thời gian. Thật vậy, thay đổi được khuyến khích!

nếu đồng nghiệp của bạn sử dụng biến int, nó không có rủi ro bảo mật, Nhưng tôi nghĩ rằng việc thay đổi những mã đó không lãng phí thời gian và thực sự nên thay đổi những mã đó. Nó làm cho mã dễ đọc hơn, dễ bảo trì hơn và thực thi nhanh hơn.

Thực ra có hai câu hỏi trong một. Và câu hỏi từ tiêu đề có rất ít liên quan đến mối quan tâm của OP trong các bình luận sau đó.

Mặc dù tôi nhận thấy rằng đối với OP thì vấn đề cụ thể của họ mới là vấn đề quan trọng, đối với độc giả đến từ Google, điều quan trọng là phải trả lời cho câu hỏi tổng quát hơn, có thể được diễn giải là "nối an toàn như các câu đã chuẩn bị sẵn nếu tôi chắc chắn rằng mọi chữ tôi đang nối có an toàn không? ". Vì vậy, tôi muốn tập trung vào phần sau này. Và câu trả lời là

Tất nhiên là không.

Lời giải thích không trực tiếp như hầu hết độc giả mong muốn, nhưng tôi sẽ cố gắng hết sức.

Tôi đã cân nhắc về vấn đề này trong một thời gian, dẫn đến bài viết (mặc dù dựa trên môi trường PHP), nơi tôi đã cố gắng tổng hợp mọi thứ. Tôi nhận ra rằng câu hỏi về việc bảo vệ khỏi SQL injection thường bị né tránh đối với một số chủ đề có liên quan nhưng hẹp hơn, như thoát chuỗi, ép kiểu, v.v. Mặc dù một số biện pháp có thể được coi là an toàn khi tự thực hiện, nhưng không có hệ thống, cũng như quy tắc đơn giản để tuân theo. Điều này làm cho nền đất rất trơn trượt, đặt quá nhiều vào sự chú ý và kinh nghiệm của nhà phát triển.

Câu hỏi về SQL injection không thể được đơn giản hóa thành một vấn đề cú pháp cụ thể nào đó. Nó rộng hơn các nhà phát triển trung bình thường nghĩ. Đó cũng là một câu hỏi về phương pháp luận . Nó không chỉ là "Chúng tôi phải áp dụng định dạng cụ thể nào", mà còn là " Nó phải được thực hiện như thế nào ".

(Từ quan điểm này, một bài báo của Jon Skeet được trích dẫn trong câu trả lời khác đang làm khá tệ hơn là tốt, vì nó lại phản bác một số trường hợp phức tạp, tập trung vào một vấn đề cú pháp cụ thể và không giải quyết được toàn bộ vấn đề.)

Khi bạn đang cố gắng giải quyết câu hỏi bảo vệ không phải toàn bộ mà là một loạt các vấn đề cú pháp khác nhau, bạn đang đối mặt với vô số vấn đề.

• danh sách các lựa chọn định dạng có thể thực sự rất lớn. Có nghĩa là người ta có thể dễ dàng bỏ qua một số. Hoặc nhầm lẫn chúng (bằng cách sử dụng chuỗi thoát cho mã định danh chẳng hạn).
• Kết hợp có nghĩa là tất cả các biện pháp bảo vệ phải được thực hiện bởi lập trình viên, không phải chương trình. Chỉ riêng vấn đề này đã dẫn đến một số hậu quả:
  • định dạng như vậy là thủ công. Thủ công có nghĩa là rất dễ xảy ra lỗi. Đơn giản là người ta có thể quên nộp đơn.
  • hơn nữa, có một sự cám dỗ để di chuyển các thủ tục định dạng vào một số chức năng tập trung, làm mọi thứ rối tung hơn nữa và làm hỏng dữ liệu không được đưa vào cơ sở dữ liệu.
• khi có nhiều nhà phát triển tham gia, các vấn đề sẽ nhân lên với hệ số mười.
• khi phép nối được sử dụng, người ta không thể chỉ ra một truy vấn tiềm ẩn nguy hiểm: tất cả chúng đều tiềm ẩn nguy hiểm!

Không giống như mớ hỗn độn đó, những tuyên bố chuẩn bị thực sự là Chén Thánh:

• nó có thể được diễn đạt dưới dạng một quy tắc đơn giản dễ làm theo.
• về cơ bản nó là biện pháp không thể lưu trữ, có nghĩa là nhà phát triển không thể can thiệp, và dù cố ý hay không cố ý, làm hỏng quá trình.
• bảo vệ khỏi tiêm thực sự chỉ là một tác dụng phụ của các câu lệnh chuẩn bị, mục đích thực sự là tạo ra câu lệnh đúng cú pháp. Và một câu lệnh đúng về mặt cú pháp là bằng chứng tiêm 100%. Tuy nhiên, chúng tôi cần cú pháp của chúng tôi phải chính xác bất chấp khả năng tiêm bất kỳ.
• nếu được sử dụng tất cả các cách xung quanh, nó bảo vệ ứng dụng bất kể kinh nghiệm của nhà phát triển. Nói rằng, có một thứ gọi là tiêm bậc hai . Và một ảo tưởng rất mạnh rằng "để bảo vệ, Thoát khỏi Tất cả Đầu vào do Người dùng Cung cấp ". Kết hợp với nhau, chúng sẽ dẫn đến sự tiêm nhiễm, nếu một nhà phát triển có quyền tự do quyết định, điều gì cần được bảo vệ và điều gì không.

(Suy nghĩ xa hơn, tôi phát hiện ra rằng tập hợp các trình giữ chỗ hiện tại không đủ cho nhu cầu thực tế và phải được mở rộng, cho cả các cấu trúc dữ liệu phức tạp, như mảng và thậm chí cả từ khóa hoặc mã định danh SQL, đôi khi phải được thêm vào truy vấn động cũng vậy, nhưng một nhà phát triển không có vũ khí cho trường hợp như vậy và buộc phải quay lại nối chuỗi nhưng đó là vấn đề của một câu hỏi khác).

Điều thú vị là, tranh cãi của câu hỏi này bị kích động bởi tính chất gây tranh cãi của Stack Overflow. Ý tưởng của trang web là sử dụng các câu hỏi cụ thể từ những người dùng hỏi trực tiếp để đạt được mục tiêu là có cơ sở dữ liệu các câu trả lời cho mục đích chung phù hợp với những người dùng đến từ tìm kiếm . Ý tưởng này không phải là xấu cho mỗi gia nhập , nhưng nó bị lỗi trong một tình huống như thế này: khi người dùng yêu cầu một câu hỏi rất hẹp , đặc biệt là để có được một cuộc tranh cãi trong một tranh chấp với một đồng nghiệp (hoặc quyết định nếu nó có giá trị để cấu trúc lại mã). Trong khi hầu hết những người tham gia có kinh nghiệm đang cố gắng viết câu trả lời, hãy ghi nhớ nhiệm vụ về tổng thể Stack Overflow, làm cho câu trả lời của họ tốt cho càng nhiều người đọc càng tốt, chứ không chỉ OP.

Đừng chỉ nghĩ về các cân nhắc về bảo mật hoặc an toàn kiểu.

Lý do bạn sử dụng truy vấn được tham số hóa là để cải thiện hiệu suất ở cấp cơ sở dữ liệu. Từ góc độ cơ sở dữ liệu, một truy vấn được tham số hóa là một truy vấn trong bộ đệm SQL (để sử dụng thuật ngữ của Oracle mặc dù tôi tưởng tượng rằng tất cả các cơ sở dữ liệu đều có một khái niệm tương tự trong nội bộ). Vì vậy, cơ sở dữ liệu có thể chứa một lượng truy vấn nhất định trong bộ nhớ, được chuẩn bị và sẵn sàng thực thi. Những truy vấn này không cần phải được phân tích cú pháp và sẽ nhanh hơn. Các truy vấn thường xuyên chạy thường sẽ nằm trong bộ đệm và sẽ không cần phân tích cú pháp mỗi khi chúng được sử dụng.

TRỪ KHI

Ai đó không sử dụng truy vấn tham số hóa. Trong trường hợp này, bộ đệm liên tục bị tuôn ra bởi một luồng các truy vấn gần giống hệt nhau, mỗi truy vấn trong số đó cần được phân tích cú pháp và chạy bởi cơ sở dữ liệu và hiệu suất bị ảnh hưởng toàn diện vì các truy vấn chạy thường xuyên cuối cùng cũng được phân tích lại nhiều lần. ngày. Tôi đã điều chỉnh cơ sở dữ liệu để kiếm sống và đây là một trong những nguồn lợi nhuận thấp nhất.

HIỆN NAY

Để trả lời câu hỏi của bạn, NẾU truy vấn của bạn có một số lượng nhỏ các giá trị số riêng biệt, bạn có thể sẽ không gây ra sự cố và thực tế có thể cải thiện hiệu suất một cách nhanh chóng. Tuy nhiên, NẾU có thể có hàng trăm giá trị và truy vấn được gọi rất nhiều, bạn sẽ ảnh hưởng đến hiệu suất của hệ thống, vì vậy đừng làm điều đó.

Có, bạn có thể tăng bộ đệm SQL nhưng cuối cùng nó luôn phải trả giá bằng các cách sử dụng quan trọng khác cho bộ nhớ như bộ nhớ đệm Chỉ mục hoặc Dữ liệu. Về mặt đạo đức, hãy sử dụng các truy vấn được tham số hóa khá tôn giáo để bạn có thể tối ưu hóa cơ sở dữ liệu của mình và sử dụng nhiều bộ nhớ máy chủ hơn cho những thứ quan trọng ...

Để thêm một số thông tin vào câu trả lời Maciek:

Có thể dễ dàng thay đổi thông tin văn hóa của ứng dụng .NET bên thứ ba bằng cách gọi hàm chính của assembly bằng cách phản ánh:

using System;
using System.Globalization;
using System.Reflection;
using System.Threading;

namespace ConsoleApplication2
{
  class Program
  {
    static void Main(string[] args)
    {
      Assembly asm = Assembly.LoadFile(@"C:\BobbysApp.exe");
      MethodInfo mi = asm.GetType("Test").GetMethod("Main");
      mi.Invoke(null, null);
      Console.ReadLine();
    }

    static Program()
    {
      InstallBobbyTablesCulture();
    }

    static void InstallBobbyTablesCulture()
    {
      CultureInfo bobby = (CultureInfo)CultureInfo.InvariantCulture.Clone();
      bobby.DateTimeFormat.ShortDatePattern = @"yyyy-MM-dd'' OR ' '=''";
      bobby.DateTimeFormat.LongTimePattern = "";
      bobby.NumberFormat.NegativeSign = "1 OR 1=1 OR 1=";
      Thread.CurrentThread.CurrentCulture = bobby;
    }
  }
}

Điều này chỉ hoạt động nếu chức năng Chính của BobbysApp là công khai. Nếu Main không công khai, bạn có thể gọi các chức năng công khai khác.

Theo ý kiến ​​của tôi nếu bạn có thể đảm bảo rằng tham số bạn đang làm việc sẽ không bao giờ chứa một chuỗi thì nó sẽ an toàn nhưng tôi sẽ không làm điều đó trong mọi trường hợp. Ngoài ra, bạn sẽ thấy hiệu suất giảm nhẹ do thực tế là bạn đang thực hiện nối. Câu hỏi tôi sẽ hỏi bạn là tại sao bạn không muốn sử dụng các tham số?

Nó ổn nhưng không bao giờ an toàn .. và bảo mật luôn phụ thuộc vào các đầu vào, ví dụ: nếu đối tượng đầu vào là TextBox, những kẻ tấn công có thể làm điều gì đó khó khăn vì hộp văn bản có thể chấp nhận chuỗi, vì vậy bạn phải đặt một số loại xác nhận / chuyển đổi để có thể ngăn người dùng nhập sai. Nhưng có điều, nó không an toàn. Đơn giản là như vậy.

Không, bạn có thể bị tấn công SQL injection theo cách đó. Tôi đã viết một bài báo cũ bằng tiếng Thổ Nhĩ Kỳ cho thấy cách làm ở đây . Ví dụ bài viết trong PHP và MySQL nhưng khái niệm hoạt động giống nhau trong C # và SQL Server.

Về cơ bản bạn tấn công theo cách sau. Hãy coi bạn có một trang hiển thị thông tin theo giá trị id số nguyên. Bạn không tham số này về giá trị, như bên dưới.

http://localhost/sqlEnjeksiyon//instructors.aspx?id=24

Được rồi, tôi giả sử bạn đang sử dụng MySQL và tôi tấn công theo cách sau.

http://localhost/sqlEnjeksiyon//instructors.aspx?id=ASCII((SELECT%20DATABASE()))

Lưu ý rằng ở đây giá trị được đưa vào không phải là chuỗi. Chúng tôi đang thay đổi giá trị char thành int bằng cách sử dụng hàm ASCII. Bạn có thể thực hiện điều tương tự trong SQL Server bằng cách sử dụng "CAST (YourVarcharCol AS INT)".

Sau đó, tôi sử dụng các hàm chiều dài và chuỗi con để tìm về tên cơ sở dữ liệu của bạn.

http://localhost/sqlEnjeksiyon//instructors.aspx?id=LEN((SELECT%20DATABASE()))

http://localhost/sqlEnjeksiyon//instructors.aspx?id=ASCII(SUBSTR(SELECT%20DATABASE(),1,1))

Sau đó, sử dụng tên cơ sở dữ liệu, bạn bắt đầu lấy tên bảng trong cơ sở dữ liệu.

http://localhost/sqlEnjeksiyon//instructors.aspx?id=ASCII(SUBSTR((SELECT table_name FROM INFORMATION_SCHEMA.TABLES LIMIT 1),1,1))

Tất nhiên bạn phải tự động hóa quá trình này, vì bạn chỉ nhận được MỘT ký tự cho mỗi truy vấn. Nhưng bạn có thể dễ dàng tự động hóa nó. Bài viết của tôi cho thấy một ví dụ trong watir . Chỉ sử dụng một trang và không phải giá trị ID được tham số hóa. Tôi có thể tìm hiểu mọi tên bảng trong cơ sở dữ liệu của bạn. Sau đó, tôi có thể tìm kiếm các bảng quan trọng. Nó sẽ mất thời gian nhưng nó có thể làm được.

Chà ... chắc chắn một điều: Bảo mật KHÔNG ĐƯỢC, khi bạn nối một chuỗi (do người dùng lấy) với chuỗi lệnh SQL của bạn. Không có vấn đề gì bất cứ khi nào mệnh đề where đề cập đến một Số nguyên hoặc bất kỳ loại nào; có thể xảy ra tiêm.

Điều quan trọng trong SQL Injection là kiểu dữ liệu của biến được sử dụng để nhận giá trị từ người dùng.

Giả sử chúng ta có một số nguyên trong mệnh đề where và:

1. biến người dùng là một chuỗi. Vậy thì ok, nó không phải là rất dễ dàng để tiêm (sử dụng UNION) nhưng nó rất dễ dàng bỏ qua bằng cách sử dụng 'OR 1 = 1' - như các cuộc tấn công ...

2. Nếu biến người dùng là một số nguyên. Sau đó, một lần nữa, chúng tôi có thể 'kiểm tra' sức mạnh của hệ thống bằng cách vượt qua kiểm tra số lượng lớn bất thường để tìm sự cố hệ thống hoặc thậm chí đối với lỗi tràn bộ đệm ẩn (trên chuỗi cuối cùng) ...;)

Có thể các tham số đối với truy vấn hoặc (thậm chí tốt hơn - imo) đối với Thủ tục được lưu trữ không phải là an toàn 100% về Đe dọa, nhưng chúng là biện pháp ít bắt buộc nhất (hoặc là biện pháp cơ bản nếu bạn muốn) để giảm thiểu chúng.