Cursor'ın build düzeltmesi jwt.verify() yerine jwt.decode() kullanarak sahte admin token'larının geçmesine izin veriyor

dev.to'da yazan bir geliştirici, Cursor'ın tek kelimelik bir değişiklikle ciddi bir kimlik doğrulama açığı nasıl ortaya çıkardığını belgeledi: başarısız bir build'i düzeltmesi istenen editör, Next.js middleware'inde jwt.verify() yerine jwt.decode() koydu ve uygulama imzaları hiç doğrulanmayan session token'larını kabul etmeye başladı.

Hata nasıl ortaya çıktı

Gönderiye göre geliştirici, Cursor'dan küçük bir Next.js uygulamasına route koruması eklemesini istemiş. Cursor'ın ilk denemesi webtoken paketini middleware.ts içine import etti ve build başarısız oldu; çünkü Next.js middleware'ini çalıştıran Edge runtime, Node'un crypto modülünü sunmuyor. Editörden hatayı ortadan kaldırması istendiğinde Cursor, decode() ile değiştirdi. Ortaya çıkan middleware hâlâ token süresinin dolup dolmadığını kontrol ediyor ve admin route'larına erişimden önce payload'taki role claim'ini karşılaştırıyordu — ama bu claim'leri imza doğrulaması yapmayan bir fonksiyonla okuyordu.

Gönderi bunu CWE-347, yani kriptografik imzanın hatalı doğrulanması olarak sınıflandırıyor. jwt.decode() payload'ı yazıldığı şekliyle döndürür; bu nedenle üzerine kurulan her yetkilendirme kararı, istemcinin tamamen kontrol ettiği verilere güvenir. Sömürü için kriptografik beceri gerekmez: bir JWT üç base64url segmentten oluşur ve ortadaki segment herkes tarafından okunabilir ve düzenlenebilir. Gerçek bir session cookie alıp "role": "user" değerini "admin" yapın, geçerlilik süresini bir yıl ileri itin, yeniden kodlayın ve geri yapıştırın. Sondaki imza artık değiştirilmiş payload ile eşleşmiyordur ve middleware'de onu inceleyen hiçbir şey yoktur.

Yazar, webtoken README'sinin bile decode'un imza doğrulaması yapmadığı ve güvenilmeyen girdi üzerinde kullanılmaması gerektiği konusunda uyardığını — ve her cookie'in güvenilmeyen sayıldığını belirtiyor. Python tarafında benzer bir durum, bir geliştirici PyJWT DecodeError ile karşılaşıp bir editörden bunu çözmesini istediğinde ortaya çıkıyor: editör jwt.decode(token, options={"verify_signature": False}) üretiyor; PyJWT bu seçeneği, asla güvenmeye niyetlenmediğiniz claim'leri okumak için belgeliyor.

Bu değişiklik neden sürekli yaşanıyor

Gönderi, tekrarlanan bu kalıbı birbirini güçlendiren üç nedene bağlıyor. Runtime kısıtı gerçek: webtoken, Edge runtime için bundle edilemiyor ve doğru yanıt — Web Crypto tabanlı jose kütüphanesine geçmek — aynı paketteki başka bir fonksiyonu çağırmaktan daha fazla iş. Sıradan testler bu iki çağrıyı ayırt edemez: meşru imzalı bir token kullanan test, decode() ve verify()den aynı payload'ı alır; ikisi yalnızca sahte token'larda ayrışır ve kimse build'i geçirmeye çalışırken sahte token yazmaz. Ayrıca eğitim verisinde decode()un meşru kullanımları bolca var — kullanıcı adı gösteren veya token ID'sini log'layan istemci tarafı kod parçaları gibi — bu yüzden model çağrıyı, onu güvenli kılan bağlam olmadan öğreniyor. Daha genel olarak yazar, editörlerin önlerindeki belirli hatayı yok etmeye optimize edildiğini ve bu değişikliğin fırlatan bir çağrıdan çalışan bir çağrıya giden en kısa yol olduğunu savunuyor.

Gönderi ayrıca bu kalıbı webtoken 8.5.1 ve altındaki iki eski danışma metnine bağlıyor. CVE-2022-23540, algoritmalar seçeneği olmadan ve falsy bir anahtarla — örneğin ayarlanmamış bir environment variable — çağrılan verify()fonksiyonunun none algoritmasına düşmesine ve imzasız token'ları kabul etmesine izin veriyordu. CVE-2022-23541 ise tek bir anahtar arama fonksiyonu iki anahtar türüne de hizmet verdiğinde RS256 token'larının HS256 olarak doğrulanmasına izin veriyordu. İkisi de 9.0.0'da düzeltildi; ama package. dosyasında ^8.5.1 sabitleyen bir editör bunları yeniden geri getirir.

Önerilen düzeltme

Yazarın önerisi net: yetkilendirme kararı veren her istek imzayı doğrulamalı, algoritmayı açıkça sabitlemeli ve herhangi bir hatada kapalı şekilde başarısız olmalı. Next.js Edge middleware'i için bu, jose ve onun jwtVerify() fonksiyonu anlamına gelir; issuer ve audience kontrolleriyle birlikte, ayrıca secret ayarlanmamışsa başlangıçta kesin bir hata verilir. Sıradan Node route handler'larında algoritma listesi sabitlenmiş webtoken 9.x yeterlidir; Python'da doğrulamayı devre dışı bırakmak yerine anahtarı ve açık bir algoritma listesini geçirin. Decode, görüntüleme içindir; asla erişim kontrolü için değildir.

İki uygulama öne çıkıyor. Eksik secret'ta exception fırlatmak, CVE-2022-23540'ın gerektirdiği falsy anahtar yolunu ortadan kaldırıyor. Ve sahte token testi — geçerli bir token üzerinde tek bir claim'i değiştirip yeniden kodlayarak 401 veya bir redirect beklentisi ortaya koymak — decode() ile verify() arasındaki ayrımı yapabilen tek test. Hızlı bir denetim için yazar, erişim kararı veren herhangi bir dosyada depoda decode( ve verify_signature aramayı öneriyor.

Neden önemli

Bu, özellikle AI destekli geliştirmeden şekillenmiş bir güvenlik başarısızlığı. Değişiklik küçük ve makul görünüyor, bildirilen hatayı çözüyor, her makul testten geçiyor ve işler yolunda gittiğinde yokluğu görünmez olan bir kontrolü sessizce ortadan kaldırıyor. Editörler build hataları üzerinde daha fazla özerklik kazandıkça, yeşil bir build ile gerçekten bir şeyi doğrulayan auth kodu arasındaki boşluk, tek seferlik bir hata olmaktan çıkıp sistematik bir riske dönüşüyor — ve sahte token testi şu anda tek güvenilir mayın dedektörü.