2010-12-15 18 views
10

Zgodnie z zasadą "jeśli chodzi jak kaczka i brzmi jak kaczka", to z pewnością wydaje się, że zapytania o smaku SQL, które obsługuje Amazon SimpleDB, powinny być podatne na ataki typu SQL injection. Oto prosty przykład, który zakłada wejście atakującego będzie w zmiennej $ kategorii, i że potrafi odgadnąć nazwę kolumna:Jak mogę chronić Amazon SimpleDB przed SQL Injection?

$category = "Clothes' OR Category LIKE '%"; 
$results = $sdb->select("SELECT * FROM `{$domain}` WHERE Category = '$category'"); 

Jeśli grasz w grę gospodarzy, linie te mogą być in-place zamiennik linii 119 w pliku html-sdb_create_domain_data.php w przykładowym kodzie w pakiecie PHP SDK Amazon (1.2).

Amazon publikuje , i przypuszczam, że mógłbym napisać coś, co zapewni, że jakiekolwiek "lub" wejście użytkownika zostanie podwojone ... ale zawsze rozumiałem, że ucieczka jest w zasadzie wyścigiem zbrojeń, który sprawia, że ​​parametryzacja jest moją bronią z wyboru przy użyciu, na przykład, MySQL.

Jakie są inne osoby korzystające bronić zapytań SimpleDB?

Odpowiedz

8

SimpleDB Wybierz operacja jest nieniszczących, więc jedyną rzeczą, do ochrony przed to dodatkowe dane zapytań wyjście do atakujący:

Rozwiązanie do sanityzacji użytkownika ut dla zapytania jest dość proste w przypadku SimpleDB, ponieważ sub-selekcje i instrukcje złożone nie są dozwolone. Więc to nie jest wyścig zbrojeń; sekwencje jednego lub większej liczby znaków cudzysłowu na wejściu muszą zostać zmienione, jeśli długość sekwencji jest nieparzysta.

Powiązane problemy