• 05-10-2024, 17:09:25
    #1
    Merhaba, projede JWT Token yapılandırması ekledim UI tarafına access token ve refresh tokenı döndüm ve interceptor olarak login register gibi işlemler dışında her istekte dönen tokenın süresine bakıp eğer süre dolmuşsa apiye refresh tokenı yollayarak onunda süresi dolmadıysa yeni token üretip UI tarafına dönüyorum. Refresh token süresi de doldusya login sayfasına atıyorum. Merak ettiğim konu dbde refresh token şifrelenmiş olarak kayıtlı JWT token ve refresh tokenı storageda saklarken şifrelenmiş mi kayıt etmeliyim? API ye istek atarkende önce şifreyi çözüp mü istek atmalıyım? Diğer türlü birinin token ve refresh tokenını kopyalarlarsa bunlarla istediği gibi istek atamazlar mı? Burada özellikle dikkat edilmesi gereken konu nedir?
  • 05-10-2024, 17:17:21
    #2
    Refresh token db de tutuluyorsa sifreli kalmali, client tarafta acik olarak saklanabilir. Token refresh ederken bu tokeni alan ip halen ayni ise refresh yapabilsin, degilse yapamasin diye kural koyabilirsiniz. Zaten gecerlilik vb kontrolleri yapiyorsunuz. Tokenlqrin suresi de cok uzun degilse sorun yasanmaz. Client tarafta sifreleyip cozmenin bir avantaji yoktur.
  • 05-10-2024, 17:22:22
    #3
    erbasaran adlı üyeden alıntı: mesajı görüntüle
    Refresh token db de tutuluyorsa sifreli kalmali, client tarafta acik olarak saklanabilir. Token refresh ederken bu tokeni alan ip halen ayni ise refresh yapabilsin, degilse yapamasin diye kural koyabilirsiniz. Zaten gecerlilik vb kontrolleri yapiyorsunuz. Tokenlqrin suresi de cok uzun degilse sorun yasanmaz. Client tarafta sifreleyip cozmenin bir avantaji yoktur.
    süresi var evet ama tokenle refresh tokenı alan birisi ip kontrolü yapmadıkca refresh token ile token yenileme apisine istek atarsa yenileme tokeninin süresi bitmedikçe istediği kadar token alamaz mı? Ben UI da interceptorda refresh token kontrolü yapıyorum ama apide refresh token farklı platformlardan istek atmaya çalışırsa bunu nasıl engellerim
  • 05-10-2024, 18:22:10
    #4
    Cors policy uygulayabilir, request header kismina birkac deger ekleyip api tarafinda dogrulamasini yapabilirsiniz.
  • 05-10-2024, 18:31:57
    #5
    erbasaran adlı üyeden alıntı: mesajı görüntüle
    Cors policy uygulayabilir, request header kismina birkac deger ekleyip api tarafinda dogrulamasini yapabilirsiniz.
    Evet, ben mi çok detaya indim acaba? Benim tereddütüm hesap bir yerde açık unutulursa vs diyeydi. Bu durumda banane mi demeliyiz acaba Headerdan device ıd alıp refresh tokenle beraber kayıt etmeyi düşünüyorum. Tekrar login olurken device ıd farklıysa hesabınız şu ıdli cihazda açık sonlandırmak ister misiniz gibi bir seçenek ekleyeceğim.
  • 05-10-2024, 18:37:03
    #6
    digitalDev adlı üyeden alıntı: mesajı görüntüle
    süresi var evet ama tokenle refresh tokenı alan birisi ip kontrolü yapmadıkca refresh token ile token yenileme apisine istek atarsa yenileme tokeninin süresi bitmedikçe istediği kadar token alamaz mı? Ben UI da interceptorda refresh token kontrolü yapıyorum ama apide refresh token farklı platformlardan istek atmaya çalışırsa bunu nasıl engellerim
    Middleware, rate limiting kullan. Ama bu ikisi de iṣe yaramıyor. Diyelim ki, api adresine saldırganlar dakikada milyonlarca istek atıyor. (çoğu hatalı istek) ama bu hatalı istekler; sunucunu ṣiṣirir.

    En profesyonel çözüm; cloudflare ve docker kubernetes ile güvenlik duvarı kurmaktır. Baṣkasından gelen saldırgan request isteklerini engellersin.
  • 05-10-2024, 18:43:17
    #7
    ibrahimorginall adlı üyeden alıntı: mesajı görüntüle
    Middleware, rate limiting kullan. Ama bu ikisi de iṣe yaramıyor. Diyelim ki, api adresine saldırganlar dakikada milyonlarca istek atıyor. (çoğu hatalı istek) ama bu hatalı istekler; sunucunu ṣiṣirir.

    En profesyonel çözüm; cloudflare ve docker kubernetes ile güvenlik duvarı kurmaktır. Baṣkasından gelen saldırgan request isteklerini engellersin.
    Mevzu o değil, authN/authZ işini bir API gateway'e de bırakabilir. Kaç yıldır greenfield ve brownfield projelerde çalışıyorum, ne zaman iş authN/Z'ye el atmaya gelse JWT varsa bu tasarım kararını kim verdiyse arkasından güzel bir sövüyorum. Abi şunu anlamak zor değil, JWT denen nane partiler arası veri paslamıyorsanız (SSO vs sosyal medya login'i durumlarında vs.) Web authentication için kullanılmıyor. Auth0, Okta bile yapmıyor bu saçmalığı, ama ne hikmetse bir JWT manyası var geliştiricilerde. Adamlar 25-30 yıl önce bu sorunu çözmüşler zaten cookie ile.

    https://www.google.com/search?q=don%...combinator.com
  • 05-10-2024, 18:49:12
    #8
    berkantipek adlı üyeden alıntı: mesajı görüntüle
    Mevzu o değil, authN/authZ işini bir API gateway'e de bırakabilir. Kaç yıldır greenfield ve brownfield projelerde çalışıyorum, ne zaman iş authN/Z'ye el atmaya gelse JWT varsa bu tasarım kararını kim verdiyse arkasından güzel bir sövüyorum. Abi şunu anlamak zor değil, JWT denen nane partiler arası veri paslamıyorsanız Web authentication için kullanılmıyor. Auth0, Okta bile yapmıyor bu saçmalığı, ama ne hikmetse bir JWT manyası var geliştiricilerde. Adamlar 25-30 yıl önce bu sorunu çözmüşler zaten cookie ile.

    https://www.google.com/search?q=don%...combinator.com
    ibrahimorginall adlı üyeden alıntı: mesajı görüntüle
    Middleware, rate limiting kullan. Ama bu ikisi de iṣe yaramıyor. Diyelim ki, api adresine saldırganlar dakikada milyonlarca istek atıyor. (çoğu hatalı istek) ama bu hatalı istekler; sunucunu ṣiṣirir.

    En profesyonel çözüm; cloudflare ve docker kubernetes ile güvenlik duvarı kurmaktır. Baṣkasından gelen saldırgan request isteklerini engellersin.
    işin içine girince jwt mantığı büyük platformlarda en azından bir sosyal platformda çokta güvenli değil sanırım network kısmına apiye erişmiş biri kullanıcın access token ve refresh tokenını ele geçirdiyse kullanıcı fark edene kadar rate limiting yoksa sistemi kullanıcı adına kullanabiliyor bunu engellemenin ip ve cihaz dışında bir yöntemi yok sanırım
  • 05-10-2024, 18:53:54
    #9
    digitalDev adlı üyeden alıntı: mesajı görüntüle
    işin içine girince jwt mantığı büyük platformlarda en azından bir sosyal platformda çokta güvenli değil sanırım network kısmına apiye erişmiş biri kullanıcın access token ve refresh tokenını ele geçirdiyse kullanıcı fark edene kadar rate limiting yoksa sistemi kullanıcı adına kullanabiliyor bunu engellemenin ip ve cihaz dışında bir yöntemi yok sanırım
    Bu sorun JWT'a özel bir şey değil, cookie'lerle session oluşturduğunda da aynı olası problemi adreslemen gerekiyor zaten. Bunu bazı uygulamalar IP tabanlı validasyonla proaktif şekilde önlemeye çalışıyor, diğerleri de kullanıcı istemediği takdirde (beni hatırla vs.) oturum süresini olabildiğince kısa tutmaya çalışıyor. Cookie'lerde tarayıcı kapanınca ilgili cookie'yi silme mevzusu da var, o da bir seçenek olabiliyor. Diğer türlü o oturumun korunmasında kullanıcının da eşit sorumluluğu var. Makinene trojan girip bütün tarayıcı verini çalarsa ne yapabilirsin ki? Ek olarak, JWT kullanıyorsan sitende XSS açığı oluşursa bütün tokenleri yürütürler haberin olsun. O yüzden CSP ayarlarını da iyi yap. Bunu mesela cookie kullanıyorsan eğer HttpOnly deyip çözebiliyorsun, düşünmene gerek kalmıyor.

    Sana tavsiyem first party auth yapıyorsan, cookie ve opak tokenlerden faydalan. JWT'ın sana bir faydası yok işleri karıştırmaktan başka.

    https://zitadel.com/blog/jwt-vs-opaque-tokens