WordPress wypuszcza aktualizację – SQL injection

Wczoraj udostępniona została aktualizacja WordPressa (4.8.3), która po raz drugi łata problemy z SQL injection (poprzednia nieudana – jak się okazało – próba była w 4.8.2).

Dziwi też zachowanie załogi WordPressa, która początkowo na zgłoszenie odpowiadała zgodnie z zasadą „spieprzaj dziadu”. Czy mamy gdzieś Twoje zgłoszenie, nie poprawimy. Dopiero groźba tzw. full disclosure (który zresztą macie w pierwszym linku tego posta) zadziałał na wyobraźnię deweloperów WordPressa i zabrali się za łatanie (które zajęło… 6 tygodni).

Do rzeczy – obecnie zalecaną i niezależną od języka programowania metodą ochrony przed podatnością SQL injection jest użycie zapytań parametryzowanych. To jakaś magiczna sztuczka chroniąca przed SQLi? ;-) Oczywiście nie – trzeba jeszcze przy tym chwilę pomyśleć. Przykład zapytania parametryzowanego:

$stmt = $dbh->prepare("SELECT * FROM users WHERE USERNAME = ? AND PASSWORD = ?");
$stmt->execute(array($username, $pass));

Jest ono bezpieczne, ale co się stanie jeśli zrobimy coś takiego?

$stmt = $dbh->prepare("SELECT * FROM users WHERE USERNAME = ? AND PASSWORD = ? $dodatkowa_wartosc_pochodzaca_od_uzytkownika");
$stmt->execute(array($username, $pass));

Stanie się tyle, że nasza aplikacja jest podatna na SQL injection. Wniosek – nie przekazywać żadnych dynamicznych wartości pochodzących od użytkownika do ->prepare (!).

Co z WordPressem? Tutaj z jakiegoś powodu twórcy wytworzyli własną funkcję odpowiedzialną za zapytania parametryzowane. Działa ona na zasadzie match & replace. Czyli np. %s podstawiany jest odpowiednią wartością. Podatny przykład z WordPress core (/wp-includes/meta.php):

if ( $delete_all ) {
  $value_clause = '';
  if ( '' !== $meta_value && null !== $meta_value && false !== $meta_value ) {
    $value_clause = $wpdb->prepare( " AND meta_value = %s", $meta_value );
  }
  $object_ids = $wpdb->get_col( $wpdb->prepare( "SELECT $type_column FROM $table WHERE meta_key = %s $value_clause", $meta_key ) );
}

W linijce numer 4,  %s zostanie podmieniony (z odpowiednim escapowaniem mającym chronić przed SQLi) na $meta_value – wartość kontrolowaną przez użytkownika.  Ale co się stanie jeśli do $meta_value podstawimy %s ? W linijce 6-stej spowoduje to możliwość kontrolowania przez nas zapytania – czyli SQL injection!

To tak zwany double prepare query, którego należy unikać. Bardziej rozbudowany przykład, pokazany krok po kroku zobaczycie w oryginalnym badaniu.

Jak się chronić?

Dla większości użytkowników (na razie) wystarczy zaktualizować WordPressa do wersji 4.8.3 (chyba że używamy pluginu, który nadpisuje $wpdb – wtedy również należy go zaktualizować).

Bardziej pewna i bezpieczna zasada dotyczy developerów (pluginy!):

The simple fix is to not pass user input to the $query parameter to WPDB::prepare() in meta.php. Passing user input to $query is always wrong. Full stop.

Czyli wracamy do naszego pierwszego zalecenia:

nie przekazywać żadnych dynamicznych wartości pochodzących od użytkownika do ->prepare (!).

–Michał Sajdak