• Lenovo smartfonunda proqramı necə silmək olar
• PC üçün ən yaxşı Android emulyatorları
• Baidu Root (Rus versiyası)
• iOS 11-ə yüksəltməliyəm?
• Şəbəkə trafik analizatoru sniffer
• FRP: Funksional Reaktiv Proqramlaşdırma olduğu kimi
• GTA IV başlamazsa nə etməli gta 4 ilə bağlı problemlər
• GTA San Andreas Android haqqında hər şey
• GTA 5-i yükləməyə qənaət edin
• GTA San Andreas-da modların quraşdırılması GTA San Andreas üçün modları necə yükləmək olar

Tətbiq təhlükəsizliyinə gəldikdə, təkcə aparat və əməliyyat sisteminə deyil, həm də təhlükəsiz skriptlərin yazılmasına diqqət yetirmək vacibdir. Bu məqalədə siz tətbiqinizi necə qoruyacağınızı və onu daha az həssas hala gətirəcəyinizi öyrənəcəksiniz. Aşağıda tətbiqinizi bütün növ hücumlardan qorumağa kömək edəcək tədbirlərin siyahısı verilmişdir:

1. Daxil olan məlumatların doğrulanması
2. XSS hücumlarına qarşı qorunma
3. CSRF hücumlarına qarşı qorunma
4. SQL injection qarşısının alınması
5. Fayl sisteminin qorunması
6. Sessiya məlumatlarının qorunması
7. Emal zamanı xəta
8. Qoşma qorunması

Daxil olan məlumatların doğrulanması

Tətbiqi tərtib edərkən onu "pis" girişdən qorumağa çalışmalısınız. Təqib ediləcək qayda belədir: "İstifadəçinin daxil etdiyinə heç vaxt etibar etməyin." Əksər istifadəçilərin təhlükə yaratmamasına baxmayaraq, hər zaman kiminsə formalar və ya ünvan çubuğu vasitəsilə daxil edilmiş “pis” məlumatlardan istifadə edərək saytınızı sındırmaq istəməsi ehtimalı var. Daxil olan məlumatları həmişə doğrulayır və filtrləyirsinizsə, o zaman təhlükəsiz proqram yazmaq üçün yaxşı şansınız var.

Həmişə məlumatlarınızı PHP skriptlərində yoxlayın. Əgər siz məlumatları təsdiqləmək üçün JavaScript-dən istifadə edirsinizsə, o zaman təcavüzkar istənilən vaxt onu öz brauzerində deaktiv edə bilər. Bu halda ərizəniz risk altındadır. Heç kim JavaScript-in təsdiqinə qarşı deyil, lakin yaxşı qorunma üçün PHP skriptlərindəki məlumatları iki dəfə yoxlamaq lazımdır.

XSS hücumlarına qarşı qorunma

Saytlararası skript və ya XSS hücumu potensial olaraq həssas səhifələrə kodun yeridilməsinə əsaslanan hücumdur. Təhlükə ondadır ki, zərərli kodu formalar vasitəsilə daxil etmək və sonra brauzerdə göstərmək olar.

Tutaq ki, saytınızın şərhləri daxil etmək üçün bir forması var və əlavə edildikdən sonra dərhal göstərilir. Təcavüzkar JavaScript kodu olan şərh daxil edə bilər. Forma təqdim edildikdən sonra məlumatlar serverə göndərilir və verilənlər bazasına daxil edilir. Bundan sonra məlumatlar verilənlər bazasından götürülür və yeni şərh daxili JavaScript kodu daxil olmaqla HTML səhifəsində göstərilir. O, istifadəçini hansısa zərərli səhifəyə və ya fişinq saytına yönləndirə bilər.

Tətbiqlərinizi qorumaq üçün daxil olan məlumatları strip_tags() funksiyası vasitəsilə ötürün, bu da mövcud bütün teqləri siləcək. Brauzerdə məlumatları göstərərkən htmlentities() funksiyasından istifadə edin.

CSRF hücumlarına qarşı qorunma

Baxacağımız növbəti hücum növü CSRF hücumu və ya saytlararası sorğu saxtakarlığıdır. Təcavüzkar qurbanın xəbəri olmadan məxfi məlumatları əldə etmək və ya əməliyyatı tamamlamaq üçün müxtəlif hiylələrdən istifadə edir. Bu, əsasən iş məntiqinin GET sorğularının işinə əsaslandığı zəif qorunan saytlarda baş verir.

Ümumiyyətlə, GET sorğuları idempotentdir. Idempotency, bu kontekstdə, heç bir üçüncü tərəfin müdaxiləsi olmadan eyni səhifəyə istədiyiniz qədər daxil ola biləcəyiniz deməkdir. Buna görə GET sorğuları yalnız məlumat əldə etmək üçün istifadə edilməlidir, lakin heç bir halda müxtəlif növ əməliyyatları həyata keçirmək üçün istifadə edilməməlidir.

Aşağıdakı sadə nümunə etibarsız saytın CSRF hücumuna necə məruz qala biləcəyini göstərir:

Tutaq ki, Bob Alisa CSRF hücumu həyata keçirmək istəyir. O, xüsusi bir url ünvanı yaratdı və onu elektron poçtla Alisa göndərdi:

Saytımı ziyarət edin!

Alice example.com saytında səlahiyyətlidirsə və bu linki izləyirsə, onun hesabından Bobun hesabına 1000 dollar köçürüləcək. Alternativ olaraq, Bob şəkli də göndərə və src atributuna "pis" ünvan qoya bilər.

Brauzer bu şəkli göstərə bilməyəcək, çünki o, mövcud deyil, lakin sorğu Alisanın xəbəri və iştirakı olmadan ediləcək.

Bu cür hücumun qarşısını almaq üçün verilənlər bazasındakı məlumatları dəyişdirmək üçün nəzərdə tutulan proseslərdə yalnız POST sorğularından istifadə edin. $_REQUEST istifadə etməyin. GET parametrlərini emal etmək üçün $_GET, POST parametrlərini əldə etmək üçün isə $_POST istifadə edin.

Əlavə tədbir olaraq siz bir növ unikal işarə yarada və onu hər POST sorğusuna əlavə edə bilərsiniz. İstifadəçi daxil olduqda, təsadüfi bir token yaradıla və sessiyaya yazıla bilər. Bütün formalar istifadəçiyə göstərildiyi üçün bu işarə gizli sahədə yazılmalıdır. Tətbiqin biznes məntiqi formalardan işarəni və sessiyada saxlanan nişanı yoxlayacaq funksionallığı təmin etməlidir.

SQL injection qarşısının alınması

PDO verilənlər bazasını sorğulamaq üçün istifadə edilməlidir. Parametrləşdirilmiş sorğular və hazırlanmış ifadələrlə siz SQL inyeksiya təhlükəsini aradan qaldıra bilərsiniz.

Aşağıdakı misala baxaq:

Yuxarıdakı kodda biz hazır() metoduna sorğu göndəririk, o cümlədən adlandırılmış parametrlər: :name və :age . Beləliklə, sorğu əlavə məlumatların dəyişdirilməsi üçün əvvəlcədən tərtib edilir. execute() metodu çağırıldıqda sorğu tam formalaşır və icra olunur. Bu texnikadan istifadə etsəniz, təcavüzkarın SQL inyeksiyasını yerinə yetirmək üçün bütün cəhdləri ləğv ediləcək.

Fayl sisteminin qorunması

Məsuliyyətli bir tərtibatçı olaraq, həmişə fayl sisteminizə zərər verməyən kod yazmalısınız. İstifadəçinin təqdim etdiyi məlumatlardan asılı olaraq faylı yükləmək üçün göndərən koda baxaq.

Bu skript çox təhlükəlidir, çünki onun sayəsində skriptlə fayldan mövcud olan istənilən qovluğa giriş əldə edə bilərsiniz: sessiyalar, sistem qovluqları və s.

Sessiya məlumatlarının qorunması

Varsayılan olaraq, bütün sessiya məlumatları müvəqqəti qovluğa yazılır. Paylaşılan hostinqdən istifadə edirsinizsə, sizdən başqa kimsə skript yaza və sessiya məlumatlarını oxuya bilər. Odur ki, parolları və ya kredit kartı nömrələrini sessiyalarda saxlamaqdan çəkinin.

Əgər hələ də belə məlumatları sessiyada saxlamağa ehtiyacınız varsa, şifrələmə ən yaxşı tədbirdir. Bu, problemi tamamilə həll etmir, çünki şifrələnmiş məlumatlar 100% təhlükəsiz deyil, lakin saxlanılan məlumat oxunmayacaqdır. Siz həmçinin verilənlər bazası kimi sessiya məlumatlarını başqa yerdə saxlamağı da düşünməlisiniz. PHP-də sessiya məlumatlarını öz qaydasında saxlamağa imkan verən xüsusi session_set_save_handler() metodu var.

PHP 5.4-dən bəri siz SessionHandlerInterface tipli obyekti session_set_save_handler() -ə ötürə bilərsiniz.

Emal zamanı xəta

Tətbiqin inkişafı zamanı baş verə biləcək hər cür səhvlərə diqqət yetirməyə dəyər, lakin onlar son istifadəçilərdən gizlədilməlidir. Səhvlər istifadəçilərə göstərilirsə, bu, saytınızı həssas edir. Beləliklə, ən yaxşı həll təyinat serveri və inkişaf serveri üçün fərqli konfiqurasiya olardı.

İctimai serverdə siz display_errors və display_start_up_errors kimi seçimləri deaktiv etməlisiniz, lakin error_reporting və log_errors kimi seçimlər aktivləşdirilməlidir ki, istifadəçilərin qarşılaşdığı bütün səhvlər qeyd olunsun.

Siz həmçinin öz səhv idarəçinizi təyin etmək üçün set_error_handler istifadə edə bilərsiniz. Bununla belə, burada məhdudiyyətlər ola bilər, çünki yerli işləyici yerli PHP mexanizmindən daha aşağıdır. E_CORE_ERROR , E_STRICT və ya E_COMPILER_ERROR xətaları xüsusi işləyici ilə eyni faylda tutula bilməz. Üstəlik, işləyicinin özündə baş verə biləcək səhvlər də tutula bilməz.

İstisnaları tutmağın daha zərif yolu üçün potensial təhlükəli kod cəhd/tutmaq blokuna yerləşdirilməlidir. Bütün yerli istisnalar İstisna siniflərinin və ya alt siniflərinin obyektləri olmalıdır. İstisnalar atılıbsa, onlar try/catch blokunda idarə oluna bilər.

Qoşma qorunması

Çox vaxt PHP skriptlərində verilənlər bazasına qoşulma və bir çox başqa fayllar kimi digər fayllar yüklənir. Bəzi tərtibatçılar bu fayllara .inc uzantısını verirlər. Bu cür fayllar standart olaraq PHP tərəfindən təhlil edilmir. Əgər siz onlara birbaşa ünvanda daxil olsanız, istifadəçi bu faylın mətnini görə biləcək. Əgər haker verilənlər bazası ilə məlumat bağlantısını saxlayan fayla giriş əldə etməyi bacarırsa, o zaman daha sonra tətbiqinizdəki bütün məlumatlara giriş əldə edə bilər. Beləliklə, həmişə yüklənmiş fayllar üçün .php uzantısından istifadə edin və onları birbaşa istifadəçi girişi olmayan yerdə saxlayın.

Nəticə

Bu 8 qaydaya əməl etsəniz, bu, tətbiqinizin müxtəlif növ hücumlara qarşı müqavimətini xeyli artıracaq. İstifadəçilərin daxil etdiyi məlumatlara etibar etməyin, fayllarınızı və verilənlər bazanızı qoruyun.

Fəaliyyət göstərən veb proqram yaratmaq döyüşün yalnız yarısıdır. Müasir onlayn xidmətlər və veb proqramlar, öz məzmunlarına əlavə olaraq, istifadəçi məlumatlarını saxlayır. Bu məlumatların qorunması etibarlılıq və təhlükəsizlik baxımından yaxşı yazılmış koddan asılıdır.

Zəifliklərin əksəriyyəti kənardan alınan məlumatların düzgün işlənməməsi və ya onların kifayət qədər ciddi yoxlanılması ilə bağlıdır. Bu boşluqlardan biri saytlararası skriptdir (Cross Site Scripting, XSS) saytın pozulmasına, istifadəçinin yoluxmuş resursa yönləndirilməsinə, veb-resursa zərərli kodun daxil edilməsinə, kukilərin, sessiyaların oğurlanmasına və s. məlumat. XSS-ə təkbaşına müqavimət göstərmək aşağıda müzakirə olunacaq təhlükəsiz proqramlaşdırma üçün ən yaxşı təcrübələri və tövsiyələri tətbiq etməyə kömək edəcək.

1. Giriş/çıxışdan qaçışdan istifadə edin. Kodunuzu zərərli skriptlərdən təmizləmək üçün daxili funksiyalardan istifadə edin. Bunlara htmlspecialchar(), htmlentities() və strip_tags() kimi funksiyalar daxildir.
İstifadə nümunələri:

$name = strip_tags($_POST["ad"]); $name = htmlentities($_POST["ad"], ENT_QUOTES, "UTF-8"); $name = htmlspecialchars($_POST["ad"], ENT_QUOTES);
Daxili PHP funksiyaları, öz-özünə yazılmış funksiyalardan fərqli olaraq, daha sürətli işləyir və həmçinin daha az təhlükəsizlik səhvləri və zəifliklərə malikdir, çünki. daim təkmilləşdirilir. Daxili funksiyalar və filtrlər əsasında qurulmuş xüsusi kitabxanalardan istifadə etmək də tövsiyə olunur. Nümunələrə OWASP Enterprise Security API (ESAPI), HTML Purifier, Reform, ModSecurity daxildir.
Kitabxananın düzgün işləməsi üçün əvvəlcə onu konfiqurasiya etmək lazımdır!

2. Ağ siyahıya daxil etmə yanaşmasından istifadə edin. Yanaşma “icazə verilməyən qadağandır” prinsipi ilə işləyir. Bu, saxlanacaq məlumatları qəbul etməzdən əvvəl başlıqlar, kukilər, sorğu sətirləri, gizli sahələr, eləcə də forma sahəsinin uzunluğu, növü, sintaksisi, etibarlı simvollar və digər qaydalar daxil olmaqla bütün daxil edilmiş məlumatların yoxlanılması üçün standart sahə yoxlama mexanizmidir. saytda nümayiş etdirilir. Məsələn, bir sahəyə soyad daxil etmək istəyirsinizsə, yalnız hərflərə, defislərə və boşluqlara icazə verməlisiniz. Qalan hər şeyi rədd etsəniz, d'Arc soyadı rədd ediləcək - zərərli məlumatları qəbul etməkdənsə etibarlı məlumatı rədd etmək daha yaxşıdır.
Təəssüf ki, daxili PHP məlumatların yoxlanılması filtrləri öz vəzifələrinin öhdəsindən gəlmir, buna görə də öz filtrlərinizi yazmaq və lazım olduqda onları "bitirmək" tövsiyə olunur. Beləliklə, zaman keçdikcə giriş filtrləmə üsullarınız təkmilləşəcək. Bu filtrlərdən yan keçmək üçün çoxlu aktiv məzmun növləri və kodlaşdırma üsullarının olduğunu da xatırlamağa dəyər. Eyni səbəbdən, qara siyahıdan istifadə etməyin.

3. Hər veb səhifəsində kodlaşdırmanı təyin edin. Hər bir veb səhifə üçün hər hansı bir xüsusi sahənin qarşısında kodlaşdırma (məsələn, ISO-8859-1 və ya UTF-8) təyin etməlisiniz.
İstifadə nümunəsi:

və ya Apache veb serverinin .htaccess faylına sətri əlavə edin:

AddDefaultCharset UTF-8

Kodlaşdırma http başlığında və ya meta teqlərində göstərilməyibsə, brauzer səhifə kodlaşdırmasının özünü müəyyən etməyə çalışır. HTML 5 standartı JIS_C6226-1983, JIS_X0212-1990, HZ-GB-2312, JOHAB (Windows kod səhifəsi 1361), ISO-2022 və EBCDIC əsaslı kodlaşdırmaları ehtiva edən kodlaşdırmaların istifadəsinə mane olur. Həmçinin, veb tərtibatçıları CESU-8, UTF-7, BOCU-1 və SCSU kodlaşdırmalarından istifadə etməməlidirlər. Bu kodlaşdırmalar heç vaxt veb məzmunu üçün nəzərdə tutulmamışdır. Teq teqdən əvvəl yerləşirsə və istifadəçi məlumatı ilə doludursa, təcavüzkar UTF-7 kodlaşdırmasına zərərli html kodu daxil edə bilər, beləliklə, ‘ kimi simvolların filtrasiyasını keçərək.<’ и ‘"’.

4. HttpOnly bayrağını təyin edin. Bu bayraq müştəri kukilərini JavaScript kimi skript dilləri vasitəsilə əlçatmaz edir.
Bu parametr aktivləşdirilib
- php.ini-də:

Session.cookie_httponly=Doğrudur

Skriptdə session_set_cookie_params() funksiyası vasitəsilə:

Sessiya_set_cookie_params etibarsızdır (int $ömür boyu [, string $yol [, string $domain [, bool $təhlükəsiz = false [, bool $httponly = doğru ]]]])
- setcookie() funksiyası vasitəsilə veb proqramda:

bool setcookie (string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = true ]]]]]])
Bu funksiya ümumi brauzerlərin ən son versiyaları tərəfindən dəstəklənir. Bununla belə, bəzi brauzerlərin köhnə versiyaları XMLHttpRequest və digər güclü brauzer texnologiyaları vasitəsilə HTTP başlıqlarına, o cümlədən HttpOnly bayraqları olan Set-Cookie başlığına oxunma girişini təmin edir.

5. Məzmun Təhlükəsizlik Siyasətindən (CSP) istifadə edin. Bu, müxtəlif məlumatları, məsələn, JS, CSS, şəkillər və s. yükləyə biləcəyiniz mənbələrin "ağ siyahısı"nı açıq şəkildə elan etməyə imkan verən başlıqdır. Təcavüzkar veb səhifəyə skripti yerləşdirməyi bacarsa belə, icazə verilən mənbələr siyahısına uyğun gəlmədikcə icra olunmayacaq.
CSP-dən istifadə etmək üçün veb proqram Məzmun-Təhlükəsizlik-Siyasət HTTP başlığı vasitəsilə siyasəti brauzerə göndərməlidir.
İstifadə nümunəsi:

Məzmun-Təhlükəsizlik-Siyasəti: default-src "self"; script-src trustedscripts.example.com style-src "self" ajax.googleapis.com; connect-src "self" https://api.myapp.com realtime.myapp.com:8080; media-src "self" youtube.com; obyekt-src media1.example.com media2.example.com *.cdn.example.com; frame-src "self" youtube.com embed.ly
"Məzmun-Təhlükəsizlik Siyasəti" rəsmi W3C tərəfindən təsdiqlənmiş http başlığıdır və Chrome 26+, Firefox 24+ və Safari 7+ brauzerləri tərəfindən dəstəklənir. "X-Content-Security-Policy" HTTP başlığı Firefox 4-23 və IE 10-11 üçün, "X-Webkit-CSP" başlığı Chrome 14-25, Safari 5.1-7 üçün istifadə olunur.

Veb tərtibatçısının nöqteyi-nəzərindən, CSP-ni resursunuzda düzgün və bacarıqlı şəkildə yerləşdirmək olduqca problemlidir, çünki saytın hər bir səhifəsi üçün ayrıca siyasət təyin edilməlidir.

6. Müntəzəm olaraq kod təhlükəsizliyi nəzərdən keçirin və nüfuz testini həyata keçirin. Həm əl, həm də avtomatlaşdırılmış yanaşmalardan istifadə edin. Nessus, Nikto və OWASP Zed Attack Proxy kimi alətlər sizə veb tətbiqinizdə XSS boşluqlarını tapmağa kömək edəcək.

7. İstifadəçilərə brauzerlərini mütəmadi olaraq yeni versiyaya yeniləmək və onlar üçün NoScript kimi genişlənmələrdən istifadə etmək tövsiyə olunur.
Gördüyünüz kimi, hər bir tövsiyənin öz üstünlükləri və mənfi cəhətləri var, buna görə də saytlararası skriptlərə qarşı mübarizənin effektivliyi kompleks qorunma tətbiq etməklə əldə edilir, yəni. məcmu olaraq təsvir edilən tövsiyələrin istifadəsi.

Və bu məqalə, xüsusən yeni başlayanlar üçün məlumatlı olmağı vəd edir.

Və XSS haqqında təsəvvürə malik olmaq üçün məqaləni 2 hissəyə böləcəyəm, burada 1-ci hissədə bu XSS-nin hansı heyvan olduğunu təhlil edəcəyik. İkincisində isə onun PHP-də necə işlədildiyini və özünüzü ondan necə qoruyacağınızı nəzərdən keçirəcəyik.

- XSS. Nə baş verdi?

Nəzəriyyə

Saytlararası skript veb sistemi tərəfindən buraxılmış səhifəyə zərərli kodun yeridilməsindən (bu səhifəni açdıqda istifadəçinin kompüterində yerinə yetiriləcək) və bu kodla təcavüzkarın interneti ilə qarşılıqlı əlaqədən ibarət veb sistemlərinə hücum növüdür. server. Niyə CSS olmadığını bilirsinizmi? Düzdür, çünki bu abbreviatura kaskad üslubları tərəfindən qəbul edilir.

Ümumiyyətlə, XSS 2 növə bölünür:

• Yansıtılmış (qeyri-daimi). Bu növə daha yaxından nəzər salaq. Bu tip XSS bütün inyeksiyalar arasında ən populyar və ən çox yayılmışdır. Hücum növü olduqca sadədir, giriş məlumatları süzülməsə belə işləyir, əksər hallarda saytdakı bəzi formalar vasitəsilə. Misal üçün,

  Site.ru/search.php?q=

  Belə çıxır ki, əgər bu daxil olan xətt server tərəfində süzülməsə, o zaman “r0hack” mesajı alırıq. Yaxşı, nə deyirsən, böyük bir şey deyil. Amma yox, çünki bu yolla biz istifadəçi icazə kukilərini oğurlaya bilərik. Məsələn, kök ilə 1 tapşırığa nəzər salaq. Baxmayaraq ki, bu, hər iki hücum növünə aid edilə bilər, lakin bu nümunədə istifadəçi kukilərini necə oğurlaya biləcəyimizi və saxlanılan növün necə işlədiyini görə bilərsiniz.

• Saxlanılır (saxlanır). Bu halda biz öz kodumuzu serverə yükləyə bilirik və hər dəfə bu kodla səhifə açanda o, başlayır və sarsıdıcı zərbə vurur, məsələn, yuxarıda dediyim kimi, kukiləri oğurlayır və başqa bir istifadəçinin kimliyini göstərə bilir. İndi isə yuxarıda yazdığım tapşırığı təhlil edək.

Bu tapşırığı təhlil edəcəyik:

Qonaqlardan gizlədilib

Gördüyünüz kimi, tapşırıqda administrator kukilərini oğurlamaq və onların köməyi ilə daxil olmaq deyilir.
Və mənə mesaj göndərə biləcəyimiz sadə bir forum verdilər. Yaxşı, burada kukiləri alacağımız klikləməklə mesajın skriptə göndərilməsi lazım olduğunu dərhal başa düşə bilərsiniz. Belə məqsədlər üçün, məsələn, saytdan istifadə edə bilərik

Qonaqlardan gizlədilib

Bir keçid meydana gətirdiyi yerdə və onu izlədikdə başlıq məlumatlarını, kukiləri və bütün bunları oğurlayır. Gəlin bunu edək və mesajımızı foto kimi maskalayıb göndərək.

Burada göndərmək üçün belə bir skript yaradırıq:

Sonra göndəririk və səhifə admin tərəfindən açıldıqda biz kukiləri alırıq:

Və bu məlumatları kukilərdə əvəz etsək, ziyarətçi statusu Admin olaraq dəyişəcək.

Bununla bağlı XSS ​​haqqında danışmağı bitirəcəyik, əgər bir şey aydın deyilsə, soruşun və ya google-dan soruşun, çoxlu məlumat var.

– PHP-də XSS zəifliklərinin istismarı

Gəlin praktikaya keçək və XSS hücumunun hansı şəraitdə işləyə biləcəyinə baxaq.
Bizdə gedən məlumatlardan qaçmayan bir kod parçası var:

$query = $_GET["query"] ?? 0; echo "Tapıldı:". $query;

Və gördüyünüz kimi, bu halda ssenarimiz işləyir.

– PHP-ni XSS-dən necə qorumaq olar

Və bu zəifliyin istismarını necə bağlamaq olar, bütün bunları etmək olduqca sadədir, biz sadəcə onu qoruyuruq:

$query = $_GET["query"] ?? 0; $query = htmlspecialchars($query, ENT_QUOTES); echo "Tapıldı:". $query;

Və biz htmlspecialchars sayəsində skriptimizi düz mətn kimi əldə edirik, ENT_QUOTES - həm cüt, həm də tək dırnaqları çevirir. Və xoşbəxt olacaqsan.

Məsələn, başqa bir Alman saytı:

XSS üçün budur. Ümid edirəm ki, pis alınmadı. Sualları şərhlərdə yazın. Çox sağ ol.

Cəmi bir neçə il əvvəl XSS zəifliklərinin əsl çiçəklənmə dövrünü görə bilərdiniz. Sonra veb tərtibatçılarının səhlənkarlığı nəinki yüksək, hətta peşəkar səviyyəyə çatdı. Bu gün webmasterlər artıq bu problemə daha ciddi yanaşmağa başlayıblar.

Bu qısa məqalədə XSS hücumlarından qorunmağın ən yaxşı yollarından danışacağam. Ancaq əvvəlcə XSS zəiflikləri haqqında bir neçə söz.

XSS zəifliyi

XSS veb səhifələrdə xüsusi JS skriptlərinin onlara daxil olması nəticəsində yaranan zəiflikdir.

XSS zəiflikləri harada və necə istifadə olunur?

Ən məşhur istiqamətlərdən bəziləri bunlardır:

Giriş
XSS-in əsas məqsədlərindən biri məhz qurbanın kukisini əldə etmək və onların hesabına sızmaqdır. Bunun üçün siz müvafiq zəifliyi tapmalı, səhifədəki snayferə kuki göndərmək üçün skript daxil etməli və sonra istədiyiniz sayta daxil olmaq üçün oğurlanmış kukilərdən istifadə etməlisiniz.

İş qüvvəsi
JavaScript + PHP-nin hiyləgər birləşmələri vasitəsilə başqasının resursunun istifadəçiləri tərəfindən onun pulsuz deşifrə edilməsi üçün captcha-nın banal endirilməsi həyata keçirilir. Bunun üçün istifadəçi ondan kodu daxil edənə qədər hücuma məruz qalan səhifə bloklanır.

CSRF
Bəzən istifadəçi adı və parol/sessiya ilə belə, haker hesaba daxil ola bilmir, çünki bağlama ip-ünvanı, brauzer və digər məlumatlar ola bilər. Buna görə də XSS təmiz formada keçmir. Lakin saytın dizaynını bilən təcavüzkar yenə də saytlararası sorğu saxtakarlığından istifadə edərək hesaba daxil ola bilər.

XSS zəifliklərinə qarşı TOP 5 qoruma:

1. Htmlspecialchars() funksiyası ilə qorunma.
Bu funksiya ona ötürülən arqumenti HTML obyektlərinə çevirir və o, potensial olaraq təhlükəli olan simvolları çevirir.

2. strip_tags() funksiyası ilə qorunma.
htmlspecialchars() funksiyasından fərqli olaraq, bu funksiya arqument sətirindən yalnız teqləri silir, ikinci arqument isə silinməməli olan istisnaları təyin etmək üçün istifadə olunur. Xətlər ondan keçir:<, >, < img.

3. BB kodları.
Yalnız müəyyən teqlərin buraxılması, bəzən HTML standartlarının icazə verdiyindən çox fərqli formada

4. Daimi ifadələr.
Bəzi insanlar müntəzəm ifadələri bəyənir, bəziləri bəyənmir, bəziləri isə hətta potensial təhlükəli simvolların və ya etiketlərin keçmədiyi öz sözlərini yazmağa üstünlük verir. Qalanların HTML obyektini dəyişmədən, daxil edilmiş teqdən arqumentləri xaric edərkən faydalıdır.

5. Öz-özünə yazılmış funksiyalar.
XSS ilə çox çevik şəkildə məşğul olan bütün növ rekursiv sətir təhlilçiləri də olduqca populyardır. Baxmayaraq ki, öz-özünə yazılmış funksiyalarda bir növ zəiflik tapmaq daha çox yayılmışdır.

Sizi "və ondan necə qorunmaq olar" məqaləsi də maraqlandıra bilər. Və bu gün üçün hamısı budur. Uğurlar və informasiya təhlükəsizliyi!

Saxlanmış XSS hücumları

Saytlararası Skript hücum məlumatı oğurlamaq və ya başqa zərər vurmaq məqsədilə istifadəçinin brauzerinə zərərli proqramın təsiridir. CSS-ə (Caskading Style Sheets) kölgə salmamaq üçün abreviaturadakı ilk simvolu əvəz etməyə razılaşdıq, qısaltma aldıq: XSS-hücum.

Saxlanılır XSS hücumları skriptin təcavüzkar tərəfindən səhifənin əsas hissəsinə əlavə edildiyi hücumlardır (giriş formaları vasitəsilə - mətn sahələri, girişlər, məzmun redaktə edilə bilən elementlər - forumlarda, qonaq kitablarında və s.). Mesaja daxil edilmiş maskalanmış XSS skripti sayt tərəfindən saxlanılır (buna görə də adı), sonra istifadəçilər yoluxmuş səhifəni tələb etdikdə, işə salınır və hücumlara məruz qalır.

Kukiləri oğurlayan daxil edilmiş XSS kodu üçün üslub seçimləri
Etiketlərdə :

Html teqində hadisə idarəedicisi olaraq:

bəzi mətn

Pseudo-protokoldan istifadə javascript: :

Bu nümunələrdən hər hansı birinin başqasının saytının səhifəsinə daxil edilməsinin nəticəsi onu yükləyən brauzerlərdən sorğunun formalaşması olacaq,
http://example.com/login=sasha;%20parol=terminator,
Harada http://example.com/- təcavüzkarın saytı və giriş = sasha, parol = terminator- istifadəçinin kompüterindən kukilər (kukilər və ya oğurlanan məlumatın növü fərqli ola bilər, lakin bu hal hazırda bizim üçün vacib deyil). Oğrunun saytında, əlbəttə ki, tələb olunan ünvanla heç bir səhifə yoxdur, ona görə də onun domeninin serveri ( http://example.com/) sorğu ünvanını tutmaq və daxil etmək asan olan 404 xətası yaradacaq. Beləliklə, zərərverici yuxarıda göstərilən XSS skriptlərindən hər hansı birini başqasının saytının səhifəsinə daxil etdikdə (saytda qorunma tədbirləri olmadıqda), sonra bir müddət serverdə http://example.com/ yoluxmuş səhifəni yükləyən bütün istifadəçilərin brauzerlərindən kukilər haqqında məlumatı ehtiva edən log faylı avtomatik olaraq yaradılacaq.

Saxlanılan XSS hücumlarına qarşı server tərəfdən qorunma

Problemin həlli göz qabağındadır: istifadəçinin daxil etdiyi, saxladığı və sonra digər istifadəçilərə göstərdiyi mətnin brauzerdə proqramlı icra imkanını istisna etmək. Buna görə də, girişdə açıq və ya ehtimal olunan bir skripti ehtiva edən bütün yerləri zərərsizləşdirmək lazımdır, məsələn:
- qablar ;
- hadisə idarəçiləri etiketlərdə;
- psevdo protokollar javascript: .

Bu sadə görünür: mətndən əvvəllər məlum olan təhlükəli simvol ardıcıllığını silmək. Onlar bunu adətən belə edirlər: serverdə php işləyicisi (filtr) girişi təhlil edir, onu kəsir və ya içindəki şübhəli fraqmentləri əvəz edir. Amma! Axı brauzerlər PHP haqqında heç nə “bilmədən” JavaScript-i icra edirlər, server, əksinə, javascript haqqında “bilmir”. Server qorunmasının pis tərəfi odur ki, o, ümumiyyətlə, nə etdiyini başa düşmür. Buradan, saxlanılan XSS hücumlarının "ustalarının" səyləri aydın olur. Sonuncular hücum edilmiş mühərriklər üçün serverdəki filtrin artıq onu tanımadığı və bəzən saytı yoluxdurmağa kömək etdiyi zərərli skripti zədələmək üçün bir üsul seçmək istiqamətində hərəkət edir.

Ən sadə misal. Təcavüzkar içəri girir:

Mesaj şimala göndərilir. Serverdə filtr təhlükəli simvol ardıcıllığını "görür" siçan üzərində və onu kəsir. Nəticədə, heç bir təhlükə yaratmır (brauzerlər tərəfindən tanınmır) oonmouseovernmouseoverçevrilir siçan üzərində, yəni. hadisənin brauzer üçün uyğun göstəricisinə çevrilir. Ümumi halda, saxlanılan XSS hücumları bu şəkildə həyata keçirilir: onlar sayt sahələrinə simvol kombinasiyalarını daxil edir, onları göndərir və çıxışa baxırlar. Sonra filtrin necə işlədiyinə dair fərziyyələr irəli sürür və bunun üçün “döyüş” kombinasiyası yaratmağa başlayırlar.

Serverdə html-i tam tanımaq üçün orada müəyyən bir brauzerin müxtəlif versiyalarının xüsusiyyətlərinə qədər hər şeyi nəzərə alacaq bir html analizatoru lazımdır. Çarpaz deyil, SUPER-brauzer təhlilçisi. Həll tapşırığın özündən daha mürəkkəb ola bilər.

Saxlanılan XSS hücumlarına qarşı brauzerin qorunması

Html analizatorları artıq mövcuddur - brauzerlərdə. Bundan istifadə edərək, saxlanılan XSS hücumlarının (yaxşı, onlardan qorunma) tanınması vəzifəsini brauzerlərin özlərinə keçirtmək cazibədar olur. Sonra serverdə foruma əlavə edilən mesajın Firefox-un aktiv məzmununu görüb-görməyəcəyini, Internet Explorer-in orada aktiv məzmunu görüb-görməyəcəyini və sair proqnozlaşdırmaq lazımsız olur. Brauzerdən soruşmaq daha məntiqlidir: "Firefox, sən burada ssenarini görürsənmi?". Və ya: "Internet Explorer-də bu mesajda aktiv məzmun görürsünüz?" Brauzer - bu xüsusi, bu versiya - skripti aşkar edibsə, onda siz brauzerə aşkarlananı zərərsizləşdirmək üçün göstəriş verə bilərsiniz.

Səhifə yükləndikcə skriptlər brauzer tərəfindən icra olunur. Bir mətn parçası görünməz və ya gizli olsa belə - orada bir skript varsa, skript mütləq işə salınacaq. Skriptlərin icrasını qadağan edən bir növ html konteyneri hələ icad edilməmişdir (əgər belə bir konteyner icad edilsəydi, saxlanılan XSS hücumları məsələsi prinsipcə olmazdı).

Bizə "passiv" yükləmə lazımdır - skriptlərin işləməməsi üçün. Ağlıma gələn tək şey şərhdən istifadə etməkdir ( ). Brauzerlər tərəfindən şərh edilənlər şərh edilmir, göstərilmir, lakin DOM-a (Sənəd Obyekt Modeli) yüklənir və daxil edilir. Beləliklə, sayt səhifəsində bilərəkdən XSS-şübhəli məzmuna malik olsaq da, biz qorxmadan bu səhifəni yalnız təhlükəsizlik baxımından şübhəli olan fraqmentləri şərh etdikdən sonra brauzerlərə verə bilərik.

Yükləmənin sonunda brauzer mətnin bizim tərəfimizdən qeyd olunan hissələrini təhlil etməli, onların təhlükəsizliyini təmin etməli və sonra onları yalnız istifadəçiyə göstərməlidir. Səhifənin yüklənməsinin sonuna uyğun bir hadisə var, buna deyilir yükləmə, konteynerə aiddir bədən. Bu o deməkdir ki, saytımızdakı səhifələrin əsas hissəsi, ən azı istifadəçi tərəfindən əlavə edilmiş məzmunu ehtiva edənlər, yükün sonuna cavab verməlidir:
,
Harada getid("mesaj")- məzmunu təhlil edilməli və zərərsizləşdirilməli olan html konteynerinin identifikatorunu qəbul edən funksiya.

Funksiya: fraqment seçicisi

Internet Explorer-in 6 və ya 7 versiyası, indi - 2014-cü ilin yayında - hələ də istifadə olunur. Runet statistikasına əsaslanaraq, biz 6 və 7 kəşfiyyatçılarının trafikin 1%-də payını qiymətləndirə bilərik. Bəlkə də bunlar ən həssas brauzerlərdir. Düşünürəm ki, mühafizə elə qurulmalıdır ki, altıncı kəşfiyyatçıdan başlayaraq işləsin. Bu, kodda bir qədər kobudluq versin.

Altıncı tədqiqatçı cavab olaraq document.getElementByClassName() obyekt istehsal edir (gözlənildiyi kimi obyektlərin toplusu deyil). Biz ən zəifə uyğunlaşmalıyıq, buna görə də biz Explorer 6-nın istədiyi şəkildə mətn fraqmentlərini alacağıq - bir-bir. Biz hələ də arxalanacağıq id, lakin eyni zamanda eyni ilə bir çox fraqmentlərə icazə verir id bir səhifədə. Bu qaydalara ziddir, lakin bu, cross-brauzer olacaq.

Funksiya getid (id) :

funksiya getid(id) ( var obj; while (document.getElementById(id)) ( obj = document.getElementById(id); obj.removeAttribute("id"); obj.innerHTML = obj.innerHTML.replace("", ""); clearhtml(obj); <[^>]*?script[^>]*?>/gi, ""); obj.innerHTML = obj.innerHTML.replace(/<[^>]*?js:[^>]*?>/gi, ""); } }

Mürəkkəb bir şey yoxdur, lakin hər bir sətir üçün izahatlar var - başlıqlarda (sadəcə üzərinə sürüşdürün).

Funksiya: html təmizləyicisi

DOM metodlarından və xüsusiyyətlərindən istifadə edərək, xüsusən də əldə edə bilərsiniz:
- iç içə html konteynerlər massivi;
- hər bir daxili html konteynerinin adı;
- hər bir html konteynerinin bütün atributlarının adları.
kimi rekordda