Htmlentities vs addslashes vs mysqli_real_escape_string

Question

Tôi đã thực hiện một số đọc về bảo mật các ứng dụng PHP, và dường như với tôi rằng mysqli_real_escape_string là chức năng chính xác để sử dụng khi chèn dữ liệu vào bảng MySQL vì addslashes có thể gây ra một số điều kỳ lạ xảy ra kẻ tấn công thông minh. Đúng?

Tuy nhiên, có một điều khiến tôi khó hiểu. Tôi dường như nhớ rằng việc được thông báo addslashes tốt hơn htmlentities khi lặp lại dữ liệu do người dùng nhập lại cho người dùng để bảo vệ dữ liệu của họ, nhưng có vẻ như addslashes là người có lỗ hổng. Điều này đúng hay tôi nhớ không chính xác?

Answer 1

Có các ngữ cảnh khác nhau cho dữ liệu của bạn. Ngữ cảnh chèn dữ liệu vào cơ sở dữ liệu cần phải được thoát khác với ngữ cảnh hiển thị html/xml hoặc thậm chí là thông báo email.

Dữ liệu thoát vào một db sẽ không được chấp nhận trong tất cả mã mới có lợi cho các câu lệnh được chuẩn bị. Bất cứ ai nói với bạn bằng cách khác là làm bạn một sự bất hòa lớn.

Dữ liệu thoát vào trình duyệt cần phải được thoát theo một số cách khác nhau tùy thuộc vào mục tiêu. Đôi khi htmlspecialchars là đủ, đôi khi bạn cần phải sử dụng htmlentities. Đôi khi bạn cần các thực thể dạng số. Đó là một chủ đề bạn nên làm một số nghiên cứu về để biết tất cả các sắc thái.

Quy tắc chung tôi đang sống là xác thực (không lọc, từ chối nếu không chính xác) đầu vào & đầu ra thoát (dựa trên ngữ cảnh).

Answer 2

Bạn cũng có thể sử dụng số PDO libs mà hầu hết các lần thoát cho bạn, trong trường hợp bạn có thể sử dụng PHP5 trên máy chủ.

Hồi âm lại, cá nhân tôi thích htmlspecialchars hơn, nhưng người ta có thể sửa tôi

Answer 3

Chúng là các công cụ khác nhau cho các mục đích khác nhau.

mysqli_real_escape_string làm cho dữ liệu an toàn để chèn vào MySQL (nhưng các truy vấn được tham số tốt hơn).

htmlentities làm cho dữ liệu an toàn cho xuất ra thành một tài liệu HTML

addslashes làm cho an toàn trong một vài tình huống khác dữ liệu, nhưng không đủ để MySQL

Answer 4

có, sử dụng mysqli_real_escape_string hoặc một thư viện như PDO trên tất cả các người sử dụng đầu vào. Khi lặp lại, tôi sử dụng htmlentities với ENT_QUOTES làm tham số thứ hai, vì nó thoát tất cả các ký tự có thể áp dụng cho các thực thể html của chúng, bao gồm cả dấu ngoặc kép.

Answer 5

Lưu ý: Bạn nên tránh sử dụng htmlentities() trong tài liệu được mã hóa UTF-8.Xem:

• Interfacing with Systems using other Charsets
• Common Problem Areas with UTF-8

Chú ý đến (trích dẫn từ phpwact.org):

Với các trình duyệt web hiện đại và hỗ trợ widespead cho UTF-8, bạn don' t cần htmlentities vì ​​tất cả các ký tự này có thể được biểu diễn trực tiếp trong UTF-8. Quan trọng hơn, trong chung, chỉ các trình duyệt mới hỗ trợ các ký tự đặc biệt của HTML - một văn bản bình thường trình chỉnh sửa, chẳng hạn, không biết về các đối tượng HTML . Tùy thuộc vào những gì bạn đang làm, sử dụng htmlentities có thể giảm khả năng của các hệ thống khác thành "tiêu thụ" nội dung của bạn.

Ngoài ra (không được xác nhận nhưng có vẻ hợp lý - từ anon bình luận ở đây), thực thể ký tự (những thứ như thế »hay -) không hoạt động khi một tài liệu được phục vụ như application/xml + xhtml (trừ khi bạn xác định chúng). Tuy nhiên, bạn vẫn có thể lấy đi bằng biểu mẫu dạng số.

Answer 6

Một giải pháp thú vị cho PHP 5.2 trở lên là sử dụng phần mở rộng lọc: http://www.php.net/manual/en/book.filter.php

Nó cho phép bạn xác nhận và khử trùng đầu vào người dùng. Có rất nhiều bộ lọc tích hợp sẵn có và chúng có thể được kết hợp với cờ để tinh chỉnh hành vi của chúng. Ngoài ra bộ lọc hese cũng có thể được sử dụng để xác nhận/khử trùng ints, float, email, biểu thức chính quy cụ thể.

Cá nhân tôi đã bắt đầu sử dụng chúng trong các dự án của mình để xác thực biểu mẫu và xuất dữ liệu do người dùng nhập và tôi rất vui vì tôi đã làm. Mặc dù, khi tôi chèn các giá trị trong cơ sở dữ liệu MySQL, tôi sử dụng các truy vấn đã chuẩn bị để tăng cường bảo mật. Các giải pháp này cùng nhau có thể giúp tránh được hầu hết các lần tiêm SQL và các cuộc tấn công kiểu XSS.

Answer 7

Bạn không thể có một chức năng "thoát" và mong muốn nó hoạt động mọi lúc. Có những cuộc tấn công khác nhau đòi hỏi thói quen vệ sinh cụ thể. Cách duy nhất để hiểu khái niệm này là viết một số mã dễ bị tổn thương và sau đó khai thác nó. Viết mã khai thác là rất quan trọng đối với sự hiểu biết của bất kỳ hệ thống bảo mật nào.

Ví dụ truy vấn này là dễ bị SQL injection:

$host=htmlspecialchars($_GET[host],ENT_QUOTES); 
$name=htmlspecialchars($_GET[name],ENT_QUOTES); 
mysql_query("select * from user where Host='$host' and Name='$name' "); 

Khai thác: http://localhost/sqli_test.php?host= \ & name =% 20sleep (20) -% 201

Chức năng thoát tốt nhất cho mysql được mysqli_real_escape_string() nhưng điều này có thể không thành công:

mysql_query("select * from user where id=".mysqli_real_escape_string($_GET[id])); 

khai thác: http://localhost/sqli_test.php?id=1%20or%20sleep(20)

Trong thực tế, cách tốt nhất để chăm sóc tiêm sql không gọi là một chức năng thoát, nó sử dụng các yêu cầu parametrized ADODB cho tiêm sql. Sử dụng htmlspecialcahrs ($ var, ENT_QUTOES) cho XSS.Đọc số OWASP top 10 vì có rất nhiều thứ có thể sai với bảo mật ứng dụng web.