tpug Thu Dec 13 11:23:02 2001 EDT
Added files:
/phpdoc/tr/chapters security.xml
Log:
complete translation by Serdar
Index: phpdoc/tr/chapters/security.xml
+++ phpdoc/tr/chapters/security.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision: 1.1 $ -->
<chapter id="security">
<title>G�venlik</title>
<simpara>
PHP, hem
web sunucusu mod�l� hem de <acronym>CGI</acronym> uygulaması
s�r�mleri ile, sistemdeki dosyaları okuyabilen, komutları
�alıştırabilen ve
ağ bağlantıları kurabilen �ok g��l� bir dildir. Bu
�zellikler, g�venlik �nlemi
alınmamış bir web sunucusunda istenilen her şeyin
�alıştırılabilmesini sağlar.
PHP, CGI programlarının yazıldığı Perl ve
C gibi dillerden daha g�venli bir
dil olacak şekilde tasarlanmıştır, derleme
sırasında ve �alışma sırasında ayarlanabilen
konfig�rasyon
se�enekleri, ve doğru kodlama teknikleri ile size istediğiniz �zg�rl�k
ve g�venlik
birleşimini verecektir.
</simpara>
<simpara>
PHP'yi bir�ok farklı alanlarda kullanabildiğiniz gibi,
davranışlarını kontrol ettiğiniz
bir�ok farklı konfig�rasyon se�eneği mevcuttur. Geniş bir
se�enek yelpazesi
PHP'yi �ok �eşitli ama�larla kullanmanıza imkan tanırken,
aynı zamanda
bu ayarların arasından yapılacak birleşimlerin g�vensiz
kurulumlarla sonu�lanmasına
neden olabilir.
</simpara>
<simpara>
PHP'nin esnek konfig�rasyon yapısı, esnek kod yapısı ile
aynı g��tedir.
PHP b�y�k sunucu uygulamaları yazarken shell
kullanıcısının b�t�n g�c�n� kullanma
olanağını sağlarken, ufak sunucu taraflı
eklentilerle kontrolde tutulan ve ufak risk
taşıyan uygulamaların da yazılabilmesini sağlar.
Bu ortamın nasıl inşa edildiği, ve
ne kadar g�venli olduğu, �ok b�y�k miktarda PHP geliştiricisine
bağlıdır.
</simpara>
<simpara>
Bu b�l�m bazı genel g�venlik �nerilerinden başlayarak, birlikte
g�venle kullanılabilecek
farklı konfig�rasyon se�eneklerini ve durumları a�ıklayacak, ve
farklı g�venlik seviyeleri
i�in kodlama sırasında alınabilecek farklı
kararları ele alacaktır.
</simpara>
<sect1 id="security.general">
<title>Genel Bakış</title>
<simpara>
Tamamen g�venli bir sistem sanal bir imkansızlıktır, o nedenle
g�venlik işine
sıklıkla riskin ve kullanılabilirliğin dengelenmesi
olarak bakılır. Kullanıcı tarafından
g�nderilen veri iki farklı biometrik doğrulamadan (retina
taraması ve parmak izi gibi)
ge�iriliyorsa, olduk�a y�ksek bir maliyet �deyeceksiniz demektir. Ayrıca
karışık
sayılabilecek bir formun doldurulması yarım saati bulacak, bu
da kullanıcıların
g�venlik sistemini aşmak i�in cesaret bulmasına neden
olacaktır.
</simpara>
<simpara>
En iyi g�venlik, kullanıcıların işini engellemeden ve
onları gereksiz bir karmaşıklığa
s�r�klemeden sağlanabilir. �te yandan, bazı g�venlik
saldırıları bu tip normal
�st� g�venliğe sahip sistemlerde, zamanla bu sistemlerin zaman
aşımına uğraması
sonucu ger�ekleşmektedir.
</simpara>
<simpara>
Hatırlanmaya değer bir s�z: Bir zincir yalnızca en
zayıf halkası kadar sağlamdır.
B�t�n işlemler zaman, yer, işlem tipi vb. gibi ince detaylara kadar
kaydedilirken,
kullanıcı yalnızca tek bir �erezle
doğrulanıyorsa, kaydı tutulan diğer işlemlerin
doğruluğu da ciddi bi�imde kuşku yaratır.
</simpara>
<simpara>
Sistemi denerken, en basit sayfalar i�in bile b�t�n olası testleri
yapamayacağınızı
aklınızda bulundurun. Sizin aklınıza gelmeyecek bir
şey bilin�siz bir �alışan tarafından,
bol bol vakti olan bir cracker tarafından, ya da klavyenin �st�nde y�r�yen
bir kedi
tarafından yapılabilir. İşte bu nedenle koda
mantık perspektifinden yaklaşmalı,
beklenmeyen verinin nereden geleceğini bulmalı, ve buradaki
a�ığın nasıl giderileceği
�zerinde �alışmalısınız.
</simpara>
<simpara>
Internet sizin kodunuzu bozarak, sitenizi g��erterek, k�f�rl� i�erik g�ndererek, ve
ilgin� bir g�n ge�irmenize neden olarak kendisine isim yapmak isteyen insanlarla
doludur. K���k ya da b�y�k bir siteye sahip olmanız �nemli değildir,
online olarak
zaten bir hedef haline gelirsiniz. Bir�ok saldırı programı
boyutu �nemsemez,
yalnızca geniş IP bloklarını tarayarak
kurbanlarını ararlar. Onlardan biri olmamaya
�alışın.
</simpara>
</sect1>
<sect1 id="security.cgi-bin">
<title>CGI Kurulum</title>
<sect2 id="security.cgi-bin.attacks">
<title>Olası saldırılar</title>
<simpara>
PHP'nin bir nedenden dolayı sunucu yazılımına (Apache
gibi) entegre edilmek
istenmediği, ya da PHP'yi farklı tipte CGI okuyucuları
kullanarak uygulamalar
i�in g�venli chroot ve setuid ortamlarının yaratılmak
istendiği durumlarda
PHP'yi <acronym>CGI</acronym> bir se�enek olabilir. Bu kurulum PHP
�alıştırılabilir dosyasının web
sunucusunun cgi-bin klas�r�ne kurulmasıyla
ger�ekleştirilebilir. CERT danışmanı <ulink
url="&url.cert;">CA-96.11</ulink>
cgi-bin klas�r�ne hi�bir yorumlayıcının
kurulmamasını tavsiye eder. PHP,
tek başına okuyucu olarak kullanıldığı
takdirde, bu tip kurulumdan kaynaklanan
aşağıdaki saldırıları �nleyecek bi�imde
tasarlanmıştır:
</simpara>
<itemizedlist>
<listitem>
<simpara>
Sistem dosyalarına erişim:
<filename
role="url">http://my.host/cgi-bin/php?/etc/passwd</filename>
</simpara>
<simpara>
URL i�indeki soru işaretinden (?) sonra gelen sorgu bilgisi, CGI aray�z�
tarafından okuyucuya komut satırı parametresi olarak
aktarılır. Sıklıkla
okuyucular komut satırının ilk arg�manı olarak
belirtilmiş dosyayı a�ar ve
�alıştırırlar.
</simpara>
<simpara>
CGI olarak �alıştırıldığında,
PHP komut satırı parametrelerini işlemeyi reddeder.
</simpara>
</listitem>
<listitem>
<simpara>
Sunucudaki herhangi bir web dok�manına erişim:
<filename
role="url">http://my.host/cgi-bin/php/secret/doc.html</filename>
</simpara>
<simpara>
URL i�indeki PHP �alıştırılabilirinden sonraki yol
bilgisi,
<filename role="uri">/secret/doc.html</filename>,
<acronym>CGI</acronym> aray�z� tarafından programa iletilecek ve
program tarafından a�ılıp yorumlanacak dosyanın
ismini belirtir.
Bazı web sunucu konfig�rasyon direktifleri (Apache: Action) bu tip
istekleri
<filename
role="url">http://my.host/secret/script.php</filename> gibi adreslere
y�nlendirmek i�in kullanılır. Bu tip kurulumla, web sunucusu �nce
<filename
role="uri">/secret</filename> klas�r�ne erişim hakkını
g�zden ge�irir, ve
sonra y�nlendirilmiş isteği yaratır <filename
role="url">http://my.host/cgi-bin/php/secret/script.php</filename>.
Ne yazık ki, istek orjinal olarak bu şekilde verildiyse, web
sunucusu
<filename
role="uri">/secret/script.php</filename> dosyasına erişimi kontrol
etmeyecek, yalnızca <filename role="uri">/cgi-bin/php</filename>
i�in kontrol yapacaktır. Bu şekilde <filename
role="uri">/cgi-bin/php</filename> a erişimi olan herhangi bir
kullanıcı,
web sunucusu �zerindeki korunan herhangi bir dok�mana erişebilir
olacaktır.
</simpara>
<simpara>
PHP, bu saldırıları derleme sırasındaki
konfig�rasyon se�eneği <link
linkend="install.configure.enable-force-cgi-redirect">--enable-force-cgi-redirect</link>
ve �alışma sırasındaki konfig�rasyon direktifi <link
linkend="ini.doc-root">doc_root</link> ve <link
linkend="ini.user-dir">user_dir</link> ile sunucu dok�man
ağacı erişim kısıtlaması
yapılmış bir klas�re sahipse �nleyebilir.
Aşağıdaki
�rneği inceleyerek farklı birleşimler i�in
a�ıklamalar bulabilirsiniz.
</simpara>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="security.cgi-bin.default">
<title>Durum 1: yalnızca public dosyaların sunulması</title>
<simpara>
Sunucunuz parola ile kısıtlanmış bir b�l�me sahip
değilse ya da IP bazında
erişim kontrol� yapılmıyorsa, bu konfig�rasyon
ayarlarına ihtiyacınız yoktur.
Web sunucunuz y�nlendirme işlemine izin vermiyorsa, ya da sunucunuzun
PHP ile iletişim kurup isteğin g�venli bir y�nlendirme isteği
olduğunu iletme
imkanı yoksa, <link
linkend="install.configure.enable-force-cgi-redirect">--enable-force-cgi-redirect</link>
se�eneğini kullanarak konfig�rasyon yapabilirsiniz. PHP
uygulamalarınızın bu
uygulamayı başka bir yoldan ya da direk olarak
�alıştırabilir olmadığından emin
olmalısınız.
Bu ne <filename
role="php">http://my.host/cgi-bin/php/dir/script.php</filename>
olmalıdır, ne de
<filename
role="php">http://my.host/dir/script.php</filename> olmalıdır.
</simpara>
<simpara>
Y�nlendirme Apache i�ersinden AddHandler ve Action direktifleri kullanılarak
yapılabilir (aşağıya bakın).
</simpara>
</sect2>
<sect2 id="security.cgi-bin.force-redirect">
<title>Durum 2: --enable-force-cgi-redirect kullanımı</title>
<simpara>
Bu derleme sırasında kullanılan komut, PHP'nin <filename
role="php">http://my.host/cgi-bin/php/secretdir/script.php</filename>
gibi bir url kullanılarak direk olarak
�ağrılmasını �nler. PHP bu modda
yalnızca web sunucusu bir y�nlendirme kuralı
oluşturmuşsa �alışacaktır.
</simpara>
<simpara>
Apache konfig�rasyonu i�inde y�nlendirme aşağıdaki
direktifler izlenerek
yapılabilir:
</simpara>
<programlisting role="apache-conf">
<![CDATA[
Action php-script /cgi-bin/php
AddHandler php-script .php
]]>
</programlisting>
<simpara>
Bu se�enek yalnızca Apache web sunucusu i�in test edilmiştir, ve
Apache'ın
y�nlendirmede kullandığı CGI ortam değişkeni
<envar>REDIRECT_STATUS</envar>
değişkenine bağımlıdır. Web sunucunuz
isteğin direk mi yoksa y�nlendirme mi olduğunu
iletme �zelliğine sahip değilse, bu se�eneği
kullanamazsınız. Bu durumda
burada anlatan diğer CGI kurulumlarından birini denemeniz gereklidir.
</simpara>
</sect2>
<sect2 id="security.cgi-bin.doc-root">
<title>Durum 3: setting doc_root ya da user_dir</title>
<simpara>
Uygulamalar ve �alıştırılabilirler gibi, web sunucu
dok�man klas�rlerine
canlı i�erik eklemek i�in, bazı durumlarda g�vensiz işlemler
yapmanız gerekir.
Bazı konfig�rasyon hataları y�z�nden, uygulamalar d�zg�n
�alıştırılmaz ve
normal HTML dok�manları gibi g�r�nt�lenirse, bu durum parolaların
ele verilmesi
gibi istenmeyen g�venlik a�ıklarına neden olacaktır. Bir�ok
sistem y�neticisi,
yalnızca yorumlayan ve �ıktı �retmeyen uygulama
dosyaları i�in yalnızca PHP CGI tarafından erişilebilen
farklı bir klas�r yapısı yaratmayı
tercih etmektedir.
</simpara>
<simpara>
Bir �nceki b�l�mde anlatıldığı gibi, isteklerin
y�nlendirilmediğini kontrol eden
sistem kullanılamaz olduğunda, web sunucusunun k�k dok�man klas�r�
haricinde
bir doc_root ayarlanması mutlaka gereklidir.
</simpara>
<simpara>
PHP uygulama k�k dok�man klas�r�n� isterseniz
<link linkend="configuration.file">konfig�rasyon dosyası</link>
i�indeki <link linkend="ini.doc-root">doc_root</link> direktifinden,
isterseniz ortam değişkeni olan <envar>PHP_DOCUMENT_ROOT</envar>
değerinden değiştirebilirsiniz. Bu değer
kullanıldığında, PHP'nin CGI s�r�m�
a�ılacak dosya ismini <parameter>doc_root</parameter> değeriyle
belirtilene
g�re yaratacak, b�ylece bu klas�r�n dışındaki hi�bir uygulama
�alıştırılmayacaktır
(<parameter>user_dir</parameter> dışındakiler).
</simpara>
<simpara>
Bir diğer kullanışlı se�enek <link
linkend="ini.user-dir">user_dir</link> se�eneğidir. user_dir boş
olduğunda,
a�ılan dosya yalnızca <parameter>doc_root</parameter> ile kontrol
edilir.
<filename
role="url">http://my.host/~user/doc.php</filename> gibi bir url a�ılmak
istendiğinde, PHP users klas�r�ndeki dosyayı a�mak yerine, doc_root
altındaki
<filename role="uri">~user/doc.php</filename> isimli bir dosyayı a�maya
</simpara>
<simpara>
�rneğin user_dir <filename
role="dir">public_php</filename> olarak ayarlanmışsa, <filename
role="url">http://my.host/~user/doc.php</filename> gibi bir istek,
<filename role="dir">public_php</filename> altındaki aynı isimli
dosyaya
y�nlendirilecektir. Eğer kullanıcının ana klas�r�
<filename
role="dir">/home/user</filename> ise, dosya
<filename>/home/user/public_php/doc.php</filename> olarak
�alıştırılır.
</simpara>
<simpara>
<parameter>user_dir</parameter> genişlemesi
<parameter>doc_root</parameter> ayarından bağımsız
olarak ger�ekleşir,
bu şekilde k�k klas�r erişimi ile kullanıcı
klas�rlerine erişim birbirinden ayrı kontrol edilebilir.
</simpara>
</sect2>
<sect2 id="security.cgi-bin.shell">
<title>Durum 4: PHP okuyucusu web ağacının
dışında</title>
<para>
PHP okuyucu dosyasının web ağacı
dışında bir yere yerleştirilmesi �ok g�venli
bir kurulumdur. Dosya �rneğin <filename
role="dir">/usr/local/bin</filename> klas�r�ne konulabilir. Bu se�enek tek
olumsuz tarafı uygulama dosyalarınızın
başına aşağıdakine benzer bir satır
koymanızı gerektirmesidir:
<informalexample>
<programlisting>
<![CDATA[
#!/usr/local/bin/php
]]>
</programlisting>
</informalexample>
Bu satır b�t�n dosyaların ilk satırına
yazılmalıdır. Ayrıca bu dosyayı
�alıştırılabilir hale getirmeniz gerekir. Bu
şekilde, PHP aynı Perl ya da sh ya da
diğer bilinen dillerin kullandığı
<literal>#!</literal> shell-ka�ış mekanizması
ile �alıştırılabilir hale gelir.
</para>
<para>
Bu kurulumda PHP'nin <envar>PATH_INFO</envar> ve
<envar>PATH_TRANSLATED</envar> değerlerini d�zg�n bi�imde alabilmesi i�in,
php okuyucusu <link
linkend="install.configure.enable-discard-path">--enable-discard-path</link>
konfig�rasyon se�eneği ile derlenmelidir.
</para>
</sect2>
</sect1>
<sect1 id="security.apache">
<title>Apache Mod�l� olarak Kurulum</title>
<simpara>
PHP Apache mod�l� olarak kullanıldığında, Apache'in
kullanıcı izinlerini alır
(genel olarak "nobody" kullanıcısının"). Bunun g�venlik
ve doğrulama işlemlerine
birka� etkisi vardır. �rneğin, PHP ile veritabanına
erişiyorsanız, veritabanı
�ny�kl� bir erişim kontrol�ne sahip olmadığı s�rece,
veritabanını "nobody" kullanıcısı
tarafından erişilebilir halde tutmanız gerekir. Bunun
anlamı k�t� niyetli bir
uygulama kullanıcı ve parola dahi kullanmadan veritabanına
erişip �zerinde değişiklik yapabilir
demektir. Bir web �r�mceğinin veritabanındaki b�t�n y�netici web
sayfalarını alması
ve veritabanınızı komple yok etmesi m�mk�nd�r. Bundan Apache
doğrulama sistemini
kullanarak korunabilirsiniz, ya da �rneğin LDAP kullanarak kendi
erişim modelinizi
oluşturabilir, .htaccess kullanabilir vb. ve bu kodu kendi PHP
uygulamalarınıza
ekleyebilirsiniz.
</simpara>
<simpara>
Sıklıkla, bir defa PHP kullanıcısı (bu durumda,
apache kullanıcısı) �ok az riskle
�alışır hale getirildiğinde, PHP
kullanıcı klas�rlerine yazamaz hale gelir. Ya da belki
veritabanlarına erişim ya da işlem yapma hakkını
kaybetmiştir. PHP iyi ve k�t�
dosyalara, iyi ve k�t� veritabanı işlemlerine eşit derecede
g�venlik uygular.
</simpara>
<simpara>
Bu noktada sıklıkla yapılan bir g�venlik hatası,
apache'a root kullanıcı izni vermek,
ya da Apache'in sınırlarını farklı bir yolla
genişletmektir.
</simpara>
<simpara>
Apache kullanıcısının izinlerini root seviyesine
�ıkartmak olduk�a tehlikelidir
ve b�t�n sistemi etkileyebilir. Bu nedenle sudo, chroot, ve diğer root olarak
�alıştırma işlemleri, g�venlik uzmanları
tarafından tercih edilmemesi gereken
y�ntemlerdir.
</simpara>
<simpara>
Daha basit bazı ��z�mler mevcuttur. <link
linkend="ini.open-basedir">open_basedir</link>
kullanarak PHP tarafından kullanılabilecek klas�rleri kontrol
edebilir ve kısıtlayabilirsiniz.
Aynı şekilde yalnızca Apache tarafından
erişilebilecek alanları ayarlayabilir, b�ylece
b�t�n web tabanlı aktiviteyi kontrol altına alabilirsiniz.
</simpara>
</sect1>
<sect1 id="security.filesystem">
<title>Dosya Sistemi G�venliği</title>
<simpara>
PHP bir�ok sunucu sisteme kurulu g�venlik sisteminin dosya ve klas�r izinlerine
uyum g�sterir. Bu, size dosya sistemindeki hangi dosyaların
okunabileceğini kontrol
etme imkanını verir. Herkes tarafından okunabilir
dosyaların, dosya sistemine
erişimi olan kullanıcılar tarafından g�venle okunabilir
olması mutlaka dikkate
alınmalıdır.
</simpara>
<simpara>
PHP dosya sistemine kullanıcı seviyesi tabanlı erişim
sağlamak �zere tasarlandığından,
PHP uygulamalarının /etc/password gibi sistem
dosyalarını okumaları, ethernet
bağlantıları �zerinde değişiklik
yapmaları, yazıcıya ardı ardına g�revler y�klemeleri
ve benzeri bir�ok eylemi kolayca yapmaları m�mk�nd�r. Bu durum, sizi
kullanıcıların hangi
dosyalara okuma ve yazma hakları olduğunu denetlemeye zorunlu
kılar.
</simpara>
<simpara>
Kullanıcının kendi ana klas�r�ndeki bir dosyayı silmek
istediği aşağıdaki uygulamayı
ele alalım. PHP web aray�z�n�n dosya y�netimini sağlamak i�in
kullanıldığını,
ve Apache kullanıcısının
kullanıcının ana klas�r�ndeki dosyaları silme iznine sahip
olduğunu kabul edelim.
</simpara>
<para>
<example>
<title>Yetersiz değişken kontrol�n�n yol
a�tığı....</title>
<programlisting role="php">
<![CDATA[
<?php
// kullanıcının ana klas�r�nden dosya silme
$username = $HTTP_POST_VARS['user_submitted_name'];
$homedir = "/home/$username";
$file_to_delete = "$userfile";
unlink ($homedir/$userfile);
echo "$file_to_delete silindi!";
?>
]]>
</programlisting>
</example>
username bir kullanıcı formundan g�nderilebilir olduğu i�in,
başkasına ait bir
kullanıcı adı ve dosya ismi ile, istediği
dosyayı silebilir. Bu durumda, bir �eşit
kullanıcı doğrulama sistemi kullanmanız gereklidir.
Burada g�nderilen değerlerin
"../etc/" ve "passwd" olduğunda neler olabileceğini d�ş�n�n.
Kodu bu şekilde okursak:
<example>
<title>... Bir dosya sistemi saldırısı</title>
<programlisting role="php">
<![CDATA[
<?php
// PHP kullanıcısının izniyle silinebilecek diskteki b�t�n
dosyalari
// siler. PHP kullanıcısı root erişimine sahipse:
$username = "../etc/";
$homedir = "/home/../etc/";
$file_to_delete = "passwd";
unlink ("/home/../etc/passwd");
echo "/home/../etc/passwd silindi!";
?>
]]>
</programlisting>
</example>
Bu durumu �nlemenizi gerektiren iki �nemli �l�� vardır.
<itemizedlist>
<listitem>
<simpara>
PHP web kullanıcısına ait binary dosyasına
yalnızca kısıtlı erişim izni ver.
</simpara>
</listitem>
<listitem>
<simpara>
G�nderilen b�t�n değerleri kontrol et.
</simpara>
</listitem>
</itemizedlist>
İşte geliştirilmiş bir uygulama:
<example>
<title>Daha g�venli dosya ismi kontrol�</title>
<programlisting role="php">
<![CDATA[
<?php
// Diskten PHP kullanicisinin silme izni varsa
// dosyayı siler.
$username = $HTTP_SERVER_VARS['REMOTE_USER']; // dogrulama mekanizmasi
$homedir = "/home/$username";
$file_to_delete = basename("$userfile"); // yol ayristiriliyor
unlink ($homedir/$file_to_delete);
$fp = fopen("/home/logging/filedelete.log","+a"); // silme islemi kaydediliyor
$logstring = "$username $homedir $file_to_delete";
fputs ($fp, $logstring);
fclose($fp);
echo "$file_to_delete silindi!";
?>
]]>
</programlisting>
</example>
Ancak bu bile istediğimizi tam olarak yapmaz. Doğrulama sisteminiz
kullanıcıların
kendilerine �zel oturum a�ma hakkını tanıyorsa, ve bir
bullanıcı "../etc" olarak
login olmayı se�erse, sistem tekrar kırılabilir. Bu nedenle,
daha �zelleştirilmiş
bir kontrol yazmayı tercih etmelisiniz:
<example>
<title>Daha g�venli dosya ismi kontrol�</title>
<programlisting role="php">
<![CDATA[
<?php
$username = $HTTP_SERVER_VARS['REMOTE_USER']; // dogrulama mekanizmasi
$homedir = "/home/$username";
if (!ereg('^[^./][^/]*$', $userfile))
die('bad filename'); //�l, islem yok
if (!ereg('^[^./][^/]*$', $username))
die('bad username'); //�l, islem yok
//vb...
?>
]]>
</programlisting>
</example>
</para>
<para>
İşletim sisteminize bağlı olarak, endişelenmenizi
gerektirecek farklı dosyalar bulunur.
Bunların arasında aygıt girişleri (/dev/ ya da COM1),
konfig�rasyon dosyaları (/etc/
dosyaları ve .ini dosyaları), herkes�e bilinen dosya saklama
alanları (/home/,
Belgelerim), vb. Bu nedenle, �ncelikle her şeyi yasaklayıp daha sonra
izin verilecek
alanları belirlemek, kullanım a�ısından daha
kolaydır.
</para>
</sect1>
<sect1 id="security.errors">
<title>Hata Raporlama</title>
<para>
PHP g�venliğinde, hataların raporlandığı iki
taraf vardır. Birincisi g�venliği
arttırmaya y�neliktir, ikincisi ise azaltmaya y�nelik.
</para>
<para>
Standart bir saldırı taktiği, sisteme uygunsuz veri
girişi yaparak, geri d�nen
hata mesajlarını incelemektir. Bu, sistemi kırmak isteyen
kişiye sunucu hakkında
bilgi toplama ve olası zayıflıklar hakkında fikir
sahibi olma şansı verir. �rneğin,
bir saldırgan form verilerinin işlendiği dosya hakkında
yeterli bilgiye sahip olursa,
değişkenleri ezmeye ya da onları değiştirmeye
�alışabilir:
<example>
<title>Değişkenlere �zelleştirilmiş bir HTML
sayfası ile saldırmak</title>
<programlisting role="php">
<![CDATA[
<form method="post" action="attacktarget?username=badfoo&password=badfoo">
<input type="hidden" name="username" value="badfoo">
<input type="hidden" name="password" value="badfoo">
</form>
]]>
</programlisting>
</example>
</para>
<para>
Normal olarak d�nd�r�len PHP hataları, uygulamasındaki
hataları ayıklayan bir
geliştirici i�in yardımcıdır. Bu şekilde
hatanın yer aldığı dosyayı, sorun yaratan
fonksiyonu, hangi satırın problem
�ıkarttığını tespit edebilir. İşte
b�t�n bu bilgiler
aynı zamanda k�t� ama�lara alet edilebilir. Bir php geliştiricisinin
hata ayıklama
s�recinde <function>show_source</function>, <function>highlight_string</function>
ya da <function>highlight_file</function> fonksiyonlarını
kullanmaları az
raslanan bir durum değildir. Ama yayındaki bir sitede, bu durum gizli
değişkenleri
a�ığa �ıkarabilir, kontrol edilmemiş s�z dizimini ele
verebilir ve bu listeye daha bir�ok
tehlikeli bilgi dahil edilebilir. �zellikle �ny�kl� hata ayıklama
y�ntemlerini ya da
bilinen hata ayıklama tekniklerini kullanıyorsanız tehlike
altındasınız demektir.
Saldırgan hangi genel tekniği
kullandığınızı belirlerse, sayfaya �eşitli
ayıklama
değerleri g�nderebilir:
<example>
<title>Ortak hata ayıklama değişkenleri �zerinden
saldırmak</title>
<programlisting role="php">
<![CDATA[
<form method="post" action="attacktarget?errors=Y&showerrors=1"&debug=1">
<input type="hidden" name="errors" value="Y">
<input type="hidden" name="showerrors" value="1">
<input type="hidden" name="debug" value="1">
</form>
]]>
</programlisting>
</example>
</para>
<para>
Hata takibi i�in kullanılan y�ntemden bağımsız olarak,
sistem hatalarına sızabilmek,
saldırgan i�in sistem hakkında daha fazla bilgi toplamak
anlamına gelir.
</para>
<para>
�rneğin, en �ok bilinen PHP hatası, sistemde PHP'nin
kullanıldığını ortaya �ıkartır.
Saldırgan bir .html sayfası arıyorsa, ve geri planda
�alışan sistemi analiz etmek
istiyorsa (sistemin bilinen zayıflıklarına saldırmak
i�in), hatalı veri g�ndererek
sistemin PHP ile yapıldığını ortaya
�ıkartabilir.
</para>
<para>
Bir fonksiyon hatası, sistemde hangi veritabanının
�alıştığını ortaya �ıkartabilir,
ya da web sayfasının nasıl programlandığı
ya da tasarlandığı hakkında ipucu verebilir.
Bu, a�ık veritabanı portlarına y�nelik daha derin
araştırmaya y�neltebilir, ya da
web sayfasında olabilecek hata veya zayıflıkları
incelettirebilir. Farklı hatalı veri
par�aları g�ndererek, bir saldırgan �rneğin uygulama i�indeki
doğrulama sıralamasını
bulabilir (hata satırlarından), ya da uygulamanın
farklı b�l�mleri i�in ge�erli olabilecek
a�ıkları tespit edebilir.
</para>
<para>
Bir dosya sistemi ya da genel PHP hatası, web sunucusunun hangi izinlere
sahip
olduğunu g�sterebilir, aynı zamanda web sunucusunun
yapısı ve organizasyonu
hakkında bilgi verir. Geliştirici tarafından
belirlenmiş hata kodu bu sorunu derinleştirebilir,
bu şekilde "gizli" bilgiler kolayca a�ığa
�ıkartılabilir.
</para>
<para>
Bu duruma ait �� �nemli ��z�m bulunmaktadır. Birincisi b�t�n kodun
fonksiyonların
i�ine g�m�lerek, hata mesajlarının
yansıtılmamasına �alışmaktır. İkincisi,
�alışmakta olan kod i�ersinden b�t�n hata raporlama işlemini
kapatmaktır. ���nc�s�,
PHP'nin �zelleştirilmiş hata kontrol fonksiyonlarını
kullanarak kendi hata takip sisteminizi
kurmaktır. G�venlik politikanıza uygun olarak, her �� durumu da kendi
sisteminize
uygulayabilirsiniz.
</para>
<para>
Bu durumdan korunmanın yollarından birisi, PHP'nin kendi
<function>error_reporting</function>
fonksiyonunu size kodunuzdaki g�venliği arttırmak ve
kullanımı tehlikeli olabilecek
değişkenleri bulmakta yardımcı olması
amacıyla kullanmaktır. Kodunuzu �retim aşamasına
ge�meden �nce E_ALL ile test ederek, neredeki değişkenlerin
farklı yollarla saldırıya
uğrayabileceğini kestirebilirsiniz. Bir defa �retim
aşamasına ge�meye hazır olduğunuzda,
E_NONE kullanarak, kodunuzu incelemelere kapatmış olursunuz.
<example>
<title>E_ALL ile tehlikeli değişkenlerin bulunması</title>
<programlisting role="php">
<![CDATA[
<?php
if ($username) { // Kullanimdan �nce kontrol edilmiyor
$good_login = 1;
}
if ($good_login == 1) { // Yukardaki test basarisiz olursa, yaratilmayacak ve
denetlenmeyecektir
fpassthru ("/highly/sensitive/data/index.html");
}
?>
]]>
</programlisting>
</example>
</para>
</sect1>
<sect1 id="security.registerglobals">
<title>Register Globals Kullanımı</title>
<para>
PHP'nin bir �zelliği, <link
linkend="ini.register-globals">register_globals</link> = off
ile konfig�re edilerek g�venliğin arttırılabilmesidir. Bu
�zelliğin kapatılması, PHP
i�ine direk olarak hi�bir değerin girmemesini sağlamak
anlamına gelir. Bu şekilde,
potansiyel bir saldırgan tarafından yapılabilecek
değişken saldırılarını
azaltmış olursunuz.
Değişkenlere saldırmaya �alışmak onlara fazladan
zamana mal olacak, ve i� değişkenler
kullanıcı tarafından g�nderilen verilerden verimli bir
şekilde izole edilmiş olacaktır.
</para>
<para>
Bu durum PHP ile �alışırken harcanması gereken
zamanı arttırsa da, faydaları
kaybettiğiniz zamana kıyasla �ok daha fazladır.
<example>
<title>register_globals=off olmadan �alışmak</title>
<programlisting role="php">
<![CDATA[
<?php
if ($username) { // get/post/cookies ile kullanıcı tarafından
değiştirilebilir
$good_login = 1;
}
if ($good_login == 1) { // get/post/cookies ile kullanıcı
tarafından değiştirilebilir
fpassthru ("/highly/sensitive/data/index.html");
}
?>
]]>
</programlisting>
</example>
<example>
<title>register_globals = off olarak �alışmak</title>
<programlisting role="php">
<![CDATA[
<?php
if($HTTP_COOKIE_VARS['username']){
// yalnızca �erezden gelebilir
$good_login = 1;
fpassthru ("/highly/sensitive/data/index.html");
}
?>
]]>
</programlisting>
</example>
Bunu akıllıca kullanarak, saldırı işlemi
ger�ekleştiğinde �alışacak bir uyarı
mekanizması
kurabilirsiniz. Değişkenin gelmesi gerektiği yeri tam olarak
biliyorsanız, g�nderilen
verinin uygunsuz olup olmadığını denetleyebilirsiniz.
Bu saldırma ama�lı kullanılan
verinin tamamen durdurulabileceğini garanti etmese de,
saldırganı doğru saldırı
şeklini tahmin etmeye zorlar.
<example>
<title>Basit değişken saldırısını
tespit etmek</title>
<programlisting role="php">
<![CDATA[
<?php
if ($HTTP_COOKIE_VARS['username'] &&
!$HTTP_POST_VARS['username'] &&
!$HTTP_GET_VARS['username'] ) {
// Kullaniciyi dogrulamak icin diger y�ntemleri uygular...
$good_login = 1;
fpassthru ("/highly/sensitive/data/index.html");
} else {
mail("[EMAIL PROTECTED]", "Olası saldırı denemesi",
$HTTP_SERVER_VARS['REMOTE_ADDR']);
echo "G�venlik ihlali, y�netici uyarildi.";
exit;
}
?>
]]>
</programlisting>
</example>
Elbette, register_globals değerinin basit bir şekilde
kapatılması, kodun g�venliğinin
sağlandığı anlamına gelmez. G�nderilen her veri
par�ası i�in, farklı denetleme işlemlerinin
de yapılması gereklidir.
</para>
</sect1>
<sect1 id="security.variables">
<title>Kullanıcı tarafından G�nderilen Veri</title>
<para>
Bir�ok PHP programındaki en b�y�k zayıflık, dilin kendi i�
dinamiklerinden değil de,
geliştiricinin kodlama s�recinde g�venliği kafasında
bulundurmamasından kaynaklanır.
Bu nedenle, verilen kod �zerindeki olası durumlar incelenmeli, beklenmedik
bir
değişken g�nderildiğinde oluşabilecek olası
hasar tespit edilmeli ve �nlenmelidir.
<example>
<title>Tehlikeli Değişken Kullanımı</title>
<programlisting role="php">
<![CDATA[
<?php
// kullanıcının... ya da bir başkasının? ana
klas�r�nden dosya
// siler
unlink ($evil_var);
// Erişimi kaydeder... ya da belki bir /etc/password girişi yapar?
fputs ($fp, $evil_var);
// Bir uygulamayı �alıştırır.. ya da rm -rf *
komutunu?
system ($evil_var);
exec ($evil_var);
?>
]]>
</programlisting>
</example>
Kodunuzu her zaman i�in web tarayıcısı tarafından
g�nderilen verilerin yeterli
şekilde denetleyecek halde tutmalı, ve kendinize
aşağıdaki soruları sormalısınız:
<itemizedlist>
<listitem>
<simpara>
Bu uygulama yalnızca istenen dosyaları mı etkiliyor?
</simpara>
</listitem>
<listitem>
<simpara>
İstenmeyen verilerin kullanımı s�z konusu olabilir mi?
</simpara>
</listitem>
<listitem>
<simpara>
Bu uygulama hesaplanmayan bi�imlerde �alıştırılabilir
mi?
</simpara>
</listitem>
<listitem>
<simpara>
Bu uygulama başka uygulamalarla olumsuz anlamda birlik yaratabilir mi?
</simpara>
</listitem>
<listitem>
<simpara>
B�t�n işlemler gerektiği bi�imde arşivleniyor mu?
</simpara>
</listitem>
</itemizedlist>
Uygulamanızı yazarken bu soruları daha sonra sormak yerine
şimdi sorarak,
g�venliğinizi arttırmak i�in kodu yeni baştan yazmak
durumunda kalmazsınız.
Bu mantıkla yola �ıkarak, belki sisteminizdeki g�venliği
garantileyemezsiniz, ama
geliştirilmesine ciddi olarak katkıda bulunmuş olursunuz.
</para>
<para>
Bunların haricinde register_globals, magic_quotes ve benzeri
değerleri kapatarak,
değişken doğrulamasında karmaşa yaratabilecek
etkilerden korunabilirsiniz.
PHP'nin hata raporlaması (E_ALL) modu ile �alışmak, sorun
yaratabilecek değişkenleri
yaratılmadan ve denetlenmeden �nce tespit etmeniz a�ısından
size yardımcı olabilir
(b�ylece uygunsuz verinin işlenmesini �nlemiş olursunuz).
</para>
</sect1>
<sect1 id="security.hiding">
<title>PHP'nin Gizlenmesi</title>
<para>
Bazı basit teknikler PHP'nin gizlenmesine yardımcı olabilir.
Bu şekilde sisteminizdeki
zayıflıkları bulmak isteyen saldırganları
yavaşlatabilirsiniz. php.ini dosyasındaki
expose_php = off değerini ayarlayarak, saldırganlara verilecek bilgi
miktarını azaltabilirsiniz.
</para>
<para>
Bir diğer taktik, apache gibi web sunucularına farklı tipteki
dosyaları PHP'den
ge�irmesini s�ylemektir. Bu .htaccess dosyası ile ya da bizzat apache
konfig�rasyon
dosyası ile yapılabilir. Aşağıdaki
uzantıları kullanarak yanlış y�nlendirmede
bulunabilirsiniz:
<example>
<title>PHP'nin farklı bir dil olarak saklanması</title>
<programlisting role="apache-conf">
<![CDATA[
# Make PHP code look like other code types
AddType application/x-httpd-php .asp .py .pl
]]>
</programlisting>
</example>
Ya da tamamen saklanması:
<example>
<title>PHP i�in bilinmeyen uzantı isimlerinin
kullanılması</title>
<programlisting role="apache-conf">
<![CDATA[
# Make PHP code look like unknown types
AddType application/x-httpd-php .bop .foo .133t
]]>
</programlisting>
</example>
Ya da html kodu gibi saklayın, yalnız bu durum performans
d�ş�ş�ne neden olabilir
��nk� b�t�n HTML dosyaları PHP motorundan ge�irilecektir:
<example>
<title>PHP uzantıları i�in html tipinin
kullanımı</title>
<programlisting role="apache-conf">
<![CDATA[
# Make all PHP code look like html
AddType application/x-httpd-php .htm .html
]]>
</programlisting>
</example>
Bunun verimli bir bişimde �alışabilmesi i�in, PHP
dosyalarınızın uzantısını yukardaki
uzantılarla değiştirmelisiniz. Bulanıklıkla
g�venliğin sağlanması bir y�ntemse de,
yan etkisi de kendi etkisi de az olan bir uygulamadır.
</para>
</sect1>
<sect1 id="security.current">
<title>G�ncel Tutmak</title>
<simpara>
PHP, diğer b�t�n b�y�k sistemler gibi, tutarlı bir gelişim
s�recindedir.
Her yeni s�r�m sıklıkla g�venliği arttırmak ve onarmak,
konfig�rasyon hatalarını d�zeltmek,
ve sistem g�venliğinin b�t�nl�ğ�n� ve
kararlılığını bozabilecek hataları d�zeltmek
i�in
b�y�k ve k���k değişiklikler i�erir.
</simpara>
<simpara>
Diğer b�t�n sistem seviyesindeki uygulama dilleri ve programlar gibi, en iyi
yaklaşım
sıklıkla g�ncellemek, ve son s�r�m ve �zerindeki
değişikliklerden haberdar olmaktır.
</simpara>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"../../manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->
