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

- 1 lub 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ądź 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 ź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ądź 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 ź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

„

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.

--

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 = ''

SQL Injection - przykłady

„

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...

-- atak SQL Injection - próba logowania

SELECT * FROM Uzytkownicy WHERE Login = '

' OR 1=1 --

' AND Haslo = ''

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 znaleźć 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.