Czyszczenie danych: najlepsze praktyki z przykładami kodu


15

Próbuję zrozumieć dezynfekcję danych (nie sprawdzanie poprawności danych), aby pomóc mi napisać bezpieczne motywy dla WordPress. Przeszukałem Internet, próbując znaleźć kompleksowy przewodnik dla twórców motywów zawierający szczegółowe informacje na temat najlepszych praktyk. Znalazłem kilka zasobów, w tym stronę kodeksu zatytułowaną „Sprawdzanie poprawności danych”, ale żadne z nich nie było dla mnie przydatne. Strona kodeksu zawiera listę dostępnych funkcji odkażających, ich użycie i to, co robią, ale nie wyjaśnia, dlaczego miałbyś używać jednej z nich w innej sytuacji lub w jakiej sytuacji używałbyś określonej funkcji odkażania. Celem tego postu jest poproszenie wszystkich o podanie przykładów złego / niezaanalizowanego kodu oraz o tym, jak należy go przepisać w celu poprawnej dezynfekcji. Może to być ogólny kod odkażający tytuł posta lub post thumnails src lub bardziej rozbudowany kod, który obsługuje odkażanie$_POST dane dla żądań Ajax.

Ponadto chciałbym wiedzieć, czy funkcje WordPress służące do dodawania / aktualizowania bazy danych (np. Wymienione w poniższym bloku kodu) automatycznie zajmują się czyszczeniem? Jeśli tak, to czy są jakieś wyjątki, kiedy podejmowałbyś dodatkowe środki w celu oczyszczenia danych wysyłanych do tych funkcji WordPress?

add_user_meta
update_user_meta
add_post_meta
update_post_meta
//just to name a few

Czy dezynfekcja HTML w PHP jest inna niż w przypadku wbudowanego HTML? Aby wyjaśnić, o co proszę, oto kod:

<?php echo '<div class="some-div ' . $another_class . '" data-id="' . $id . '" >' . $text . '</div>'; ?>

<div class="some-div <?php echo $another_class; ?>" data-id="<?php echo $id; ?>"><?php echo $text; ?></div>

Oba powyższe stwierdzenia osiągają to samo. Ale czy trzeba je santaryzować inaczej?


1
Mogłoby to pomóc, gdybyśmy wiedzieli, co próbujesz oczyścić. Motywy służą do prezentowania danych ... wystarczy oczyścić dane przesyłane przez użytkownika, a przesyłanie jest zwykle obsługiwane przez wtyczki.
EAMann

@EAMann Funkcje ucieczki, takie jak esc_attr, esc_html itp., Są tworzone w celu ucieczki od wyjścia. Popraw mnie, jeśli się mylę. Prezentowanie danych oznacza, że ​​wysyłasz dane, więc ucieczka jest również wymagana w obrębie motywów. W przeciwnym razie nie byłoby potrzeby korzystania z funkcji esc. Chcę zrozumieć odkażanie w motywach WordPress jako całość i nie ogranicza się do odkażania jednego lub dwóch fragmentów kodu.
John

„Prezentowanie danych oznacza, że ​​wysyłasz dane, więc ucieczka jest również wymagana w ramach tematów” - nie. Ponownie musisz tylko uciec przed danymi, którym nie ufasz
onetrickpony

@OneTrickPony Dla mnie robi się coraz lepiej. Żeby być absolutnie pewnym, że rozumiem to - unikałbym treści komentarza, ale nie unikałbym identyfikatora komentarza ani identyfikatora postu, gdybym miał wydrukować je w HTML. Przepraszam, że naprawdę zadawałem ci pytania jedno po drugim.
John

2
„Musisz tylko uciec przed danymi, którym nie ufasz” - całkowicie się zgadzam. Dodam tylko, że nigdy nie powinieneś ufać danym;)
Ian Dunn

Odpowiedzi:


12

Myślę, że ta strona kodeksu całkiem dobrze to wyjaśnia.

Prawdopodobnie najważniejszą i najczęściej używaną funkcją esc_attr. Weź ten przykład:

<a href="<?php print $author_url; ?>" title="<?php print $author_name; ?>"> 
  <?php print $author_name; ?>
</a>

Jeśli $author_namezawiera "postać, atrybut zostanie zamknięty, a jeśli po onclick="do_something();"niej pojawi się znak , może się pogorszyć :)

Wykonanie print esc_attr($author_name)zapewnia, że ​​takie znaki są zakodowane, a przeglądarka nie robi rzeczy, których nie powinna robić.

Jest jeden przypadek, w którym go nie potrzebujesz: kiedy oczekujesz liczby, w którym to przypadku możesz po prostu rzucić dane wejściowe na liczbę całkowitą, na przykład:

print (int)$_POST['some_number'];


Wymienione tam funkcje meta * już dbają o odkażanie danych wejściowych do przechowywania bazy danych, więc nie musisz się tym martwić.

wpdb->prepare()Metoda musi być stosowana, gdy robisz DB pyta siebie. Oto przykład:

$sql = $wpdb->prepare('
    UPDATE wp_posts SET post_title = %s WHERE ID = %d', 
      $_POST['title'], $_POST['id']);

$wpdb->query($sql);

%sI %dsłowa kluczowe zostaną zastąpione ze swoimi odkażonych wartości $ _POST.

Bardzo częstym błędem, który widzę w wielu wtyczkach w repozytorium WP.org, jest przekazanie do niego już przygotowanego zapytania (i źle przygotowanego), takiego jak:

$wpdb->prepare('UPDATE wp_posts SET post_title = \''.$_POST['title'].' WHERE ...

Nie rób tego :)

Czy dezynfekcja musi być wykonywana inaczej w echo HTML w PHP niż w PHP w HTML?

Oba powyższe stwierdzenia osiągają to samo. Ale czy trzeba je santaryzować inaczej?

Nie.


Dzięki za wkład. Twoje wyjaśnienie wyjaśnia mi wszystko.
Jan

Konieczne jest dalsze wyjaśnienie. Jeśli przekażę ciąg znaków do zmiennej var (np. $ Var = 'string';) w PHP i wywołam echo jako atrybut HTML, czy dezynfekuję $ var podczas echa. Lub odkażanie jest wymagane tylko, jeśli pobrałem wartość $ var z bazy danych.
Jan

Podczas echa na ekranie, w taki czy inny sposób
onetrickpony

Tak więc, jeśli dobrze cię zrozumiałem, czy przekazałem ciąg znaków do $ var w kodzie PHP, czy pobrałem dane z bazy danych i przekazałem do $ var, oba wymagają ode mnie wyjścia. Poprawny?
Jan

Tak, jeśli te dane pochodzą od użytkownika, na przykład nazwisko autora komentarza. Jeśli przez „przekazałeś ciąg znaków do $ var w kodzie PHP” masz na myśli, że przypisałeś znaną wartość zmiennej, to oczywiście - nie, nie musisz dezynfekować tej zmiennej
znaną

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.