Ćwiczenia > Mechanizmy bezpieczeństwa w MS SQL Server 2000 > Przykładowe techniki włamań

9.6 Przykładowe techniki włamań



Na ogół najprostszym sposobem na "dostanie się" do serwera baz danych jest wykorzystanie złego funkcjonowania (lub braku) walidacji danych wprowadzanych przez użytkowników w aplikacji (np. w polach tekstowych dynamicznej strony WWW). W tym rozdziale zaprezentujemy Ci przykładowe techniki włamań do SQL Servera (jako włamanie będziemy rozumieć nie tylko przejęcie kontroli nad serwerem, ale także uzyskanie dostępu do danych przez osoby nieupoważnione) właśnie z poziomu aplikacji. W poniższych przykładach czerwonym kolorem wyszczególniliśmy kod wstawiony umyślnie przez "złośliwego" uzytkownika aplikacji.

Krok 1 - Zobacz jak działa technika "wstrzyknięcia SQL"

1. Uruchom program Query Analyzer.
2. Zaloguj się używając uwierzytelnienia systemu Windows.
3. W menu głównym programu wybierz File - Open.
4. W oknie Open Query File wybierz plik demo_9_6_1.sql.
5. Zaznacz i uruchom (klawisz F5) fragment kodu oznaczony w komentarzu jako (1).


-- (1) SQL Injection
USE Northwind
GO

SELECT LastName, FirstName, HireDate
FROM Employees
WHERE EmployeeID = 'Costam' 
OR 1=1 -- '
GO


Załóżmy, że celem powyższego zapytania SELECT w zamierzeniu projektanta aplikacji bazodanowej było wyświetlenie danych określonego pracownika - tzn. aplikacja zawierała formularz z polem telstowym, w które użytkownik wprowadzić miał nazwisko osoby do wyświetlenia. W kodzie aplikacji budowane było za pomocą konkatenacji (złączenia łańcuchów tekstowych) zapytanie SQL z dołączaną zawartością pola tekstowego. Jednak "złośliwy" użytkownik wprowadził kod podświetlony na czerwono. W wyniku dodania warunku OR 1=1 wartość logiczna warunku zawsze wynosi PRAWDA, zatem serwer wyświetli zawartość całej tabeli (a nie to było zamierzeniem - co by było, gdyby na przykład dane zawierały numery kart kredytowych...). Znak komentarza serwera (dwa myślniki) powoduje, że nawet jeśli do zapytania po wstawionej wartości pola tekstowego dołączona była dalsza składnia zapytania SELECT (np. sortowanie czy dalsze warunki), byłaby ona przez serwer zignorowana! Po co umieściliśmy znak apostrofu po komentarzu? W celu domknięcia ewentualnego rozpoczętego łańcucha znaków (zauważ, że i tak komentarz spowoduje, że serwer tego apostrofu nie zauważy, ale aplikacja owszem!). I tym sposobem użytkownik uzyskał dostęp do danych, do których dostępu uzyskać nie miał prawa.

Opisana technika nazywa się popularnie SQL Injection ("wstrzyknięcie SQL") i jest najpopularniejszą techniką włamań do serwerów baz danych z poziomu aplikacji bazodanowych. Zauważ, że metoda ta działa wówczas, gdy programista lub projektant aplikacji nie umieści w kodzie aplikacji odpowiednich procedur sprawdzających poprawność danych wprowadzanych przez użytkowników. Dlatego zaleca się sprawdzanie wpisywanych przez użytkowników wartości na kilku poziomach aplikacji (m.in. w kodzie procedur składowanych). Dobrze jest też unikać używania konkatenacji w kodzie aplikacji do tworzenia zapytań SQL (świetnie można tu wykorzystać procedury składowane).

Jeśli kiedykolwiek będziesz tworzył aplikację bazodanową, spotkasz się z problemem walidacji danych. Pamiętaj, że twój kod walidujący powinien sprawdzać, czy kod jest tym, czego oczekujesz (sprawdzaj między innymi długość wstawionego tekstu oraz typ danych). Całą resztę należy odrzucić. O wiele trudniej jest sprawdzać wszystkie błędne wpisy - po prostu możesz jakąś możliwość przeoczyć.

Krok 2 - Jakie niebezpieczeństwa niesie za sobą procedura xp_cmdshell

1. Zaznacz i uruchom (F5) fragment kodu oznaczony w komentarzu jako (2).


-- (2) SQL Injection + xp_cmdshell
SELECT LastName, FirstName, HireDate
FROM Employees
WHERE LastName = 'Costam';
EXEC master.dbo.xp_cmdshell 'dir /p' -- '
GO


W powyższym przykładzie również "złośliwy użytkownik" skorzystał z SQL Injection. Ale tym razem dodał (średnik oznacza koniec jednego i początek drugiego polecenia) wywołanie procedury rozszerzonej xp_cmdshell (o której już pisaliśmy w ćwiczeniach). Załóżmy, że powyższe zapytanie jest wykonywane wewnątrz procedury składowanej oraz że procedura zawierająca ów kod jest wykonywana w kontekście uprzywilejowanego użytkownika (np. administratora serwera). Widzisz co może się stać? W powyższym przykładzie zostanie jedynie wyświetlona zawartość katalogu systemowego Windows. Ale rzuć okiem na kod oznaczony w komentarzu jako (3)!


-- (3) j.w. ale juz tego nie uruchamiaj
SELECT LastName, FirstName, HireDate
FROM Employees
WHERE LastName = 'Costam';
EXEC master.dbo.xp_cmdshell 'net user haker tajne_haslo /ADD';
EXEC master.dbo.xp_cmdshell 'net localgroup Administratorzy haker /ADD' -- '
GO


Teraz sytacja może być krytyczna. Użytkownik dodaje nowy login do systemu Windows (zakładamy, że serwer pracuje w systemie Windows XP/2000/2003) i co gorsza dołącza ów login do grupy lokalnych administratorów (jeśli chcesz, wykonaj powyższy kod, a następnie sprawdź, czy dodane zostało nowe konto w systemie Windows). W tym momencie o bezpieczeństwie nie może być już mowy. Zapamiętaj, że jeśli wewnątrz jednej procedury składowanej wywołujesz inną, to wewnętrzna procedura jest wykonywana w kontekście użytkownika wykonującego procedurę zewnętrzną. Oznacza to, że za wszelką cenę należy unikać pracy w serwerze jako członek uprzywilejowanej grupy serwera (np. sysadmin) przy takich operacjach jak tworzenie procedur składowanych w bazach danych.




Ćwiczenia > Mechanizmy bezpieczeństwa w MS SQL Server 2000 > Przykładowe techniki włamań