Tôi có phải đề phòng việc tiêm SQL nếu tôi sử dụng trình đơn thả xuống không?

Tôi hiểu rằng bạn KHÔNG BAO GIỜ nên tin tưởng đầu vào của người dùng từ một biểu mẫu, chủ yếu là do cơ hội đưa vào SQL.

Tuy nhiên, điều này có áp dụng cho biểu mẫu mà đầu vào duy nhất là từ (các) danh sách thả xuống (xem bên dưới) không?

Tôi đang lưu $_POST['size']vào một Phiên mà sau đó được sử dụng trên toàn trang web để truy vấn các cơ sở dữ liệu khác nhau (với mysqlitruy vấn Chọn) và bất kỳ nội dung SQL nào chắc chắn sẽ gây hại (có thể làm rơi) chúng.

Không có khu vực cho đầu vào của người dùng đã nhập để truy vấn cơ sở dữ liệu, chỉ có (các) danh sách thả xuống.

<form action="welcome.php" method="post">
<select name="size">
  <option value="All">Select Size</option> 
  <option value="Large">Large</option>
  <option value="Medium">Medium</option>
  <option value="Small">Small</option>
</select>
<input type="submit">
</form>

Bạn có thể làm điều gì đó đơn giản như ví dụ sau để đảm bảo kích thước được đăng là những gì bạn mong đợi.

$possibleOptions = array('All', 'Large', 'Medium', 'Small');

if(in_array($_POST['size'], $possibleOptions)) {
    // Expected
} else {
    // Not Expected
}

Sau đó, sử dụng mysqli_ * nếu bạn đang sử dụng phiên bản php> = 5.3.0 mà bạn nên sử dụng để lưu kết quả của mình. Nếu được sử dụng đúng cách này sẽ giúp tiêm sql.

Có bạn cần phải bảo vệ chống lại điều này.

Hãy để tôi chỉ cho bạn lý do tại sao sử dụng bảng điều khiển dành cho nhà phát triển của Firefox:

Nếu bạn không làm sạch dữ liệu này, cơ sở dữ liệu của bạn sẽ bị phá hủy. (Đây có thể không phải là một câu lệnh SQL hoàn toàn hợp lệ, nhưng tôi hy vọng tôi đã hiểu rõ ý của mình.)

Chỉ vì bạn đã giới hạn những tùy chọn có sẵn trong menu thả xuống không có nghĩa là bạn đã giới hạn dữ liệu tôi có thể gửi cho máy chủ của bạn.

Nếu bạn đã cố gắng hạn chế hành vi này hơn nữa bằng cách sử dụng hành vi trên trang của mình, các tùy chọn của tôi bao gồm vô hiệu hóa hành vi đó hoặc chỉ viết một yêu cầu HTTP tùy chỉnh đến máy chủ của bạn để bắt chước gửi biểu mẫu này. Có một công cụ được gọi là curl được sử dụng cho chính xác điều đó và tôi nghĩ rằng lệnh để gửi SQL injection này sẽ trông giống như sau:

curl --data "size=%27%29%3B%20DROP%20TABLE%20*%3B%20--"  http://www.example.com/profile/save

(Đây có thể không phải là một lệnh curl hoàn toàn hợp lệ, nhưng một lần nữa, tôi hy vọng tôi đã hiểu rõ ý của mình.)

Vì vậy, tôi sẽ nhắc lại:

KHÔNG BAO GIỜ tin tưởng đầu vào của người dùng. LUÔN LUÔN bảo vệ chính mình.

Đừng cho rằng bất kỳ đầu vào của người dùng nào là an toàn. Nó có khả năng không an toàn ngay cả khi nó đến thông qua một số phương tiện khác ngoài biểu mẫu. Không ai trong số đó đủ tin cậy để từ bỏ việc bảo vệ bạn khỏi SQL injection.

Vì câu hỏi này đã được gắn thẻ sql-tiêm, đây là câu trả lời liên quan đến loại tấn công cụ thể này:

Như bạn đã được nói trong phần nhận xét, bạn phải sử dụng các câu lệnh đã chuẩn bị sẵn cho mọi truy vấn liên quan đến bất kỳ dữ liệu biến nào, không có ngoại lệ .

Bất kể nội dung HTML nào!
Điều cần thiết là phải hiểu rằng các truy vấn SQL phải được định dạng đúng cách bất kể yếu tố bên ngoài nào, có thể là đầu vào HTML hay bất kỳ thứ gì khác.

Mặc dù bạn có thể sử dụng danh sách trắng được đề xuất trong các câu trả lời khác cho mục đích xác thực đầu vào, nó sẽ không ảnh hưởng đến bất kỳ hành động nào liên quan đến SQL - chúng phải giữ nguyên, bất kể bạn có xác thực đầu vào HTML hay không. Nó có nghĩa là bạn vẫn phải sử dụng các câu lệnh đã chuẩn bị sẵn khi thêm bất kỳ biến nào vào truy vấn.

Ở đây, bạn có thể tìm thấy một lời giải thích cặn kẽ, tại sao các câu lệnh đã chuẩn bị là điều bắt buộc và cách sử dụng chúng đúng cách và chúng không áp dụng được ở đâu và phải làm gì trong trường hợp đó: Hướng dẫn Bảo vệ SQL Injection của Hitchhiker

Ngoài ra, câu hỏi này đã được gắn thẻ với mysqli. Tôi đoán chủ yếu là do tình cờ, nhưng dù sao, tôi phải cảnh báo bạn rằng mysqli thô không phải là một sự thay thế thích hợp cho các hàm mysq_ * cũ . Đơn giản vì nếu sử dụng theo kiểu cũ thì sẽ thêm phần không bảo mật. Mặc dù việc hỗ trợ cho các câu lệnh đã chuẩn bị rất khó khăn và rắc rối, nhưng người dùng PHP trung bình không thể cố gắng hết sức. Vì vậy, nếu không có ORM hoặc một số loại thư viện trừu tượng là tùy chọn, thì PDO là lựa chọn duy nhất của bạn.

Đúng.

Bất kỳ ai cũng có thể giả mạo bất kỳ thứ gì để lấy các giá trị thực sự được gửi -

VẬY, để xác thực menu thả xuống, bạn chỉ có thể kiểm tra để đảm bảo rằng giá trị mà bạn đang làm việc nằm trong menu thả xuống - một cái gì đó như thế này sẽ là cách tốt nhất (hoang tưởng nhất):

if(in_array($_POST['ddMenu'], $dropDownValues){

    $valueYouUseLaterInPDO = $dropDownValues[array_search("two", $arr)];

} else {

    die("effin h4x0rs! Keep off my LAMP!!"); 

}

Một cách để bảo vệ khỏi việc người dùng thay đổi trình đơn thả xuống của bạn bằng cách sử dụng bảng điều khiển là chỉ sử dụng các giá trị số nguyên trong đó. Sau đó, bạn có thể xác thực rằng giá trị POST chứa một số nguyên và sử dụng một mảng để chuyển đổi giá trị đó thành văn bản khi cần. Ví dụ:

<?php
// No, you don't need to specify the numbers in the array but as we're using them I always find having them visually there helpful.
$sizes = array(0 => 'All', 1 => 'Large', 2 => 'Medium', 3 => 'Small');
$size = filter_input(INPUT_POST, "size", FILTER_VALIDATE_INT);

echo '<select name="size">';
foreach($sizes as $i => $s) {
    echo '<option value="' . $i . '"' . ($i == $size ? ' selected' : '') . '>' . $s . '</option>';
}
echo '</select>';

Sau đó, bạn có thể sử dụng $sizetrong truy vấn của mình với kiến ​​thức rằng nó sẽ chỉ chứa FALSEhoặc một số nguyên.

Các câu trả lời khác đã bao gồm những gì bạn cần biết. Nhưng có thể nó sẽ giúp làm sáng tỏ thêm một số điều:

Có hai điều bạn cần làm:

1. Xác thực dữ liệu biểu mẫu.

Như câu trả lời của Jonathan Hobbs cho thấy rất rõ ràng, việc lựa chọn phần tử html cho đầu vào biểu mẫu không thực hiện bất kỳ bộ lọc đáng tin cậy nào đối với bạn.

Việc xác thực thường được thực hiện theo cách không làm thay đổi dữ liệu, nhưng sẽ hiển thị lại biểu mẫu, với các trường được đánh dấu là "Vui lòng sửa lỗi này".

Hầu hết các khuôn khổ và CMS đều có trình tạo biểu mẫu giúp bạn thực hiện nhiệm vụ này. Và không chỉ vậy, chúng còn giúp chống lại CSRF (hoặc "XSRF"), là một dạng tấn công khác.

2. Dọn dẹp / Thoát biến trong câu lệnh SQL ..

.. hoặc để các câu lệnh chuẩn bị sẵn thực hiện công việc cho bạn.

Nếu bạn xây dựng một câu lệnh SQL (của Tôi) với bất kỳ biến nào, do người dùng cung cấp hoặc không, bạn cần phải thoát và trích dẫn các biến này.

Nói chung, bất kỳ biến nào như vậy bạn chèn vào một câu lệnh MySQL phải là một chuỗi hoặc một cái gì đó mà PHP có thể biến một cách đáng tin cậy thành một chuỗi mà MySQL có thể tiêu hóa. Chẳng hạn như, các con số.

Đối với chuỗi, sau đó bạn cần chọn một trong một số phương pháp để thoát khỏi chuỗi, nghĩa là thay thế bất kỳ ký tự nào sẽ có tác dụng phụ trong MySQL.

• Trong MySQL + PHP cũ, mysql_real_escape_string () thực hiện công việc. Vấn đề là nó quá dễ quên, vì vậy bạn hoàn toàn nên sử dụng các câu lệnh đã chuẩn bị sẵn hoặc trình tạo truy vấn.
• Trong MySQLi, bạn có thể sử dụng các câu lệnh đã chuẩn bị sẵn.
• Hầu hết các khuôn khổ và CMS đều cung cấp các trình tạo truy vấn giúp bạn thực hiện nhiệm vụ này.

Nếu bạn đang xử lý một số, bạn có thể bỏ qua lối thoát và dấu ngoặc kép (đây là lý do tại sao các câu lệnh đã chuẩn bị cho phép chỉ định một kiểu).

Điều quan trọng là phải chỉ ra rằng bạn thoát khỏi các biến cho câu lệnh SQL và KHÔNG cho chính cơ sở dữ liệu . Cơ sở dữ liệu sẽ lưu trữ chuỗi gốc, nhưng câu lệnh cần phiên bản thoát.

Điều gì xảy ra nếu bạn bỏ qua một trong những điều này?

Nếu bạn không sử dụng xác thực biểu mẫu , nhưng bạn làm sạch đầu vào SQL của mình, bạn có thể thấy tất cả các loại lỗi đang xảy ra, nhưng bạn sẽ không thấy SQL injection! (*)

Đầu tiên, nó có thể đưa ứng dụng của bạn vào trạng thái mà bạn không dự kiến. Ví dụ: nếu bạn muốn tính độ tuổi trung bình của tất cả người dùng, nhưng một người dùng đã cho "aljkdfaqer" cho độ tuổi, thì phép tính của bạn sẽ không thành công.

Thứ hai, có thể có tất cả các loại tấn công tiêm khác mà bạn cần xem xét: Ví dụ: đầu vào của người dùng có thể chứa javascript hoặc những thứ khác.

Vẫn có thể xảy ra sự cố với cơ sở dữ liệu: Ví dụ: nếu một trường (cột trong bảng cơ sở dữ liệu) bị giới hạn ở 255 ký tự và chuỗi dài hơn thế. Hoặc nếu trường chỉ chấp nhận số và bạn cố gắng lưu một chuỗi không phải số. Nhưng đây không phải là "tiêm", nó chỉ là "crash ứng dụng".

Tuy nhiên, ngay cả khi bạn có trường văn bản miễn phí, nơi bạn cho phép bất kỳ đầu vào nào mà không cần xác thực, bạn vẫn có thể lưu trường này vào cơ sở dữ liệu giống như vậy, nếu bạn thoát nó đúng cách khi nó chuyển đến câu lệnh cơ sở dữ liệu. Vấn đề xảy ra khi bạn muốn sử dụng chuỗi này ở đâu đó.

(*) hoặc đây sẽ là một cái gì đó thực sự kỳ lạ.

Nếu bạn không thoát khỏi các biến cho câu lệnh SQL , nhưng bạn đã xác thực đầu vào biểu mẫu, thì bạn vẫn có thể thấy điều tồi tệ xảy ra.

Đầu tiên, bạn có nguy cơ khi bạn lưu dữ liệu vào cơ sở dữ liệu và tải lại, nó sẽ không còn là dữ liệu như cũ nữa, "mất bản chất".

Thứ hai, nó có thể dẫn đến các câu lệnh SQL không hợp lệ và do đó làm hỏng ứng dụng của bạn. Ví dụ: nếu bất kỳ biến nào chứa một dấu ngoặc kép hoặc ký tự dấu ngoặc kép, tùy thuộc vào loại dấu ngoặc kép bạn sử dụng, bạn sẽ nhận được câu lệnh MySQL không hợp lệ.

Thứ ba, nó vẫn có thể gây ra SQL injection.

Nếu đầu vào của người dùng của bạn từ các biểu mẫu đã được lọc / xác thực, thì việc đưa vào SQl có chủ đích có thể trở nên ít xảy ra hơn, NẾU đầu vào của bạn bị giảm thành danh sách tùy chọn được mã hóa cứng hoặc nếu nó bị giới hạn ở số. Nhưng bất kỳ kiểu nhập văn bản miễn phí nào cũng có thể được sử dụng cho SQL injection, nếu bạn không thoát đúng các biến trong câu lệnh SQL.

Và ngay cả khi bạn hoàn toàn không có đầu vào biểu mẫu, bạn vẫn có thể có các chuỗi từ tất cả các loại nguồn: Đọc từ hệ thống tệp, cóp nhặt từ internet, v.v. Không ai có thể đảm bảo rằng các chuỗi này an toàn.

Trình duyệt web của bạn không "biết" rằng nó đang nhận một trang từ php, tất cả những gì nó thấy là html. Và lớp http còn biết ít hơn thế. Bạn cần có khả năng xử lý gần như bất kỳ loại đầu vào nào có thể vượt qua lớp http (may mắn là đối với hầu hết các đầu vào php sẽ báo lỗi). Nếu bạn đang cố gắng ngăn các yêu cầu độc hại làm rối db của mình, thì bạn cần phải giả định rằng người ở đầu dây bên kia biết anh ta đang làm gì và anh ta không bị giới hạn những gì bạn có thể thấy trong trình duyệt của mình trong các trường hợp bình thường ( chưa kể bạn có thể làm gì với các công cụ dành cho nhà phát triển của trình duyệt). Vì vậy, có, bạn cần cung cấp cho bất kỳ đầu vào nào từ trình đơn thả xuống của mình, nhưng đối với hầu hết các đầu vào, bạn có thể đưa ra lỗi.

Thực tế là bạn đã hạn chế người dùng chỉ sử dụng các giá trị từ một danh sách thả xuống nhất định là không liên quan. Người dùng kỹ thuật có thể nắm bắt yêu cầu http được gửi đến máy chủ của bạn trước khi nó rời khỏi mạng của họ, thay đổi nó bằng một công cụ như máy chủ proxy cục bộ, sau đó tiếp tục thực hiện. Sử dụng yêu cầu đã thay đổi, họ có thể gửi các giá trị tham số không phải là giá trị mà bạn đã chỉ định trong danh sách thả xuống. Các nhà phát triển phải có suy nghĩ rằng các hạn chế của khách hàng thường là vô nghĩa, vì bất kỳ thứ gì trên máy khách đều có thể bị thay đổi. Xác thực máy chủ được yêu cầu tại mỗi điểm mà dữ liệu máy khách nhập vào. Những kẻ tấn công dựa vào sự ngây thơ của các nhà phát triển trong khía cạnh duy nhất này.

Tốt nhất là sử dụng một truy vấn được tham số hóa để đảm bảo chống lại việc đưa vào SQL. Trong trường hợp đó, giao diện của truy vấn sẽ là:

SELECT * FROM table WHERE size = ?

Khi bạn cung cấp một truy vấn như trên với văn bản chưa được xác minh về tính toàn vẹn (đầu vào không được xác thực trên máy chủ) và nó chứa mã chèn SQL thì nó sẽ được xử lý chính xác. Nói cách khác, yêu cầu sẽ dẫn đến một cái gì đó như thế này xảy ra trong lớp cơ sở dữ liệu:

SELECT * FROM table WHERE size = 'DROP table;'

Thao tác này sẽ chỉ chọn 0 kết quả vì nó trả về, điều này sẽ làm cho truy vấn không hiệu quả trong thực tế gây hại cho cơ sở dữ liệu mà không cần danh sách trắng, kiểm tra xác minh hoặc các kỹ thuật khác. Xin lưu ý rằng một lập trình viên có trách nhiệm sẽ thực hiện bảo mật trong các lớp và thường sẽ xác thực ngoài việc tham số hóa các truy vấn. Tuy nhiên, có rất ít lý do để không tham số hóa các truy vấn của bạn từ góc độ hiệu suất và tính bảo mật được bổ sung bởi phương pháp này là một lý do chính đáng để bạn làm quen với các truy vấn được tham số hóa.

Bất cứ thứ gì được gửi từ biểu mẫu của bạn sẽ đến máy chủ của bạn dưới dạng văn bản trên dây. Không có gì ngăn cản bất cứ ai tạo ra một bot để bắt chước khách hàng hoặc nhập nó từ một thiết bị đầu cuối nếu họ muốn. Đừng bao giờ cho rằng bởi vì bạn đã lập trình ứng dụng khách, nó sẽ hoạt động như bạn nghĩ. Điều này thực sự dễ dàng để giả mạo.

Ví dụ về những gì có thể và sẽ xảy ra khi bạn tin tưởng khách hàng.

Một hacker hoàn toàn có thể vượt qua trình duyệt, bao gồm cả kiểm tra biểu mẫu Javascript, bằng cách gửi yêu cầu bằng Telnet. Tất nhiên, anh ta sẽ xem mã của trang html của bạn để lấy tên trường mà anh ta phải sử dụng, nhưng từ đó trở đi, mọi thứ sẽ xảy ra với anh ta. Vì vậy, bạn phải kiểm tra tất cả các giá trị được gửi trên máy chủ như thể chúng không bắt nguồn từ trang html của bạn.