Korzystając z WordPressa, czy ktoś może mi powiedzieć, jaki jest najlepszy sposób dezynfekcji wejścia?

Question

Korzystając z WordPressa, czy ktoś może mi powiedzieć, jaki jest najlepszy sposób dezynfekcji wejścia?

Rozwijam aplikację wykorzystującą Wordpress jako CMS.

Mam formularz z dużą ilością pól wejściowych, który należy wyczyścić przed zapisaniem w bazie danych.
Chcę zapobiec SQL injection, o kod javascript i PHP injected i innych szkodliwych kodu.

Obecnie używam własnych metod do dezynfekcji danych, ale uważam, że lepiej byłoby użyć funkcji, których używa WP.

Przeglądałem walidację danych w WordPressie, ale nie jestem pewien na ile tych funkcji powinienem używać i w jakiej kolejności. Czy ktoś może powiedzieć jakie funkcje WP są najlepsze do wykorzystania?

Obecnie "odkażam" swój wkład, wykonując następujące czynności:

Ponieważ znaki z akcentami (é, ô, æ, ø, å) zostały w zabawny sposób zapisane w bazie danych (mimo że moje tabele są ustawione na ENGINE=InnoDB, DEFAULT CHARSET=utf8 i COLLATE=utf8_danish_ci), jestem teraz konwertowanie pól wejściowych, które mogą mieć akcenty, za pomocą htmlentities ().
Podczas tworzenia ciągu SQL do wprowadzania danych, używam mysql_real_escape_string().

Myślę, że to nie wystarczy, aby zapobiec atakom. Tak więc sugestie dotyczące poprawy są bardzo mile widziane.

14

php wordpress sanitize

Author: Steven, 2010-01-24

Source

1 answers

score 16 · Accepted Answer

Wejście "sanityzacja" jest fałszywe.

Nie powinieneś próbować chronić się przed problemami z wtryskiem poprzez filtrowanie (*) lub unikanie danych wejściowych, powinieneś pracować z surowymi łańcuchami, dopóki nie umieścisz ich w innym kontekście. W tym momencie potrzebujesz poprawnej funkcji ucieczki dla tego kontekstu, która jest mysql_real_escape_string dla zapytań MySQL i htmlspecialchars dla wyjścia HTML.

(WordPress dodaje własne funkcje ucieczki, takie jak esc_html, które w zasadzie nie różnią się.)

( * : No, z wyjątkiem wymagania specyficzne dla aplikacji, takie jak sprawdzanie adresu e-mail jest tak naprawdę adresem e-mail, upewnienie się, że hasło jest rozsądne i tak dalej. Istnieje również rozsądny argument za odfiltrowaniem znaków sterujących na etapie wejściowym, chociaż rzadko się to robi.)

Konwertuję teraz pola wejściowe, które mogą mieć akcenty, używając htmlentities ().

Zdecydowanie odradzam. Twoja baza danych powinna zawierać surowy tekst; znacznie utrudniasz to operacje bazy danych na kolumnach, jeśli zakodowałeś je jako HTML. Unikasz znaków, takich jak < i " w tym samym czasie, co znaki inne niż ASCII. Kiedy pobierasz dane z bazy danych i używasz ich z innego powodu niż kopiowanie ich na stronę, masz teraz fałszywe ucieczki HTML w danych. Nie unikaj HTML-escape aż do ostatniego momentu pisania tekstu na stronę.

Jeśli masz problemy z wprowadzaniem znaków innych niż ASCII do bazy danych, jest to inny problem które należy rozwiązać najpierw zamiast iść do niezrównoważonych obejść, takich jak przechowywanie danych zakodowanych w HTML. Jest tu wiele postów o tym, aby PHP i bazy danych mówiły poprawnie o UTF-8, ale najważniejsze jest, aby upewnić się, że same strony wyjściowe HTML są poprawnie serwowane jako UTF-8 za pomocą Content-Type header/meta. Następnie sprawdź, czy Twoje połączenie MySQL jest ustawione na UTF-8, np. za pomocą mysql_set_charset().

Podczas tworzenia ciągu SQL do wprowadzania danych, używam mysql_real_escape_string().

Tak, zgadza się. Tak długo, jak to robisz, nie jesteś podatny na SQL injection. Możesz być podatny na HTML-injection (powodujący XSS), jeśli na końcu bazy danych zamiast na końcu wyjścia szablonu jest HTML-escaping. Ponieważ każdy ciąg znaków, który nie przeszedł przez bazę danych (np. fetched directly from $_GET) will ' t have been HTML-Escape.