IDZ DO

PRZYKADOWY ROZDZIA
SPIS TRECI

KATALOG KSIEK
KATALOG ONLINE
ZAMW DRUKOWANY KATALOG

PHP. Bezpieczne
programowanie
Autor: Chris Shiflett
Tumaczenie: Sawomir Dzieniszewski
ISBN: 83-246-0425-1
Tytu oryginau: Essential PHP Security
Format: B5, stron: 128

TWJ KOSZYK
DODAJ DO KOSZYKA

CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK

CZYTELNIA
FRAGMENTY KSIEK ONLINE

Bezpieczestwo danych w sieci to temat, ktry jest ostatnio poruszany niezwykle

czsto. Serwery internetowe zajmujce si przetwarzaniem transakcji elektronicznych,
wywietlaniem stron WWW i przesyaniem danych stay si ulubionym celem atakw
komputerowych przestpcw. Kluczowym zagadnieniem jest wic bezpieczestwo
aplikacji dziaajcych na tych serwerach. Aplikacje napisane w najpopularniejszym
jzyku, w PHP, stanowi dla hakerw akomy ksek. Nie jest to jednak wina jzyka,
a raczej twrcw aplikacji, ktrzy w projektach nie uwzgldniaj mechanizmw
obronnych.
Ksika PHP. Bezpieczne programowanie zawiera przegld metod pozwalajcych na
ochron aplikacji internetowych przed rnymi rodzajami atakw. Czytajc j, nauczysz
si projektowa bezpieczne formularze, zapobiega przechwytywaniu informacji z baz
danych oraz zabezpiecza mechanizmy sesji. Dowiesz si, w jaki sposb uchroni si
przed kradzie danych oraz uniemoliwi atak polegajcy na wstrzykiwaniu polece
i kodu SQL. Poznasz take oglne zasady ochrony kodu rdowego.
Ataki na formularze
Zabezpieczanie przed wykonywaniem skryptw
Ochrona baz danych
Zabezpieczanie mechanizmw sesji i danych logowania
Uniemoliwianie uruchamiania obcych aplikacji
Ochrona systemu plikw na serwerze
Utrzymywanie aplikacji na wspdzielonym serwerze i eliminowanie
zwizanych z tym zagroe
Poznaj rne rodzaje atakw i stwrz mechanizmy obronne

Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl

Przedmowa ..................................................................................................................... 5
O ksice ......................................................................................................................... 7
1. Wprowadzenie .............................................................................................................. 11
Funkcje jzyka PHP
Strategie
Dobre praktyki

12
14
17

2. Formularze i adresy URL ............................................................................................... 25

Formularze i dane
Ataki semantyczne na adresy URL
Ataki zwizane z adowaniem plikw
Ataki typu cross-site scripting
Ataki typu CSRF
Podrabiane zatwierdzenia formularza
Sfaszowane dania HTTP

25
28
30
33
34
38
39

3. Bazy danych i SQL .........................................................................................................43

Ujawnienie uwierzytelnie dostpu
Wstrzykiwanie kodu SQL
Ujawnienie danych przechowywanych w bazie

44
45
50

4. Sesje i cookie ..................................................................................................................51

Kradzie cookie
Ujawnienie danych sesji
Zafiksowanie sesji
Przechwytywanie sesji

53
54
54
58

5. Pliki doczane do programw .................................................................................... 61

Ujawnienie kodu rdowego
Adresy URL otwierajce tylne drzwi
Manipulowanie nazw pliku
Wstrzykiwanie kodu

61
63
63
65

6. Pliki i polecenia ............................................................................................................. 67

Trawersowanie katalogw
Zagroenia zwizane z plikami zdalnymi
Wstrzykiwanie polece

67
69
71

7. Uwierzytelnianie i autoryzacja .................................................................................... 73

amanie zabezpiecze metod brutalnej siy
Podsuchiwanie hase
Ataki metod powtrzenia
Trway login

74
77
78
79

8. Na wsplnym hocie .....................................................................................................85

Ujawnienie kodu rdowego
Ujawnienie danych sesji
Wstrzykiwanie sesji
Przegldanie systemu plikw
Bezpieczny tryb jzyka PHP

85
88
91
93
94

A Dyrektywy konfiguracyjne ........................................................................................... 97

B Funkcje ......................................................................................................................... 103
C Kryptografia ................................................................................................................ 109
Skorowidz .................................................................................................................... 115

Spis treci

ROZDZIA 3.

Bardzo czsto kod PHP wykorzystywany jest jako poczenie midzy rnymi rdami danych a uytkownikiem. Prawd powiedziawszy, niektrzy twierdz, e jzyk PHP jest raczej
platform programow ni zwykym jzykiem programowania. Jest on na przykad bardzo
czsto wykorzystywany do komunikacji z baz danych.
Jzyk PHP jest dobrze przystosowany do tej roli gwnie z uwagi na to, e potrafi si kontaktowa z dug list rnych baz danych. Oto tylko kilka najbardziej popularnych systemw
baz danych, ktre jzyk PHP obsuguje:
DB2
InterBase
MySQL

ODBC
Oracle
PostgreSQL

SQLite
Sybase
DBM

Tak jak jest w przypadku kadego zewntrznego miejsca skadowania danych, tak i bazy danych nios ze sob pewne ryzyko. Mimo i w niniejszej ksice nie zajmujemy si bezpieczestwem baz danych, powinnimy pamita, e piszc aplikacje WWW, naley mie na wzgldzie problemy zwizane z bezpieczestwem baz danych, w szczeglnoci w sytuacjach, kiedy
naley traktowa dane otrzymywane z bazy danych jako dane zewntrzne (dane wejciowe).
Tak jak wspomniaem w rozdziale 1., wszelkie dane wejciowe powinny by filtrowane, a wszelkie dane zwracane (dane wyjciowe) powinny by opatrywane odpowiednimi znakami ucieczki.
W odniesieniu do komunikacji z bazami danych bdzie to oznacza, e wszystkie dane nadchodzce z bazy danych musz by filtrowane, a wszelkie dane wysyane do bazy musz by
opatrzone znakami ucieczki.
Jeden z typowych bdw polega na zapominaniu, e zapytanie SELECT rwnie
wysya dane do bazy danych. Mimo i jego zadaniem jest pobieranie danych, samo
jednak zawiera dane wyjciowe wysyane przez aplikacje.

Wielu programistw PHP zapomina o koniecznoci filtrowania danych nadchodzcych z bazy danych, poniewa w bazie przechowywane s zazwyczaj wycznie dane ju przefiltrowane. Mimo i ryzyko zwizane z tym zaniedbaniem nie jest due, ja jednak zalecabym, aby
nie uatwia sobie w ten sposb ycia. Podejcie to bowiem pokada zbyt wielkie zaufanie
w bezpieczestwie bazy danych, a ponadto amie zasad tworzenia w miar moliwoci dodatkowych zabezpiecze. Naley pamita, e wprowadzanie takich dodatkowych zabezpiecze

43

wzmacnia oglne bezpieczestwo aplikacji i komunikacja z baz danych jest znakomitym

przykadem korzyci pyncych z zaimplementowania dodatkowych mechanizmw ochronnych. Jeli komu uda si w jaki sposb wprowadzi do bazy danych niebezpieczne dane, to
odpowiedni mechanizm filtrowania danych w aplikacji je wyapie, pod warunkiem oczywicie,
e bdzie istnia.
W niniejszym rozdziale przyjrzymy si paru problemom zwizanym z bezpieczestwem
komunikacji z bazami danych, midzy innymi ujawnieniu uwierzytelnie dostpu czy wstrzykiwaniu kodu SQL. Szczegln uwag naley zwrci wanie na wstrzykiwanie kodu SQL
z uwagi na to, e czsto wykrywa si w popularnych aplikacjach PHP podatno na takie ataki.

Ujawnienie uwierzytelnie dostpu

Jednym z wanych problemw zwizanych z korzystaniem z baz danych jest niebezpieczestwo ujawnienia uwierzytelnie umoliwiajcych dostp do bazy danych czyli nazwy
uytkownika i hasa. Czsto s one dla wygody zachowywane w pliku takim jak db.inc:
<?php
$db_user = 'myuser';
$db_pass = 'mypass';
$db_host = '127.0.0.1';
$db = mysql_connect($db_host, $db_user, $db_pass);
?>

Zarwno nazwa uytkownika myuser, jak i haso mypass s szczeglnie wane dla bezpieczestwa bazy danych i aplikacji, dlatego te naley zwrci na nie szczegln uwag. Umieszczanie ich w kodzie rdowym wie si z pewnym ryzykiem, ktrego jednak raczej nie da
si unikn. Bez nich nasza baza danych nie mogaby by chroniona za pomoc nazwy uytkownika i hasa.
Jeli przyjrzymy si plikowi httpd.conf (standardowemu plikowi konfiguracyjnemu serwera
WWW Apache), przekonamy si, e domylny typ zawartoci zdefiniowany zosta tam jako
text/plain. Ustawienie takie jest szczeglnie niebezpieczne, gdy plik z hasami, taki jak
db.inc, jest przechowywany w katalogu dokumentw WWW. Kademu dokumentowi przechowywanemu w katalogu dokumentw WWW przypisany zostaje bowiem odpowiedni adres
URL i poniewa serwer Apache nie okrela zazwyczaj specjalnego typu zawartoci dla plikw .inc, wic kade danie tego rodzaju zasobu zwrci plik z hasami w postaci zwykego
pliku tekstowego (domylny typ zawartoci). W ten sposb dajcy bez trudu uzyska dostp do uwierzytelnie dostpu bazy danych.
Aby lepiej wyjani zagroenia zwizane z tak sytuacj, zamy, e mamy serwer WWW,
w ktrym dokumenty przechowywane s w katalogu /www. Jeli plik db.inc bdzie przechowywany w podkatalogu www/inc, to otrzyma wasny adres URL http://example.org/inc/dbinc
(zakadajc, e adres internetowy hosta serwera WWW to example.org). Zagldajc pod ten
adres URL, uytkownik bdzie mg obejrze kod rdowy pliku db.inc w postaci zwykego
tekstu (jak to okrela domylny typ zawartoci). Dlatego te, jeli plik db.inc przechowywany
jest w ktrymkolwiek z podkatalogw katalogu dokumentw /www, zawsze istnieje ryzyko
ujawnienia uwierzytelnie dostpu osobom niepowoanym.

44

Rozdzia 3. Bazy danych i SQL

Najlepszym rozwizaniem tego problemu jest przechowywanie plikw zaczanych (z rozszerzeniem .inc od ang. includes) poza katalogiem dokumentw WWW. Aby korzysta z nich
za pomoc dyrektyw include czy require, nie trzeba ich umieszcza w adnym cile okrelonym katalogu w systemie plikw mona umieci je w dowolnym miejscu, trzeba tylko
zadba, by serwer WWW mia uprawnienia do odczytywania plikw przechowywanych
w tym katalogu. Jak wic wida, umieszczanie ich w katalogu dokumentw WWW wie si
jedynie z niepotrzebnym ryzykiem, a kada metoda, ktra bdzie prbowa zmniejszy to
ryzyko, nie przenoszc ich jednak poza katalog dokumentw WWW, bdzie tylko prodkiem. Generalnie w katalogu dokumentw WWW naley umieszcza wycznie te pliki i zasoby, ktre koniecznie musz by dostpne po podaniu odpowiedniego adresu URL. W kocu
jest to katalog dostpny publicznie dla wszystkich uytkownikw internetu.
Rada ta odnosi si rwnie do baz SQLite. Bardzo wygodnym rozwizaniem jest
umieszczenie bazy danych w biecym katalogu, dziki czemu mona si do niej
odwoywa, podajc tylko nazw, a nie ca ciek do katalogu bazy danych. Niemniej
w ten sposb umieszczamy baz danych w katalogu dokumentw WWW i naraamy
na niepotrzebne ryzyko. Baza taka moe zosta skompromitowana za pomoc prostego dania HTTP, o ile nie przedsiwemiemy odpowiednich krokw, aby j dodatkowo zabezpieczy przed moliwoci bezporedniego dostpu z zewntrz. Najbardziej polecanym rozwizaniem pozostaje jednak umieszczenie bazy danych poza
drzewem dokumentw WWW.

Jeli z powodu jakich czynnikw zewntrznych nie bdziemy mogli skorzysta z optymalnego rozwizania polegajcego na umieszczeniu wszystkich zaczanych plikw poza katalogiem dokumentw WWW, mona zawsze skonfigurowa serwer Apache, tak aby odrzuca
dania HTTP o pliki .inc:
<Files ~ "\.inc$">
Order allow,deny
Deny from all
</Files>

W rozdziale 8. opisuj metod chronienia uwierzytelnie dostpu bazy danych

szczeglnie efektywn w rodowiskach, gdzie na tym samym hocie dziaaj rne
programy (w takim przypadku pliki znajdujce si poza katalogiem WWW nadal
naraone s ryzyko ujawnienia).

Wstrzykiwanie kodu SQL

Podatno na technik ataku zwan wstrzykiwaniem kodu SQL (ang. SQL injection) jest jedn z najczstszych saboci aplikacji PHP. Jest to szczeglnie zadziwiajce, jako e ataki tego
typu moliwe s tylko wtedy, gdy programista popeni od razu dwa powane bdy zapomni o filtrowaniu danych nadchodzcych do aplikacji z zewntrz (danych wejciowych)
i jednoczenie zapomni o koniecznoci opatrywania znakami ucieczki danych wysyanych do
aplikacji (danych wyjciowych). Nie powinno si zapomina o adnym z tych dwu podstawowych zabiegw, a tylko stosowanie obu technik jednoczenie daje gwarancj powanego
ograniczenia bdw.

Wstrzykiwanie kodu SQL

45

Wykorzystanie techniki wstrzykiwania kodu SQL zazwyczaj wymaga ze strony atakujcego

odrobiny zgadywania i pewnego eksperymentowania musi odgadn, jak wyglda schemat naszej bazy danych (zakadajc oczywicie, e nie udao mu si zdoby dostpu do naszego kodu rdowego lub schematu bazy danych). Rozwamy nastpujcy prosty formularz
logowania:
<form action="/login.php" method="POST">
<p>Nazwa uytkownika: <input type="text" name="username" /></p>
<p>Haso: <input type="password" name="password" /></p>
<p><input type="submit" value="Zaloguj si" /></p>
</form>

Rysunek 3.1 pokazuje, jak formularz ten bdzie wyglda w oknie przegldarki.

Rysunek 3.1. Prosty formularz logowania wywietlony w oknie przegldarki

Haker, ktry zobaczy taki formularz, bdzie mg sprbowa zgadn, za pomoc jakiego
zapytania sprawdzamy wpisywan nazw uytkownika i haso. Przegldajc kod rdowy
HTML, atakujcy moe sprbowa zgadywa, jakie stosujemy konwencje nazewnicze. Typowe zaoenie hakera bdzie takie, e nazwy uywane w formularzu powinny odpowiada
nazwom kolumn w tabelach bazy danych. Oczywicie samo tylko stosowanie rnych nazw
w obu przypadkach nie jest wystarczajcym zabezpieczeniem.
Na podstawie tego formularza mona z duym prawdopodobiestwem zgadywa, e zapytanie wysyane przez aplikacj do bazy danych bdzie miao nastpujc posta (i tak jest
w istocie w moim przykadzie):
<?php
$password_hash = md5($_POST['password']);
$sql = "SELECT
FROM
WHERE
AND

count(*)
users
username = '{$_POST['username']}'
password = '$password_hash'";

?>

46

Rozdzia 3. Bazy danych i SQL

Typowego zabezpieczenia polegajcego na szyfrowaniu hasa uytkownika za pomoc algorytmu MD5 nie mona ju duej traktowa jako wystarczajcej ochrony.
Ostatnimi czasy wykryto kilka sabych punktw algorytmu szyfrujcego MD5. Ponadto wiele baz danych korzystajcych z tego algorytmu szyfrujcego osabia jego
skuteczno, starajc si uproci mechanizm odszyfrowywania danych zaszyfrowanych algorytmem MD5. Odpowiednie przykady mona znale pod adresem: http://
md5.rednoize.com/.
Najlepszym rozwizaniem jest specjalne znakowanie hase uytkownikw poprzez
dodawanie do nich acucha, ktry bdzie unikatowy dla naszej aplikacji, na przykad w ten sposb:
<?php
$salt = 'SHIFLETT';
$password_hash = md5($salt . md5($_POST['password'] . $salt));
?>

Oczywicie atakujcy nie musi poprawnie odgadn schematu bazy danych ju za pierwszym razem. Prawie zawsze musi najpierw przeprowadzi par eksperymentw. Dobrym
przykadem takiego eksperymentu jest przesanie aplikacji pojedynczego cudzysowu jako
nazwy uytkownika, poniewa w ten sposb haker moe zdoby kilka istotnych informacji.
Wielu programistw, obsugujc bdy pojawiajce si w trakcie wykonywania zapyta skierowanych do baz danych, korzysta z odpowiednich funkcji takich jak mysql_error(). Tutaj
pokazuj przykad takiego podejcia:
<?php
mysql_query($sql) or exit(mysql_error());
?>

Jednak rozwizanie takie, cho bardzo pomocne podczas programowania, jeli pozostawimy
je w gotowej aplikacji, moe zdradzi atakujcemu bardzo istotne informacje. Jeli haker
przele jako nazw uytkownika pojedynczy cudzysw, a jako haso mypass, zapytanie wysane przez aplikacj przyjmie nastpujc posta:
<?php
$sql = "SELECT
FROM
WHERE
AND

*
users
username = '''
password = 'a029d0df84eb5549c641e04a9ef389e5'";

?>

Jeli takie zapytanie zostanie wysane do bazy MySQL, tak jak zademonstrowaem to w poprzednim przykadzie, to uytkownikowi wywietlony zostanie nastpujcy bd:
You have an error in your SQL syntax. Check the manual that corresponds to your
MySQL server version for the right syntax to use near 'WHERE username = ''' AND
password = 'a029d0df84eb55

Jak wida, bez wielkiego wysiku atakujcy pozna nazwy dwch kolumn w naszej bazie danych (username i password) oraz porzdek, w jakim pojawiaj si w zapytaniu. Dodatkowo
haker ju wie, e dane nie s odpowiednio filtrowane (nie zosta wywietlony bd aplikacji
informujcy o nieprawidowej nazwie uytkownika) ani opatrywane znakami ucieczki (pojawi

Wstrzykiwanie kodu SQL

47

si bd bazy danych), a ponadto pozna ca skadni klauzuli WHERE. Znajc format klauzuli
WHERE, atakujcy moe teraz wpywa na to, ktre rekordy bd dopasowywane przez zapytanie.
W tym momencie intruz ma wiele moliwoci. Moe na przykad sprbowa przygotowa
zapytanie, ktre zostanie zakwalifikowane jako prawidowe niezalenie od tego, czy uwierzytelnienia dostpu bd waciwe, podajc nastpujc nazw uytkownika:
myuser' or 'foo' = 'foo' --

Zakadajc, e jako haso poda mypass, wygenerowane zapytanie przyjmie posta:

<?php
$sql = "SELECT
FROM
WHERE
AND

*
users
username = 'myuser' or 'foo' = 'foo' -password = 'a029d0df84eb5549c641e04a9ef389e5'";

?>

Poniewa -- oznaczaj pocztek komentarza SQL, baza danych uzna, e w tym momencie
zapytanie si koczy. Dziki temu uytkownik bdzie si mg zalogowa bez koniecznoci
podawania prawidowej nazwy uytkownika i hasa.
Jeli z kolei atakujcy bdzie zna jedn z prawidowych nazw uytkownika, na przykad
chris, to moe poda nazw uytkownika w sposb nastpujcy:
chris' --

Jeli nazwa uytkownika chris okae si prawidowa, to atakujcy bdzie mg przej kontrol nad kontem tego uytkownika, poniewa zapytanie przyjmie nastpujc posta:
<?php
$sql = "SELECT
FROM
WHERE
AND
?>

*
users
username = 'chris' -password = 'a029d0df84eb5549c641e04a9ef389e5'";

Na szczcie przed atakami opartymi na technice wstrzykiwania kodu SQL mona si do

atwo zabezpieczy. Jak wspomniaem w rozdziale 1., naley zawsze filtrowa dane wejciowe
i opatrywa znakami ucieczki dane wyjciowe.
Mimo i oczywicie adnej z tych operacji nie naley zaniedbywa, to nawet wykonanie tylko
jednej z nich pozwala na wyeliminowanie ryzyka zwizanego z atakami polegajcymi na
wstrzykiwaniu kodu SQL. Jeli na przykad przefiltrujemy dane wejciowe, ale zapomnimy
opatrzy dane wyjciowe znakami ucieczki, to aplikacja nadal moe wywietla bdy bazy
danych (nawet prawidowe dane mog spowodowa wygenerowanie niepoprawnego zapytania SQL), mao jest jednak prawdopodobne, e waciwe dane zmieni zachowanie zapytania w sposb nieprzewidywalny. Z kolei, jeli opatrzymy znakami ucieczki dane wyjciowe,
ale zapomnimy o filtrowaniu danych wejciowych, to dziki opatrzeniu danych wysyanych
do bazy znakami ucieczki bdziemy mieli gwarancj, e dane te nie bd mogy zmieni
formatu zapytania SQL, co ochroni nas przed wielu typowymi atakami opartymi na technice
wstrzykiwania kodu SQL.

48

Rozdzia 3. Bazy danych i SQL

Oczywicie naley zawsze stosowa oba rodki zapobiegawcze. Sposb filtrowania danych
wejciowych zalee bdzie cakowicie od rodzaju filtrowanych danych (par przykadw
mona znale w rozdziale 1.), natomiast opatrywanie znakami ucieczki danych wysyanych
do bazy wymaga zazwyczaj przygotowania tylko jednej funkcji. W przypadku uytkownikw bazy MySQL bdzie to funkcja mysql_real_escape_string():
<?php
$clean = array();
$mysql = array();
$clean['last_name'] = "O'Reilly";
$mysql['last_name'] = mysql_real_escape_string($clean['last_name']);
$sql = "INSERT
INTO
user (last_name)
VALUES ('{$mysql['last_name']}')";
?>

Zawsze naley si stara uywa funkcji waciwej dla naszej bazy danych, jeli tylko jzyk
PHP j oferuje. Jeli nie, ostatni desk ratunku jest zawsze funkcja addslashes().
Jeli wszystkie dane suce do przygotowania zapytania zostan odpowiednio przefiltrowane
i opatrzone znakami ucieczki, to ryzyko atakw typu wstrzykiwania kodu SQL spada do zera.
Jeli korzystamy z bazy danych, ktra pozwala na korzystanie z parametrw wicych lub zmiennych zastpczych (takiej jak PEAR::DB czy PDO), to moemy doda
jeszcze jedn warstw zabezpiecze. Na przykad zamy, e przesyamy do bazy
PEAR::DB nastpujce zapytanie (dodajce do tabeli uytkownikw nazwiska uytkownikw):
<?php
$sql = 'INSERT
INTO
user (last_name)
VALUES (?)';
$dbh->query($sql, array($clean['last_name']));
?>

Poniewa przesyane dane nie mog teraz wpyn na format zapytania, ryzyko
udanego ataku technik wstrzykiwania kodu SQL jeszcze si zmniejsza. System baz
danych PEAR::DB automatycznie bdzie opatrywa dane znakami ucieczki i ujmowa je
w cudzysowy, dziki czemu trafi do bazy danych w bezpiecznej postaci i nasza
odpowiedzialno ograniczona zostanie do koniecznoci odpowiedniego filtrowania
danych wejciowych.
Jeli uyjemy parametrw wicych, to nasze dane nigdy nie znajd si w kontekcie, w ktrym mogyby zosta potraktowane jako cokolwiek innego ni dane przesyane do bazy. Dziki temu nie bdziemy musieli opatrywa danych wysyanych
znakami ucieczki, poniewa zabieg ten nie bdzie teraz niczego zmienia (jeli mimo
wszystko zdecydujemy si na dodanie znakw ucieczki), bowiem nie bdziemy wysya adnych znakw, ktre bd musiay zosta potraktowane w ten sposb. Parametry wice s jednym z najlepszych zabezpiecze przeciw wstrzykiwaniu kodu SQL.

Wstrzykiwanie kodu SQL

49

Ujawnienie danych przechowywanych w bazie

Kolejnym ryzykiem zwizanym z bazami danych, ktre naley uwzgldni, jest niebezpieczestwo ujawnienia osobom postronnym wanych danych przechowywanych w bazie. Jeli
przechowujemy tam informacje takie jak numery kart kredytowych, numery PESEL, numery
ubezpieczenia spoecznego (w USA), lub te inne podobnie wane dane, naley bezwzgldnie si upewni, e informacje przechowywane w bazie danych bd bezpieczne.
Mimo i problemy zwizane z bezpieczestwem bazy danych nie wchodz w zakres tej ksiki
(i przewanie nie nale do zakresu kompetencji programisty tworzcego aplikacj PHP),
warto wiedzie, e aby je dodatkowo zabezpieczy, mona szyfrowa najbardziej istotne dane. Dziki temu nawet zdobycie przez osob postronn zawartoci bazy danych nie bdzie
wielk tragedi, pod warunkiem, e osoba ta nie wejdzie w posiadanie klucza szyfrujcego.
Wicej informacji na temat szyfrowania i kryptografii mona znale w dodatku C.

50

Rozdzia 3. Bazy danych i SQL