Vebmasterlər üçün Veb-sayt Təhlükəsizliyi

12 may 2011, Cümə axşamı

İstifadəçilərə mürəkkəb antivirus proqramları quraşdırmaqla zərərli proqramlardan qorunmaq öyrədilir, lakin onlar tez-tez şəxsi məlumatlarını sizin kimi veb-saytlara etibar edirlər; bu halda onların məlumatlarını qorumaq çox vacibdir. Öz məlumatlarınızı qorumaq da çox vacibdir; əgər onlayn mağazanız varsa, soyulmaq istəməzsiniz.

İllər ərzində şirkətlər və vebmasterlər öyrəndilər — əksər hallarda çətin yolla — ki, veb-tətbiq təhlükəsizliyi zarafat deyil; biz istifadəçi parollarının sızdırıldığını görmüşük:
SQL injection
hücumları, oğurlanmış kukilər (cookies) və
XSS, və səhlənkar daxiletmə yoxlanışı səbəbindən hakerlərin əlinə keçmiş veb-saytlar.

Bu gün biz sizə veb-tətbiqin necə istismar oluna biləcəyinə dair bəzi nümunələr göstərəcəyik ki, onlardan dərs çıxarasınız; bunun üçün biz
Gruyere, daxildə təhlükəsizlik təlimləri üçün də istifadə etdiyimiz qəsdən zəif tətbiqdən istifadə edəcəyik. İcazəsiz olaraq başqalarının veb-saytlarında zəiflikləri yoxlamayın çünki bu, hakerlik kimi qəbul edilə bilər; lakin siz Gruyere üzərində testlər keçirməkdə sərbəstsiniz — hətta buna təşviq edilirsiniz.

Müştəri vəziyyətinin manipulyasiyası – URL-i dəyişsəm nə baş verəcək?

Tutaq ki, şəkil hostinqi saytınız var və istifadəçilərin yüklədiyi şəkilləri göstərmək üçün PHP skriptindən istifadə edirsiniz:

Bəs URL-i buna bənzər bir şeyə dəyişsəm və userpasswords.txt real fayldırsa, tətbiq nə edəcək?

userpasswords.txt faylının məzmununu əldə edəcəyəmmi?

Müştəri vəziyyətinin manipulyasiyasının digər nümunəsi forma sahələri yoxlanılmadıqda baş verir. Məsələn, tutaq ki, bu forma var:

Görünür, təqdim edən şəxsin istifadəçi adı gizli daxiletmə sahəsində saxlanılır. Çox gözəl! Bu o deməkdirmi ki, həmin sahənin dəyərini başqa istifadəçi adı ilə əvəz etsəm, formanı həmin istifadəçi kimi təqdim edə bilərəm? Çox güman ki, belə olacaq; istifadəçi girişi aşkar şəkildə, məsələn, serverdə yoxlanıla bilən token ilə təsdiqlənmir.

Təsəvvür edin ki, həmin forma alış-veriş səbətinizin bir hissəsidir və mən 1000 dollarlıq məhsulun qiymətini 1 dollara dəyişib sifarişi yerləşdirdim.

Tətbiqinizi bu cür hücumlardan qorumaq asan deyil; tətbiqinizi necə qorumaq barədə bəzi ipuçları əldə etmək üçün Gruyere -nin üçüncü hissəsinə nəzər salın.

Saytlararası skriptinq (XSS) – İstifadəçi girişinə etibar etmək olmaz

Sadə, zərərsiz URL:

Lakin o, həqiqətənmi zərərsizdir? Əgər
faiz kodlaşdırılmış
simvolları dekod etsəm, alıram:

Gruyere, xüsusi xəta səhifələri olan
çox saylı saytlar kimi, HTML səhifəsinə yol komponentini daxil etmək üçün nəzərdə tutulub. Bu, XSS kimi təhlükəsizlik xətalarına səbəb ola bilər, çünki o, istifadəçi girişini birbaşa veb-tətbiqin render edilmiş HTML səhifəsinə daxil edir. Siz deyə bilərsiniz ki, “Bu sadəcə xəbərdarlıq qutusudur, nə olsun?” Məsələ bundadır ki, əgər mən xəbərdarlıq qutusu daxil edə bilirdimsə, çox güman ki, başqa bir şey də daxil edə bilərəm və bəlkə də saytınıza sizin kimi daxil olmaq üçün istifadə edə biləcəyim kukilərinizi oğurlaya bilərəm.Digər nümunə saxlanılan istifadəçi girişi təmizlənmədikdə baş verir. Tutaq ki, bloqunuzda şərh yazıram; şərh sadədir:

Əgər digər istifadəçilər mənim günahsız linkimə klikləsələr, onların kukiləri məndədir:

Öz veb-tətbiqinizdə XSS zəifliklərini necə tapmağı və onları necə düzəltməyi

Gruyere
-nin ikinci hissəsində öyrənə bilərsiniz; və ya təcrübəli tərtibatçısınızsa,Onlayn Təhlükəsizlik bloqu
muzda bloq yazısı yazdığımız şablon sistemlərində avtomatik qaçış (escaping) xüsusiyyətlərinə nəzər salın..

Saytlararası sorğu saxtakarlığı (XSRF) – evil.com saytından gələn sorğulara etibar etməliyəmmi?

Uups, qırılmış şəkil. O, təhlükəli ola bilməz — axı o qırılıb — bu o deməkdir ki, şəklin URL-i 404 və ya sadəcə səhv qurulub. Bütün hallarda bu, doğrudurmu?

Xeyr, doğru deyil! Məzmun növündən asılı olmayaraq istənilən URL-i şəkil mənbəyi kimi təyin edə bilərsiniz. O, HTML səhifəsi, JavaScript faylı və ya digər potensial zərərli resurs ola bilər. Bu halda şəkil mənbəyi sadə səhifənin URL-i idi:

Həmin səhifə yalnız mən daxil olmuşamsa və bəzi kukilər təyin olunubsa işləyəcək. Mən faktiki olaraq tətbiqə daxil olduğum üçün brauzer şəkil mənbəyi URL-inə daxil olmaqla şəkli əldə etməyə çalışarkən, o, həm də mənim birinci fraqmentimi silib. Bu, xüsusilə təhlükəli səslənmir, lakin tətbiqlə bir qədər tanışamsa, mən həmçinin istifadəçinin profilini silən və ya adminlərə digər istifadəçilər üçün icazələr verməyə imkan verən URL-i işə sala bilərəm.

Tətbiqinizi XSRF-dən qorumaq üçün
GETvasitəsilə vəziyyəti dəyişən əməliyyatların çağırılmasına icazə verməməlisiniz; vəziyyəti dəyişən bu cür sorğular üçün POST metodu ixtira edilmişdir. Təkcə bu dəyişiklik yuxarıdakı hücumu zərərsizləşdirə bilərdi, lakin adətən bu kifayət etmir və XSRF-in qarşısını almaq üçün bütün vəziyyəti dəyişən sorğulara proqnozlaşdırıla bilməyən dəyər daxil etməlisiniz. XSRF haqqında daha çox öyrənmək istəyirsinizsə, lütfən Gruyere üzərinə keçin.

Saytlararası skript daxil edilməsi (XSSI) – Bütün skriptləriniz bizə məxsusdur

Bu gün bir çox saytlar JSON məlumatları qaytaran asinxron JavaScript sorğuları vasitəsilə səhifənin məzmununu dinamik olaraq yeniləyə bilər. Bəzən JSON həssas məlumatlar ehtiva edə bilər və düzgün ehtiyat tədbirləri görülməzsə, hücumçunun bu həssas məlumatları oğurlaması mümkün ola bilər.

Aşağıdakı ssenarini təsəvvür edək: Mən standart HTML səhifəsi yaratmışam və sizə linki göndərirəm; mənə etibar etdiyiniz üçün göndərdiyim linkə daxil olursunuz. Səhifə yalnız bir neçə sətirdən ibarətdir:

Gruyere-ə daxil olduğunuz və şəxsi fraqmentiniz olduğu üçün səhifəmdə fraqmentinizin məzmunu barədə sizi məlumatlandıran xəbərdarlıq qutusu görəcəksiniz. Həmişə olduğu kimi, əgər xəbərdarlıq qutusu işə sala bildimsə, istədiyim başqa hər şeyi edə bilərəm; bu halda bu sadə fraqment idi, lakin o, sizin ən böyük sirriniz də ola bilərdi.

Tətbiqinizi XSSI-dən qorumaq çox çətin deyil, lakin o, hələ də diqqətli düşünmək tələb edir. XSRF bölməsində izah edildiyi kimi tokenlərdən istifadə edə bilərsiniz, skriptinizi yalnız POST sorğularına cavab vermək üçün tənzimləyə bilərsiniz və ya skriptin icra oluna bilməyəcəyindən əmin olmaq üçün sadəcə JSON cavabına ‘n’ ilə başlaya bilərsiniz.

SQL İnyektsiyası – Hələ də hesab edirsiniz ki, istifadəçi girişi təhlükəsizdir?

Tətbiிnizə
JohnDoe'; DROP TABLE members;--

kimi istifadəçi adı ilə daxil olmağa çalışsam nə baş verəcək?

Bu xüsusi nümunə istifadəçi məlumatlarını ifşa etməyəcək, lakin o, böyük başağrısına səbəb ola bilər, çünki tətbiqinizin üzvlər haqqında məlumatları saxladığı SQL cədvəlini tamamilə silmək potensialına malikdir.
Ümumiyyətlə, siz proaktiv düşüncə və daxiletmə yoxlanışı ilə tətbiqinizi SQL inyektsiyasından qoruya bilərsiniz. Birincisi, əminsinizmi ki, SQL istifadəçisininDROP TABLE members əmrini icra etmək üçün icazəsi olmalıdır? Yalnız SELECT

hüquqlarının verilməsi kifayət etməzmi? SQL istifadəçisinin icazələrini diqqətlə tənzimləməklə ağrılı təcrübələrdən və çoxlu problemlərdən qaça bilərsiniz. Siz həmçinin xəta hesabatını elə konfiqurasiya etmək istəyə bilərsiniz ki, uğursuz sorğu zamanı verilənlər bazası və onun cədvəllərinin adları ifşa olunmasın.

İkincisi, XSS halında öyrəndiyimiz kimi, heç vaxt istifadəçi girişinə etibar etməyin: sizə giriş forması kimi görünən şey hücumçu üçün potensial qapı kimi görünür. Verilənlər bazasında saxlanılacaq girişi həmişə təmizləyin və dırnaq işarələri ilə qoruyun və mümkün olduqda əksər verilənlər bazası proqramlaşdırma interfeyslərində mövcud olan hazırlanmış və ya parametrləşdirilmiş ifadələr adlanan ifadələrdən istifadə edin.
Veb-tətbiqlərin necə istismar oluna biləcəyini bilmək onları necə qorumağı başa düşməkdə ilk addımdır. Bununiə əlaqədar olaraq, siziGruyere kursu
nə keçməyə,
Google Code University
saytından digər veb-təhlükəsizlik kursları almağa və avtomatlaşdırılmış veb-tətbiq təhlükəsizliyi testi aləti axtarırsınızsa,
skipfish
alətini yoxlamağa təşviq edirik. Əgər daha çox sualınız varsa, lütfən onları.

Vebmaster Yardım Forumu
müzdə paylaşın.Yazdı: