Bir geli\u015ftirici olarak, kod yazd\u0131\u011f\u0131n\u0131zda her zaman en iyisini, en performansl\u0131s\u0131n\u0131 ve en g\u00fcvenlisini hedeflersiniz. Ancak teori ile pratik her zaman \u00f6rt\u00fc\u015fmez. Peki ya kendi ellerinizle in\u015fa etti\u011finiz bir g\u00fcvenlik uygulamas\u0131n\u0131, yine kendi ellerinizle k\u0131rmaya \u00e7al\u0131\u015fsan\u0131z ne olur? \u0130\u015fte bu makale, tam da bu sorunun pe\u015finden giden, bir geli\u015ftiricinin kendi koduna kar\u015f\u0131 verdi\u011fi m\u00fccadeleyi ve bu s\u00fcre\u00e7te edindi\u011fi paha bi\u00e7ilmez dersleri konu al\u0131yor. Bu deneyim, sadece zafiyetleri ortaya \u00e7\u0131karmakla kalmad\u0131, ayn\u0131 zamanda g\u00fcvenli yaz\u0131l\u0131m geli\u015ftirme konusundaki bak\u0131\u015f a\u00e7\u0131m\u0131 da k\u00f6kten de\u011fi\u015ftirdi.<\/p>\n
Yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131nda, i\u015flevsellik ve performans \u00e7o\u011fu zaman \u00f6ncelikli kabul edilirken, g\u00fcvenlik genellikle sonradan akla gelen bir detay olabiliyor. Ancak g\u00fcn\u00fcm\u00fcz\u00fcn siber tehditlerle dolu ortam\u0131nda, bu yakla\u015f\u0131m b\u00fcy\u00fck riskler bar\u0131nd\u0131r\u0131yor. Kendi g\u00fcvenlik uygulamam\u0131 geli\u015ftirme fikri de tam olarak bu noktadan do\u011fdu: G\u00fcvenli\u011fin bir \u00f6zellik de\u011fil, bir zorunluluk oldu\u011funu kan\u0131tlamak ve bu s\u00fcreci bizzat deneyimlemek istedim.<\/p>\n
Motivasyonum olduk\u00e7a basitti: \u00d6\u011frenmek ve meydan okumak. Piyasadaki mevcut g\u00fcvenlik \u00e7\u00f6z\u00fcmleri harika olsa da, bir \u015feyin nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 tam olarak anlaman\u0131n en iyi yolu, onu kendiniz in\u015fa etmektir. Bir yandan modern web teknolojilerini kullanarak bir uygulama geli\u015ftirecek, di\u011fer yandan da bu uygulaman\u0131n potansiyel g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 tespit edip kapatmaya \u00e7al\u0131\u015facakt\u0131m. Bu s\u00fcre\u00e7, hem bir yaz\u0131l\u0131mc\u0131 olarak yeteneklerimi s\u0131nayacak hem de bir “etik hacker” (beyaz \u015fapkal\u0131 hacker) gibi d\u00fc\u015f\u00fcnme becerimi geli\u015ftirecekti. Hedefim, kullan\u0131c\u0131 verilerini koruyan, yetkisiz eri\u015fimi engelleyen ve potansiyel sald\u0131r\u0131lara kar\u015f\u0131 diren\u00e7li bir sistem olu\u015fturmakt\u0131. Bu ki\u015fisel proje, teorik bilgileri prati\u011fe d\u00f6kme ve ger\u00e7ek d\u00fcnya senaryolar\u0131nda g\u00fcvenlik zafiyetlerinin nas\u0131l ortaya \u00e7\u0131kt\u0131\u011f\u0131n\u0131 anlama f\u0131rsat\u0131 sundu.<\/p>\n
Geli\u015ftirdi\u011fim uygulama, temel olarak hassas verilerin g\u00fcvenli bir \u015fekilde depolanmas\u0131n\u0131 ve y\u00f6netilmesini sa\u011flayan bir platformdu. Kullan\u0131c\u0131lar\u0131n g\u00fcvenli notlar olu\u015fturabilece\u011fi, dosyalar\u0131n\u0131 \u015fifreleyerek saklayabilece\u011fi ve yetkilendirilmi\u015f ki\u015filerle payla\u015fabilece\u011fi bir “ki\u015fisel kasa” gibi d\u00fc\u015f\u00fcnebilirsiniz. Bu t\u00fcr bir uygulamada g\u00fcvenlik, i\u015flevselli\u011fin ta kendisi haline gelir. E\u011fer uygulama yeterince g\u00fcvenli de\u011filse, varl\u0131k amac\u0131 ortadan kalkar. G\u00fcvenli\u011fin \u00f6nceli\u011fi, “CIA \u00fc\u00e7l\u00fcs\u00fc” (Confidentiality, Integrity, Availability – Gizlilik, B\u00fct\u00fcnl\u00fck, Eri\u015filebilirlik) prensipleriyle a\u00e7\u0131klanabilir. Uygulamam, kullan\u0131c\u0131 verilerinin gizlili\u011fini (yetkisiz ki\u015filerin eri\u015fememesi), b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc (verilerin de\u011fi\u015ftirilememesi) ve eri\u015filebilirli\u011fini (yetkili ki\u015filerin verilere her zaman ula\u015fabilmesi) sa\u011flamak zorundayd\u0131. Bu, sadece teknik bir gereklilik de\u011fil, ayn\u0131 zamanda kullan\u0131c\u0131lara kar\u015f\u0131 bir sorumluluktu.<\/p>\n
Uygulamay\u0131 geli\u015ftirirken, “Secure by Design” (tasar\u0131mla g\u00fcvenlik) prensibini benimsedim. G\u00fcvenlik, geli\u015ftirme ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fcn her a\u015famas\u0131nda, yani mimari tasar\u0131mdan kodlama ve test etmeye kadar s\u00fcrekli bir d\u00fc\u015f\u00fcnce oda\u011f\u0131 oldu. Bir Python tabanl\u0131 web framework’\u00fc (\u00e7er\u00e7evesi) olan Flask’\u0131 tercih ettim, \u00e7\u00fcnk\u00fc esnekli\u011fi ve kontrol\u00fc sayesinde g\u00fcvenlik katmanlar\u0131n\u0131 manuel olarak entegre etme imkan\u0131 sunuyordu. Kimlik do\u011frulama (authentication) i\u00e7in sa\u011flam bir parola hashleme algoritmas\u0131 (\u00f6rne\u011fin, bcrypt) kulland\u0131m ve oturum y\u00f6netimi i\u00e7in g\u00fcvenli \u00e7erezler (cookie) ve JWT (JSON Web Tokens) kombinasyonunu tercih ettim. Yetkilendirme (authorization) mekanizmalar\u0131n\u0131 ise her API endpoint’i (u\u00e7 nokta) i\u00e7in ayr\u0131 ayr\u0131 tan\u0131mlad\u0131m. Veri \u015fifreleme i\u00e7in AES-256 gibi g\u00fc\u00e7l\u00fc algoritmalar\u0131 kulland\u0131m ve hassas verileri veritaban\u0131nda asla d\u00fcz metin olarak saklamad\u0131m. \u00d6rne\u011fin, kullan\u0131c\u0131 \u015fifrelerini veritaban\u0131na kaydetmeden \u00f6nce tuzlama (salting) ve hashleme i\u015flemlerinden ge\u00e7irdim. A\u015fa\u011f\u0131daki pseudokod (s\u00f6zde kod) \u00f6rne\u011fi, bu yakla\u015f\u0131m\u0131 basit\u00e7e g\u00f6stermektedir:<\/p>\n
\/\/ Pseudokod: Kullan\u0131c\u0131 \u015fifresini g\u00fcvenli bir \u015fekilde hashleme ve kaydetme\n function registerUser(username, password) {\n const salt = generateRandomSalt(); \/\/ Her kullan\u0131c\u0131 i\u00e7in benzersiz tuz\n const hashedPassword = hashPasswordWithBcrypt(password, salt); \/\/ G\u00fc\u00e7l\u00fc hashleme\n saveUserToDatabase(username, hashedPassword, salt); \/\/ Hash ve tuzu kaydet\n }\n\n \/\/ Pseudokod: Kullan\u0131c\u0131 giri\u015fini do\u011frulama\n function loginUser(username, password) {\n const user = getUserFromDatabase(username);\n if (user && verifyPasswordWithBcrypt(password, user.hashedPassword, user.salt)) {\n return true; \/\/ Giri\u015f ba\u015far\u0131l\u0131\n }\n return false; \/\/ Giri\u015f ba\u015far\u0131s\u0131z\n }<\/code><\/pre>\n<\/p><\/div>\nBu ad\u0131mlar, uygulaman\u0131n temelden g\u00fcvenli olmas\u0131 i\u00e7in at\u0131lan ilk ad\u0131mlard\u0131. Ancak as\u0131l e\u011flence, bu g\u00fcvenlik katmanlar\u0131n\u0131 test etmeye ba\u015flad\u0131\u011f\u0131mda ortaya \u00e7\u0131kt\u0131.<\/p>\n
Kendi Uygulamama S\u0131zma Testi: Ad\u0131m Ad\u0131m Sald\u0131r\u0131 Senaryolar\u0131<\/h2>\n
Uygulaman\u0131n geli\u015ftirme a\u015famas\u0131n\u0131 tamamlad\u0131ktan sonra, bir sonraki mant\u0131ksal ad\u0131m, onu k\u0131rmaya \u00e7al\u0131\u015fmakt\u0131. Bu, bir s\u0131zma testi (penetration test) s\u00fcrecini sim\u00fcle etmek anlam\u0131na geliyordu. Amac\u0131m, bir sald\u0131rgan\u0131n g\u00f6z\u00fcnden uygulamaya bakmak, potansiyel zafiyetleri bulmak ve bunlar\u0131 istismar etmeye \u00e7al\u0131\u015fmakt\u0131. Bu s\u00fcre\u00e7, uygulaman\u0131n ger\u00e7ekten ne kadar diren\u00e7li oldu\u011funu anlaman\u0131n tek yoluydu.<\/p>\n
S\u0131zma Testi Metodolojisi ve Kullan\u0131lan Ara\u00e7lar<\/h3>\n
S\u0131zma testine ba\u015flarken standart bir metodolojiyi takip ettim. Bu metodoloji genellikle \u015fu ad\u0131mlardan olu\u015fur:<\/p>\n
\n- Ke\u015fif (Reconnaissance):<\/strong> Uygulama hakk\u0131nda m\u00fcmk\u00fcn oldu\u011funca fazla bilgi toplama. Bu, kullan\u0131lan teknolojiler, a\u00e7\u0131k portlar, alt alan adlar\u0131 ve genel mimari hakk\u0131nda bilgi edinmeyi i\u00e7erir.
Nmap<\/code> gibi ara\u00e7lar ve basit web taray\u0131c\u0131lar\u0131 bu a\u015famada olduk\u00e7a faydal\u0131d\u0131r.<\/li>\n- Tarama (Scanning):<\/strong> Uygulaman\u0131n ve altyap\u0131s\u0131n\u0131n zafiyetler i\u00e7in taranmas\u0131. Otomatik zafiyet taray\u0131c\u0131lar\u0131 ve port taray\u0131c\u0131lar\u0131 kullan\u0131l\u0131r.<\/li>\n
- Zafiyet Analizi (Vulnerability Analysis):<\/strong> Tarama sonu\u00e7lar\u0131n\u0131 analiz ederek potansiyel zafiyetleri belirleme ve bunlar\u0131n nas\u0131l istismar edilebilece\u011fini de\u011ferlendirme.<\/li>\n
- \u0130stismar (Exploitation):<\/strong> Bulunan zafiyetleri kullanarak sisteme yetkisiz eri\u015fim sa\u011flamaya veya istenmeyen eylemleri ger\u00e7ekle\u015ftirmeye \u00e7al\u0131\u015fma.<\/li>\n
- Raporlama (Reporting):<\/strong> Bulunan zafiyetleri, bunlar\u0131n etkilerini ve giderilmesi i\u00e7in \u00f6nerileri detayl\u0131 bir \u015fekilde belgeleme.<\/li>\n<\/ol>\n
Bu s\u00fcre\u00e7te kulland\u0131\u011f\u0131m temel ara\u00e7lardan baz\u0131lar\u0131 \u015funlard\u0131: Burp Suite Community Edition<\/code> (web proxy, zafiyet tarama ve istismar i\u00e7in), Nmap<\/code> (a\u011f ke\u015ffi ve port taramas\u0131 i\u00e7in) ve bazen SQLMap<\/code> (SQL Enjeksiyonu testleri i\u00e7in). Ayr\u0131ca, web taray\u0131c\u0131m\u0131n geli\u015ftirici ara\u00e7lar\u0131 ve basit komut sat\u0131r\u0131 ara\u00e7lar\u0131 (\u00f6rne\u011fin, curl<\/code>) da s\u0131k\u00e7a ba\u015fvurdu\u011fum yard\u0131mc\u0131lar\u0131md\u0131.<\/p>\nOWASP Top 10 Odakl\u0131 \u0130lk Sald\u0131r\u0131 Denemeleri<\/h3>\n
S\u0131zma testime, web g\u00fcvenli\u011fi alan\u0131ndaki en bilinen zafiyet listesi olan OWASP Top 10’a odaklanarak ba\u015flad\u0131m. Bu liste, web uygulamalar\u0131nda en s\u0131k rastlanan ve en kritik g\u00fcvenlik risklerini i\u00e7erir. \u0130lk denemelerim \u015funlar\u0131 i\u00e7eriyordu:<\/p>\n
\n- SQL Enjeksiyonu (SQL Injection):<\/strong> Kullan\u0131c\u0131 giri\u015f alanlar\u0131na k\u00f6t\u00fc niyetli SQL sorgular\u0131 enjekte etmeye \u00e7al\u0131\u015ft\u0131m. Amac\u0131m, veritaban\u0131ndan yetkisiz bilgi \u00e7ekmek veya veritaban\u0131n\u0131 manip\u00fcle etmekti. \u00d6rne\u011fin, bir arama kutusuna
' OR '1'='1<\/code> gibi ifadeler girerek, normalde eri\u015fmemem gereken t\u00fcm verileri listelemeye \u00e7al\u0131\u015ft\u0131m. \u0130lk ba\u015fta parametreli sorgular kulland\u0131\u011f\u0131m i\u00e7in ba\u015far\u0131l\u0131 olamad\u0131m, ancak bir noktada dinamik olarak olu\u015fturulan bir sorguda k\u00fc\u00e7\u00fck bir hata buldum.<\/li>\n- XSS (Cross-Site Scripting):<\/strong> Uygulaman\u0131n kullan\u0131c\u0131 girdilerini d\u00fczg\u00fcn bir \u015fekilde sanitasyon (temizleme) edip etmedi\u011fini test ettim. Forum yorumlar\u0131, profil a\u00e7\u0131klamalar\u0131 gibi alanlara
<script>alert('XSS');<\/script><\/code> gibi kodlar enjekte ederek, taray\u0131c\u0131n\u0131n bu kodu \u00e7al\u0131\u015ft\u0131rmas\u0131n\u0131 sa\u011flamaya \u00e7al\u0131\u015ft\u0131m. Ba\u015far\u0131l\u0131 olursam, oturum \u00e7erezlerini \u00e7almak veya kullan\u0131c\u0131 ad\u0131na eylemler ger\u00e7ekle\u015ftirmek m\u00fcmk\u00fcnd\u00fc.<\/li>\n- Bozuk Kimlik Do\u011frulama ve Oturum Y\u00f6netimi (Broken Authentication and Session Management):<\/strong> Oturum \u00e7erezlerini manip\u00fcle etmeye, zay\u0131f parolalarla deneme yan\u0131lma sald\u0131r\u0131lar\u0131 (brute-force) yapmaya ve oturum zaman a\u015f\u0131mlar\u0131n\u0131n do\u011fru \u00e7al\u0131\u015f\u0131p \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 kontrol etmeye \u00e7al\u0131\u015ft\u0131m. Ayr\u0131ca, oturum belirte\u00e7lerinin (token) tahmin edilebilir olup olmad\u0131\u011f\u0131n\u0131 da inceledim.<\/li>\n<\/ul>\n
SQL Enjeksiyonu denemem s\u0131ras\u0131nda, bir raporlama mod\u00fcl\u00fcnde basit bir zafiyet tespit ettim. Normalde parametreli sorgular kullan\u0131rken, belirli bir arama filtresinde kullan\u0131c\u0131 girdisi do\u011frudan bir SQL sorgusuna ekleniyordu. A\u015fa\u011f\u0131daki pseudokod, bu durumu \u00f6zetliyor:<\/p>\n
\n\/\/ \u00d6rnek: SQL Enjeksiyonu zafiyeti i\u00e7eren pseudokod\n function getFilteredReports(filterCriteria) {\n \/\/ G\u00fcvenlik a\u00e7\u0131\u011f\u0131: filterCriteria de\u011fi\u015fkeni do\u011fru \u015fekilde sanitize edilmiyor\n const sqlQuery = \"SELECT * FROM reports WHERE status = '\" + filterCriteria + \"'\";\n \/\/ Sald\u0131rgan, filterCriteria'ya ' OR 1=1 -- gibi bir de\u011fer girerek t\u00fcm raporlar\u0131 \u00e7ekebilir.\n \/\/ Do\u011fru yakla\u015f\u0131m: Parametreli sorgular veya ORM kullanmak.\n return database.execute(sqlQuery);\n }<\/code><\/pre>\n<\/p><\/div>\nBu k\u00fc\u00e7\u00fck hata, uygulaman\u0131n temel g\u00fcvenlik mimarisine ra\u011fmen nas\u0131l bir zafiyetin ortaya \u00e7\u0131kabilece\u011fini g\u00f6sterdi. \u0130lk ba\u015fta, bu t\u00fcr bir hatay\u0131 kendi kodumda bulmak beni \u015fa\u015f\u0131rtt\u0131, ancak bu, “insan fakt\u00f6r\u00fcn\u00fcn” g\u00fcvenlikteki rol\u00fcn\u00fc bir kez daha vurgulad\u0131.<\/p>\n
Yetkilendirme ve Oturum Y\u00f6netimi Zafiyetleri Av\u0131<\/h3>\n
OWASP Top 10’daki di\u011fer \u00f6nemli maddelerden biri olan “Bozuk Eri\u015fim Kontrol\u00fc” (Broken Access Control) \u00fczerine yo\u011funla\u015ft\u0131m. Bu, yetkili bir kullan\u0131c\u0131n\u0131n, normalde eri\u015fmemesi gereken kaynaklara veya i\u015flevlere eri\u015fmeye \u00e7al\u0131\u015fmas\u0131 durumunu ifade eder. IDOR (Insecure Direct Object References – G\u00fcvenli Olmayan Do\u011frudan Nesne Referanslar\u0131) zafiyetleri, bu kategorinin klasik \u00f6rneklerindendir. Uygulamamda, kullan\u0131c\u0131lar\u0131n kendi notlar\u0131n\u0131 ve dosyalar\u0131n\u0131 y\u00f6netti\u011fi bir b\u00f6l\u00fcm vard\u0131. URL’deki ID (kimlik) parametresini de\u011fi\u015ftirerek ba\u015fka bir kullan\u0131c\u0131n\u0131n notlar\u0131na eri\u015fip eri\u015femeyece\u011fimi test ettim. \u00d6rne\u011fin, \/notes\/view\/123<\/code> adresindeki 123<\/code> ID’sini 124<\/code> yaparak, ba\u015fka bir kullan\u0131c\u0131n\u0131n notunu g\u00f6rmeye \u00e7al\u0131\u015ft\u0131m. Beklentimin aksine, bu alanda bir zafiyet buldum! Uygulama, not ID’sini kontrol ederken, bu notun ger\u00e7ekten oturum a\u00e7m\u0131\u015f kullan\u0131c\u0131ya ait olup olmad\u0131\u011f\u0131n\u0131 her zaman do\u011frulam\u0131yordu. Bu, ciddi bir veri s\u0131z\u0131nt\u0131s\u0131 riskine yol a\u00e7abilecek bir hatayd\u0131.<\/p>\nOturum sabitleme (session fixation) ve yetki y\u00fckseltme (privilege escalation) denemeleri de yapt\u0131m. Oturum sabitleme, bir sald\u0131rgan\u0131n ge\u00e7erli bir oturum ID’sini kurbana verip, kurban\u0131n bu ID ile oturum a\u00e7mas\u0131n\u0131 sa\u011flayarak kurban\u0131n oturumunu ele ge\u00e7irmesi anlam\u0131na gelir. Uygulamam\u0131n oturum y\u00f6netimini dikkatlice tasarlad\u0131\u011f\u0131m\u0131 d\u00fc\u015f\u00fcnsem de, belirli senaryolarda oturum ID’sinin oturum a\u00e7madan \u00f6nce olu\u015fturulup daha sonra de\u011fi\u015ftirilmemesi gibi k\u00fc\u00e7\u00fck bir bo\u015fluk buldum. Bu, teorik olarak bir sald\u0131rgan\u0131n kurban\u0131 kendi kontrol\u00fcndeki bir oturum ID’si ile oturum a\u00e7maya zorlayabilece\u011fi anlam\u0131na geliyordu. Bu t\u00fcr detaylar, g\u00fcvenlik testlerinin neden bu kadar kritik oldu\u011funu bir kez daha g\u00f6sterdi. Her ne kadar dikkatli olsan\u0131z da, g\u00f6zden ka\u00e7an k\u00fc\u00e7\u00fck ayr\u0131nt\u0131lar b\u00fcy\u00fck g\u00fcvenlik a\u00e7\u0131klar\u0131na yol a\u00e7abilir.<\/p>\n
Beklenmedik Zafiyetler ve K\u00f6r Noktalar\u0131m\u0131 Ke\u015ffetmek<\/h2>\n
Kendi uygulamam\u0131 k\u0131rmaya \u00e7al\u0131\u015f\u0131rken, en \u015fa\u015f\u0131rt\u0131c\u0131 anlar, tahmin etmedi\u011fim veya g\u00f6zden ka\u00e7\u0131rd\u0131\u011f\u0131m zafiyetleri buldu\u011fum zamanlard\u0131. Bu “k\u00f6r noktalar”, genellikle en iyi niyetlerle tasarlanm\u0131\u015f veya uygulaman\u0131n kenar durumlar\u0131nda ortaya \u00e7\u0131kan hatalard\u0131. Bu deneyim, bana g\u00fcvenlik konusunda ne kadar \u00e7ok \u015fey \u00f6\u011frenmem gerekti\u011fini bir kez daha hat\u0131rlatt\u0131.<\/p>\n
Kendi Kodumdaki G\u00f6zden Ka\u00e7an Hatalar<\/h3>\n
Yukar\u0131da bahsetti\u011fim IDOR zafiyeti (G\u00fcvenli Olmayan Do\u011frudan Nesne Referanslar\u0131), benim i\u00e7in b\u00fcy\u00fck bir ders niteli\u011findeydi. Bir kullan\u0131c\u0131n\u0131n kendi notlar\u0131na eri\u015fimini sa\u011flayan API endpoint’i (u\u00e7 noktas\u0131) olan \/api\/notes\/<note_id><\/code>, not ID’sini do\u011frudan URL’den al\u0131yor ve veritaban\u0131ndan \u00e7ekiyordu. Kodun bir k\u0131sm\u0131 \u015funa benziyordu:<\/p>\n\n\/\/ Hatal\u0131 yetkilendirme kontrol\u00fc \u00f6rne\u011fi (pseudokod)\n @app.route('\/api\/notes\/<int:note_id>', methods=['GET'])\n @login_required \/\/ Kullan\u0131c\u0131n\u0131n giri\u015f yapm\u0131\u015f olmas\u0131 \u015fart\u0131\n def get_note(note_id):\n note = Note.query.get(note_id) \/\/ Notu ID'sine g\u00f6re \u00e7ek\n if not note:\n return jsonify({\"message\": \"Not bulunamad\u0131\"}), 404\n \/\/ Eksik kontrol: Bu notun ger\u00e7ekten current_user'a ait olup olmad\u0131\u011f\u0131 kontrol edilmiyor!\n return jsonify(note.to_dict()), 200<\/code><\/pre>\n<\/p><\/div>\n@login_required<\/code> dekorat\u00f6r\u00fc, kullan\u0131c\u0131n\u0131n oturum a\u00e7t\u0131\u011f\u0131n\u0131 garanti ediyordu. Ancak, bu notun ger\u00e7ekten oturum a\u00e7m\u0131\u015f kullan\u0131c\u0131ya ait olup olmad\u0131\u011f\u0131n\u0131 kontrol etmeyi unutmu\u015ftum. Bu, yetkili bir kullan\u0131c\u0131n\u0131n, URL’deki note_id<\/code> parametresini de\u011fi\u015ftirerek ba\u015fka bir kullan\u0131c\u0131n\u0131n notlar\u0131n\u0131 okuyabilece\u011fi anlam\u0131na geliyordu. Bu t\u00fcr bir hata, genellikle geli\u015ftiricinin “benim kullan\u0131c\u0131lar\u0131m bunu yapmaz” veya “bu zaten oturum kontrol\u00fcyle korunuyor” gibi varsay\u0131mlar\u0131ndan kaynaklan\u0131r. Ancak g\u00fcvenlikte varsay\u0131mlara yer yoktur. Her eri\u015fim iste\u011fi, en d\u00fc\u015f\u00fck ayr\u0131cal\u0131k prensibine (Principle of Least Privilege) g\u00f6re, ilgili kayna\u011fa eri\u015fim yetkisinin olup olmad\u0131\u011f\u0131n\u0131 a\u00e7\u0131k\u00e7a do\u011frulamal\u0131d\u0131r. Bu zafiyet, uygulaman\u0131n \u00e7ekirdek veri gizlili\u011fini tehlikeye at\u0131yordu ve acilen d\u00fczeltilmesi gerekiyordu.<\/p>\nMisconfiguration (Hatal\u0131 Yap\u0131land\u0131rma) ve Varsay\u0131lan G\u00fcvenlik A\u00e7\u0131klar\u0131<\/h3>\n
Bir di\u011fer \u00f6nemli bulgu ise, hatal\u0131 yap\u0131land\u0131rma (misconfiguration) kaynakl\u0131yd\u0131. Uygulaman\u0131n geli\u015ftirme ortam\u0131nda debug (hata ay\u0131klama) modunun a\u00e7\u0131k b\u0131rak\u0131lmas\u0131, canl\u0131 ortamda ciddi g\u00fcvenlik riskleri yaratabilir. Benim durumumda, uygulaman\u0131n bir API endpoint’i, geli\u015ftirme a\u015famas\u0131nda sistem ayarlar\u0131n\u0131 ve veritaban\u0131 ba\u011flant\u0131 bilgilerini i\u00e7eren bir yap\u0131land\u0131rma dosyas\u0131n\u0131 if\u015fa ediyordu. Normalde bu endpoint, yaln\u0131zca belirli IP adreslerinden eri\u015filebilir olmal\u0131 veya sadece geli\u015ftirme ortam\u0131nda aktif olmal\u0131yd\u0131. Ancak, yanl\u0131\u015fl\u0131kla canl\u0131 ortamda da eri\u015filebilir kalm\u0131\u015ft\u0131.<\/p>\n
\n\/\/ \u00d6rnek: Hatal\u0131 yap\u0131land\u0131rma kaynakl\u0131 bilgi s\u0131z\u0131nt\u0131s\u0131 (pseudokod)\n @app.route('\/api\/admin\/config', methods=['GET'])\n def get_admin_config():\n \/\/ Bu k\u0131s\u0131m sadece geli\u015ftirme ortam\u0131nda \u00e7al\u0131\u015fmal\u0131yd\u0131, ancak kontrol eksikli\u011fi var.\n \/\/ if app.config['ENV'] == 'development':\n \/\/ return jsonify(app.config), 200\n \/\/ else:\n \/\/ return jsonify({\"message\": \"Eri\u015fim Reddedildi\"}), 403\n\n \/\/ Canl\u0131 ortamda yanl\u0131\u015fl\u0131kla bu \u015fekilde b\u0131rak\u0131l\u0131rsa, hassas bilgiler if\u015fa olur.\n return jsonify(app.config), 200<\/code><\/pre>\n<\/p><\/div>\nBu, veritaban\u0131 \u015fifreleri, API anahtarlar\u0131 veya di\u011fer hassas bilgilerin yetkisiz ki\u015filerin eline ge\u00e7mesine neden olabilecek potansiyel bir s\u0131z\u0131nt\u0131yd\u0131. Hatal\u0131 yap\u0131land\u0131rmalar, genellikle g\u00f6zden ka\u00e7an k\u00fc\u00e7\u00fck detaylard\u0131r ancak b\u00fcy\u00fck sonu\u00e7lar do\u011furabilirler. Varsay\u0131lan ayarlar\u0131n g\u00fcvenli oldu\u011fundan emin olmak, kullan\u0131lmayan \u00f6zelliklerin kapat\u0131lmas\u0131 ve her ortam i\u00e7in ayr\u0131 yap\u0131land\u0131rma dosyalar\u0131n\u0131n kullan\u0131lmas\u0131 bu t\u00fcr riskleri azalt\u0131r.<\/p>\n
Zafiyetlerin \u0130stismar Senaryolar\u0131 ve Potansiyel Etkileri<\/h3>\n
Buldu\u011fum bu zafiyetlerin her biri, farkl\u0131 istismar senaryolar\u0131na yol a\u00e7abilirdi. SQL Enjeksiyonu, veritaban\u0131ndaki t\u00fcm kullan\u0131c\u0131 notlar\u0131n\u0131 veya hassas sistem bilgilerini s\u0131zd\u0131rmak i\u00e7in kullan\u0131labilirdi. IDOR zafiyeti, bir sald\u0131rgan\u0131n di\u011fer kullan\u0131c\u0131lar\u0131n gizli notlar\u0131na veya dosyalar\u0131na eri\u015fmesine olanak tan\u0131yarak b\u00fcy\u00fck bir gizlilik ihlaline neden olabilirdi. Hatal\u0131 yap\u0131land\u0131rma ise, uygulaman\u0131n altyap\u0131s\u0131na dair kritik bilgilerin if\u015fa olmas\u0131na yol a\u00e7arak daha ileri d\u00fczey sald\u0131r\u0131lar i\u00e7in bir basamak g\u00f6revi g\u00f6rebilirdi. Bu t\u00fcr zafiyetler, sadece veri s\u0131z\u0131nt\u0131s\u0131na de\u011fil, ayn\u0131 zamanda itibar kayb\u0131na, yasal sorunlara ve finansal zararlara da yol a\u00e7abilir. Kendi uygulamamda bu zafiyetleri bulmak, bana bir sald\u0131rgan\u0131n ne kadar yarat\u0131c\u0131 olabilece\u011fini ve en k\u00fc\u00e7\u00fck bo\u015flu\u011fun bile nas\u0131l istismar edilebilece\u011fini somut bir \u015fekilde g\u00f6sterdi.<\/p>\n
G\u00fcvenli\u011fi Yeniden \u0130n\u015fa Etmek: Zafiyetleri Giderme ve Gelece\u011fe Bak\u0131\u015f<\/h2>\n
Kendi uygulamamda buldu\u011fum zafiyetler, ba\u015flang\u0131\u00e7ta beni hayal k\u0131r\u0131kl\u0131\u011f\u0131na u\u011fratsa da, bu deneyimden paha bi\u00e7ilmez dersler \u00e7\u0131kard\u0131m. G\u00fcvenlik testleri, sadece zay\u0131f noktalar\u0131 ortaya \u00e7\u0131karmakla kalmaz, ayn\u0131 zamanda bir geli\u015ftiricinin g\u00fcvenlik bilincini de art\u0131r\u0131r. Zafiyetleri bulduktan sonraki ad\u0131m, bunlar\u0131 etkili bir \u015fekilde gidermek ve uygulaman\u0131n genel g\u00fcvenlik duru\u015funu g\u00fc\u00e7lendirmekti.<\/p>\n
Zafiyet Giderme S\u00fcreci ve Yama Stratejileri<\/h3>\n
Bulunan her zafiyet i\u00e7in, \u00f6nceliklendirme yaparak bir giderme plan\u0131 olu\u015fturdum. Kritik zafiyetler (\u00f6rne\u011fin, IDOR ve SQL Enjeksiyonu) en y\u00fcksek \u00f6nceli\u011fe sahipti. Giderme s\u00fcreci \u015fu ad\u0131mlar\u0131 i\u00e7eriyordu:<\/p>\n
\n- Analiz ve K\u00f6k Neden Tespiti:<\/strong> Zafiyetin neden ortaya \u00e7\u0131kt\u0131\u011f\u0131n\u0131 ve temel nedenini anlamak. Bu, sadece semptomu de\u011fil, as\u0131l problemi \u00e7\u00f6zmek i\u00e7in \u00f6nemlidir. \u00d6rne\u011fin, IDOR zafiyetinin k\u00f6k nedeni, her kaynak eri\u015fiminde yetkilendirme kontrol\u00fcn\u00fcn eksik olmas\u0131yd\u0131.<\/li>\n
- Yama (Patch) Uygulama:<\/strong> Kodu veya yap\u0131land\u0131rmay\u0131, zafiyeti ortadan kald\u0131racak \u015fekilde de\u011fi\u015ftirmek. SQL Enjeksiyonu i\u00e7in parametreli sorgulara ge\u00e7i\u015f yapt\u0131m. IDOR i\u00e7in ise her not eri\u015fiminde, notun sahibinin oturum a\u00e7m\u0131\u015f kullan\u0131c\u0131 olup olmad\u0131\u011f\u0131n\u0131 kontrol eden ek bir yetkilendirme katman\u0131 ekledim.<\/li>\n
- Tekrar Test Etme (Re-testing):<\/strong> Yama uyguland\u0131ktan sonra, ayn\u0131 zafiyetin hala mevcut olup olmad\u0131\u011f\u0131n\u0131 do\u011frulamak i\u00e7in tekrar testler yapt\u0131m. Ayr\u0131ca, yaman\u0131n yeni bir zafiyete yol a\u00e7\u0131p a\u00e7mad\u0131\u011f\u0131n\u0131 (regresyon testi) da kontrol ettim.<\/li>\n
- Geriye D\u00f6n\u00fck Kontroller:<\/strong> Benzer zafiyetlerin uygulaman\u0131n ba\u015fka yerlerinde de olup olmad\u0131\u011f\u0131n\u0131 kontrol etmek. Bir zafiyetin bulunmas\u0131, genellikle benzer mant\u0131k hatalar\u0131n\u0131n ba\u015fka mod\u00fcllerde de olabilece\u011fine i\u015faret eder.<\/li>\n<\/ol>\n
Bu s\u00fcre\u00e7, g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 kapatmak i\u00e7in sistematik bir yakla\u015f\u0131m\u0131n \u00f6nemini vurgulad\u0131. Her bir yama, uygulaman\u0131n genel g\u00fcvenli\u011fini bir ad\u0131m daha ileri ta\u015f\u0131d\u0131.<\/p>\n
Savunma Derinli\u011fi (Defense in Depth) Prensibini Uygulamak<\/h3>\n
Buldu\u011fum zafiyetler, bana “savunma derinli\u011fi” (Defense in Depth) prensibinin ne kadar kritik oldu\u011funu g\u00f6sterdi. Bu prensip, tek bir g\u00fcvenlik katman\u0131na g\u00fcvenmek yerine, birden fazla g\u00fcvenlik kontrol\u00fcn\u00fc bir araya getirerek bir sald\u0131rgan\u0131n hedefe ula\u015fmas\u0131n\u0131 zorla\u015ft\u0131rmay\u0131 ama\u00e7lar. \u00d6rne\u011fin, kullan\u0131c\u0131 giri\u015fimi i\u00e7in hem istemci taraf\u0131nda (client-side) do\u011frulama hem de sunucu taraf\u0131nda (server-side) do\u011frulama uygulamak, tek ba\u015f\u0131na bir g\u00fcvenlik kontrol\u00fcnden \u00e7ok daha etkilidir. Uygulamamda \u015funlar\u0131 g\u00fc\u00e7lendirdim:<\/p>\n
\n- Giri\u015f Do\u011frulama:<\/strong> T\u00fcm kullan\u0131c\u0131 girdilerini s\u0131k\u0131 bir \u015fekilde do\u011frulamak ve temizlemek (input validation and sanitization).<\/li>\n
- Yetkilendirme Katmanlar\u0131:<\/strong> Her API \u00e7a\u011fr\u0131s\u0131nda ve hassas kaynak eri\u015fiminde, kullan\u0131c\u0131n\u0131n o eylemi ger\u00e7ekle\u015ftirmeye yetkili olup olmad\u0131\u011f\u0131n\u0131 kontrol eden sa\u011flam yetkilendirme mekanizmalar\u0131.<\/li>\n
- \u015eifreleme:<\/strong> Hem aktar\u0131m halindeki (in-transit) hem de depolanm\u0131\u015f (at-rest) veriler i\u00e7in g\u00fc\u00e7l\u00fc \u015fifreleme algoritmalar\u0131 kullanmak.<\/li>\n
- G\u00fcvenlik Ba\u015fl\u0131klar\u0131:<\/strong> Web sunucusu yap\u0131land\u0131rmas\u0131na HTTP g\u00fcvenlik ba\u015fl\u0131klar\u0131 (\u00f6rne\u011fin, Content Security Policy – CSP, X-Frame-Options) eklemek.<\/li>\n
- G\u00fcnl\u00fckleme ve \u0130zleme:<\/strong> \u015e\u00fcpheli aktiviteleri tespit etmek i\u00e7in kapsaml\u0131 g\u00fcnl\u00fckleme (logging) ve izleme (monitoring) mekanizmalar\u0131 kurmak.<\/li>\n<\/ul>\n
Bu katmanl\u0131 yakla\u015f\u0131m, bir g\u00fcvenlik kontrol\u00fc atlat\u0131lsa bile, di\u011fer katmanlar\u0131n sald\u0131r\u0131y\u0131 durdurma \u015fans\u0131n\u0131 art\u0131r\u0131r.<\/p>\n
S\u00fcrekli G\u00fcvenlik Entegrasyonu ve Otomasyonun \u00d6nemi<\/h3>\n
G\u00fcvenlik, tek seferlik bir i\u015flem de\u011fildir; s\u00fcrekli bir s\u00fcre\u00e7tir. Bu nedenle, g\u00fcvenlik kontrollerini geli\u015ftirme ve da\u011f\u0131t\u0131m s\u00fcre\u00e7lerine (CI\/CD pipeline) entegre etmek b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. Uygulamamda \u015funlar\u0131 yapmaya ba\u015flad\u0131m:<\/p>\n
\n- Statik Kod Analizi (SAST):<\/strong> Kodu yazarken veya depoya (repository) g\u00f6ndermeden \u00f6nce potansiyel g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 otomatik olarak tespit eden ara\u00e7lar kullanmak (\u00f6rne\u011fin, Bandit for Python).<\/li>\n
- Dinamik Kod Analizi (DAST):<\/strong> Uygulama \u00e7al\u0131\u015f\u0131rken zafiyetleri test eden ara\u00e7lar kullanmak (\u00f6rne\u011fin, OWASP ZAP).<\/li>\n
- Ba\u011f\u0131ml\u0131l\u0131k G\u00fcvenli\u011fi:<\/strong> Kullan\u0131lan \u00fc\u00e7\u00fcnc\u00fc taraf k\u00fct\u00fcphanelerin ve ba\u011f\u0131ml\u0131l\u0131klar\u0131n bilinen zafiyetler i\u00e7erip i\u00e7ermedi\u011fini d\u00fczenli olarak kontrol etmek (\u00f6rne\u011fin, Snyk veya Dependabot gibi ara\u00e7larla).<\/li>\n<\/ul>\n
Bu otomasyonlar, g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131n erken a\u015famalarda tespit edilmesine ve d\u00fczeltilmesine yard\u0131mc\u0131 olur, b\u00f6ylece canl\u0131ya \u00e7\u0131kmadan \u00f6nce riskler minimize edilir. Kendi uygulamam\u0131 geli\u015ftirip k\u0131rmaya \u00e7al\u0131\u015fmak, bu otomasyonlar\u0131n ne kadar de\u011ferli oldu\u011funu bizzat deneyimlememi sa\u011flad\u0131. Art\u0131k g\u00fcvenlik, yaz\u0131l\u0131m geli\u015ftirme s\u00fcrecimin ayr\u0131lmaz bir par\u00e7as\u0131 haline geldi.<\/p>\n
Sonu\u00e7: Kendi Uygulaman\u0131z\u0131 K\u0131rmak Neden De\u011ferli Bir \u00d6\u011frenme Deneyimi?<\/h2>\n
Kendi g\u00fcvenlik uygulamam\u0131 in\u015fa etmek ve ard\u0131ndan onu k\u0131rmaya \u00e7al\u0131\u015fmak, bir geli\u015ftirici olarak kariyerimin en ayd\u0131nlat\u0131c\u0131 deneyimlerinden biri oldu. Bu s\u00fcre\u00e7, bana sadece teknik beceriler kazand\u0131rmakla kalmad\u0131, ayn\u0131 zamanda g\u00fcvenli yaz\u0131l\u0131m geli\u015ftirme konusundaki bak\u0131\u015f a\u00e7\u0131m\u0131 da k\u00f6kten de\u011fi\u015ftirdi. G\u00f6rd\u00fcm ki, en iyi niyetlerle bile kod yazarken hatalar yap\u0131labiliyor ve bu hatalar, bir sald\u0131rgan i\u00e7in alt\u0131n madeni olabiliyor. G\u00fcvenlik, bir \u00f6zellik de\u011fil, bir zihniyet meselesidir; geli\u015ftirme ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fcn her a\u015famas\u0131nda d\u00fc\u015f\u00fcn\u00fclmesi gereken bir konudur.<\/p>\n
Bu deneyimden \u00e7\u0131kard\u0131\u011f\u0131m en \u00f6nemli ders, asla varsay\u0131mlara dayanmamak ve her zaman bir sald\u0131rgan\u0131n g\u00f6z\u00fcnden d\u00fc\u015f\u00fcnmeye \u00e7al\u0131\u015fmakt\u0131r. Kendi kodunuzu test etmek, sizi daha iyi bir geli\u015ftirici yapar, \u00e7\u00fcnk\u00fc potansiyel zay\u0131f noktalar\u0131 \u00f6nceden g\u00f6rmenizi ve daha sa\u011flam, daha diren\u00e7li uygulamalar in\u015fa etmenizi sa\u011flar. G\u00fcvenlik, s\u00fcrekli bir \u00f6\u011frenme ve adaptasyon s\u00fcrecidir. Bu yolculukta, ne kadar \u00e7ok \u015feyi bilmedi\u011fimi fark ettim ve bu fark\u0131ndal\u0131k, beni daha fazla ara\u015ft\u0131rmaya ve kendimi geli\u015ftirmeye te\u015fvik etti. T\u00fcm geli\u015ftiricilere kendi uygulamalar\u0131n\u0131 “k\u0131rmay\u0131” denemelerini \u015fiddetle tavsiye ederim; bu, g\u00fcvenli kodlama pratiklerini i\u00e7selle\u015ftirmenin en etkili yollar\u0131ndan biridir.<\/p>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n\n- \n
Soru 1: G\u00fcvenlik uygulamas\u0131 geli\u015ftirmeye nereden ba\u015flamal\u0131y\u0131m?<\/strong><\/p>\nCevap 1:<\/strong> Temel web g\u00fcvenli\u011fi prensiplerini (OWASP Top 10 gibi) \u00f6\u011frenerek ba\u015flay\u0131n. Ard\u0131ndan, g\u00fc\u00e7l\u00fc kimlik do\u011frulama, yetkilendirme ve veri \u015fifreleme mekanizmalar\u0131n\u0131 anlamaya odaklan\u0131n. G\u00fcvenli kodlama pratiklerini benimseyen bir framework (\u00f6rne\u011fin Django, Flask, ASP.NET Core) se\u00e7mek iyi bir ba\u015flang\u0131\u00e7 noktas\u0131d\u0131r.<\/p>\n<\/li>\n- \n
Soru 2: S\u0131zma testi i\u00e7in temel ara\u00e7lar nelerdir?<\/strong><\/p>\nCevap 2:<\/strong> Ba\u015flang\u0131\u00e7 i\u00e7in Burp Suite Community Edition<\/code> (web proxy ve zafiyet tarama), OWASP ZAP<\/code> (otomatik web zafiyet taray\u0131c\u0131), Nmap<\/code> (a\u011f ke\u015ffi) ve web taray\u0131c\u0131n\u0131z\u0131n geli\u015ftirici ara\u00e7lar\u0131 yeterli olacakt\u0131r. SQL Enjeksiyonu i\u00e7in SQLMap<\/code> da olduk\u00e7a faydal\u0131d\u0131r.<\/p>\n<\/li>\n- \n
Soru 3: Her geli\u015ftirici kendi uygulamas\u0131n\u0131 test etmeli mi?<\/strong><\/p>\nCevap 3:<\/strong> Kesinlikle evet. Kendi kodunuzu bir sald\u0131rgan\u0131n g\u00f6z\u00fcnden test etmek, g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 erken a\u015famada tespit etmenizi sa\u011flar ve g\u00fcvenli kodlama al\u0131\u015fkanl\u0131klar\u0131 geli\u015ftirmenize yard\u0131mc\u0131 olur. Bu, “shift-left security” (g\u00fcvenli\u011fi sola kayd\u0131rma) prensibinin bir par\u00e7as\u0131d\u0131r.<\/p>\n<\/li>\n- \n
Soru 4: En yayg\u0131n web zafiyetleri nelerdir ve nas\u0131l korunulur?<\/strong><\/p>\nCevap 4:<\/strong> En yayg\u0131n zafiyetler aras\u0131nda SQL Enjeksiyonu, XSS (Cross-Site Scripting), Bozuk Kimlik Do\u011frulama, Bozuk Eri\u015fim Kontrol\u00fc ve G\u00fcvenlik Misconfiguration (hatal\u0131 yap\u0131land\u0131rma) bulunur. Korunmak i\u00e7in parametreli sorgular, girdi do\u011frulama, do\u011fru yetkilendirme kontrolleri, g\u00fcvenli oturum y\u00f6netimi ve d\u00fczenli g\u00fcvenlik yamalar\u0131 kullanmak \u00f6nemlidir.<\/p>\n<\/li>\n- \n
Soru 5: Buldu\u011fum g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 nas\u0131l raporlamal\u0131y\u0131m?<\/strong><\/p>\nCevap 5:<\/strong> Bir g\u00fcvenlik a\u00e7\u0131\u011f\u0131 buldu\u011funuzda, bunu detayl\u0131 bir \u015fekilde belgeleyin. Zafiyetin t\u00fcr\u00fcn\u00fc, etkisini, istismar ad\u0131mlar\u0131n\u0131 ve \u00f6nerilen \u00e7\u00f6z\u00fcm yollar\u0131n\u0131 i\u00e7eren bir rapor haz\u0131rlay\u0131n. E\u011fer bir ba\u015fkas\u0131n\u0131n uygulamas\u0131nda bulduysan\u0131z, sorumlu ekibe “sorumlu if\u015fa” (responsible disclosure) prensipleri \u00e7er\u00e7evesinde bildirin.<\/p>\n<\/li>\n<\/ul>\n#WebG\u00fcvenli\u011fi #SiberG\u00fcvenlik #UygulamaG\u00fcvenli\u011fi #S\u0131zmaTesti #OWASP<\/p>\n