2011-11-17 36 views
5

Đối với nhập email trong một hộp văn bản bởi người sử dụng tôi đang làm kiểm tra phía khách hàng, để tìm xem email có giá trị hay khônglàm thế nào để ngăn chặn SQL Injection trong một trang web asp.net

string emailexist = "SELECT COUNT(DISTINCT UserID) as count FROM tbl_user WHERE [email protected] ";  


    <asp:RegularExpressionValidator ID="RegularExpressionValidator2" ValidationGroup="Login" ControlToValidate="txtUserName" 
          ValidationExpression="\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*" CssClass="Error" 
          runat="server" /> 

là thường xuyên này biểu hiện đủ tốt để ngăn chặn tiêm sql cho email.

chữ khác:

string groupExistQuery = "SELECT COUNT(DISTINCT GroupID) as count FROM tbl_group WHERE [email protected]"; 

Tôi đang làm một truy vấn trong phía máy chủ để kiểm tra xem tên nhóm nhập vào bởi người sử dụng đã có sẵn trong cơ sở dữ liệu, có một khả năng mạnh mẽ để thực hiện tiêm sql đây. Làm thế nào tôi nên ngăn chặn nó.

+1

Tôi nghĩ chúng tôi đã được hơn này: không sử dụng thẻ 'asp'. –

+0

@ JoelCoehoorn - Tôi thực sự muốn thảo luận về meta đã dẫn đến 'asp' được thay đổi thành' asp-classic': ( – Polynomial

+0

+1 chỉ để hỏi –

Trả lời

8

Một regex là không liên quan để chèn SQL (danh sách đen, v.v. không bao giờ là cách tiếp cận mạnh nhất); tuy nhiên, việc sử dụng tham số @Email có nghĩa là (giả sử nó vẫn là được tham số hóa) là không dễ bị tiêm SQL.

Chèn SQL liên quan đến việc ghép nối đầu vào không phù hợp; công cụ chính để chống lại nó là các thông số đã xảy ra ở đây.

Ví dụ, nếu bạn đã làm:

var sql = "SELECT ...snip... WHERE Email='" + email + "'"; // BAD!!!!! 

sau đó rằng là nặng nề dễ bị SQL injection. Bằng cách sử dụng một tham số, giá trị không được coi là một phần của truy vấn, vì vậy kẻ tấn công không có vector tấn công.

+1

Điều này đúng trên hầu hết các ngôn ngữ (và không phải tất cả) ngôn ngữ và hệ thống DBMS. truy vấn hầu như luôn là giải pháp tốt nhất.Tôi không thể đếm số lần tôi đã nhìn thấy ai đó sử dụng mã xác nhận tùy chỉnh và sau đó có một cái nhìn bất ngờ kinh hoàng khi ai đó truy cập chúng với một 'DROP BẢNG'. – Polynomial

4

Bạn có thể ngăn chặn bằng cách không sử dụng Direct SQL và sử dụng truy vấn được tham số hóa và/hoặc Thủ tục được lưu trữ thay thế.

6

Nếu bạn sử dụng giá trị được tham số hóa, bạn sẽ không sao, bạn không thể tiêm thông qua thông số, chỉ thông qua các giá trị được nối.

0

Here là thư trả lời từ Microsoft Pattern & Nhóm thực tiễn cho câu hỏi của bạn.

Nói chung, quy tắc đơn giản là: không sử dụng tạo SQL động và nếu bạn làm, hãy khử trùng đầu vào của bạn.

Không bao giờ chỉ nối các chuỗi để tạo truy vấn SQL của bạn. Nếu bạn cần xây dựng một truy vấn của riêng bạn trong ứng dụng của bạn, sau đó sử dụng các truy vấn SQL parametrized với các tham số - theo cách này bạn đang ở bên an toàn.

Dưới đây là một ví dụ từ các tài liệu tôi cung cấp các liên kết đến trên:

DataSet userDataset = new DataSet(); 
    SqlDataAdapter myCommand = new SqlDataAdapter( 
      "LoginStoredProcedure", connection); 
    myCommand.SelectCommand.CommandType = CommandType.StoredProcedure; 
    myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11); 
    myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text; 

    myCommand.Fill(userDataset); 
+0

Nhận xét của tôi đã được giải quyết. Tiếp tục :) –

+0

Sử dụng các thông số an toàn loại chỉ là cách để khử trùng đầu vào của bạn, theo ý kiến ​​của tôi. –

+0

Xem nhận xét của tôi về câu trả lời của Mark. Lọc tùy chỉnh không thể tính đến mọi đường dẫn SQL injection có thể, bao gồm tất cả các cú pháp, mã hóa và thủ thuật mà kẻ tấn công sẽ tìm ra. Tôi đã thấy mọi người thử điều này, và một số đã rất thông minh với việc lọc của họ, nhưng mỗi lần tôi thấy nó kết thúc trong thảm họa khi hệ thống của họ bị buộc tội. Truy vấn tham số là giải pháp tuyệt đối vì chúng xử lý các giá trị dưới dạng dữ liệu trong ngữ cảnh được phân tách hoàn toàn và không bao giờ có thể được phân tích cú pháp dưới dạng mã. – Polynomial

1
  1. Sử dụng parameterised giá trị
  2. Mã hóa chuỗi của bạn
+1

với trọng tâm nặng, nặng trên 1; tùy chọn 2 là thứ gì đó nhiều nhất ** sẽ ** sai. Cá nhân, tôi sẽ giới hạn bất kỳ việc sử dụng nào 2 đối với các giá trị được liệt kê trắng rõ ràng (thay vì được liệt kê bằng màu đen) –

+0

@MarcGravell - Đồng ý. Việc chuyển đổi sang các loại thích hợp sẽ cảnh báo bạn về vấn đề định dạng, nhưng chắc chắn đó không phải là biện pháp bảo mật. – Polynomial

+0

Mã hóa Html không ngăn chặn một số cuộc tấn công – user182630

Các vấn đề liên quan