Bezpieczeństwo aplikacji. Bazy danych 237

Bezpieczeństwo aplikacji Bazy danych 237

238 Bazy danych Przegląd zagadnień Najczestsze bledy programistów SQL Injection Podsumowanie Laboratorium Nawet najlepiej zabezpieczona baza danych moŝe paść ofiarą ataku przeprowadzonego z poziomu aplikacji, która z bazy danych korzysta. Dlatego waŝne jest, by administratorzy i programiści byli świadomy zagroŝeń, jakie niesie za sobą dostęp do baz danych przy pomocy zewnętrznych aplikacji. Prawdopodobnie najwięcej przypadków nieautoryzowanego dostępu do danych wynika z błędów programistycznych. Dlatego niezbędne jest stałe edukowanie programistów w temacie bezpieczeństwa dostępu do danych.

Bazy danych 239 Najczęstsze błędy programistów Programowanie z dostepem do danych - bledy Programowanie z dostepem do danych - najlepsze nawyki Wyobraź sobie, Ŝe jesteś programistą. Praktycznie kaŝda dzisiejsza aplikacja korzysta z bazy danych. Bazy danych słuŝą jako magazyny danych, jako przechowalnia danych uwierzytelniających uŝytkowników w aplikacji, jako podstawa pod wiele mechanizmów (cache'owanie, profile, raporty). Zrozumienie zasad pisania bezpiecznych z punktu widzenia dostępu do danych aplikacji jest kluczem do tworzenia dobrych programów.

240 Bazy danych Programowanie z dostępem do danych - błędy Najczęściej popełniane przez programistów błędy to: dostęp do serwera baz danych z uŝyciem konta o zbyt duŝych uprawnieniach - powoduje to, Ŝe w przypadku ataku potencjalny agresor działa w SZBD często z uprawnieniami administratora, przechowywanie kluczowych danych, takich jak hasła, w plikach konfiguracyjnych aplikacji - zdobycie takich danych często otwiera drogę potencjalnemu agresorowi, brak kontroli nad danymi wprowadzanymi w aplikacji przez uŝytkowników - daje to bardzo często moŝliwość ataku SQL Injection, następstwem czego moŝe być nieuprawniony dostęp do danych, a w skrajnych przypadkach nawet przejęcie kontroli nad bazą danych lub serwerem, wyświetlanie w aplikacji domyślnych komunikatów błędów SZBD - powoduje to często ujawnienie struktury bazy danych i uŝytych w aplikacji zapytań SQL, co prowadzi na ogół do ataku typu SQL Injection, błędne podejście przy wykrywaniu nieprawidłowości w danych wprowadzanych przez uŝytkownika - często programista stara się wypisać wszystkie przypadki, które są według niego nieprawidłowe, pominięcie jednego z przypadków tworzy lukę w bezpieczeństwie, brak kontroli nad zasobami serwera baz danych - pozostawianie otwartych połączeń, nie zamykanie obiektów (jak na przykład kursory). Programowanie z dostępem do danych - najlepsze nawyki Jak zatem naleŝy pisać aplikacje? NaleŜy trzymać się pewnych zasad. UŜywaj konta o minimalnych uprawnieniach niezbędnych do wykonania operacji w bazie danych. Nigdy nie ufaj uŝytkownikom aplikacji. Kontroluj wprowadzane przez nich dane. Sprawdzaj tylko, czy wprowadzane przez uŝytkowników dane są tym, czego się spodziewasz, a resztę odrzucaj. Nie wyświetlaj domyślnych komunikatów o błędach w aplikacji (zwłaszcza w aplikacjach WWW). Jeśli uŝywasz transakcji, staraj się, by były one jak najkrótsze. Nigdy nie trzymaj danych poufnych w plikach konfiguracyjnych, chyba Ŝe w postaci zaszyfrowanej. Zawsze sprzątaj po sobie - zamykaj otwarte przez aplikację połączenia z serwerami. W razie potrzeby zapewniaj bezpieczne przesyłanie danych po sieci (uŝywaj SSL). UŜywaj procedur składowanych i widoków do implementacji bezpiecznego dostępu do danych. Staraj się nie uŝywać mechanizmów powszechnie uwaŝanych za niebezpieczne (np. dynamiczny SQL).

Bazy danych 241 SQL Injection SQL Injection co to takiego Nastepstwa Przyklady Obrona SQL Injection to dziś wśród programistów i administratorów baz danych prawie legenda. Mimo to wciąŝ zdarzają się sytuacje, w których aplikacja jest napisana tak, Ŝe umoŝliwia ten atak.

242 Bazy danych SQL Injection - co to takiego? SQL Injection to atak na bazę danych przeprowadzony przy uŝyciu nieprawidłowo napisanej aplikacji. W ataku tym agresor wykorzystuje fakt, Ŝe aplikacja nie sprawdza lub sprawdza niedostatecznie dane wprowadzane w aplikacji przez uŝytkowników. Dzięki temu atakujący jest w stanie podać fragment kodu języka SQL, który wykona w bazie danych czynność niedozwoloną i nieprzewidzianą z punktu widzenia programisty. Co jest najwaŝniejsze, na atak ten jest naraŝony kaŝdy SZBD, jeśli tylko istnieje odpowiednio źle napisana aplikacja, która się do tego systemu dostaje i korzysta z baz w nim przechowywanych. SQL Injection następstwa Następstwa ataku SQL Injection mogą być róŝne. Najczęściej występujące objawy to: nieuprawniony dostęp do danych, udana próba uwierzytelnienia w aplikacji bez znajomości danych uwierzytelniających, wykonanie nieporządanej operacji w bazie danych (np. usunięcie tabeli), wykonanie nieporządanej operacji w SZBD (np. stworzenie nowej bazy danych), wykonanie nieporządanej operacji w systemie operacyjnym (skrajny przypadek, ale moŝliwy). SQL Injection - przykłady Przykład 1 - Nieuprawniony dostęp do danych -- zapytanie bez danych uŝytkownika SELECT * FROM Uzytkownicy WHERE Login = '' AND Haslo = '' -- zapytanie z danymi uŝytkownika SELECT * FROM Uzytkownicy WHERE Login = 'Pawel' AND Haslo = 'P@ssw0rd' -- atak SQL Injection - próba logowania SELECT * FROM Uzytkownicy WHERE Login = '' OR 1=1 --' AND Haslo = '' W powyŝszym przykładzie zapytanie słuŝy do uwierzytelnienia uŝytkownika w aplikacji. Zapytanie pobiera od uŝytkownika dwie informacje: login i hasło. W drugim fragmencie kodu na zielono zaznaczyliśmy dane wstawione przez uŝytkownika w pola tekstowe w aplikacji. Jeśli istnieje podany przez uŝytkownika login i na dodatek dla podanego loginu zgodzi się równieŝ hasło, to zapytanie zwróci jeden rekord.

Bazy danych 243 Przyjrzyj się jednak trzeciemu fragmentowi kodu SQL, w którym kolorem czerwonym zaznaczyliśmy napis wstawiony przez atakującego w pole tekstowe słuŝące do pobrania loginu. Zakładając, Ŝe mamy do czynienia z Microsoft sql Server (chodzi o symbol komentarza - dwa myślniki powodują wykomentowanie reszty kodu SQL), atak spowoduje najprawdopodobniej udaną próbę logowania na pierwszy dostępny login. Dlaczego ten atak zadziałał? Przyjrzyj się, co powoduje wstawienie złośliwego kodu. JuŜ widzisz? Najpierw zamykany jest apostrof, by zapytanie było prawidłowym zapytaniem SQL, potem następuje stworzenie warunku, który zawsze jest prawdziwy (dla kaŝdego rekordu), wreszcie uŝywany jest symbol komentarza w celu zignorowania pozostałej części oryginalnego zapytania. W sumie zapytanie wybiera z tabeli wszystkie rekordy... Taki atak ma szansę powodzenia, jeśli aplikacja wykorzystuje konkatenację do tworzenia składni SQL w kodzie aplikacji. Pamiętaj, Ŝe do wykonania ataku SQL Injection czasem nie jest potrzebne uŝycie symbolu komentarza. Zamiast tego moŝna we wszystkie pola w aplikacji wstawić warunek zawsze spełniony i tym sposobem atak jest moŝliwy do wykonania nawet w bazach danych, które nie oferują symbolu komentarza (np. Microsoft Access). Np.: SELECT * FROM Uzytkownicy WHERE Login = '' OR 'a'='a' AND Haslo = '' OR 'a'='a' Przykład 2 - Wykonanie niepoŝądanej operacji w bazie danych -- zapytanie bez danych uŝytkownika SELECT * FROM Uzytkownicy WHERE Login = '' AND Haslo = '' -- zapytanie z danymi uŝytkownika SELECT * FROM Uzytkownicy WHERE Login = 'Pawel' AND Haslo = 'P@ssw0rd' -- atak SQL Injection - próba usunięcia tabeli SELECT * FROM Uzytkownicy WHERE Login = ''; DROP TABLE Uzytkownicy --' AND Haslo = '' Tym razem celem ataku nie jest zalogowanie się do aplikacji, a popsucie bazy danych przez usunięcie tabeli (polecenie DROP TABLE). Taki atak ma szansę powodzenia, jeśli aplikacja wykorzystuje konkatenację do tworzenia składni SQL w kodzie aplikacji i dodatkowo aplikacja dostaje się do bazy danych w kontekście konta o zbyt wysokich uprawnieniach (umoŝliwiających wykonanie polecenia kasowania tabeli). Przykład 3 - Przejęcie kontroli nad systemem operacyjnym Czasem SZBD jest mocno zintegrowany z systemem operacyjnym. Zachodzi wówczas moŝliwość ataku, którego efektem będzie wykonanie niepoŝądanej operacji w samym systemie operacyjnym.

244 Bazy danych -- zapytanie bez danych uŝytkownika SELECT * FROM Uzytkownicy WHERE Login = '' AND Haslo = '' -- zapytanie z danymi uŝytkownika SELECT * FROM Uzytkownicy WHERE Login = 'Pawel' AND Haslo = 'P@ssw0rd' -- atak SQL Injection - próba usunięcia tabeli SELECT * FROM Uzytkownicy WHERE Login = ''; EXEC master..xp_cmdshell 'net user Haker P@ssw0rd /add --' AND Haslo = '' W powyŝszym przykładzie w trzecim bloku kodu wykonany jest atak polegający na dodaniu uŝytkownika do systemu operacyjnego Windows. Następnym krokiem mogłoby być dodanie uŝytkownika do grupy administratorów systemowych. Taki atak ma szansę powodzenia, jeśli aplikacja wykorzystuje konkatenację do tworzenia składni SQL w kodzie aplikacji i dodatkowo aplikacja dostaje się do bazy danych w kontekście konta o zbyt wysokich uprawnieniach (sysadmin w systemie Microsoft SQL Server). SQL Injection - obrona Aby obronić się przed SQL Injection programista powinien stosować pewne zasady. UŜywaj konta o minimalnych uprawnieniach niezbędnych do wykonania operacji w bazie danych. Nigdy nie ufaj uŝytkownikom aplikacji. Kontroluj wprowadzane przez nich dane. Sprawdzaj tylko, czy wprowadzane przez uŝytkowników dane są tym, czego się spodziewasz, a resztę odrzucaj. Nie wyświetlaj domyślnych komunikatów o błędach w aplikacji (zwłaszcza w aplikacjach WWW). UŜywaj procedur składowanych i ich parametrów do dostępu do danych. Unikaj stosowania konkatenacji (łączenia napisów) przy tworzeniu składni SQL w kodzie aplikacji. UŜywaj mechanizmów dostępnych w językach programowania (jak parametry w.net lub prepared statements w Javie). Wykrywaj i usuwaj z podawanych przez uŝytkowników danych znaki charakterystyczne dla języka SQL, którego uŝywa Twój SZBD. Jako ciekawostkę podamy Ci równieŝ fakt, Ŝe wyszukiwarki internetowe z Google na czele, zapamiętują wystąpienia komunikatów błędów na stronach WWW. Zatem atakujący moŝe wyszukać podatne na ataki witryny w bardzo prosty sposób, jeśli zna słowa kluczowe komunikatów serwera (a to moŝna znaleźć chociaŝby w dokumentacji).

Bazy danych 245 Podsumowanie Najczestsze bledy programistów SQL Injection Bezpieczeństwo to temat-rzeka. Jednak znajomość podstawowych problemów i odpowiedzi na potencjalne zagroŝenia znacznie ogranicza moŝliwości ataku na administrowany przez Ciebie serwer. Dlatego warto poświęcać sporo uwagi zagadnieniom bezpieczeństwa. Bezpieczeństwo aplikacji jest równie waŝne, jak bezpieczeństwo serwera baz danych, jako Ŝe bardzo często decyduje ono o tym, czy nasza baza będzie funkcjonowała poprawnie i czy firma nie będzie naraŝona na straty z powodu udanych ataków, których liczba rośnie z kaŝdym rokiem.

246 Bazy danych Laboratorium

Bazy danych 247 SQL Injection W tym ćwiczeniu zobaczysz składnie T-SQL symulujące cztery wersje ataku SQL Injection. Spreparowany przez nas złośliwy kod T-SQL wstawiany w pola tekstowe aplikacji wyszczególniamy na czerwono. Krok 1 - Stworzenie przykładowego mechanizmu logowania Zaloguj się do maszyny wirtualnej ZBD jako uŝytkownik Administrator z hasłem P@ssw0rd. Kliknij Start. Z grupy programów Microsoft SQL Server 2005 uruchom SQL Server Management Studio. W oknie logowania kliknij Connect. Kliknij w menu głównym programu Management Studio na File. Kliknij Open - File. Odszukaj plik C:\Labs\Lab12\SQLInjection.sql i kliknij Open. Zaznacz kod, który tworzy tabelę Users, w której będą przechowywane dane umoŝliwiające uwierzytelnienie uŝytkowników, takie jak login i hasło. USE AdventureWorks GO CREATE TABLE Users ( UserID int IDENTITY(1,1) PRIMARY KEY, Login nvarchar(20) NOT NULL, Password nvarchar(20) NOT NULL ) GO INSERT Users VALUES ('pawel','password') INSERT Users VALUES ('tomek','password') INSERT Users VALUES ('adam','password') -- zapytanie uwierzytelniajace SELECT * FROM Users WHERE Login = 'pawel' AND Password = 'password' Wciśnij F5, aby uruchomić zaznaczony fragment kodu. Wykonanie powyŝszego fragmentu kodu powoduje utworzenie tabeli Users, która zawiera kolumny Login (nazwa uŝytkownika) i Password (hasło). Kolumny te przechowują dane uŝytkowników niezbędne do uwierzytelnienia. Aby zalogować się do systemu uŝytkownik musi podać istniejący w tabeli login i odpowiadające mu hasło. Ostatnia linia wykonanego kodu zawiera zapytanie ilustrujące proces logowania. Jeśli to zapytanie zwraca jakikolwiek rekord, aplikacja uznaje, Ŝe uŝytkownik został poprawnie uwierzytelniony i jest zalogowany. Wyobraź sobie, Ŝe dane logowania (login i hasło) uŝytkownik podaje do zapytania przy uŝyciu aplikacji, w kodzie której zapytanie jest konstruowane przy uŝyciu

248 Bazy danych konkatenacji (łączenia) fragmentów zapytania SELECT z zawartością pól tekstowych zawierających wpisane przez uŝytkownika dane. Krok 2 - Atak SQL Injection - modyfikacja pierwsza Zaznacz kod, który symuluje pierwszy atak SQL Injection (patrz kod poniŝej). -- SQL Injection - 1 SELECT * FROM Users WHERE Login = '' OR 1=1 --' AND Password = 'password' Wciśnij F5, aby uruchomić zaznaczony fragment kodu. Wykonanie powyŝszego fragmentu kodu spowoduje wyświetlenie całej zawartości tabeli Users, a zarazem zalogowanie na konto pierwszego dostępnego w tej tabeli uŝytkownika. Składnia ' OR 1=1 -- wpisana w pole tekstowe zamiast loginu spowoduje, Ŝe zapytanie T-SQL zostanie zmodyfikowane na zapytanie, które nie pobiera drugiego pola (hasło) na skutek wykomentowania odpowiedniej części kodu (dwa myślniki komentują resztę składni). Natomiast stworzony sztucznie warunek z operatorem OR jest spełniony dla kaŝdego rekordu w tabeli (wyraŝenie 1=1 ma wartość logiczną 1). Krok 3 - Atak SQL Injection - modyfikacja druga Zaznacz kod, który symuluje drugi atak SQL Injection (patrz kod poniŝej). -- SQL Injection - 2 SELECT * FROM Users WHERE Login = '' OR 'a'='a' AND Password = '' or 'a'='a' Wciśnij F5, aby uruchomić zaznaczony fragment kodu. Wykonanie powyŝszego fragmentu kodu spowoduje wyświetlenie całej zawartości tabeli Users, a zarazem zalogowanie na konto pierwszego dostępnego w tej tabeli uŝytkownika. RóŜnica między tą wersją ataku a poprzednią jest taka, Ŝe tym razem nie uŝyliśmy symboli komentarza, a jedynie wstawiliśmy w pola login i hasło odpowiednio spreparowany fragment kodu T-SQL tworzący dwa zawsze spełnione warunki w klauzuli WHERE (wyraŝenie 'a'='a' ma wartość logiczną 1).

Bazy danych 249 Krok 5 - Atak SQL Injection - modyfikacja trzecia Zaznacz kod, który symuluje trzeci atak SQL Injection (patrz kod poniŝej). -- SQL Injection - 3 SELECT * FROM Users WHERE Login = ''; DROP TABLE Users --' AND Password = 'password' 2. Wciśnij F5, aby uruchomić zaznaczony fragment kodu. Wykonanie powyŝszego fragmentu kodu spowoduje próbę usunięcia tabeli Users z bazy danych (moŝesz sprawdzić, czy tabela została usunięta poprzez zaznaczenie i wykonanie ostatniej linii kodu z kroku 1). Operacja ta powiedzie się, jeŝeli aplikacja, z poziomu której powyŝsze zapytanie jest wykonywane łączy się z bazą danych w kontekście uŝytkownika, który ma uprawnienia do usunięcia tabeli.

250 Bazy danych Quiz - błędy programistów W tym ćwiczeniu spróbujesz w podanym przez nas kodzie znaleźć błędy, które sprawiają, Ŝe aplikacja staje się zagroŝeniem dla bazy danych i serwera baz danych. Krok 1 - Błędny kod W poniŝszym kodzie spróbuj odnaleźć 4 błędy, które mogą mieć wpływ na bezpieczeństwo bazy danych. PoniŜszy kod przedstawia fragment aplikacji napisanej w języku C#. Jeśli nigdy nie programowałeś w tym języku, nie szkodzi. Prześledź kod, a następnie przeczytaj zapisane poniŝej pytania i odpowiedzi. 1 SqlConnection conn = 2 new SqlConnection ("integrated security=false;" + "initial catalog=adventureworks;data source=zbd;uid=sa;pwd=password"); 3 SqlDataAdapter da = 4 new SqlDataAdapter("SELECT ProductID, Unitprice FROM Production.Product WHERE Name = '" + txtproduct.text + "'", conn); 5 6 try 7 { 8 da.fill (ds); 9 datagrid1.datasource = ds.tables[0]; 10 } 11 catch (SqlException ex) 12 { 13 MessageBox.Show (ex.message); 14 } Krok 2 - Odnajdywanie błędów Po prześledzeniu kodu z kroku 1 spróbuj odpowiedzieć na poniŝsze pytania (odpowiedź moŝesz uzyskać klikając na pytaniu). Pytanie 1.: Linia 2 kodu zawiera tzw. connection string, czyli opcje połączenia z bazą danych. Jakie dwa błędy związane z dostępem do bazy danych znajdują się w tych opcjach? Odpowiedź: A) Połączenie z serwerem nawiązywane jest za pomocą loginu ze zbyt wysokimi uprawnieniami (sa ma najwyŝsze uprawnienia w SQL Server - naleŝy do roli sysadmin). B) śaden login lub konto nie powinno mieć tak prostego hasła, jakie widnieje w linijce 2 kodu (password to jedno z pierwszych haseł na liście w atakach słownikowych na systemy).

Bazy danych 251 Pytanie 2.: W linii 4 programista zapisał zapytanie napisane w języku T-SQL. Jaki błąd popełnił programista w tworzeniu tego zapytania? Odpowiedź: Programista zbudował zapytanie uŝywając konkatenacji łańcucha reprezentującego kod T-SQL z zawartością pola tekstowego txtproduct, co umoŝliwia atak SQL Injection. Większość języków programowania oferuje mechanizmy, które pozwalają unikać podobnych konstrukcji kodu SQL. Na przykład na platformie.net istnieje klasa SqlParameter, która sprawia, Ŝe tekst wpisywany w aplikacji przez uŝytkowników jest traktowany jak zwykły tekst, a nie jak fragment kodu SQL. Pytanie 3.: Jaki inny błąd znajdujesz w powyŝszym kodzie? Odpowiedź: Programista zaprogramował obsługę błędów uŝywając strukturalnego przechwytywania wyjątków, ale wykorzystał domyślne komunikaty zwracane przez serwer (patrz linia 13). Komunikaty te mogą zawierać informacje, których nie powinien otrzymać uŝytkownik aplikacji. Dobrym nawykiem jest stosowanie swoich własnych komunikatów.