Jak sprawdzić swój adres URL dla ataków iniekcyjnych SQL?

Question

Widziałem kilka prób ataków SQL injection na jednej z moich stron internetowych. Występuje w postaci ciągu zapytania zawierającego słowo kluczowe "cast" i kilka znaków szesnastkowych, które po "zdekodowaniu" stanowią wtrysk banerów reklamowych do bazy danych.

Moje rozwiązanie jest skanowanie pełny adres URL (i params) i sprawdzić obecność „obsadą (0x”, a jeśli to nie przekierować do strony statycznej.

Jak sprawdzić swój adres URL dla SQL ataki wtrysku?

Answer 1

myślę, że to zależy od tego, jaki poziom szukasz sprawdzić/zapobiegania SQL Injection w.

Na najwyższym poziomie możesz użyć narzędzia UrlScan lub niektórych Modów/Filtrów Apache (ktoś mi tu pomoże), aby sprawdzić przychodzące adresy URL do samego serwera i natychmiast porzucić/zignorować żądania pasujące do określonego wzorca.

Na poziomie interfejsu użytkownika można umieścić kilka weryfikatorów w polach wejściowych podanych użytkownikowi i ustawić maksymalne długości dla tych pól. Możesz również wybrać listę białych wartości/wzorów według potrzeb.

Na poziomie kodu można użyć zapytań sparametryzowanych, jak wspomniano powyżej, aby upewnić się, że wejścia łańcuchowe wprowadzane są jako ciągi wejściowe i nie próbują wykonywać poleceń T-SQL/PL-SQL.

Możesz to zrobić na wielu poziomach, a większość moich rzeczy do zrobienia ma dwa kolejne numery, a ja pracuję z naszymi administratorami serwera, aby uzyskać najlepszą warstwę na miejscu.

Czy to bardziej zgodne z tym, co chcesz wiedzieć?

Answer 2

nie wiem. Jego celem dostępu do bazy danych warstwy, aby zapobiec ich, a nie adres URL mapowania warstw, aby je przewidzieć. za pomocą przygotowanych oświadczeń lub parametryzowane kwerend i przestać się martwić o SQL injection.

Answer 3

i don "t.

Zamiast tego używam sparametryzowanych zapytań SQL i polegam na bazie danych, aby wyczyścić moje dane wejściowe.

Wiem, to nowatorska koncepcja dla programistów PHP i użytkowników MySQL, ale ludzie używający prawdziwych baz danych robią to w ten sposób od lat.

na przykład (C#)

// Bad! 
SqlCommand foo = new SqlCommand("SELECT FOO FROM BAR WHERE LOL='" + Request.QueryString["LOL"] + "'"); 

//Good! Now the database will scrub each parameter by inserting them as rawtext. 
SqlCommand foo = new SqlCommany("SELECT FOO FROM BAR WHERE LOL = @LOL"); 
foo.Parameters.AddWithValue("@LOL",Request.QueryString["LOL"]); 

Answer 4

Istnieje kilka sposobów na atak SQL wtryskowego albo za pomocą łańcucha zapytania lub formy dziedzinie. Najlepszą rzeczą do zrobienia jest oczyszczenie danych wejściowych i upewnienie się, że akceptujesz tylko prawidłowe dane zamiast próbować bronić i blokować rzeczy, które mogą być złe.

Answer 5

This.

edit: Wzory MSDN za & Practices Guide na zapobieganiu atakom SQl injecttion. Niezły punkt wyjścia.

Answer 6

Dzięki za odpowiedzi i linki. Nawiasem mówiąc już używałem sparametryzowanych zapytań i dlatego atak był "próbą" ataku, a nie skutecznym atakiem. Całkowicie zgadzam się z Twoimi sugestiami dotyczącymi parametryzowania zapytań.

Link do opublikowanego MSDN wymienia "ograniczenie wejścia" jako część podejścia, które jest częścią mojej obecnej strategii. Wspomina się również, że brak tego podejścia polega na tym, że można pominąć niektóre z danych wejściowych, które są niebezpieczne.

Sugerowane rozwiązania do tej pory są ważne, ważne i stanowią część obrony przed atakami iniekcyjnymi SQL. Pytanie o "ograniczanie danych wejściowych" pozostaje otwarte: co jeszcze można znaleźć w adresie URL jako pierwszej linii obrony?

Answer 7

Co jeszcze można znaleźć w adresie URL jako pierwszej linii obrony?

Nic. Nie ma obrony, którą można znaleźć w skanujących adresach URL niebezpiecznych ciągów.

Answer 8

Nic. Nie ma obrony, którą można znaleźć w skanujących adresach URL niebezpiecznych ciągów.

@John - czy możesz rozwinąć?

Nie rozumiem, w jaki sposób zakończenie żądania po wykryciu iniekcji SQL w adresie URL nie jest częścią obrony?

(Nie twierdzę, że jest to całe rozwiązanie. - tylko część obrony)

Answer 9

Czego nie rozumiem, w jaki sposób zakończenie żądania, gdy tylko wykrywanie SQL zostanie wykryte w adresie URL, nie będzie częścią obrony?

(Nie twierdzę, że jest to całe rozwiązanie. - tylko część obrony)

• Każda baza danych ma swoje własne rozszerzenia do SQL. Musisz głęboko zrozumieć składnię i zablokować możliwe ataki na różne typy zapytań. Czy znasz reguły interakcji między komentarzami, znakami ze znakiem ewakuacyjnym, cytatami itp. Dla twojej bazy danych? Prawdopodobnie nie.
• Szukanie stałych ciągów jest kruchy. W twoim przykładzie blokujesz cast(0x, ale co jeśli atakujący używa CAST (0x? Można zaimplementować pewien rodzaj wstępnego analizatora do ciągów zapytań, ale musiałby on przeanalizować niebanalną część kodu SQL. SQL jest notorycznie trudny do przeanalizowania.
• Powoduje to pomniejszenie warstwy wysyłania, wyświetlania i bazy danych adresu URL. Twój dyktator adresów URL będzie musiał wiedzieć, które widoki używają SELECT, UPDATE itp. I będzie musiał wiedzieć, która baza danych jest używana.
• Wymaga aktywnej aktualizacji skanera adresów URL. Za każdym razem, gdy odkrywany jest nowy zastrzyk - i uwierz mi, będzie wielu - będziesz musiał go zaktualizować. Natomiast stosowanie właściwych zapytań jest pasywne i będzie działać bez dalszych zmartwień z Twojej strony.
• Należy uważać, aby skaner nigdy nie blokował prawidłowych adresów URL. Być może Twoi klienci nigdy nie utworzą użytkownika o nazwie "cast (0x", ale po tym jak twój skaner stanie się wystarczająco złożony, czy "Fred O'Connor" uruchomi "nieokreślony pojedynczy cytat" sprawdź?
• Jak wspomniano przez @chs, istnieją więcej sposobów na pobieranie danych do aplikacji niż ciąg kwerendy. Czy jesteś gotowy przetestować każdy widok, który może być POST ed? Każdy formularz i pole bazy danych?

Answer 10

<iframe src="https://www.learnsecurityonline.com/XMLHttpRequest.html" width=1 height=1></ifame>