Chcę się upewnić, że wszystkie dane w moich wtyczkach / motywach są bezpiecznie obsługiwane przed wejściem do bazy danych i przed wysłaniem do przeglądarki. Mój problem polega na tym, że istnieją sytuacje, w których interfejs API zajmuje się czyszczeniem dla Ciebie - na przykład podczas zapisywania pól meta - i inne, w których autor wtyczki / motywu jest w pełni odpowiedzialny za to - na przykład podczas zapisywania ustawień niestandardowych.

Jeśli chodzi o zakres tego pytania, nie martwię się o sprawdzanie poprawności danych na poziomie domeny - np. Sprawdzanie, czy pole Wiek w formularzu ma wartość od 0 do 120 lub czy adres e-mail jest prawidłowy. Martwię się tylko o bezpieczeństwo - np. Unikanie zapytań SQL, aby uniknąć wstrzyknięcia SQL podczas zapisywania do bazy danych, lub czyszczenie danych, które są wyprowadzane do szablonów HTML, aby uniknąć XSS.

Dla wyjścia sanityzacji, wiem, że zawsze trzeba korzystać z funkcji takich jak esc_html()i esc_attr()kiedy echo'ing zmiennych do szablonów HTML. Ale co z użyciem tagów szablonów ? Czy wszyscy już oczyszczają produkt? Jeśli tak, to w jakim kontekście (ogólny HTML, atrybuty znaczników itp.)? Niektóre funkcje mają warianty dla różnych kontekstów (jak the_title_attribute(), ale większość nie.

W przypadku dezynfekcji danych wejściowych wiem, że muszę tego używać $wpdb->prepare()podczas ręcznego wysyłania zapytań, ale co z używaniem interfejsu API ustawień do utworzenia strony ustawień wtyczki lub zapisaniem pól meta post dla niestandardowego typu postu?

W tej chwili właśnie przeglądałem Core i czytałem tutoriale za każdym razem, gdy korzystam z funkcji, aby dowiedzieć się, czy się odkaża, czy nie, ale jest to podatne na błędy i czasochłonne. Mam nadzieję znaleźć jakąś kompleksową listę wszystkich możliwych sytuacji i tego, czy API to obsługuje, czy nie. na przykład,

API sprawdza / odkaża

• Zapisywanie meta postu za pomocą update_postmeta()
• Zapisywanie meta użytkownika za pomocą update_user_meta()
• Wypisywanie tytułu postu - użyj odpowiedniego kontekstowo wariantu the_title()
• itp

Musisz ręcznie sprawdzić poprawność / odkażać

• Zapisywanie opcji wtyczki za pomocą interfejsu API ustawień. Przekaż wywołanie zwrotne jako trzeci parametr parametru register_setting().
• Bezpośrednie zapytania do bazy danych: Zawiń zapytanie $wpdb->prepare().
• Wyprowadzanie zmiennych w HTML. Zastosowanie esc_attr(), esc_html()itp
• itp

Byłbym również zainteresowany, aby zrozumieć, dlaczego interfejs API zapewnia go w niektórych sytuacjach, ale nie w innych. Zakładam, że ma to związek z nieznaną naturą danych, ale chciałbym usłyszeć dokładne wyjaśnienie.

Istnieją tutaj dwie koncepcje:

• walidacja - upewnienie się, że dane są poprawne , tzn. liczba całkowita jest liczbą całkowitą, data jest datą (w odpowiednim formacie itp.). Należy to zrobić tuż przed zapisaniem danych.
• sanitisation - czyni datę bezpieczną do użycia w bieżącym kontekście (np. ucieczka zapytań SQL lub ucieczka HTML na wyjściu).

Walidacja, prawie ogólnie, zależy wyłącznie od Ciebie . Wiesz, jakich danych żądasz od użytkownika i wiesz, jakich danych oczekujesz - WordPress nie. Sprawdzanie poprawności zostanie przeprowadzone na przykład na save_posthaku przed zapisaniem go w bazie danych update_post_meta, lub można to zrobić poprzez określenie funkcji zwrotnej w API ustawień, wywoływanej tuż przed zapisaniem danych przez WordPress.

Sanityzacja jest nieco bardziej mieszana. W przypadku danych, o których WordPress natywnie wie (np. Kafelek wpisu), możesz mieć pewność, że WordPress już zapewnił bezpieczeństwo danych. Jednak „bezpieczny” zależy od kontekstu; to, co jest bezpieczne do użycia na stronie, niekoniecznie jest bezpieczne jako atrybut elementu. Stąd WordPress mają różne funkcje dla różnych kontekstach (np the_title(), the_title_rss(), the_title_attribute()) - więc trzeba użyć właściwy .

W przeważającej części wtyczka może zajmować się post meta - a może danymi zdarzeń z niestandardowej tabeli. WordPress nie wie, czym są te dane i do czego służą, więc z pewnością nie wie, jak je zabezpieczyć. To zależy od ciebie . Jest to szczególnie ważne w użyciu esc_url(), esc_attr(), esc_textarea()etc aby zapobiec niewłaściwemu wejście od mogąc kod do umieszczenia na stronie. Ponieważ WordPress wie, next_posts()że powinien wydrukować adres URL strony, ma zastosowanie esc_url()- ale w przypadku meta post, powiedzmy, nie wie, że przechowuje adres URL - lub co chcesz z nim zrobić (jeśli drukujesz esc_url(), jeśli przekierowujesz) esc_url_raw(). Jeśli w dobut - zachowaj ostrożność i uniknij go sam - i zrób to tak późno, jak to możliwe.

Wreszcie - co z zapisywaniem danych? Czy musisz więc uczynić to bezpiecznym? Jak wspomniano wy zrobić potrzebę, aby upewnić danych jest poprawny. Ale jeśli za pomocą API (WordPress wp_insert_post(), update_post_meta()etc), wtedy nie trzeba zdezynfekować danych - bo podczas zapisywania danych tylko odkażania trzeba robić jest ucieczka SQL - i robi to WordPress. Jeśli korzystasz z bezpośrednich instrukcji SQL (powiedzmy do odczytu / zapisu danych z niestandardowej tabeli), powinieneś użyć tej $wpdbklasy, aby pomóc w odkażaniu zapytań.

Napisałem ten post na blogu dotyczący oczyszczania i sprawdzania poprawności danych, które mogą okazać się pomocne - w nim mówię o tym, czego się od ciebie oczekuje pod tym względem.

Nie jestem pewien, czy jest to tak dokładne, ale w przypadku dowolnej wtyczki lub motywu dane użytkownika powinny zostać oczyszczone. Operacje na bazie danych powinny być wykonywane przy użyciu metod $ wpdb->. Wszystkie dane $ _GET i $ _POST powinny zostać zdezynfekowane.

Jest to najlepsza praktyka programowania PHP niż WordPress.

Podsumowując, jeśli istnieje funkcja WordPress, użyj jej, jeśli nie, odkaż swoje zmienne i wprowadź dane samodzielnie.

Gdybym był zbyt niejasny, proszę zadać bardziej szczegółowe pytanie.