Prepared statements / parameterized queries are generally enough to prevent 1st order injection on that statement^*. Jeśli używasz nie zaznaczonego dynamicznego sql gdziekolwiek indziej w swojej aplikacji, nadal jesteś podatny na 2nd order injection.

Drugi zastrzyk zamówienia oznacza, że dane zostały raz przepuszczone przez bazę danych, zanim zostały włączone do zapytania i jest znacznie trudniejsze do wykonania. AFAIK, prawie nigdy nie widać prawdziwych ataków 2. rzędu, jak to zazwyczaj atakującym łatwiej jest zaimplementować się w społeczności, ale czasami pojawiają się błędy drugiego rzędu z powodu dodatkowych łagodnych znaków ' lub podobnych.

Można wykonać atak iniekcji drugiego rzędu, gdy można spowodować, że wartość zostanie zapisana w bazie danych, która jest później używana jako literał w zapytaniu. Jako przykład, załóżmy, że wprowadzasz następujące informacje jako nową nazwę Użytkownika podczas tworzenia konta na stronie internetowej (zakładając MySQL DB dla tego pytania):

' + (SELECT UserName + '_' + Password FROM Users LIMIT 1) + '

Jeśli nie ma innych ograniczeń co do nazwy użytkownika, instrukcja prepared nadal upewniałaby się, że powyższe osadzone zapytanie nie zostanie wykonane w momencie wstawiania i poprawnie zapisze wartość w bazie danych. Wyobraź sobie jednak, że później aplikacja pobiera Twoją nazwę Użytkownika z bazy danych i używa konkatenacji łańcuchowej, aby dołączyć tę wartość do nowego zapytania. Możesz zobaczyć hasło kogoś innego. Ponieważ kilka pierwszych imion w tabeli użytkowników jest zazwyczaj administratorami, być może właśnie podałeś z dala od farmy. (Uwaga: jest to jeszcze jeden powód, aby nie przechowywać haseł w zwykłym tekście!)

Widzimy więc, że przygotowane instrukcje wystarczą na pojedyncze zapytanie, ale same w sobie nie są wystarczające do ochrony przed atakami SQL injection w całej aplikacji, ponieważ nie mają mechanizmu wymuszającego, aby cały dostęp do bazy danych w aplikacji używał bezpiecznego kodu. Jednak stosowane jako część dobrego projektowania aplikacji - które mogą obejmować takie praktyki, jak przegląd kodu lub analiza statyczna lub użycie ORM, warstwy danych lub warstwy usług, która ogranicza dynamiczny sql - przygotowane Oświadczenia są podstawowym narzędziem do rozwiązywania problemu SQL Injection. jeśli stosujesz dobre zasady projektowania aplikacji, takie że dostęp do danych jest oddzielony od reszty programu, łatwo jest wymusić lub skontrolować, że każde zapytanie poprawnie wykorzystuje parametryzację. W tym przypadku SQL injection (zarówno pierwszego, jak i drugiego rzędu) jest całkowicie / align = "left" /

_{^*okazuje się, że MySql / PHP są (ok, były) po prostu głupi o obsłudze parametrów, gdy szerokie znaki są zaangażowane, i nadal istnieje Rzadki przypadek opisany w inne wysoko głosowane odpowiedź tutaj, które mogą pozwolić injection prześlizgnąć się przez parametryzowane zapytanie.}

Nie, Nie zawsze są.

Zależy to od tego, czy użytkownik zezwala na umieszczenie danych wejściowych w samym zapytaniu. Na przykład:

$dbh = new PDO("blahblah");

$tableToUse = $_GET['userTable'];

$stmt = $dbh->prepare('SELECT * FROM ' . $tableToUse . ' where username = :username');
$stmt->execute( array(':username' => $_REQUEST['username']) );

Będzie podatny na iniekcje SQL i użycie gotowych instrukcji w tym przykładzie nie zadziała, ponieważ dane wejściowe użytkownika są używane jako identyfikator, a nie jako dane. Poprawną odpowiedzią byłoby użycie pewnego rodzaju filtrowania / walidacji, takiego jak:

$dbh = new PDO("blahblah");

$tableToUse = $_GET['userTable'];
$allowedTables = array('users','admins','moderators');
if (!in_array($tableToUse,$allowedTables))    
 $tableToUse = 'users';

$stmt = $dbh->prepare('SELECT * FROM ' . $tableToUse . ' where username = :username');
$stmt->execute( array(':username' => $_REQUEST['username']) );

Uwaga: nie możesz używać PDO do wiązania danych, które wykraczają poza DDL (język definicji danych), tzn. to nie działa:

$stmt = $dbh->prepare('SELECT * FROM foo ORDER BY :userSuppliedData');

Powodem, dla którego powyższe nie działa, jest to, że DESC i ASC nie są danymi . PDO może uciec tylko dla danych . Po drugie, nie można nawet umieścić ' cytatów wokół niego. Jedynym sposobem na umożliwienie sortowania wybranego przez użytkownika jest ręczne filtrowanie i sprawdzanie, czy jest to DESC lub ASC.

Tak, wystarczy. Sposób, w jaki ataki typu injection działają, polega na tym, że jakiś interpreter (baza danych) oceni coś, co powinno być danymi, jakby to był Kod. Jest to możliwe tylko wtedy, gdy mieszasz kod i dane na tym samym nośniku (np. podczas konstruowania zapytania jako ciąg znaków).

Parametryzowane zapytania działają wysyłając kod i dane oddzielnie, więc nigdy nie będzie można znaleźć dziury w tym.

Nadal możesz być podatny na inne ataki typu wtrysku. Na przykład, jeśli używasz danych na stronie HTML, możesz być narażony na ataki typu XSS.

Nie to nie wystarczy (w niektórych szczególnych przypadkach)! Domyślnie PDO używa emulowanych gotowych instrukcji, gdy używa MySQL jako Sterownika bazy danych. Podczas korzystania z MySQL i PDO należy zawsze wyłączyć emulowane instrukcje:

$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

Kolejna rzecz, którą zawsze należy zrobić to ustawić poprawne kodowanie bazy danych:

$dbh = new PDO('mysql:dbname=dbtest;host=127.0.0.1;charset=utf8', 'user', 'pass');

Zobacz także podobne pytanie: Jak mogę zapobiec wtrysku SQL w PHP?

Zwróć również uwagę, że dotyczy to tylko Strony bazy danych rzeczy, które nadal trzeba uważać podczas wyświetlania danych. Np. poprzez ponowne użycie htmlspecialchars() z poprawnym kodowaniem i stylem cytowania.

Osobiście zawsze najpierw uruchamiałbym jakąś formę sanitacji na danych, ponieważ nigdy nie można ufać wejściom użytkownika, jednak przy użyciu wiążących elementów zastępczych / parametrów wprowadzone dane są wysyłane do serwera oddzielnie do instrukcji sql, a następnie łączone razem. Kluczem tutaj jest to, że wiąże dostarczone dane do określonego typu i określonego zastosowania i eliminuje możliwość zmiany logiki instrukcji SQL.

Eaven jeśli zamierzasz zapobiec front-endowi SQL injection, używając sprawdzeń html lub js, musisz wziąć pod uwagę, że sprawdzania front-end są "pomijalne".

Możesz wyłączyć js lub edytować wzorzec za pomocą narzędzia programistycznego (wbudowanego obecnie w firefox lub chrome).

Tak więc, aby zapobiec SQL injection, byłoby prawo do dezynfekcji backend daty wejścia wewnątrz kontrolera.

Chciałbym zaproponować Ci użycie natywnej funkcji PHP filter_input () w celu dezynfekcja wartości GET I INPUT.

Jeśli chcesz przejść do bezpieczeństwa, dla sensownych zapytań do bazy danych, chciałbym zasugerować Ci użycie wyrażenia regularnego do walidacji formatu danych. preg_match () pomoże Ci w tym przypadku! Ale uważaj na siebie! Silnik Regex nie jest tak lekki. Używaj go tylko w razie potrzeby, w przeciwnym razie wydajność aplikacji spadnie.

Bezpieczeństwo ma swoje koszty, ale nie marnuj swojej wydajności!

Prosty przykład:

Jeśli chcesz dokładnie sprawdzić, czy wartość, otrzymana z GET jest liczbą, mniejszą niż 99 if(!preg_match('/[0-9]{1,2}/')){...} is heavyer of

if (isset($value) && intval($value)) <99) {...}