Proqramlaşdırmada hardkod: bu nədir, səbəbləri və ondan necə qaçınmaq olar

Proqramlaşdırmada hardkod nədir

Hardkod (hardcode, hard coding) — məlumatların, parametrlərin və ya konfiqurasiya dəyərlərinin birbaşa proqram mətninə daxil edildiyi anti-nümunədir. Tərtibatçı bu məlumatları xarici mənbələrdən oxumaq əvəzinə, onları literal olaraq — sətirlər, rəqəmlər, boolean dəyərlər — birbaşa funksiyanın, sinfin və ya modulun gövdəsində yazır. Termin 1980-ci illərdə tərtibatçı icmasında yaranmışdır, o zaman proqram təminatı müxtəlif aparat platformalarına yayılmağa başlamış və sərt kodlanmış parametrlərin daşınmaya mane olduğu aydın olmuşdur.

Hardkodun əsas problemi ondan ibarətdir ki, hər hansı belə dəyərin dəyişdirilməsi mənbə kodunda düzəliş, yenidən kompilə etmə və tətbiqin yenidən yerləşdirilməsini tələb edir. Bu, yeniləmə prosesini yavaş, səhvlərə meyilli və təhlükəli edir — tərtibatçı sərt kodlanmış parametri redaktə edərkən təsadüfən koddə başqa bir şeyi də dəyişə bilər. Müasir DevOps təcrübələrində bu yanaşma qətiyyən tövsiyə edilmir.

Veracode State of Software Security 2024 araşdırmasına görə, kommersiya tətbiqlərindəki bütün zəifliklərin təxminən 23%-i sərt kodlanmış etimadnamə məlumatlarının istifadəsi ilə bağlıdır. Bu, hardkodla mübarizəni təkcə rahatlıq məsələsi deyil, həm də informasiya təhlükəsizliyinin kritik vəzifəsi edir.

Hardkodun sadə sözlərlə tərifi

Sərt kodlanmış dəyər — konfiqurasiyadan yüklənməyən, birbaşa koddə yazılmış hər hansı rəqəm, sətir və ya parametrdir. Məsələn, tərtibatçı verilənlər bazasına qoşulma sinfi daxilində `connectionTimeout = 30` yazırsa — bu hardkoddur. Əgər o, vaxt aşımını mühit dəyişənindən və ya konfiqurasiya faylından oxuyursa — bu düzgün yanaşmadır.

Terminin mənşəyi

Hardkod sözü ingilis dilindəki hard code — „sərt kod“ ifadəsindən yaranmışdır. Çevik konfiqurasiyalardan fərqli olaraq, hardkod sözün əsl mənasında icra olunan fayla „tikilir“ və yenidən yığılmadan dəyişdirilə bilməz.

Hardkod niyə zərərli təcrübə sayılır

Hardkod uzunmüddətli perspektivdə çoxsaylı problemlər yaradır. Birinci və ən aşkarı — mənbə kodunu dəyişmədən tətbiqin davranışını dəyişmək mümkünsüzlüyü. İkincisi — məxfi məlumatların sızması riski. Üçüncüsü — test etmənin, xüsusilə də vahid və inteqrasiya testlərinin çətinləşməsi.

Agile və DevOps-da müxtəlif mühitlərdə — development, staging, production — sürətli yerləşdirmə tələb olunduqda, hardkod keçilməz maneəyə çevrilir. Komanda hər yerləşdirmədən əvvəl kodu düzəltməyə və ya əl ilə yamaqlar tətbiq etməyə məcbur olur, bu da Continuous Delivery prinsiplərinə ziddir.

Cambridge University (2023) araşdırması göstərmişdir ki, yüksək hardkod səviyyəsi olan layihələrdə buraxılış zamanı 47% daha çox qüsur olur və dəyişikliklərin edilməsi üçün 2,3 dəfə çox vaxt tələb olunur. Bu, sərt kodlanmış kodun saxlanması xərclərinin inkişafın ilkin mərhələsində vaxta qənaətdən əhəmiyyətli dərəcədə çox olduğunu təsdiqləyir.

Ölçeklenebilirlik və daşınma qabiliyyəti

Tətbiq sərt kodlanmış parametrlərlə müxtəlif platformalara uyğunlaşdırılması çətindir. Məsələn, `C:\Users\admin\data.txt` fayl yolu Linux serverində işləməyəcək. 14pt şrift ölçüsü isə müxtəlif piksel sıxlığı olan cihazlarda fərqli görünə bilər.

Kodun saxlanma qabiliyyəti

Hardkod bütün layihəyə yayıldıqda, tərtibatçı hər bir dəyəri əl ilə axtarmalı olur — grep və ya IDE axtarışından istifadə edərək. Bu, inkişafı yavaşladır, lazımi dəyəri qaçırma ehtimalını artırır və səhvlərə yol açır. Üstəlik, komandanın yeni üzvü „sehrli rəqəmləri“ və sətirləri başa düşmək üçün əhəmiyyətli dərəcədə daha çox vaxt sərf edir.

Hansı dəyərlər daha çox hardkodlanır

Parollar və etimadnamə məlumatları — hardkodun ən təhlükəli növüdür. Tərtibatçılar tez-tez verilənlər bazası parollarını, üçüncü tərəf xidmətlərinin API açarlarını, avtorizasiya tokenlərini lokal inkişaf rahatlığı üçün birbaşa koddə saxlayır, lakin commitdən əvvəl onları konfiqurasiyaya çıxarmağı unudurlar. Bu, ictimai depozitarlarda sızmalara səbəb olur.

URL ünvanları və xarici xidmətlərin endpointləri də tez-tez hardkodun qurbanı olur. Hostinq və ya API versiyası dəyişdikdə, tərtibatçı URL-i onlarla yerdə yeniləməlidir. Ünvan bir neçə modulda sərt kodlanmışdırsa, keçidlərin bir hissəsi köhnə qalır və tətbiq düzgün işləmir.

Sehrli rəqəmlər — izahatsız rəqəm sabitləri. Məsələn, `price * DISCOUNT_RATE` əvəzinə `price * 0.85`. Kodun oxucusu 0.85-in nə demək olduğunu başa düşmür. Bu, Martin Faulerin „Refaktorinq“ (1999) kitabında təsvir edilmiş klassik hardkod nümunəsidir.

Sehrli sətirlər

Sətir literalları proqramın müxtəlif hissələrində təkrarlanan — hardkodun daha bir geniş yayılmış növüdür. Məsələn, lüğət açarları, HTTP başlıqları, iOS tətbiqində görünüş adları. Sətir bir yerdə dəyişərsə, ancaq başqa yerdə qalarsa, tətbiq sıradan çıxar. Həll — sətirləri sabitlərə və ya lokallaşdırma fayllarına çıxarmaqdır.

Mühit konfiqurasiyası

Tətbiqin iş rejimləri (debug/release), loglama parametrləri, SMTP server ünvanları — bütün bu parametrlər xarici olmalıdır. Əgər onlar sərt kodlanıbsa, başqa serverə köçürərkən tətbiq işə düşməyə və ya gözlənilməz davrana bilər.

Hardkodun istifadəsində təhlükəsizlik riskləri

Sərt kodlanmış parollar və açarlar tətbiqin təhlükəsizliyinə birbaşa təhlükə yaradır. Təcavüzkar mənbə koduna giriş əldə edərsə (depozitar sızması, insider və ya dekompilasiya yolu ilə), o, dərhal bütün qorunan resurslara giriş əldə edir. 2023-cü ildə GitHub ictimai depozitarlarda 12 milyondan çox sirr sızması aşkar etmişdir.

OWASP (Open Web Application Security Project) standartı etimadnamə məlumatlarının hardkodunu A04:2021 — Insecure Design kateqoriyasına daxil edir. OWASP tövsiyəsi — parolları, tokenləri və ya açarları heç vaxt mənbə kodunda saxlamamaqdır. Bunun əvəzinə ixtisaslaşdırılmış sirr idarəetmə xidmətlərindən istifadə edin: HashiCorp Vault, AWS Secrets Manager və ya Azure Key Vault.

Positive Technologies (2024) tərəfindən aparılan təhlükəsizlik auditi göstərmişdir ki, sınaqdan keçirilmiş mobil tətbiqlərin 78%-i ən azı bir sərt kodlanmış açar və ya token ehtiva edir. Veb tətbiqlərdə bu göstərici 62% təşkil edir. Zəifliklərin əksəriyyəti məlumatların konfiqurasiya fayllarına sadə çıxarılması ilə aradan qaldırıla bilər.

# sərt kodlanmış sirlər — təhlükəsiz deyil
password = "supersecret123"
api_key = "sk-abc123def456"

# təhlükəsiz yanaşma — mühit dəyişənlərindən oxu
import os
password = os.getenv("DB_PASSWORD")
api_key = os.getenv("API_KEY")

Versiyaya nəzarət sistemi vasitəsilə sızmalar

Git bütün commit tarixçəsini saxlayır. Sərt kodlanmış parol depozitara düşərsə, o, cari versiyadan silindikdən sonra belə tarixçədə qalır. git-secrets və truffleHog kimi alətlər belə sızmaları aşkar etməyə kömək edir, lakin onların kod icmalı mərhələsində qarşısını almaq daha yaxşıdır.

Tənzimləyici tələblər

PCI DSS, GDPR və HIPAA standartları məxfi məlumatların mənbə kodunda saxlanmasını birbaşa qadağan edir. Hardkodun istifadəsi hüquqi nəticələrə və cərimələrə, xüsusilə maliyyə və tibb sektorlarında səbəb ola bilər.

Layihələrdə hardkoddan necə qaçınmaq olar

Birinci addım — komanda səviyyəsində problemin dərk edilməsi. Kod icmalı sərt yazılmış dəyərlərin yoxlanılmasını əhatə etməlidir. Potensial hardkodu vurğulayacaq linter və ya statik analizator quraşdırın. TypeScript üçün ESLint no-hardcoded-credentials qaydası ilə, Python üçün Bandit uyğundur.

İkinci addım — Configuration as Code nümunəsinin tətbiqi. Müxtəlif mühitlərdə fərqlənə bilən bütün parametrlər mühit dəyişənlərində və ya konfiqurasiya fayllarında saxlanmalıdır. dotenv (Node.js), python-decouple (Python) və ya Spring Cloud Config (Java) kimi kitabxanalar bu yanaşmanı standart edir.

Üçüncü addım — konfiqurasiya idarəetmə xidmətlərindən istifadə: Consul, etcd, Zookeeper. Bulud layihələri üçün AWS Parameter Store, Google Cloud Secret Manager və ya Azure App Configuration uyğundur. Mikroxidmət arxitekturasında mərkəzləşdirilmiş konfiqurasiya idarəetməsi kritik əhəmiyyət kəsb edir.

• Mühit dəyişənləri — sirlər və həssas məlumatlar üçün
• .env faylları — lokal inkişaf üçün
• Konfiqurasiya sinifləri — xarici mənbələrdən oxuma ilə
• Feature Toggles — funksionallığı yandırmaq/söndürmək üçün
• Beynəlmiləlləşdirmə — sətir resursları üçün

Ən yaxşı təcrübələr

Hər bir konfiqurasiya parametrini sənədləşdirin: onun təyinatı, icazə verilən dəyərlər, defolt dəyər. Konfiqurasiya üçün schema validation istifadə edin — bu, tətbiqin başlanğıcında səhvləri tutmağa imkan verir. Bütün lazımi dəyişənlərlə .env.example faylı yaradın, ancaq real dəyərlər olmadan.

Hardkodun refaktorinq nümunələri

JavaScript-də konkret nümunəni nəzərdən keçirək. Refaktorinqdən əvvəl kod sərt kodlanmış URL və vaxt aşımı ehtiva edir. Refaktorinqdən sonra bütün parametrlər konfiqurasiyaya çıxarılıb. Bu, kodu test edilə bilən, çevik və təhlükəsiz edir.

// refaktorinqdən əvvəl — sərt kodlanmış dəyərlər
const response = await fetch("https://api.example.com/v1/users", {
  timeout: 5000,
  headers: { "Authorization": "Bearer sk-abc" }
});

// refaktorinqdən sonra — konfiqurasiya ilə idarə olunan
const config = {
  apiUrl: process.env.API_URL,
  timeout: parseInt(process.env.API_TIMEOUT || "30000"),
  authToken: process.env.AUTH_TOKEN
};

const response = await fetch(config.apiUrl, {
  timeout: config.timeout,
  headers: { "Authorization": "Bearer " + config.authToken }
});

Java-da refaktorinq

Java-da hardkod tez-tez verilənlər bazası qoşulma sətirləri şəklində rast gəlinir. Spring Boot-un application.yml ilə istifadəsi bu problemi həll edir: fayl müxtəlif mühitlər üçün profillər ehtiva edir, kod isə @Value anotasiyası vasitəsilə dəyərləri oxuyur.

// sərt kodlanmış — Java nümunəsi
class DatabaseConnection {
    private String url = "jdbc:mysql://localhost:3306/mydb";
    private String user = "admin";
    private String password = "pass123";
}

// Spring Boot vasitəsilə düzgün konfiqurasiya
@Value("${db.url}")
private String url;

Müxtəlif proqramlaşdırma dillərində hardkod

Hardkodla mübarizə yanaşmaları dildən və ekosistemdən asılıdır. İnterpretə olunan dillərdə (Python, JavaScript, Ruby) konfiqurasiya adətən mühit dəyişənlərində və ya .env fayllarında saxlanılır. Kompilə olunan dillərdə (Java, C#, Go) — YAML, JSON, XML konfiqurasiya fayllarında və ya daxili resurslarda.

Python-da python-decouple kitabxanası populyardır, o, .env faylından konfiqurasiyanı oxuyur və tipləşdirilmiş getterlər təqdim edir. Go-da Viper istifadə olunur — müxtəlif mənbələrdən konfiqurasiyalarla işləmək üçün güclü kitabxana. Swift-də iOS inkişafı üçün konfiqurasiyalar Info.plist və ya ayrıca Configuration fayllarına çıxarılır.

Statik analiz alətləri, SonarQube, ESLint, Pylint kimi, sərt kodlanmış dəyərləri avtomatik aşkar edə bilər. SonarQube müxtəlif dillərdə koddə sehrli rəqəmləri və sətirləri axtarmaq üçün hazır qaydalara malikdir. CI/CD pipeline-da belə yoxlamaların quraşdırılması yeni hardkodun yaranmasının qarşısını almağın ən yaxşı yoludur.

Hardkod yoxlamasının avtomatlaşdırılması

Pre-commit git-hookları sərt kodlanmış sirlərin olması üçün commiti yoxlayan skriptləri işə sala bilər. git-secrets aləti parollar, açarlar və tokenlər üçün müntəzəm ifadələrlə uyğunluqlar üçün commitləri skan edir. TruffleHog və Gitleaks daha da irəli gedir — onlar sızmalar üçün git tarixçəsini yoxlayır.