Khi chúng tôi có dữ liệu từ biểu mẫu của mình, chúng tôi cần thực hiện một số thao tác làm sạch trước khi thực sự có thể gửi dữ liệu đó qua email. Chúng tôi đã hoàn thành một phần việc này bằng cách đưa htmlspecialchars vào yêu cầu POST của mình, nhưng chúng tôi sẽ phải làm thêm một chút nữa để giữ cho dữ liệu sạch sẽ. Chúng tôi sẽ làm theo các bước tương tự để làm sạch ba biến khác nhau của chúng tôi. $from, $subject và $message
Một cách dễ dàng để viết mã mà chúng ta phải lặp lại nhiều lần là sử dụng một hàm
Hãy gọi hàm của chúng ta là clean_data. Nó sẽ chấp nhận dữ liệu thô từ biểu mẫu của chúng tôi, làm sạch nó và trả lại dữ liệu sạch và an toàn mà chúng tôi có thể lưu vào các biến $from, $subject và $message. Nó chấp nhận đầu vào
function cleanPost[$val] {
if[!isset[$_POST[$val]]] {
$_POST[$val] = NULL;
return;
}
$_POST[$val] = trim[htmlentities[$_POST[$val], ENT_QUOTES, 'UTF-8']];
}
3 và xuất dữ liệu đã được làm sạch POST0 [từ khóa POST1 được sử dụng để xuất dữ liệu từ một hàm]Chúng ta nên xác định chức năng của mình ở đầu tập lệnh, ngay sau khi chúng ta khai báo các biến của mình. Sau đó, chúng ta có thể gọi [sử dụng] chức năng của mình khi chúng ta chỉ định $from, $subject và $message
Chính xác thì chúng ta cần chức năng của mình để làm gì? . ] ở đầu hoặc cuối đầu vào của người dùng. PHP thuận tiện đi kèm với một chức năng tích hợp có tên là POST5, chức năng này thực hiện chính xác điều đó
Thứ hai, chức năng của chúng tôi phải đảm bảo dữ liệu được an toàn. Có thể nguy hiểm khi để người dùng viết bất kỳ thứ gì vào hộp văn bản, đặc biệt nếu chúng tôi đang gửi văn bản đó trực tiếp đến hộp thư đến của mình. Ví dụ, một người dùng có thể sử dụng
Làm sạch các biến đầu vào thường là bước mà các nhà phát triển bỏ qua hoặc quên. Bước này có thể quan trọng khi đến lúc ghi nhật ký hoạt động của người dùng, lưu dữ liệu vào cơ sở dữ liệu hoặc bất kỳ hành động quan trọng nào khác mà mã của bạn cần thực thi. Các biến sạch rất quan trọng để ngăn chặn tất cả các loại mục đích xấu khác nhau, chẳng hạn như SQL Injections
Cách dễ dàng để xóa các biến được truyền qua $_POST và $_GET là đặt các lệnh thích hợp trong php. tập tin ini
magic_quotes_gpc = Off magic_quotes_runtime = Off
Nếu bạn không thể sửa đổi php. ini, có một cách đơn giản để khắc phục vấn đề này. Ý tưởng chính của việc làm sạch các biến đầu vào khá đơn giản và nó giúp thoát khỏi dấu ngoặc đơn và dấu ngoặc kép
Đây là một chức năng đơn giản sẽ làm sạch các biến
function cleanPost[$val] {
if[!isset[$_POST[$val]]] {
$_POST[$val] = NULL;
return;
}
$_POST[$val] = trim[htmlentities[$_POST[$val], ENT_QUOTES, 'UTF-8']];
}
Ví dụ, chúng ta phải chèn vào cơ sở dữ liệu chuỗi này
$_POST['comment'] = "This is a long string with \"quotes\" and single 'quotes' including a bold tag";
Nếu bạn không sử dụng "addslasches" để làm sạch biến này, bạn sẽ gặp lỗi SQL và một số người dùng có thể lợi dụng lỗ hổng này
We might be thinking of different meanings of “sanitize.” For example, “O’Neil” might be a validated name, but that doesn’t make it safe for SQL. “” might be valid content [like this post], but that doesn’t make it safe for HTML templates. Even valid content still needs to be escaped.
Vệ sinh là loại bỏ các ký tự không hợp lệ đối với loại dữ liệu cụ thể đó. Sự khác biệt so với việc xác thực là việc xác thực sẽ báo lỗi nếu có các ký tự không hợp lệ thay vì loại bỏ chúng. Thoát đang chuyển đổi các ký tự có ý nghĩa đặc biệt khi mã và dữ liệu được trộn lẫn với nhau [điều này xảy ra khi bạn viết dữ liệu vào HTML chứ không phải với SQL khi mã đi vào câu lệnh chuẩn bị và dữ liệu đi vào câu lệnh liên kết - và do đó thoát không phải là
Vì vậy, "O'Neil" không cần phải thoát vì không có gì trong đó sẽ gây ra sự cố khi nó được đưa vào HTML và trong SQL, nơi nó sẽ gây ra sự cố mà nó không bao giờ cần được đưa vào cùng một câu lệnh như mã
“” does not need to be escaped when written to the database either - but it does need to be escaped if you are writing it into a web page as HTML has no way to keep the data and code separate.
Đầu vào cần được làm sạch nếu nó đến từ nguồn nội bộ [ví dụ: đọc từ cơ sở dữ liệu] và được xác thực nếu nó đến từ người dùng
Đầu ra cần được thoát nếu đích kết hợp lộn xộn mã và dữ liệu với nhau và dữ liệu có thể chứa các ký tự hợp lệ có thể bị hiểu sai thành mã. Nó không cần phải thoát nếu nó không được phép chứa các ký tự có thể bị nhầm lẫn với mã nhưng nó vẫn hữu ích để làm như vậy [phòng thủ sâu]
Không có điểm nào trong việc thoát dữ liệu khi nó được tách biệt khỏi mã, ví dụ: sử dụng các câu lệnh chuẩn bị và liên kết riêng cho các lệnh gọi cơ sở dữ liệu để bất kể dữ liệu chứa gì, nó không thể bị hiểu sai thành mã như trong câu lệnh dữ liệu [liên kết]
Như tôi đã nói trước đây - TẤT CẢ _POST và _GET các trường phải được XÁC NHẬN trước khi bạn chuyển các giá trị ra khỏi các mảng bị nhiễm độc đó sang các biến khác - .
Vâng, đối với tôi, sự nhấn mạnh này cũng quá mạnh và tôi không thực sự đồng ý rằng tất cả các trường _POST và _GET phải được xác thực. Có nhiều trường hợp mình không validate những giá trị đó chỉ vì làm vậy chẳng ích lợi gì, nói cách khác là nó không mang lại lợi ích thiết thực nào nên việc viết code để validate rất phí thời gian. Ví dụ: một trang yêu cầu id số trong $_GET như thế này.
http. //ví dụ. com/article?id=123
Tôi có thể xác thực id nhưng tôi không thực sự cần vì tôi chỉ có thể chuyển nó thành số nguyên và hoàn thành việc đó. Truyền tới số nguyên trong trường hợp này là khử trùng - nó làm cho biến an toàn vì mã của tôi mong đợi một số nguyên. Nếu ai đó gửi ?id=some_garbage, thì không có hại gì cả, giá trị được chuyển thành 0 và sau đó mã của tôi có thể xử lý 0 mà không gặp vấn đề gì vì đây là loại biến hợp lệ [mặc dù nó có thể không phải là id hiện có, mà
Và tôi có thể nghĩ ra nhiều trường hợp khác như thế này khi việc xác thực GET và POST đơn giản là không mang lại bất kỳ lợi ích thiết thực nào. Trên thực tế, trong thực tế, tôi thấy rằng các biến cần được xác thực là thiểu số nhưng tất nhiên điều này sẽ phụ thuộc vào ứng dụng. Trong một số trường hợp nhất định, ngay cả việc khử trùng cũng không cần thiết - ví dụ: khi biến GET được sử dụng làm tiêu chí tìm kiếm trong mệnh đề WHERE trong SQL - trong trường hợp này, không có tác hại nào có thể xảy ra cho dù dữ liệu nào được gửi đi, vì vậy tôi có thể sử dụng biến GET
Vì vậy, để tổng hợp. khử trùng có, nhưng từng biến riêng lẻ tùy thuộc vào ý nghĩa của nó, không bao giờ có số lượng lớn như được đề xuất trong bài đăng đầu tiên tại đây. Ngay cả khi vệ sinh hàng loạt có vẻ như là một phím tắt hay, nó có thể phản tác dụng khi ứng dụng phát triển và sau đó thay đổi nó sẽ yêu cầu tái cấu trúc mã nghiêm túc
Ví dụ: một trang yêu cầu id số trong $_GET như thế này
http. //ví dụ. com/article?id=123
Tôi có thể xác thực id nhưng tôi không thực sự cần vì tôi chỉ có thể chuyển nó thành số nguyên và hoàn thành việc đó. Truyền tới số nguyên trong trường hợp này là khử trùng - nó làm cho biến an toàn vì mã của tôi mong đợi một số nguyên. Nếu ai đó gửi ?id=some_garbage, thì không có hại gì cả, giá trị được chuyển thành 0 và sau đó mã của tôi có thể xử lý 0 mà không gặp vấn đề gì vì đây là loại biến hợp lệ [mặc dù nó có thể không phải là id hiện có, mà
Bạn đang nhận được mục đích xác thực lẫn lộn với bảo mật. Xác thực không phải để bảo mật - đó là để cung cấp thông báo lỗi khi người dùng nhập sai nội dung vào một biểu mẫu
Người dùng có nhập 123 ở đâu đó ngay từ đầu không?
Nếu đó không phải là đầu vào của người dùng thì không cần xác thực [vì chỉ cần xác thực đối với đầu vào của người dùng ].
Trường hợp giá trị đang được chuyển từ một nơi khác mà người dùng không được phép nhập thì mô-đun hiện tại sẽ làm sạch nó - như bạn đang làm bằng cách truyền nó
Xác thực tất cả thông tin nhập của người dùng [để thông báo cho họ biết nếu thông tin họ nhập không hợp lệ]. Điều này không nhằm mục đích bảo mật nhưng có tác dụng phụ là bảo mật.
Khử trùng tất cả đầu vào khác. Điều này là để bảo mật - trong trường hợp dữ liệu đã bị giả mạo.
Thực hiện cả hai điều này trước khi chuyển các giá trị sang biến cục bộ - theo cách đó bạn biết tất cả các biến cục bộ đều không bị ô nhiễm.
thoát bất kỳ biến nào đang được xuất ra lẫn lộn với mã bằng cách sử dụng hàm thoát thích hợp cho loại mã mà bạn đang trộn mã đó.
Không thoát khỏi các biến không bị xáo trộn với mã.
Vì vậy, để quay lại câu hỏi của OP - nếu các giá trị đã được người dùng nhập vào một biểu mẫu và được chuyển từ đó sang tập lệnh thì mỗi trường cần được xác thực theo nội dung được phép chứa. Nếu nó được mã hóa cứng ở trang trước thì nó cần được làm sạch theo nội dung mà từng trường riêng lẻ được phép chứa
Không có quy trình chung để vệ sinh vì TẤT CẢ các ký tự đều hợp lệ ở đâu đó. Vì vậy, quy trình chung mà bạn có thể đưa vào trông như thế này
Bạn không thể sử dụng FILTER_SANITIZE_STRING vì một trong các đầu vào có thể được phép chứa thứ gì đó mà quá trình vệ sinh sẽ loại bỏ