Có một số nhầm lẫn ở đây, bởi vì không phải tất cả trong số này là xác nhận, có 2 điều khác là cần thiết để hiểu những gì phù hợp:
- Thẩm định
- khử trùng
- thoát
Vệ sinh
Vệ sinh làm cho mọi thứ sạch sẽ và hình thành tốt
Việc này sẽ dọn sạch dữ liệu, ví dụ như cắt xén các khoảng trắng ở cuối, xóa các chữ cái trong trường số, làm cho tất cả các trường chữ thường đều là chữ thường, v.v.
Ví dụ: Người dùng đã nhập " Banana "
, vì vậy hãy biến nó thành"Banana"
Khử trùng là điều đầu tiên nên xảy ra với đầu vào đến từ một nơi khác, ví dụ như khi xử lý một biểu mẫu, vệ sinh dữ liệu trước khi làm bất cứ điều gì với nó. Giống nhau của bất kỳ dữ liệu nào đến từ một kết nối từ xa, v.v.
Các phương pháp vệ sinh phổ biến bao gồm:
- tước bỏ HTML hoặc các thẻ cụ thể thông qua
wp_kses
wp_strip_all_tags
vv
- Xóa phạm vi ký tự, chẳng hạn như ký tự không phải là số hoặc dấu chấm câu
- Cắt xén các ký tự như dấu cách
- Áp dụng các giới hạn như giới hạn giá trị trong phạm vi (thay vào đó có thể được thực hiện dưới dạng kiểm tra xác thực)
Thẩm định
Kiểm tra xác nhận nếu mọi thứ là hợp lệ
Xác nhận kiểm tra xem số điện thoại người dùng đã nhập thực sự là số điện thoại. Đó là một true
hoặc false
kiểm tra.
Vd: Là trái cây người dùng chọn thực sự là một loại trái cây?
Điều này nên được thực hiện trên đầu vào sau khi vệ sinh và nếu xác nhận thất bại, hủy bỏ, các phương thức xác nhận phổ biến bao gồm:
- chức năng như
is_numeric
vv
- biểu thức thông thường, hữu ích cho những thứ như số điện thoại hoặc URL, những thứ có định dạng mong đợi
- kiểm tra vai trò và khả năng để xác minh người dùng thực sự có khả năng thực hiện hành động dự định
- kiểm tra nonce
- danh sách trắng các giá trị được phép xác định trước
- kiểm tra các giá trị nằm trong phạm vi hợp lệ, ví dụ: không ai có số điện thoại dài 200 ký tự, cũng không có ai sống ở số nhà
-2000000
Chạy trốn
Thoát làm cho các giá trị an toàn cho đầu ra và thực thi các giả định
Thoát muộn, trốn thường xuyên.
Chạy trốn không được nói nhiều, nhưng hãy tưởng tượng nó sử dụng ví dụ trái cây từ trên cao. Thoát hiểm giống như một băng chuyền với hình trái cây được cắt ra. Bạn luôn nhận được một cái gì đó hình trái cây ở cuối. Nếu một quả đi qua, nó không bị ảnh hưởng, nhưng nếu một diễn viên độc hại đi qua, một phiên bản hình trái cây xù xì nhưng an toàn sẽ xuất hiện.
Vì vậy, thoát là tất cả về thực thi các giả định. Ví dụ: trong <a>
thẻ, href
thuộc tính phải chứa URL. Nhưng điều này có thể không phải là trường hợp, thoát cho phép chúng ta hoán đổi "nên chứa" thành "sẽ luôn chứa", cung cấp cho chúng ta một sự đảm bảo. Điều này ngăn ai đó bắt đầu URL của họ bằng "/>
và chèn HTML tùy ý.
Việc thoát luôn phải được thực hiện ở đầu ra , tại điểm mới nhất có thể để đảm bảo không có gì được sửa đổi. Thoát cũng là bối cảnh nhạy cảm. Bạn sẽ sử dụng esc_attr
để thoát các thuộc tính HTML, nhưng nếu đó là thuộc tính href
hoặc src
thuộc tính, chúng tôi sẽ sử dụng esc_url
để chỉ ra đó là URL mà chúng tôi dự định xuất ra.
Lưu ý về Thoát hiểm kép và wp_kses
Bạn có thể vệ sinh và xác nhận nhiều lần, nhưng bạn chỉ nên thoát một giá trị một lần. Điều này là do thoát kép có thể mã hóa gấp đôi giá trị và trong một số trường hợp có thể cho phép nội dung thoát ra khỏi thoát.
wp_kses_post
và wp_kses
cũng khác thường ở chỗ chúng có thể được sử dụng để trốn thoát và vệ sinh và có thể được sử dụng nhiều lần trên một giá trị.
Lưu ý về việc bỏ trốn sớm
Đây là một tội lỗi gần như có thể hoàn tác mọi thứ thoát ra mang lại cho bạn. Khi một cái gì đó đã được thoát, chúng ta biết rằng nó an toàn và an toàn để xuất nó, nhưng , nếu sau đó chúng ta gán nó cho một biến, ai biết điều gì có thể xảy ra với nó giữa thoát và đầu ra. Nếu biến đó được sửa đổi, được chuyển đến một hàm hoặc được dẫn qua bộ lọc, nó không còn an toàn nữa, trạng thái của nó là một bí ẩn. Chúng tôi có thể thoát nó một lần nữa nhưng bây giờ chúng tôi đã thoát gấp đôi, vì vậy chúng tôi có thể khiến dữ liệu an toàn trở nên nguy hiểm hoặc thu thập dữ liệu tốt.
Vậy về những bộ lọc đó
Chúng ta có nên vệ sinh và xác nhận apply_filters()
giống như các ví dụ dưới đây?
Nó phụ thuộc vào ngữ cảnh
Về đầu vào:
- Vệ sinh
- sau đó xác nhận
- nếu nó hợp lệ thì tiếp tục, từ chối
Trên đầu ra cho trình duyệt / request / etc:
- bạn có thể vệ sinh và xác thực một khi đã tìm nạp từ cơ sở dữ liệu nếu muốn, nhưng ưu tiên số 1 là thoát, chỉ thoát một lần và thực hiện ngay khi xuất. Đừng lưu trữ nó trong một biến, đó là thoát sớm và nó nguy hiểm
- Thoát sau khi lọc, không phải trước đó, ai biết bộ lọc đã làm gì với giá trị an toàn đã biết, một khi giá trị được trả về từ bộ lọc thì trạng thái và an toàn của nó là một bí ẩn
absint( apply_filters( 'slug_excerpt_length', 35 ) );
Tuyệt vời bây giờ chúng ta biết giá trị này chắc chắn là một con số, và một số tích cực quá. Nếu chúng ta đặt tiền tố cho câu lệnh này echo
thì đó là một giá trị thoát an toàn. Khác, đó chỉ là vệ sinh làm sạch giá trị.
wp_kses_post( apply_filters( 'slug_excerpt_more', '…' ) );
Tuyệt vời, đây là cả vệ sinh và thoát nếu chúng ta xuất ngay lập tức, nhưng nếu chúng ta lưu nó vào một biến, thì đó chỉ là vệ sinh.
esc_url( apply_filters( 'slug_login_url', home_url( '/' ) ) );
Đây là thoát, và cần một echo
tuyên bố. Nếu chúng ta gán giá trị này cho một biến thì việc thoát là vô ích và chúng tôi đưa ra một tình huống bấp bênh.
Nếu câu hỏi là, chúng ta có nên kiểm tra lại các giá trị trả về của các bộ lọc không? Vâng, đó sẽ là khôn ngoan, nhưng quá thận trọng. Trong kịch bản đó, tôi hy vọng rằng điều này sẽ được thử nghiệm cho các bộ lọc không được triển khai đúng cách, ví dụ: trả lại văn bản nơi dự kiến sẽ có một số. Trong kịch bản đó, xác nhận là lựa chọn duy nhất, thoát và khử trùng sẽ không phù hợp.
Ngoại lệ
- Khi sử dụng
the_content
bộ lọc, chuyển giá trị qua wp_kses_post
rồi chuyển nó vào bộ lọc và ngay lập tức echo, vdecho apply_filters( 'the_content', wp_kses_post( $dangerous ) );
- Trong mã ngắn, thoát và sử dụng bộ đệm đầu ra nếu bạn phải, để bạn có thể trả về một chuỗi