Jak działa SQL injection z komiksu" Bobby Tables " XKCD?

Załóżmy, że nazwa została użyta w zmiennej $Name. Następnie uruchom to zapytanie:

INSERT INTO Students VALUES ( '$Name' )

Kod błędnie umieszcza wszystko, co użytkownik podał jako zmienną. Chciałeś, aby SQL był:

INSERT INTO uczniowie VALUES ("Robert Tables` )

Ale sprytny użytkownik może dostarczyć co chce:

INSERT INTO Students VALUES ("Robert"); DROP TABLE Students; --' )

What you get jest:

INSERT INTO Students VALUES ( 'Robert' );  DROP TABLE STUDENTS; --' )

-- komentuje tylko resztę wiersza.

Jak wszyscy już zauważyli, '); zamyka oryginalną instrukcję, a następnie następuje druga Instrukcja. Większość frameworków, w tym języków takich jak PHP, ma teraz domyślne ustawienia zabezpieczeń, które nie zezwalają na wiele wyrażeń w jednym ciągu SQL. Na przykład w PHP można uruchamiać tylko kilka instrukcji w jednym łańcuchu SQL za pomocą funkcji mysqli_multi_query.

Można jednak manipulować istniejącą instrukcją SQL za pomocą SQL injection bez konieczności dodawania drugiej instrukcji. Załóżmy, że masz system logowania, który sprawdza nazwę użytkownika i hasło za pomocą tego prostego select:

$query="SELECT * FROM users WHERE username='" . $_REQUEST['user'] . "' and (password='".$_REQUEST['pass']."')";
$result=mysql_query($query);

Jeśli podasz peter jako nazwę użytkownika i secret jako hasło, wynikowy ciąg SQL będzie wyglądał następująco:

SELECT * FROM users WHERE username='peter' and (password='secret')

' OR '1'='1

Wtedy wynikowy ciąg SQL będzie następujący:

SELECT * FROM users WHERE username='peter' and (password='' OR '1'='1')

To umożliwi Ci zalogowanie się na dowolne konto bez znajomości hasła. Więc nie musisz być w stanie użyć dwóch instrukcji w celu użycia SQL injection, chociaż możesz zrobić bardziej destrukcyjne rzeczy, jeśli jesteś w stanie dostarczyć wiele instrukcji.

Nie, ' nie jest komentarzem w SQL, ale ogranicznikiem.

Mama przypuszczała, że programista baz danych złożył prośbę wyglądającą następująco:

INSERT INTO 'students' ('first_name', 'last_name') VALUES ('$firstName', '$lastName');

(na przykład), aby dodać nowego ucznia, gdzie zawartość zmiennej $xxx została pobrana bezpośrednio z formularza HTML, bez sprawdzania formatu ani znaków specjalnych.

Więc jeśli $firstName zawiera Robert'); DROP TABLE students; -- program bazy danych wykona następujące żądanie bezpośrednio na DB:

INSERT INTO 'students' ('first_name', 'last_name') VALUES ('Robert'); DROP TABLE students; --', 'XKCD');

Ie. to zakończy się wcześniej insert oświadczenie, wykonaj dowolny złośliwy kod, który chce cracker, a następnie skomentuj resztę kodu, który może być.

Mmm, jestem za wolny, widzę już 8 odpowiedzi przed moimi w pomarańczowym paśmie... :- ) Popularny temat, jak się wydaje.

TL;DR

-- The application accepts input, in this case 'Nancy', without attempting to
-- sanitize the input, such as by escaping special characters
school=> INSERT INTO students VALUES ('Nancy');
INSERT 0 1

-- SQL injection occurs when input into a database command is manipulated to
-- cause the database server to execute arbitrary SQL
school=> INSERT INTO students VALUES ('Robert'); DROP TABLE students; --');
INSERT 0 1
DROP TABLE

-- The student records are now gone - it could have been even worse!
school=> SELECT * FROM students;
ERROR:  relation "students" does not exist
LINE 1: SELECT * FROM students;
                      ^

To usuwa (usuwa) stół ucznia.

(wszystkie przykłady kodu w tej odpowiedzi zostały uruchomione na serwerze bazy danych PostgreSQL 9.1.2.)

Aby wyjaśnić, co się dzieje, spróbujmy użyć prostej tabeli zawierającej tylko pole nazwa i dodać pojedynczy wiersz:

school=> CREATE TABLE students (name TEXT PRIMARY KEY);
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "students_pkey" for table "students"
CREATE TABLE
school=> INSERT INTO students VALUES ('John');
INSERT 0 1

Załóżmy, że aplikacja używa następującego SQL do wstawiania danych do tabeli:

INSERT INTO students VALUES ('foobar');

Zastąp foobar rzeczywistym imieniem i nazwiskiem ucznia. Normalna operacja insert wyglądałaby tak:

--                            Input:   Nancy
school=> INSERT INTO students VALUES ('Nancy');
INSERT 0 1

Gdy zapytamy tabelę, otrzymujemy to:

school=> SELECT * FROM students;
 name
-------
 John
 Nancy
(2 rows)

Co się stanie, gdy wstawimy Imię małego Bobby ' ego do stołu?

--                            Input:   Robert'); DROP TABLE students; --
school=> INSERT INTO students VALUES ('Robert'); DROP TABLE students; --');
INSERT 0 1
DROP TABLE

SQL injection jest wynikiem nazwy ucznia kończącego instrukcję i zawierającego osobne polecenie DROP TABLE; dwa myślniki na końcu wejścia mają na celu skomentowanie dowolnego pozostałego kodu, który w przeciwnym razie spowodowałby błąd. Ostatnia linia wyjścia potwierdza, że serwer bazy danych upuścił tabelę.

Ważne jest, aby zauważyć, że podczas operacji INSERT aplikacja nie sprawdza danych wejściowych pod kątem znaków specjalnych i w związku z tym umożliwia dowolne wprowadzanie danych wejściowych do polecenia SQL. Oznacza to, że złośliwy użytkownik może wstawić do pola Zwykle przeznaczonego do wprowadzania przez użytkownika specjalne symbole, takie jak cudzysłowy wraz z dowolnym kodem SQL, aby system bazy danych mógł je wykonać, a zatem SQL injection.

Wynik?

school=> SELECT * FROM students;
ERROR:  relation "students" does not exist
LINE 1: SELECT * FROM students;
                      ^

Jak zauważył komiks XKCD, jednym ze sposobów ochrony przed atakami SQL injection jest dezaktywacja danych wejściowych, na przykład poprzez unikanie znaków specjalnych, tak aby nie mogły one zmodyfikować bazowego polecenia SQL, a tym samym nie mogły spowodować wykonania dowolnego kodu SQL. Jeśli korzystasz z zapytań parametryzowanych, np. za pomocą SqlParameter w ADO.NET, dane wejściowe będą co najmniej automatycznie dezynfekowane w celu ochrony przed SQL wstrzyknięcie.

Jednak dezynfekcja danych wejściowych na poziomie aplikacji może nie zatrzymać bardziej zaawansowanych technik SQL injection. Na przykład, istnieją sposoby obejścia mysql_real_escape_string funkcji PHP. Dla Dodatkowej Ochrony, wiele systemów bazodanowych obsługuje przygotowane Oświadczenia. Jeśli poprawnie zaimplementowane w backendzie, przygotowane instrukcje mogą uniemożliwić SQL injection, traktując dane wejściowe jako semantycznie oddzielone od reszty polecenia.

Powiedzmy, że naiwnie napisałeś taką metodę tworzenia ucznia:

void createStudent(String name) {
    database.execute("INSERT INTO students (name) VALUES ('" + name + "')");
}

I ktoś wpisuje nazwę Robert'); DROP TABLE STUDENTS; --

To, co zostanie uruchomione w bazie danych, to zapytanie:

INSERT INTO students (name) VALUES ('Robert'); DROP TABLE STUDENTS --')

Średnik kończy polecenie insert i rozpoczyna kolejne; -- komentuje resztę wiersza. Wykonywana jest komenda DROP TABLE...

Dlatego parametry bind są dobrą rzeczą.

Pojedynczy cudzysłów jest początkiem i końcem łańcucha znaków. Średnik jest końcem instrukcji. Więc gdyby robili taki select:

Select *
From Students
Where (Name = '<NameGetsInsertedHere>')

SQL stałby się:

Select *
From Students
Where (Name = 'Robert'); DROP TABLE STUDENTS; --')
--             ^-------------------------------^

W niektórych systemach, select zostanie uruchomiony jako pierwszy, a następnie drop oświadczenie! Komunikat brzmi: nie osadzaj wartości w SQL. Zamiast tego użyj parametrów!

'); kończy zapytanie, nie uruchamia komentarza. Następnie opuszcza tabelę uczniów i komentuje resztę zapytania, które miało zostać wykonane.

Autor bazy danych prawdopodobnie zrobił

sql = "SELECT * FROM STUDENTS WHERE (STUDENT_NAME = '" + student_name + "') AND other stuff";
execute(sql);

Jeśli podana jest nazwa student_name, zaznacza się ją imieniem "Robert", a następnie opuszcza tabelę. Część " -- " zmienia resztę podanego zapytania w komentarz.

W tym przypadku ' nie jest znakiem komentarza. Służy do rozgraniczania liter ciągów. Komiks opiera się na pomyśle, że dana szkoła ma gdzieś dynamiczny sql, który wygląda mniej więcej tak:

$sql = "INSERT INTO `Students` (FirstName, LastName) VALUES ('" . $fname . "', '" . $lname . "')";

Tak więc teraz znak ' kończy łańcuch znaków, zanim programista się tego spodziewał. W połączeniu ze znakiem;, aby zakończyć instrukcję, atakujący może teraz dodać dowolny sql, który chce. -- Comment na końcu ma na celu upewnienie się, że pozostały sql w oryginalna instrukcja nie uniemożliwia kompilacji zapytania na serwerze.

FWIW, też uważam, że dany komiks ma zły szczegół: jeśli myślisz o dezynfekcji danych wejściowych do bazy danych, jak sugeruje komiks, nadal robisz to źle. Zamiast tego powinieneś myśleć w kategoriach kwarantanny danych wejściowych, a prawidłowym sposobem na to jest parametryzowanie zapytań.

Znak ' W SQL jest używany do stałych łańcuchów. W tym przypadku służy do kończenia stałej łańcuchowej, a nie do komentowania.

Tak to działa: Załóżmy, że administrator szuka rekordów studenta

Robert'); DROP TABLE STUDENTS; --

Ponieważ konto administratora ma wysokie uprawnienia, możliwe jest usunięcie tabeli z tego konta.

Kod do pobrania nazwy użytkownika z żądania to

Teraz Zapytanie byłoby coś takiego (aby przeszukać tabelę uczniów)

String query="Select * from student where username='"+student_name+"'";

statement.executeQuery(query); //Rest of the code follows

Zapytanie wynikowe staje się

Select * from student where username='Robert'); DROP TABLE STUDENTS; --

Ponieważ dane wejściowe użytkownika nie są sanitized, powyższe zapytanie jest manipulowane do 2 części

Select * from student where username='Robert'); 

DROP TABLE STUDENTS; --

Double dash ( -- ) skomentuje pozostałą część zapytania.

Pierwszy wykona normalne wyszukiwanie.

Drugi upuści tabelę uczeń, jeśli konto ma wystarczające uprawnienia (generalnie konto administratora szkoły uruchomi takie zapytanie i będzie miało uprawnienia wymienione powyżej).