Nie. Usunięcie spacji nie zapobiegnie iniekcji SQL, ponieważ istnieje wiele innych sposobów na przetworzenie przez parser danych wejściowych. Spójrzmy na przykład. Wyobraź sobie, że masz adres URL, który w zapytaniu w sposób niebezpieczny używał danych wprowadzonych przez użytkownika:

http: //example/index.php? Id = 1 => SELECT * ze strony, gdzie id = 1

W Twoim przykładzie osoba atakująca użyłaby spacji:

http: //example/index.php? id = 1% 20 lub% 201 = 1 => SELECT * ze strony, gdzie id = 1 lub 1 = 1 .

Usunięcie spacji spowodowałoby zwinięcie iniekcji w ciąg.

Teraz wyobraźmy sobie, że atakujący użył innej formy spacji, tj. tabulatorów:

http: //example/index.php? id = 1% 09 lub% 091 = 1 => SELECT * ze strony, na której id = 1 lub 1 = 1 .

Usunięcie spacji nadal umożliwiłoby wykonanie wstrzyknięcia.

W zależności od używanej technologii osoba atakująca może zastąpić spacje kodem / ** / % 00 % 09 % 0a % 0d lub dowolna liczba unikodów, która powoduje tokenizację przez parser SQL. Podczas gdy przywoływany przykład usunął więcej niż tylko spacje, wspomniany powyżej przykład wykorzystuje komentarze SQL, aby spowodować tokenizację, które nie są białymi znakami. Nadal byłbyś podatny na ataki.

Jedynym niezawodnym sposobem zapobiegania wstrzykiwaniu SQL jest używanie zapytań parametrycznych.

Mamy 2016 rok! Zastrzyki SQL należą do przeszłości, chyba że używasz niezabezpieczonego kodu.

Niezależnie od używanego języka, jeśli chcesz zapobiec jakimkolwiek wszystkim iniekcjom SQL, użyj przygotowanych instrukcji lub dowolnego innego rodzaju wiązania danych.

Przygotowane instrukcje oddzielają zapytanie od danych, przez co dane nie mają wpływu na zapytanie.

Aby bezpośrednio odpowiedzieć na Twoje pytanie, usunięcie spacji zmniejszyłoby liczbę wstrzyknięć SQL (w przypadku użycia przestarzałego kod i biblioteki), ale z pewnością ograniczyłby wprowadzany tekst (nigdzie nie ma spacji).

Ograniczyłoby to problem, ale go nie wyeliminował. Rozważmy następującą sytuację:

  $ un = str_replace ("", "", $ _POST ["nazwa użytkownika"]); $ pw = hash ($ _ POST ["hasło"]; $ sql = "SELECT * FROM users WHERE username = '$ un' AND password = '$ pw'";  

Powiedzmy, że opublikuję nazwę użytkownika admin '- . To spowodowałoby zalogowanie mnie jako administrator bez użycia ani jednej spacji.

Jak wskazuje wireghoul, musiałbyś również usunąć inne puste znaki, takie jak tabulator. Ale ponieważ Julie Pelletier wskazuje, po prostu używaj przygotowanych instrukcji. Wymyślanie sprytnych schematów zatrzymania SQLi bez tego może być zabawną grą, ale nigdy nie zapewni Ci bezpieczeństwa, które zapewnia przygotowane oświadczenia. tylko rozproszenie uwagi.

Nie . Załóżmy, że masz to jako swój SQL:

  "wybierz * spośród osób, dla których last_name = '" + nazwisko + "'"  

Jeśli wpiszę: 'OR (1 = 1) OR'a' = ' na dane wejściowe, które zamienia w:

  select * from people where last_name =' 'OR (1 = 1) OR'a '=' ' 

Który jest wykonywany w Oracle i MySQL (przynajmniej) i zwraca wszystkie wiersze z tabeli.

Jednak gdybyś wziął ten ciąg wyszukiwania

update aTable set someColumn = 'JackedUpValue', gdzie jakaś kolumna taka jak i wykonała operację pokazaną w tym pytaniu, nie otrzymujesz

updateaTablesetsomeColumn = 'JackedUpValue'wheresomeColumn like które nie powinny być wykonywane, prawda?

Jak inni zauważyli, istnieją inne sposoby uzyskiwanie białych znaków w różnych implementacjach SQL Database, które należy uwzględnić, na przykład tabulatory i \ n (nowa linia). Prawie każdy silnik bazy danych z radością zaakceptowałby:

  updateaTablesetsomeColumn = 'JackedUpValue'  

Mogą istnieć różne znaki Unicode, które działają jako białe spacje w zależności od ustawień lokalizacji w różnych baz danych, ale naprawdę musiałbyś zagłębić się w szczegóły implementacji, aby to zrozumieć. Naprawdę nie ma powodu, aby próbować omawiać wszystkie te skrajne przypadki zastępowania ciągów, a nie tylko używania sparametryzowanych zapytań.

Oto pomysł. Serwery baz danych przyjmują przychodzące zapytanie SQL i przepuszczają je przez parser, w wyniku czego powstaje drzewo parsowania. Następnie przekształcają drzewo w plan i wykonują plan.

Istotą iniekcji jest to, że parser tworzy drzewo inne niż to zamierzone przez programistę.

Więc poprawka jest w stanie wykryć nietypowe drzewa parsowania. Przejdź po drzewie po przeanalizowaniu i utwórz ciąg w formie kanonicznej bez wartości danych. Oblicz skrót SHA ciągu. Prowadź tabelę znanych skrótów dla użytkownika aplikacji / bazy danych. Ostrzegaj lub przerywaj, jeśli serwer napotka nieznany skrót.

Oczywiście wystąpił problem z uruchomieniem. Zatem programista musiałby uruchomić aplikację w trybie testowym, wyodrębnić skróty po wyczerpujących testach i załadować serwer hashami podczas uruchamiania aplikacji. Następnie włącz abort-on-new-hash i żadne więcej wstrzyknięć SQL nie powinno być możliwe.