Bezpieczeństwo
w bazach danych
Dr inż. Izabela Rojek
Plan wykładu
Jak należy rozumieć bezpieczeństwo baz
danych?
Poziomy bezpieczeństwa
Implementacja różnych poziomów
bezpieczeństwa
Jak należy rozumieć
bezpieczeństwo baz danych?
Pojęcie bezpieczeństwa baz danych wiąże
się nieodłącznie z bezpieczeństwem
serwera baz danych
W hierarchii bezpieczeństwo serwera baz
danych stoi wyżej niż bezpieczeństwo
pojedynczej bazy
Jak należy rozumieć
bezpieczeństwo baz danych?
Bezpieczeństwo serwera baz danych to:
zapewnienie stabilnego i w miarę możliwości
bezawaryjnego działania serwera baz danych,
zapewnienie uprawnionym użytkownikom dostępu do
odpowiednich baz danych,
ograniczenie dostępu do danych dla użytkowników
nieuprawnionych,
zapewnienie jak najmniejszej ingerencji serwera baz
danych w działanie systemu operacyjnego komputera.
Jak należy rozumieć
bezpieczeństwo baz danych?
Bezpieczeństwo baz danych natomiast dotyczy
następujących aspektów:
umożliwienie tylko autoryzowanym
użytkownikom wykonywania odpowiednich
operacji na bazie danych,
zapewnienie bezpieczeństwa fizycznego bazy
danych (odpowiednia strategia kopii
zapasowych).
Jak należy rozumieć
bezpieczeństwo baz danych?
Mówiąc o bezpieczeństwie należy rozróżniać dwa
pojęcia:
uwierzytelnienie - oznacza identyfikację
użytkownika na podstawie jego nazwy i hasła
autoryzacja - jest fazą następującą po
poprawnym uwierzytelnieniu i polega na
określeniu uprawnień przypadających
uwierzytelnionemu użytkownikowi.
Poziomy bezpieczeństwa
bezpieczeństwo fizyczne danych,
bezpieczeństwo sieci,
bezpieczeństwo domeny,
bezpieczeństwo maszyny lokalnej,
bezpieczeństwo serwera baz danych,
bezpieczeństwo bazy danych,
bezpieczeństwo aplikacji bazodanowej.
Poziomy bezpieczeństwa
Bezpieczeństwa doskonałego nie można w
praktyce nigdy zapewnić, ale można podjąć
kroki, by zapobiegać skutkom wszelkich awarii,
katastrof lub niepożądanych ingerencji czynnika
ludzkiego.
Aby zadbać o globalne bezpieczeństwo, należy
zaplanować strategię na każdym z
wymienionych poziomów bezpieczeństwa
Poziom bezpieczeństwa fizycznego
danych
określa, czy w przypadku awarii sprzętu, katastrofy (jako
katastrofę rozumiemy nie tylko czynniki naturalne jak
powodzie, także kradzieże i inne wpływy czynnika
ludzkiego) lub fizycznego uszkodzenia plików danych
jesteśmy w stanie odtworzyć dane i jak długo baza
danych (lub serwer baz danych) będzie niedostępny dla
użytkowników.
Na tym poziomie należy też odpowiedzieć na pytanie czy
kopie danych są bezpieczne (m.in. czy niepowołane
osoby nie mają do nich dostępu).
Poziom bezpieczeństwa sieci
określa, czy dane są bezpiecznie
przesyłane w sieci.
Szczególnie dotyczy to ściśle poufnych
danych, tj. numerów kart kredytowych czy
danych personalnych klientów firmy.
Poziom bezpieczeństwa domeny
określa, czy komputery w domenie (w
szczególności kontrolery domeny) są
odpowiednio zabezpieczone.
W dobie integracji serwerów baz danych
(np. MS SQL Server) z systemami
operacyjnymi w przypadku braku
zabezpieczeń w systemie operacyjnym
bezpieczeństwo serwera baz danych
spada do minimum.
Poziom bezpieczeństwa serwera
baz danych
określa, czy serwer baz danych jest
odpowiednio zabezpieczony przed
nieuprawnionymi użytkownikami
(fizycznie - maszyna oraz
wirtualnie - odpowiednie mechanizmy
uwierzytelniające).
Poziom bezpieczeństwa bazy
danych
określa, czy dostęp do bazy danych i ról w
bazie danych jest odpowiednio
skonfigurowany
(na ogół jest to sprawa konfiguracji w
SZBD).
Poziom bezpieczeństwa aplikacji
bazodanowej
określa, czy kod aplikacji klienckiej
współpracującej z bazą danych jest
napisany w sposób bezpieczny
(czy aplikacja nie umożliwia zmniejszenia
bezpieczeństwa na którymkolwiek z
pozostałych poziomów).
Szczególnie należy tu zwrócić uwagę na
dane wprowadzane przez użytkowników.
Implementacja różnych poziomów
bezpieczeństwa
Implementacja bezpieczeństwa fizycznego
Implementacja bezpieczeństwa sieci
Implementacja bezpieczeństwa komputerów i
domen
Implementacja bezpieczeństwa serwerów baz
danych i samych baz
Implementacja bezpieczeństwa aplikacji
bazodanowej
Implementacja bezpieczeństwa
fizycznego
Zadaniem administratora baz danych jest zapewnienie
tolerancji błędów dysków fizycznych dla systemu i dla
danych oraz zaplanowanie strategii sporządzania i
przechowywania kopii zapasowych.
Tolerancję błędów dysków fizycznych można osiągnąć
używając woluminów typu RAID 1lub RAID 5
- - (RAID-
ang. Redundant Array of Independent Disks).
Implementacja bezpieczeństwa
fizycznego
Implementacja RAID-1 polega na jednoczesnym
przechowywaniu danych na dwóch fizycznych
dyskach stanowiących jeden dysk logiczny (dwie
kopie danych - w przypadku awarii jednego
dysku, drugi nadal umożliwia dostęp do danych).
Oznacza to, że 50% pojemności woluminu typu
RAID-1 jest przeznaczone na przechowywanie
danych, a druga połowa służy do
przechowywania kopii danych.
Implementacja bezpieczeństwa
fizycznego
RAID-5 to dysk logiczny składający się z co najmniej
trzech dysków fizycznych (z każdego dysku wolumin
zabiera tyle samo przestrzeni dyskowej).
W woluminach typu RAID-5 część przestrzeni
dyskowej jest poświęcana na zapis tzw. danych
parzystości (niezbędnych do odzyskania danych w
przypadku awarii jednego z dysków wchodzących w
skład woluminu).
Im więcej dysków wchodzi w skład woluminu, tym
mniej przestrzeni dyskowej zajmują dane
parzystości (mniejsza nadmiarowość danych).
Implementacja bezpieczeństwa
fizycznego
Najlepszym rozwiązaniem w kwestii zapewnienia
tolerancji błędów dysków fizycznych są
sprzętowe woluminy RAID pracujące z
kontrolerami SCSI (z uwagi na szybszą pracę
niż RAID software'owy). Niestety jest to
jednocześnie najdroższe rozwiązanie.
Implementacja bezpieczeństwa
fizycznego
Kopie bezpieczeństwa zwane też kopiami
zapasowymi (ang. backup) powinny być
przechowywane bądz
na zewnętrznym nośniku
(taśmy, płyty CD lub inne nośniki przenośne) lub
na innym komputerze niż ten, z którego
kopiujemy dane.
Ponadto nośniki z kopiami zapasowymi powinny
być przechowywane w innym miejscu niż
maszyna, z której pochodzą dane (zmniejszamy
ryzyko w przypadku pożarów czy powodzi).
Implementacja bezpieczeństwa
fizycznego
Strategia kopii zapasowych powinna być zaplanowana
przez administratora baz danych i administratora
systemu operacyjnego.
Należy zaplanować strategię, która odpowiada
potrzebom firmy - tzn. należy odpowiedzieć na pytanie,
czy ważniejsze jest szybkie sporządzanie kopii
zapasowych, czy też istotniejsze jest jak najszybsze
przywracanie danych po awarii.
Na ogół strategia musi uwzględnić obie kwestie.
Stąd najczęściej powtarzanym schematem sporządzania
kopii zapasowych jest wykonywanie co tydzień kopii
wszystkich danych oraz codzienne wykonywanie kopii
różnicowych (tylko dane zmodyfikowane danego dnia).
Implementacja bezpieczeństwa
fizycznego
W budowaniu strategii kopii zapasowych należy
też uwzględnić "godziny szczytu" pracy serwera
(proces wykonywania kopii zapasowych pociąga
za sobą dodatkowe obciążenie serwera).
Dlatego na ogół operacje te są wykonywane w
godzinach nocnych i są planowane w ten
sposób, by nie kolidowały z czasem, gdy
użytkowanie serwera przez klientów jest
najintensywniejsze.
Implementacja bezpieczeństwa
sieci
Przy planowaniu bezpieczeństwa sieci należy zadać
sobie pytanie,
czy dane przesyłane z naszego serwera baz danych
są poufne.
Jeśli tak, to możemy zastosować dostępne protokoły
szyfrujące, tj. SSH czy IPSec.
Oprócz implementacji sieciowych protokołów
szyfrujących do transmisji danych należy ograniczyć
ilość danych wysyłanych w świat do niezbędnego
minimum
(najlepiej nie "przedstawiać się" zbytnio w sieci -
ujawnienie oprogramowania serwera baz danych to
pierwszy krok do zachwiania bezpieczeństwa naszego
serwera).
Implementacja bezpieczeństwa
komputerów i domen
Nie należy instalować serwerów baz
danych na serwerach kluczowych dla
domeny (kontrolery domeny).
Najlepsza struktura domeny to taka, w
której każdy serwer pełni pojedynczą
funkcję
(np. serwer aplikacji, serwer plików,
serwer baz danych itd.).
Implementacja bezpieczeństwa
komputerów i domen
Niezbędna jest odpowiednia polityka
administratorów systemu (lub domeny), czyli:
utrzymywanie aktualnego poziomu
zabezpieczeń systemu operacyjnego oraz
serwera baz danych,
odpowiednia polityka bezpiecznych haseł
użytkowników,
zmiana nazw kont administratorskich,
monitorowanie logowania do systemu (domeny),
- ograniczanie dostępu do plików i folderów,
Implementacja bezpieczeństwa
komputerów i domen
nadawanie minimalnych wymaganych uprawnień dla
użytkowników i grup,
jak najmniejsze wykorzystywanie kont
administratorskich,
implementacja "zapór ogniowych" (ang. firewall),
ogranicznenie fizycznego dostępu do serwerów i
kontrolerów domeny,
uruchamianie usług serwera baz danych przy użyciu
konta użytkownika specjalnie stworzonego w tym celu
(nie administratora), zapewnienie stabilności tego konta
(np. nigdy nie wygasające hasło).
Implementacja bezpieczeństwa
serwera baz danych i samych baz
Pod hasłem bezpieczeństwa serwera baz
danych rozumiemy umożliwienie korzystania z
serwera tylko osobom do tego uprawnionym.
Większość SZBD oferuje uwierzytelnianie
użytkowników na dwóch poziomach: na
poziomie serwera (użytkownik może dostać się
do serwera) oraz na poziomie bazy danych
(użytkownik serwera ma dostęp do konkretnej
bazy danych).
Implementacja bezpieczeństwa
serwera baz danych i samych baz
Mechanizmy uwierzytelniania i autoryzacji są
różne i zależą od konkretnego SZBD.
Zazwyczaj użytkownicy dzieleni są na role
(grupy), natomiast rolom nadawane są
określone uprawnienia.
Ponadto niezbędnym dobrym nawykiem
administratora baz danych powinno być
rejestrowanie i monitorowanie zdarzeń na
serwerze w poszukiwaniu nietypowych zdarzeń.
Implementacja bezpieczeństwa
aplikacji bazodanowej
Piętą achillesową systemu informatycznego
współpracującego z bazą danych często jest interfejs
użytkownika (od strony programistycznej i implementacji
logiki biznesowej).
Szczególnie chodzi tu o umożliwienie użytkownikom
oddziaływania na serwer baz danych lub nawet na
system operacyjny serwera z poziomu aplikacji
klienckiej.
Należy ze szczególną uwagą projektować aplikacje
bazodanowe.
Implementacja bezpieczeństwa
aplikacji bazodanowej
Oto kilka zasad, którymi należy się kierować przy tworzeniu
interfejsów dla tych aplikacji:
zachowaj przezroczystość aplikacji i bazy danych (nie
pokazuj informacji o z
ródle aplikacji i o strukturze bazy
danych), szczególnie uważaj na komunikaty domyślne
aplikacji (lepiej ustawić swoje, które powiedzą tylko, że
wystąpił błąd),
nigdy nie ufaj użytkownikowi aplikacji i wpisywanym
przez niego wartościom,
sprawdzaj tylko, czy wejście jest tym, czego oczekujesz i
odrzucaj wszystko inne,
Implementacja bezpieczeństwa
aplikacji bazodanowej
walidację wejścia przeprowadzaj na wielu poziomach,
Termin walidacja pochodzi od angielskiego słowa validate i oznacza  w
kontekście informatycznym  sprawdzanie poprawności i zgodności z
zadanymi kryteriami. Jest on stosowany w odniesieniu do danych
pochodzących od użytkownika jak również w stosunku do zmiennych,
obiektów, typów i klas w różnych językach programowania.
Wprowadzając dane, użytkownik może  świadomie lub nie  popełnić
pomyłkę. Jeśli dane odebrane od użytkownika poddamy przetwarzaniu bez
weryfikacji, wówczas, w zależności od odporności aplikacji, możemy mieć do
czynienia z różnymi rodzajami błędów, od drukowania w przeglądarce klienta
komunikatów diagnostycznych PHP czy MySQL, poprzez utratę spójności bazy
danych, aż po ujawnienie niepowołanym użytkownikom informacji poufnych. Z
tego powodu, nie wolno ignorować wagi problemu.
Implementacja bezpieczeństwa
aplikacji bazodanowej
używaj wyrażeń regularnych,
staraj się nie używać konkatenacji do
tworzenia zapytań SQL (zamiast tego użyj
procedur z parametrami),
łącz się z bazą danych używając w miarę
najmniej uprzywilejowanego konta
użytkownika.
Implementacja bezpieczeństwa
aplikacji bazodanowej
Poniżej kilka porad dla administratorów systemów i serwerów
baz danych:
- nigdy nie myśl, że system i serwer baz danych są
bezpieczne,
- nigdy nie ufaj temu, co użytkownik podaje na wejście,
- zachowuj zasadę minimalnych uprawnień,
- zachowuj zasadę "domyślnie zamknięte",
- regularnie szukaj nieprawidłowości w systemie,
- bądz
na bieżąco z technologiami i technikami
programistycznymi.
Bezpieczeństwo baz danych
Bezpieczeństwo baz danych ma wiele aspektów
i musi być rozpatrywane na wielu poziomach.
Raz zabezpieczony serwer baz danych wymaga
stałego nadzoru i monitorowania.
Należy pamiętać, że nie wolno nam zakładać,
że coś jest całkowicie bezpieczne, ponieważ jak
w każdej dziedzinie informatyki, również w
bezpieczeństwie codziennie zachodzą zmiany
i dochodzą nowe zagrożenia.
Bezpieczeństwo aplikacji
Najczęstsze błędy programistów.
SQL Injection.
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.
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,
Programowanie z dostępem do
danych - błędy
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.
Programowanie z dostępem do
danych  najlepsze nawyki
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).
SQL Injection
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.
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.
SQL Injection - co to takiego?
Co jest najważniejsze, na atak ten jest
narażony każdy SZBD, jeśli tylko istnieje
odpowiednio z
le napisana aplikacja, która
się do tego systemu dostaje i korzysta z
baz w nim przechowywanych.
SQL Injection następstwa
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 niepożądanej operacji w bazie danych (np.
usunięcie tabeli),
wykonanie niepożądanej operacji w SZBD (np.
stworzenie nowej bazy danych),
wykonanie niepożą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 zaznaczono 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.
SQL Injection - przykłady
-- atak SQL Injection - próba logowania
SELECT * FROM Uzytkownicy WHERE Login = '' OR 1=1 --' AND Haslo = ''
Uwaga na trzeci fragment kodu SQL, w którym kolorem czerwonym
zaznaczono 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ł? Co powoduje wstawienie złośliwego
kodu. 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...
SQL Injection - przykłady
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'
SQL Injection  przykłady
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 = ''
SQL Injection  przykłady
Przykład 2 - Wykonanie niepożądanej operacji w bazie danych
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).
SQL Injection  przykłady
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.
SQL Injection  przykłady
Przykład 3 - Przejęcie kontroli nad systemem operacyjnym
-- 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 = ''
SQL Injection  przykłady
Przykład 3 - Przejęcie kontroli nad systemem operacyjnym
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).
SQL Injection- obrona
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.
SQL Injection
Jako ciekawostkę można podać 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 znalez
ć chociażby w dokumentacji).
Bezpieczeństwo
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.