Tôi muốn đảm bảo tất cả dữ liệu trong các plugin / chủ đề của tôi được xử lý an toàn trước khi vào cơ sở dữ liệu và trước khi được xuất ra trình duyệt. Vấn đề của tôi là có những tình huống API xử lý việc khử trùng cho bạn - như khi lưu các trường meta bài đăng - và các tình huống khác mà tác giả plugin / chủ đề chịu trách nhiệm hoàn toàn - như khi lưu cài đặt tùy chỉnh.

Đối với phạm vi của câu hỏi này, tôi không quan tâm đến việc xác thực dữ liệu ở cấp tên miền - ví dụ: kiểm tra xem trường Tuổi trên biểu mẫu có từ 0 đến 120 hay địa chỉ email có hợp lệ không. Tôi chỉ quan tâm đến bảo mật - ví dụ: thoát các truy vấn SQL để tránh SQL tiêm khi lưu vào cơ sở dữ liệu hoặc vệ sinh dữ liệu xuất ra các mẫu HTML để tránh XSS.

Để khử trùng đầu ra, tôi biết rằng bạn luôn cần sử dụng các hàm như esc_html()và esc_attr()khi lặp lại các biến thành các mẫu HTML. Nhưng, khi sử dụng thẻ mẫu thì sao? Có phải tất cả họ vệ sinh đầu ra đã? Nếu vậy, đối với bối cảnh nào (HTML chung, thuộc tính thẻ, v.v.)? Một số chức năng có các biến thể cho các bối cảnh khác nhau (như the_title_attribute(), nhưng hầu hết không.

Để khử trùng đầu vào, tôi biết rằng tôi cần sử dụng $wpdb->prepare()khi thực hiện truy vấn thủ công, nhưng khi sử dụng API Cài đặt để tạo trang cài đặt plugin hoặc lưu các trường meta bài đăng cho loại bài đăng tùy chỉnh thì sao?

Ngay bây giờ tôi vừa đào qua Core và đọc hướng dẫn mỗi khi tôi sử dụng một chức năng để tìm hiểu xem nó có vệ sinh hay không, nhưng điều đó dễ bị lỗi và mất thời gian. Tôi hy vọng tìm thấy một số loại danh sách toàn diện về tất cả các tình huống có thể xảy ra và liệu API có xử lý hay không. ví dụ,

API xác nhận / vệ sinh

• Lưu meta bài với update_postmeta()
• Lưu meta người dùng với update_user_meta()
• Xuất ra một tiêu đề bài viết - sử dụng biến thể phù hợp theo ngữ cảnh của the_title()
• Vân vân

Bạn phải xác nhận / vệ sinh bằng tay

• Lưu các tùy chọn plugin với API Cài đặt. Vượt qua một cuộc gọi lại như là tham số thứ 3 của register_setting().
• Truy vấn cơ sở dữ liệu trực tiếp: Gói truy vấn trong $wpdb->prepare().
• Xuất các biến trong HTML. Sử dụng esc_attr(), esc_html(), vv
• Vân vân

Tôi cũng muốn hiểu lý do tại sao API cung cấp nó trong một số tình huống nhất định, nhưng không phải là các API khác. Tôi cho rằng nó có liên quan đến bản chất dữ liệu chưa biết, nhưng rất thích nghe một lời giải thích kỹ lưỡng.

Có hai khái niệm ở đây:

• xác thực - đảm bảo dữ liệu hợp lệ , tức là số nguyên là số nguyên, ngày là ngày (theo đúng định dạng, v.v.). Điều này nên được thực hiện ngay trước khi lưu dữ liệu.
• khử trùng - làm cho ngày an toàn để sử dụng trong bối cảnh hiện tại (ví dụ: thoát các truy vấn SQL hoặc thoát HTML trên đầu ra).

Xác nhận là, hầu như phổ biến, chỉ phụ thuộc vào bạn . Bạn biết dữ liệu nào bạn đang hỏi từ người dùng và bạn biết dữ liệu nào bạn đang mong đợi - WordPress không. Xác thực sẽ được thực hiện, ví dụ, trên save_posthook trước khi lưu nó vào cơ sở dữ liệu update_post_metahoặc có thể được thực hiện thông qua việc chỉ định chức năng gọi lại trong API Cài đặt, được gọi ngay trước khi WordPress lưu dữ liệu.

Vệ sinh là một chút hỗn hợp. Khi xử lý dữ liệu mà WordPress thực sự biết về (ví dụ: ô của bài đăng), bạn có thể chắc chắn rằng WordPress đã làm cho dữ liệu an toàn. Tuy nhiên, "an toàn" tùy thuộc vào ngữ cảnh; những gì an toàn để sử dụng trên một trang, không nhất thiết phải an toàn như một thuộc tính yếu tố. Do đó WordPress sẽ có chức năng khác nhau cho bối cảnh khác nhau (ví dụ the_title(), the_title_rss(), the_title_attribute()) - vì vậy bạn cần phải sử dụng một trong những quyền .

Đối với hầu hết các phần, trình cắm của bạn có thể xử lý meta bài đăng - hoặc có thể dữ liệu sự kiện từ một bảng tùy chỉnh. WordPress không biết dữ liệu này là gì hoặc để làm gì, vì vậy chắc chắn nó không biết cách làm cho nó an toàn. Điều này tùy thuộc vào bạn . Điều này đặc biệt quan trọng trong việc sử dụng esc_url(), esc_attr(), esc_textarea()vv để ngăn chặn đầu vào độc hại từ việc có thể để mã nhúng. Vì WordPress biết next_posts()là giả sử in một url đến trang, nên nó được áp dụng esc_url()- nhưng với meta post, giả sử, nó không biết rằng nó lưu trữ một url - hoặc những gì bạn muốn làm với nó (nếu in esc_url(), nếu chuyển hướng esc_url_raw(). Nếu trong dobut - lỗi ở phía thận trọng và tự thoát khỏi nó - và làm điều này càng muộn càng tốt.

Cuối cùng - còn việc lưu dữ liệu thì sao? Bạn có cần phải làm cho nó an toàn sau đó? Như đã đề cập bạn làm cần thiết để đảm bảo dữ liệu là hợp lệ. Nhưng nếu sử dụng API WordPress ( wp_insert_post(), update_post_meta()v.v.) thì bạn không cần vệ sinh dữ liệu - bởi vì khi lưu dữ liệu, việc vệ sinh duy nhất bạn cần làm là thoát khỏi các câu lệnh SQL - và WordPress thực hiện điều này. Nếu bạn đang chạy các câu lệnh SQL trực tiếp (nói để đọc / ghi dữ liệu từ một bảng tùy chỉnh) thì bạn nên sử dụng $wpdblớp để giúp bạn vệ sinh các truy vấn của mình.

Tôi đã viết bài đăng trên blog này về vệ sinh dữ liệu và xác nhận mà bạn có thể thấy hữu ích - trong đó tôi nói về những gì bạn mong đợi ở khía cạnh này.

Không chắc chắn rằng nó kỹ lưỡng, nhưng với bất kỳ plugin hoặc chủ đề nào, đầu vào của người dùng nên được vệ sinh. Các hoạt động cơ sở dữ liệu nên được thực hiện bằng cách sử dụng các phương thức $ wpdb->. Tất cả dữ liệu $ _GET và $ _POST cần được vệ sinh.

Đây là cách thực hành tốt nhất cho lập trình PHP so với WordPress.

Vì vậy, kết luận, nếu có chức năng WordPress, hãy sử dụng nó, nếu không, hãy tự vệ sinh các biến của bạn và nhập liệu.

Nếu tôi quá mơ hồ, xin vui lòng hỏi một câu hỏi cụ thể hơn.