SQL inyeksiyası hücumu nədir və onun qarşısını necə almaq olar?

SQL inyeksiyası iyirmi ildən artıqdır ki, məlum və yaxşı sənədləşdirilmiş zəiflikdir və o, hələ də hər il real məlumat sızmalarında üzə çıxır — qarşısını almaq çətin olduğuna görə yox, təsadüfən yol vermək asan olduğuna görə, xüsusən də köhnə kodda və ya sıx müddətlər şəraitində yazılmış kodda.

SQL inyeksiyası əslində nədir

Əksər veb-tətbiqlər verilənləri verilənlər bazasında saxlayır və onları oxumaq və yazmaq üçün SQL adlanan sorğu dilindən istifadə edir. SQL inyeksiyası tətbiq istifadəçinin yazdığı mətni — axtarış sahəsindən, giriş formasından, URL parametrindən — götürüb əvvəlcə ona etibarsız giriş kimi yanaşmadan birbaşa verilənlər bazası sorğusuna daxil etdikdə baş verir. Təcavüzkar adi dəyər əvəzinə SQL koduna bənzəyən bir şey yazsa və tətbiq onu kor-koranə sorğuya daxil etsə, verilənlər bazası təkcə tətbiqin nəzərdə tutduğu əmrləri deyil, təcavüzkarın yazdığı əmrləri də icra edir.

Sadə nümunə

Sadə dillə belə qurulmuş giriş yoxlamasını təsəvvür edin: «istifadəçi adı [istifadəçinin yazdığı nə varsa] və parolu [istifadəçinin yazdığı nə varsa] olan istifadəçini tap». Tətbiq bu sorğunu istifadəçinin daxil etdiyi məlumatı birbaşa SQL mətninə yapışdıraraq qurursa, təcavüzkar istifadəçi adı sahəsinə sorğunun real mənasını dəyişən hiyləgər bir şey yaza bilər — məsələn, şərti paroldan asılı olmayaraq həmişə doğru edə bilər və bu da ona heç bir parol bilmədən istənilən istifadəçi kimi daxil olmağa imkan verir.

Bu, sadə haldır. Daha mürəkkəb SQL inyeksiyası istifadəçinin heç vaxt görməli olmadığı verilənləri — digər istifadəçilərin şəxsi məlumatlarını, ödəniş məlumatlarını, parol heşlərini — oxumaq, ən pis hallarda isə verilənləri birbaşa dəyişdirmək və ya silmək üçün istifadə oluna bilər.

Niyə hələ də bu qədər geniş yayılıb

Test edilənə qədər görünmür. Zəif forma bütün adi istifadəçilər üçün mükəmməl işləyir. Problem yalnız kimsə onu qəsdən zərərli girişlə yoxladıqda üzə çıxır, bu isə adi hazırlıq prosesində nadir hallarda təsadüfən baş verir.
«Yalnız bu dəfə» yazılan kodda gizlənir. Tez yazılmış admin skripti, birdəfəlik hesabat sorğusu, tələsik hazırlanmış funksiya — proqramçıların təhlükəsiz nümunədən istifadə etmək əvəzinə sorğunu sətirləri birbaşa birləşdirərək qurma ehtimalı ən yüksək olan yerlər məhz bunlardır, çünki o an bu, daha sürətli görünür.
Köhnə koda yenidən baxılmır. İllər əvvəl kod bazasının nadir hallarda toxunulan hissəsinə daxil edilmiş nümunə kimsə nəhayət axtarmağa başlayana qədər orada səssizcə qala bilər.

Qarşısını əslində necə almaq olar

Həll yolu qeyri-müəyyən prinsip kimi «istifadəçi girişini təmizləyin» deyil — ardıcıl tətbiq edildikdə problemi faktiki olaraq aradan qaldıran konkret, yaxşı sınaqdan keçmiş texnikadır.

Həmişə parametrləşdirilmiş sorğulardan (prepared statements) istifadə edin. Sorğunu sətirləri bir-birinə yapışdıraraq qurmaq əvəzinə, onu yer tutucularla yazır və istifadəçinin dəyərlərini ayrıca ötürürsünüz. Bu zaman verilənlər bazası həmin dəyərlərə, hansı simvolları ehtiva etməsindən asılı olmayaraq, ciddi şəkildə verilən kimi yanaşır, heç vaxt əmrin bir hissəsi kimi yox. Demək olar ki, hər müasir verilənlər bazası kitabxanası bunu dəstəkləyir və bu, kiminsə yadına düşəndə tətbiq edilən istisna deyil, standart olmalıdır.
ORM və ya sorğu qurucusundan istifadə edin — həm də düzgün istifadə edin. Laravel-dəki Eloquent kimi alətlər daxildə standart olaraq parametrləşdirilmiş sorğular qurur. Risk məhz proqramçı alətin asanlıqla dəstəkləmədiyi bir şeyi etmək üçün xam sorğu sətrinə keçdikdə yenidən yaranır — dayanıb iki dəfə yoxlamaq lazım olan yer də məhz budur.
Verilənlər bazası hesablarına minimal imtiyazlar prinsipini tətbiq edin. Tətbiqinizin qoşulduğu verilənlər bazası istifadəçisinin yalnız həqiqətən lazım olan icazələri olmalıdır. Sorğu hər hansı yolla istismar edilsə, bu, təcavüzkarın onunla əslində nə edə biləcəyini məhdudlaşdırır.
Giriş tiplərinin yoxlanmasını əsas müdafiə kimi deyil, ikinci qat kimi tətbiq edin. Sahə ədəd olmalıdırsa, sorğuya çatmazdan əvvəl onun həqiqətən ədəd olmasını təmin edin. Bu, təkbaşına hər şeyi tutmayacaq, amma mümkün hücumların dairəsini daraldır və aşkar səhvləri erkən aşkarlayır.

Bunun üçün niyə təkcə yaxşı vərdişlər deyil, real audit lazımdır

SQL inyeksiyasında ən məyusedici məqam budur ki, kod bazası 999 yerdə tamamilə təmiz görünə bilər və nadir hallarda toxunulan bir admin alətindəki bir xam sorğu bütün bunları heçə endirə bilər. Avtomatik skanerlər bunun bir qismini aşkarlayır, lakin həqiqətən vacib halları tapan şey sorğuların əslində necə qurulduğunun — təkcə ORM-in mövcud olub-olmamasının yox — həqiqi, diqqətli əl ilə yoxlanılmasıdır.

Bu cür əl ilə aparılan tətbiq təhlükəsizliyi auditi — sadəcə skaner işə salıb işi bitmiş saymaq deyil, sorğularınızın və giriş nəzarəti məntiqinizin əslində necə işlədiyini həqiqətən oxumaq — infrastrukturun möhkəmləndirilməsi və komandaların real uyğunluq auditinə hazırlanması ilə yanaşı, Burncode-un təhlükəsizlik üzrə işinin əsasını təşkil edir.