Utku videolarına bayılıyorum. Küçük bir kitleye hitap ediyorsun bu senin umarım şevkini kırmaz. Zira videolarını heyecanla bekliyorum. Teşekkürler her şey için.
Şu kısmı anlayamadım neden jwt token için başka bir servise istek atayım ki? Zaten auth servis üzerinde userın giriş, üye olma vb gibi işlemlerini yapıyoruz daha sonra bu tokenı istediğimiz yerde tutuyoruz. Tutuyoruz derken bunu oluşturmuş oluyoruz biliyoruz anlamında söylüyorum. Yani başka servis üzerinden bir işlem yaparken, o işlem için "bu kullanıcı auth olmuş mu?" diye kontrol ederken, tekrar auth servise mesaj göndermeye gerek yok. Her servis içerisinde common paketi içerisinde bir tane validatesignature vardır ve servis kendi içinde bu fonksiyonu çağırarak yetkili kullanıcımı diye bakabilir. Onun dışında hijaking kısmına katılıyorum ama maalesef o kısım da kullanıcının kendi bilgi güvenliği yeteneğine bakıyor biraz.
Appsec alanında arkadaşlarla tartışıyoruz. JWT'nin CSRF e çözüm önerisi sunulup sunulmamasına bu konuda fikrin nedir? Dynamic CSRF Token'ın dışında çözü önerisi sunulabilir mi? Yani JWT olan uygulamarda CSRF zafiyeti oluşmaz denilebilir mi sizce mimari olarak
csrf token'ların devri artık geçti denilebilir. artık csrf'i önlemek için çok fazla imkanımız var 1- Authorization header'ında gönderilecek JWT token ile CSRF exploit etmek mümkün olmaz. Çünkü A sitesinden B sitesine gidecek bir requestte, browser bu header'ı kullanmayacak 2- Cookie authentication'ı varsa bile artık SameSite diye bir cookie flagimiz var. Bu zaten CSRF'i tek başına önlüyor. Chrome'da hiçbir şey yapmasan da aktif oluyor. Diğer browserlar için kendin set etmen gerekebilir. Blogumda CSRF ile alakalı detaylı bir yazı var. Oradan detayları okunabilir. 3- Eğer senin API endpoint'lerin sadece application/json formatındaki requestler kabul ediyorsa yine CSRF saldırısı gerçekleştirilemez (bir implementasyon hatası yapılmadığı takdirde) tabi şunu da eklemekte fayda var. Sadece CSRF saldırılarını önlemek için cookie'yi bırakıp JWT'ye geçmenin bir anlamı yok. SameSite cookie flag'i yeterli olacaktır. dediğim gibi blogumda CSRF konusunu çok detaylı ele aldığım bir yazı var. ona bakılabilir.
Ben kullanıcı çıkış yaptığında token blacklistte tutuyorum token lari yine db de zateb süresi gecmisse extra önlem almiyorum header da null geliyor fakat postman gibi arayuzlerde iki kere üst üste login islemini yaptirdigimda onceki token ile de giriş yapilabiliyor ama bunu istemiyorum buna nasıl bi onlem alabilirim identity kullaniyorum ve jwt leri veritabaninda tutmuyorum sadece çıkış yapilanlari blackliste tutuyorum ve middleware ile istek esnasında kontrol ettiriyorum gecerli bi token sa blackliste bak orada yoksa okey faka birden cok login isleminde onceki token ile işlem yapamamasini engelleyemedim
Teşekkürler.
Bir mülakatta daha jwt geldi, yine tokatladım. Teşekkürler utku şen
Utku videolarına bayılıyorum. Küçük bir kitleye hitap ediyorsun bu senin umarım şevkini kırmaz. Zira videolarını heyecanla bekliyorum. Teşekkürler her şey için.
Utku abi muhteşem bir video olmuş. Lütfen bu seriye devam et.
Bilgilendirici , harika bir video olmuş. Eline, Emeğine sağlık
Çok temiz bir anlatım. Ağzınıza sağlık
Çok sağol bro yardımcı oldun
Cok teşekkürler anlatiminiz detayli ve degerli kolay gelsin
Teşekkürler Utku Bey
Çok faydalı reis devamını bekliyoruz
devam etmelisin, takipteyiz.😎
Gayet bilgilendirici bir video olmuş
Serinin devamını bekliyorum.
Bence çok faydalı ve güzel bir video olmuş. Tebrik ediyor ve bu içerik için çok teşekkür ediyorum.
eğitim bana faydalı oldu teşekkürler
Video için teşekkürler, “Secret key var kardeşim nasıl decode ediyorsunuz bunu?” diye sorduğum soruların hepsi cevaplandı…
Bilgilendirici videon için teşekkürler abi
Güzel bir eğitim olmuş çok teşekkürler
çok faydalı bir eğitim olmuşşşş, teşekkürler
sagolasin🙏
Onur kanka pazar buluşucaz unutma, caz yapmicaz
Utku hocam eğitim için teşekkürler. Bug bounty hakkında güncel bir sohbet veya eğitimsel bir video gelirmi? Gelirse güzel olur hocam😊❤
Şu kısmı anlayamadım neden jwt token için başka bir servise istek atayım ki? Zaten auth servis üzerinde userın giriş, üye olma vb gibi işlemlerini yapıyoruz daha sonra bu tokenı istediğimiz yerde tutuyoruz. Tutuyoruz derken bunu oluşturmuş oluyoruz biliyoruz anlamında söylüyorum. Yani başka servis üzerinden bir işlem yaparken, o işlem için "bu kullanıcı auth olmuş mu?" diye kontrol ederken, tekrar auth servise mesaj göndermeye gerek yok. Her servis içerisinde common paketi içerisinde bir tane validatesignature vardır ve servis kendi içinde bu fonksiyonu çağırarak yetkili kullanıcımı diye bakabilir. Onun dışında hijaking kısmına katılıyorum ama maalesef o kısım da kullanıcının kendi bilgi güvenliği yeteneğine bakıyor biraz.
Web Developer'ken yaptığım projeye döndüm baktım, Signature control yapmamışım 🙂
biz jwt'nin expire time'ını 1 dk yapıyoruz. sürekli refresh token ile token'ı refresh ettiriyoruz.
Refresh tokenlardan bahsetmeyi unuttum ya
Appsec alanında arkadaşlarla tartışıyoruz. JWT'nin CSRF e çözüm önerisi sunulup sunulmamasına bu konuda fikrin nedir? Dynamic CSRF Token'ın dışında çözü önerisi sunulabilir mi? Yani JWT olan uygulamarda CSRF zafiyeti oluşmaz denilebilir mi sizce mimari olarak
csrf token'ların devri artık geçti denilebilir. artık csrf'i önlemek için çok fazla imkanımız var
1- Authorization header'ında gönderilecek JWT token ile CSRF exploit etmek mümkün olmaz. Çünkü A sitesinden B sitesine gidecek bir requestte, browser bu header'ı kullanmayacak
2- Cookie authentication'ı varsa bile artık SameSite diye bir cookie flagimiz var. Bu zaten CSRF'i tek başına önlüyor. Chrome'da hiçbir şey yapmasan da aktif oluyor. Diğer browserlar için kendin set etmen gerekebilir. Blogumda CSRF ile alakalı detaylı bir yazı var. Oradan detayları okunabilir.
3- Eğer senin API endpoint'lerin sadece application/json formatındaki requestler kabul ediyorsa yine CSRF saldırısı gerçekleştirilemez (bir implementasyon hatası yapılmadığı takdirde)
tabi şunu da eklemekte fayda var. Sadece CSRF saldırılarını önlemek için cookie'yi bırakıp JWT'ye geçmenin bir anlamı yok. SameSite cookie flag'i yeterli olacaktır.
dediğim gibi blogumda CSRF konusunu çok detaylı ele aldığım bir yazı var. ona bakılabilir.
teşekkürler @@UtkuSenRUclips 🙏
Ben kullanıcı çıkış yaptığında token blacklistte tutuyorum token lari yine db de zateb süresi gecmisse extra önlem almiyorum header da null geliyor fakat postman gibi arayuzlerde iki kere üst üste login islemini yaptirdigimda onceki token ile de giriş yapilabiliyor ama bunu istemiyorum buna nasıl bi onlem alabilirim identity kullaniyorum ve jwt leri veritabaninda tutmuyorum sadece çıkış yapilanlari blackliste tutuyorum ve middleware ile istek esnasında kontrol ettiriyorum gecerli bi token sa blackliste bak orada yoksa okey faka birden cok login isleminde onceki token ile işlem yapamamasini engelleyemedim
Jwt verisini cookie üzerinden göndermek temiz
Aga ben hala abone olmamışım lan şimdi farkettim