Application security

Infrastructure-u mütəxəssislər harden edə bilər. Application kodunu isə hər developer, hər gün yazır, və hər sətir potensial vulnerability-dir. Buna görə də application security komanda deyil; o, hər mühəndisin tətbiq etdiyi, insanların qaçırdıqlarını tutan tooling ilə dəstəklənən praktikalar toplusudur.

Təkrarlanan vulnerability-lər

Eyni bug sinifləri ildən-ilə ortaya çıxır. Onları formasını tanıyacaq qədər yaxşı öyrənin.

Injection

Untrusted input downstream sistem tərəfindən kod kimi şərh edilir. SQL injection kanonik nümunədir; eyni pattern shell əmrlərində, LDAP query-lərində, XML-də, template-lərdə və indi də dil modellərinə göndərilən prompt-larda görünür.

-- vulnerable: input query-yə concatenate olunur
"SELECT * FROM users WHERE name = '" + name + "'"

-- safe: parameterised query, input həmişə data-dır, heç vaxt kod deyil
"SELECT * FROM users WHERE name = ?", [name]

Həll həmişə eynidir: bunun üçün nəzərdə tutulmuş interface-dən istifadə edərək data-nı və kodu ayrı saxlayın (parameterised query-lər, shell string-ləri əvəzinə argument array-ləri, template auto-escaping). Validation və sanitisation ikinci dərəcəli müdafiədir, əsas deyil.

Az diqqət çəkən formalar da var:

• NoSQL injection: JSON body-də string əvəzinə {"$ne": null} kimi operator obyekti göndərilir və query-nin məntiqi dəyişir. Input-un tipini yoxlayın, yalnız formasını yox.
• ORM və query builder-lər: ümumiyyətlə təhlükəsizdir, amma raw query, dinamik sıralama sütunu və ya string-dən qurulan filter yenə injection yeridir.
• Log injection: input-dakı yeni sətir simvolları saxta log qeydləri yaradır və ya log viewer-də icra olunur. Log-a yazmazdan əvvəl control simvollarını encode edin, structured logging-dən istifadə edin.

Prompt-lar xüsusi haldır: dil modeli instruction ilə data-nı ayırmır, ona görə də bu fəsildəki ayırma prinsipi orada tam işləmir. Bu Fəsil 9-un mövzusudur.

Cross-site scripting (XSS)

Untrusted input veb səhifəyə HTML və ya script kimi render olunur və digər istifadəçilərin browser-lərində icra olunur. Müasir framework-lər default olaraq escape edir; vulnerability kimsə bundan imtina edəndə (dangerouslySetInnerHTML, v-html, innerHTML), HTML-i string-lərdən quranda və ya istifadəçi məzmununu framework-ün əhatə etmədiyi attribute və ya URL kontekstində render edəndə yenidən ortaya çıxır.

Müdafiə tədbirləri: kontekstə uyğun output encoding, sərt Content Security Policy və hər raw-HTML render-ini security review üçün səbəb kimi qəbul etmək.

Broken access control

Fəsil 3-də əhatə olunub. Object-level check-lərin olmaması, function-level check-lərin olmaması, parametr manipulyasiyası ilə privilege escalation. Real assessment-lərdə ən çox rast gəlinən kritik tapıntı.

Insecure deserialisation və unsafe parsing

Untrusted data-nın kod icra edə bilən və ya məhdudiyyətsiz memory ayıra bilən parser ilə parse edilməsi. Untrusted input üçün native serialisation format-larından (Java serialisation, Python pickle) qaçın; schema validation ilə JSON istifadə edin; size limit-ləri təyin edin.

Server-side request forgery (SSRF)

Application istifadəçinin verdiyi URL-i fetch edir, attacker isə onu daxili service-lərə və ya cloud metadata endpoint-lərinə yönəldir. Destination-lar üçün allowlist tətbiq edin, private address range-lərini bloklayın və istifadəçinin verdiyi URL-ləri heç vaxt privileged şəbəkə mövqeyindən fetch etməyin.

Unsafe file handling

Upload və download funksiyaları bir neçə bug sinfini birləşdirir:

• Path traversal: ../../etc/passwd kimi fayl adı application-ı nəzərdə tutulmamış qovluqdan oxumağa və ya ora yazmağa məcbur edir. İstifadəçinin verdiyi adı heç vaxt path kimi istifadə etməyin; faylı öz yaratdığınız ID ilə saxlayın, orijinal adı isə yalnız metadata kimi.
• Content type-a etibar: extension və Content-Type header-i attacker-in nəzarətindədir. Faylın faktiki formatını məzmunundan yoxlayın və icazə verilən format-ların allowlist-i ilə müqayisə edin.
• İcra olunan upload-lar: web root-a yazılmış script fayl server tərəfindən icra oluna bilər. Upload-ları application-dan ayrı storage-da, icra icazəsi olmadan saxlayın və ayrı domain-dən serve edin ki, HTML və ya SVG faylı əsas saytın origin-ində script icra etməsin.
• Parser-lər və arxivlər: image, PDF və office parser-ləri tez-tez vulnerability mənbəyidir. Zip faylının açılması həm path traversal-a (zip slip), həm də yaddaşı dolduran "zip bomb"-a yol açır. Parse-ı sandbox-da aparın, ölçü və fayl sayı limitləri qoyun, mümkünsə malware scan edin.

Software və data integrity failures

Application yoxlamadan etibar etdiyi kodu və ya data-nı qəbul edir: signature-siz yüklənən update-lər, CI pipeline-a imzasız artifact-in daxil olması, üçüncü tərəf CDN-dən integrity hash-i olmadan yüklənən script, client-dən gələn və server tərəfindən yoxlanmayan "qiymət" və ya "role" sahəsi. Ümumi qayda: trust boundary-ni keçən hər kod və hər kritik data ya kriptoqrafik olaraq verify olunur, ya da server tərəfində yenidən hesablanır. Script-lər üçün Subresource Integrity, artifact-lər üçün signing, cookie və ya token-dəki data üçün MAC və ya signature istifadə edin (Fəsil 6).

Insecure design

Bəzi vulnerability-lər koddakı səhv deyil, design-da çatışmayan control-dur. Kod tam düzgün yazıla bilər, amma password reset link-i expire olmursa, endirim kodu limitsiz istifadə olunursa və ya bir müştəri yüz minlərlə sifarişi avtomatlaşdırıb stoku bloklaya bilirsə, problem implementation-da deyil. Bunlar code review və scanner-lərlə tapılmır. Onları threat modelling (Fəsil 2) və hər feature üçün yazılan abuse case-lər tapır. Security tələbləri mümkün qədər erkən, design mərhələsində müəyyən edilməlidir. Buna "shift left" deyilir.

Security misconfiguration

Default credential-lar, production-da debug mode, həddindən artıq ətraflı error səhifələri, açıq cloud storage, həddindən artıq icazəli CORS. Kod bug-ı deyil, lakin kodla birlikdə ship olunur. Konfiqurasiya version control-da və review altında olmalıdır.

Vulnerable dependency-lər

Application-ınız əsasən başqalarının kodundan ibarətdir. Məlum vulnerability-si olan tək bir köhnəlmiş library birbaşa giriş yoludur. Dependency scanning-i avtomatlaşdırın, cədvəl üzrə patch edin və kritik advisory-lər üçün sürətli yol hazırlayın.

Secure design pattern-ləri

• Boundary-də, allowlist ilə validate edin. Düzgün input-un necə göründüyünü müəyyən edin (tip, uzunluq, format, range) və qalan hər şeyi rədd edin. Pis pattern-lərin denylist-ləri həmişə nəyisə qaçırır.
• Output-da, kontekstə uyğun encode edin. HTML üçün HTML encoding, URL-lər üçün URL encoding və s. Input zamanı encoding data-nı pozur və yenə də kontekstləri qaçırır.
• Security-critical məntiqi mərkəzləşdirin. Bir authentication modulu, bir authorization funksiyası, secrets manager ilə danışan bir yer. Review edilə bilən və bypass edilməsi çətin.
• Platform-un cryptography-sindən istifadə edin. Özünüzünkünü yazmayın. Safe default-ları olan high-level library-lərdən (libsodium, dilin standart vetted library-si) istifadə edin. Hansı alqoritmlərin deprecated olduğunu bilin. Fəsil 6 bunu ətraflı izah edir.
• Error-ları leak etmədən handle edin. Təfərrüatları daxildə log edin; istifadəçiyə ümumi mesaj və correlation ID göstərin.
• Hər şeyi məhdudlaşdırın. Request size, upload size, rate, query mürəkkəbliyi, recursion depth, timeout-lar.

Secure development lifecycle

Software-in qurulması mərhələlərinə uyğunlaşdırılmış security praktikaları:

Tool-lar məlum pattern-ləri tutur. Onlar logic flaw-larını, authorization boşluqlarını və ya design səhvlərini tutmur. Bunlar üçün nə axtaracağını bilən insanlar lazımdır, buna görə də design və review mərhələləri ən vacibdir.

Secrets

Source repository-lərdə ən çox rast gəlinən kritik tapıntı commit edilmiş secret-dir. Qaydalar:

• Secret-lər heç vaxt source koda, repository-dəki config fayllarına, container image-lərinə və ya log-lara yazılmır.
• Hər commit-i secret pattern-ləri üçün scan edin və push-u bloklayın.
• Secret leak olanda ona dərhal compromise olunmuş kimi yanaşın. Əvvəl rotate edin, sonra araşdırın. Onu git history-dən silmək leak-i geri qaytarmır.

Supply chain

Attacker-lər getdikcə daha çox qurduğunuzu deyil, asılı olduğunuzu hədəfləyir: compromise olunmuş package-lər, zərərli build plugin-ləri, typosquatting ilə bənzədilmiş library adları, zəhərlənmiş CI action-ları.

• Dependency versiyalarını pin edin və checksum-ları verify edin.
• Lockfile-lardan istifadə edin və onlardakı dəyişiklikləri review edin.
• Aktiv maintain olunan və az transitive dependency-si olan dependency-lərə üstünlük verin.
• CI-nin çata bildiklərini məhdudlaşdırın; CI runner-ləri privileged mövqedir.
• Qurduğunuzu sign edin və deploy etdiyinizi verify edin.

Developer-lərin öz üzərinə götürə biləcəyi security testing

• Security xassələri üçün unit test-lər. "/admin-ə unauthenticated request 401 qaytarır." "10 KB-dan böyük input rədd edilir." Bunlar ucuz və daimidir.
• Use case-lərin yanında abuse case-lər. Hər feature story-si üçün attacker-in nöqteyi-nəzərindən bir story yazın.
• Parser-ləri fuzz edin. Kənardan format oxuyan hər şeyə crash etməyi dayandırana qədər random və malformed input verilir.
• Öz diff-lərinizi attacker kimi review edin. Review tələb etməzdən əvvəl dəyişikliyi "bundan necə abuse edərdim?" sualı ilə oxuyun.

Tapşırıqlar

1. Codebase-inizdə raw SQL string concatenation-u və raw HTML rendering-i axtarın. Tapıntıları sayın.
2. Bir API endpoint-i seçin. Abuse case-i yazın. Sonra abuse-un uğursuz olduğunu sübut edən test-i yazın.
3. Dependency scan işə salın. Neçə məlum vulnerability var və ən köhnəsi nə qədər köhnədir?
4. File upload funksiyasını tapın. Fayl adı path-ə daxil olurmu? Upload olunmuş HTML faylı əsas saytın domain-indən açıla bilərmi?