Đầu ngày hôm nay, một câu hỏi đã được đặt ra về các chiến lược xác thực đầu vào trong các ứng dụng web .
Câu trả lời hàng đầu, tại thời điểm viết bài, gợi ý PHPchỉ bằng cách sử dụng htmlspecialcharsvà mysql_real_escape_string.
Câu hỏi của tôi là: Điều này luôn luôn đủ? Có nhiều hơn nữa chúng ta nên biết? Các chức năng này bị hỏng do đâu?
Câu trả lời:
Khi nói đến các truy vấn cơ sở dữ liệu, hãy luôn thử và sử dụng các truy vấn được tham số sẵn. Các mysqlivà PDOcác thư viện hỗ trợ này. Điều này vô cùng an toàn hơn so với việc sử dụng các chức năng thoát như mysql_real_escape_string.
Vâng, mysql_real_escape_stringthực sự chỉ là một hàm thoát chuỗi. Nó không phải là một viên đạn ma thuật. Tất cả những gì nó sẽ làm là thoát các ký tự nguy hiểm để chúng có thể an toàn khi sử dụng trong một chuỗi truy vấn duy nhất. Tuy nhiên, nếu bạn không làm sạch đầu vào của mình trước thì bạn sẽ dễ bị tấn công bởi một số vectơ tấn công.
Hãy tưởng tượng câu lệnh SQL sau:
$result = "SELECT fields FROM table WHERE id = ".mysql_real_escape_string($_POST['id']);Bạn có thể thấy rằng điều này rất dễ bị khai thác.
Hãy tưởng tượng idtham số chứa vector tấn công phổ biến:
1 OR 1=1Không có ký tự rủi ro nào trong đó để mã hóa, vì vậy nó sẽ đi thẳng qua bộ lọc thoát. Để lại cho chúng tôi:
SELECT fields FROM table WHERE id= 1 OR 1=1Đây là một vectơ SQL injection đáng yêu và sẽ cho phép kẻ tấn công trả lại tất cả các hàng. Hoặc là
1 or is_admin=1 order by id limit 1sản xuất
SELECT fields FROM table WHERE id=1 or is_admin=1 order by id limit 1Điều này cho phép kẻ tấn công trả lại thông tin chi tiết của quản trị viên đầu tiên trong ví dụ hoàn toàn hư cấu này.
Mặc dù các chức năng này hữu ích nhưng chúng phải được sử dụng cẩn thận. Bạn cần đảm bảo rằng tất cả các đầu vào web đều được xác thực ở một mức độ nào đó. Trong trường hợp này, chúng tôi thấy rằng chúng tôi có thể bị khai thác vì chúng tôi đã không kiểm tra xem biến chúng tôi đang sử dụng dưới dạng số có thực sự là số hay không. Trong PHP, bạn nên sử dụng rộng rãi một tập hợp các hàm để kiểm tra xem đầu vào có phải là số nguyên, float, chữ và số, v.v. Nhưng khi nói đến SQL, hầu hết đều chú ý đến giá trị của câu lệnh đã chuẩn bị. Đoạn mã trên sẽ được bảo mật nếu nó là một câu lệnh được chuẩn bị sẵn vì các hàm cơ sở dữ liệu sẽ biết rằng đó 1 OR 1=1không phải là một chữ hợp lệ.
Đối với htmlspecialchars(). Đó là một bãi mìn của riêng nó.
Có một vấn đề thực sự trong PHP là nó có toàn bộ lựa chọn các hàm thoát khác nhau liên quan đến html và không có hướng dẫn rõ ràng về chính xác hàm nào làm những gì.
Thứ nhất, nếu bạn đang ở bên trong thẻ HTML, bạn đang gặp rắc rối thực sự. Nhìn vào
echo '<img src= "' . htmlspecialchars($_GET['imagesrc']) . '" />';Chúng ta đã ở trong thẻ HTML, vì vậy chúng ta không cần <hoặc> làm bất cứ điều gì nguy hiểm. Véc tơ tấn công của chúng tôi có thể làjavascript:alert(document.cookie)
Bây giờ HTML kết quả trông giống như
<img src= "javascript:alert(document.cookie)" />Cuộc tấn công được thông qua.
Nó trở nên tồi tệ hơn. Tại sao? bởi vì htmlspecialchars(khi được gọi theo cách này) chỉ mã hóa dấu ngoặc kép chứ không mã hóa đơn. Vì vậy, nếu chúng ta có
echo "<img src= '" . htmlspecialchars($_GET['imagesrc']) . ". />";Kẻ tấn công xấu xa của chúng ta giờ có thể đưa các thông số hoàn toàn mới vào
pic.png' onclick='location.href=xxx' onmouseover='...cho chúng tôi
<img src='pic.png' onclick='location.href=xxx' onmouseover='...' />Trong những trường hợp này, không có viên đạn ma thuật nào cả, bạn chỉ cần tự đánh đầu vào. Nếu bạn cố gắng và lọc ra những ký tự xấu chắc chắn bạn sẽ thất bại. Thực hiện cách tiếp cận danh sách trắng và chỉ thông qua các ký tự tốt. Xem bảng gian lận XSS để biết các ví dụ về mức độ đa dạng của các vectơ
Ngay cả khi bạn sử dụng htmlspecialchars($string)bên ngoài các thẻ HTML, bạn vẫn dễ bị tấn công bởi các vectơ tấn công bộ ký tự nhiều byte.
Hiệu quả nhất mà bạn có thể đạt được là sử dụng kết hợp mb_convert_encoding và htmlentities như sau.
$str = mb_convert_encoding($str, 'UTF-8', 'UTF-8');
$str = htmlentities($str, ENT_QUOTES, 'UTF-8');Thậm chí, điều này còn khiến IE6 dễ bị tấn công, do cách nó xử lý UTF. Tuy nhiên, bạn có thể quay trở lại mã hóa hạn chế hơn, chẳng hạn như ISO-8859-1, cho đến khi việc sử dụng IE6 giảm xuống.
Để có nghiên cứu chuyên sâu hơn về các vấn đề multibyte, hãy xem https://stackoverflow.com/a/12118602/1820
$result = "SELECT fields FROM table WHERE id = '".mysql_real_escape_string($_POST['id'])."'";2. Trong trường hợp thứ hai (thuộc tính chứa URL), không có tác dụng htmlspecialcharsgì cả; trong những trường hợp này, bạn nên mã hóa đầu vào bằng lược đồ mã hóa URL, ví dụ: sử dụng rawurlencode. Bằng cách đó, người dùng không thể chèn javascript:et al.
Take a whitelist approach and only let through the chars which are good.Một danh sách đen sẽ luôn luôn bỏ sót một cái gì đó. +1
Ngoài câu trả lời xuất sắc của Cheekysoft:
Không thực sự là một viên đạn bạc để ngăn chặn việc đưa HTML vào (ví dụ: viết mã trang web chéo), nhưng bạn có thể đạt được điều đó dễ dàng hơn nếu bạn đang sử dụng thư viện hoặc hệ thống tạo khuôn mẫu để xuất HTML. Đọc tài liệu về điều đó để biết cách thoát khỏi mọi thứ một cách thích hợp.
Trong HTML, mọi thứ cần được thoát khác nhau tùy thuộc vào ngữ cảnh. Điều này đặc biệt đúng với các chuỗi được đặt vào Javascript.
Tôi chắc chắn sẽ đồng ý với các bài viết trên, nhưng tôi có một điều nhỏ cần bổ sung để trả lời câu trả lời của Cheekysoft, cụ thể:
Khi nói đến các truy vấn cơ sở dữ liệu, hãy luôn thử và sử dụng các truy vấn được tham số sẵn. Thư viện mysqli và PDO hỗ trợ điều này. Điều này vô cùng an toàn hơn so với việc sử dụng các hàm thoát như mysql_real_escape_string.
Có, mysql_real_escape_string thực chất chỉ là một hàm thoát chuỗi. Nó không phải là một viên đạn ma thuật. Tất cả những gì nó sẽ làm là thoát các ký tự nguy hiểm để chúng có thể an toàn khi sử dụng trong một chuỗi truy vấn duy nhất. Tuy nhiên, nếu bạn không làm sạch đầu vào của mình trước thì bạn sẽ dễ bị tấn công bởi một số vectơ tấn công.
Hãy tưởng tượng câu lệnh SQL sau:
$ result = "CHỌN các trường TỪ bảng WHERE id =" .mysql_real_escape_string ($ _ POST ['id']);
Bạn sẽ có thể thấy rằng điều này rất dễ bị khai thác. Hãy tưởng tượng tham số id chứa vector tấn công phổ biến:
1 HOẶC 1 = 1
Không có ký tự rủi ro nào trong đó để mã hóa, vì vậy nó sẽ đi thẳng qua bộ lọc thoát. Để lại cho chúng tôi:
CHỌN trường TỪ bảng WHERE id = 1 HOẶC 1 = 1
Tôi đã mã hóa một hàm nhỏ nhanh chóng mà tôi đặt trong lớp cơ sở dữ liệu của mình để loại bỏ bất cứ thứ gì không phải là số. Nó sử dụng preg_replace, do đó, có một chức năng tối ưu hơn một chút, nhưng nó hoạt động không tốt ...
function Numbers($input) {
$input = preg_replace("/[^0-9]/","", $input);
if($input == '') $input = 0;
return $input;
}Vì vậy, thay vì sử dụng
$ result = "CHỌN các trường TỪ bảng WHERE id =" .mysqlrealescapestring ("1 HOẶC 1 = 1");
tôi sẽ dùng
$ result = "CHỌN các trường TỪ bảng WHERE id =" .Numbers ("1 HOẶC 1 = 1");
và nó sẽ chạy truy vấn một cách an toàn
CHỌN trường TỪ bảng WHERE id = 111
Chắc chắn, điều đó chỉ ngăn nó hiển thị đúng hàng, nhưng tôi không nghĩ rằng đó là một vấn đề lớn đối với những ai đang cố gắng đưa sql vào trang web của bạn;)
return preg_match('/^[0-9]+$/',$input) ? $input : 0;
Một phần quan trọng của câu đố này là bối cảnh. Ai đó gửi "1 OR 1 = 1" dưới dạng ID không phải là vấn đề nếu bạn trích dẫn mọi đối số trong truy vấn của mình:
SELECT fields FROM table WHERE id='".mysql_real_escape_string($_GET['id'])."'"Kết quả là:
SELECT fields FROM table WHERE id='1 OR 1=1'mà là không hiệu quả. Vì bạn đang thoát chuỗi, đầu vào không thể thoát ra khỏi ngữ cảnh chuỗi. Tôi đã thử nghiệm điều này với phiên bản 5.0.45 của MySQL và việc sử dụng ngữ cảnh chuỗi cho cột số nguyên không gây ra bất kỳ sự cố nào.
$result = "SELECT fields FROM table WHERE id = ".(INT) $_GET['id'];Hoạt động tốt, thậm chí tốt hơn trên hệ thống 64 bit. Tuy nhiên, hãy cẩn thận với những hạn chế hệ thống của bạn trong việc giải quyết số lượng lớn, nhưng đối với id cơ sở dữ liệu, điều này hoạt động hiệu quả 99%.
Bạn cũng nên sử dụng một chức năng / phương pháp duy nhất để làm sạch các giá trị của mình. Ngay cả khi hàm này chỉ là một trình bao bọc cho mysql_real_escape_string (). Tại sao? Bởi vì một ngày nào đó khi một phương pháp khai thác dữ liệu ưa thích của bạn được tìm thấy, bạn chỉ phải cập nhật nó ở một nơi, thay vì tìm và thay thế trên toàn hệ thống.
tại sao, oh TẠI SAO, bạn sẽ không bao gồm dấu ngoặc kép xung quanh đầu vào của người dùng trong câu lệnh sql của bạn? có vẻ khá ngớ ngẩn không! bao gồm dấu ngoặc kép trong câu lệnh sql của bạn sẽ làm cho "1 hoặc 1 = 1" một nỗ lực không có kết quả, phải không?
vì vậy bây giờ, bạn sẽ nói, "điều gì sẽ xảy ra nếu người dùng bao gồm một dấu ngoặc kép (hoặc dấu ngoặc kép) trong đầu vào?"
tốt, sửa chữa dễ dàng cho điều đó: chỉ cần xóa dấu ngoặc kép do người dùng nhập. ví dụ: input =~ s/'//g;. bây giờ, dường như đối với tôi, đầu vào của người dùng sẽ được bảo mật ...