Bard, ChatGPT ve Bing Chat gibi Yapay Zeka araçları , Büyük Dil Modeli (LLM) kategorisinde yükselişte olan mevcut büyük isimlerdir.
LLM'ler, günlük insan dilini bir sohbet istemi olarak kullanarak iletişim kurabilmek için geniş veri kümeleri üzerinde eğitilir. Yüksek Lisansların esnekliği ve potansiyeli göz önüne alındığında, şirketler hayatlarımızı daha iyi ve daha kolay hale getirmek için bunları teknoloji endüstrisindeki birçok iş akışına entegre ediyor. Ana yapay zeka iş akışı entegrasyonlarından biri, daha hızlı ve daha verimli kodlama için eşleşen kod modellerini öngörme ve oluşturma yeteneği sağlayan otomatik tamamlama kod eklentisidir.
Mevcut AI kod oluşturma araçları pazarında GitHub Copilot , Amazon CodeWhisperer , Google Cloud Code (Duet AI) , Blackbox AI Code Generation ve daha fazlası dahil olmak üzere birçok oyuncu var. Bu blog gönderisinde, geliştiricilerin bu tür araçları kullanırken karşılaştıkları yaygın güvenlik tuzaklarının örnekleri özetlenmektedir.
Bu makalenin amacı farkındalığı artırmak ve otomatik olarak oluşturulan kodlara körü körüne güvenilemeyeceğini ve yazılımdaki güvenlik açıklarından kaçınmak için yine de bir güvenlik incelemesi gerektiğini vurgulamaktır.
Not: Bazı satıcılar otomatik tamamlama araçlarının güvenli olmayan kod parçacıkları içerebileceğini öne sürmektedir.
Birçok makalede, otomatik tamamlama araçlarının IDOR , SQL enjeksiyonu ve XSS gibi bilinen güvenlik açıkları oluşturduğu zaten vurgulanmıştır. Bu gönderi, daha çok kodun bağlamına bağlı olan diğer güvenlik açığı türlerini vurgulayacaktır; burada AI otomatik tamamlamasının hataları kodunuza kaydırması olasılığının yüksek olduğu durumlar.
Güvenlik ve Yapay Zeka Kod Oluşturma Araçları Kod için eğitilmiş yapay zeka modelleri, genellikle işleyen kod üretme ana misyonuyla büyük kod tabanlarında eğitilir.
Pek çok güvenlik sorununun, performans yönünden taviz vermeden bilinen ve tanımlanmış bir azaltma yöntemi vardır (örneğin, kullanıcı girdisini/parametrelerini doğrudan sorguya birleştirmeyerek SQL enjeksiyonlarından kaçınılabilir) ve bu nedenle, güvenlik sorununun yazılması için bir neden olmadığı için ortadan kaldırılabilir. güvenli olmayan bir şekilde kodlayabilirsiniz.
Bununla birlikte, birçok güvenlik sorunu bağlama bağlıdır; dahili işlevsellik olarak uygulandığında tamamen güvenli olabilirken, bir istemciden gelen harici girdiyle karşılaşıldığında bir güvenlik açığı haline gelir ve bu nedenle yapay zekanın öğrenme veri kümesi aracılığıyla ayırt edilmesi zordur.
Bu tür güvenlik açıklarında kodun spesifik kullanımı genellikle kodun diğer bölümlerine ve uygulamanın genel amacına bağlıdır.
Aşağıda, bu tür güvenlik açıklarından bazılarını gösteren, test ettiğimiz bazı yaygın kullanım durumları ve örnekler verilmiştir:
Yapay zeka kod oluşturma araçlarının yukarıdaki durumları nasıl ele aldığını gördükten sonra, bunların uygun güvenlik filtreleri ve diğer etki azaltma mekanizmalarını oluşturma yeteneklerini test etmeye çalıştık.
Bilinçli olarak güvenli kod isteyerek test ettiğimiz bazı yaygın kullanım durumları ve örnekleri aşağıda verilmiştir:
Birçok uygulama, bir dosyayı dosya adına göre kullanıcıya geri getiren kod içerir. Sunucudaki rastgele dosyaları okumak için dizin geçişini kullanmak, kötü niyetli kişilerin yetkisiz bilgi elde etmek için kullandığı yaygın bir yöntemdir.
Dosyayı geri getirmeden önce kullanıcıdan gelen dosya adı/dosya yolu girişini temizlemek açık görünebilir, ancak bunun genel kod tabanları üzerinde eğitilmiş bir yapay zeka modeli için zor bir görev olduğunu varsayıyoruz; bunun nedeni, bazı veri kümelerinin bu işlemi yapmasına gerek olmamasıdır. işlevselliklerinin bir parçası olarak sterilize edilmiş yollar kullanın (hatta performansı düşürebilir veya işlevselliğe zarar verebilir) veya yalnızca dahili kullanım amaçlı olmaları amaçlandığından, sterilize edilmemiş yollardan zarar görmezler.
AI Aracı Önerisi (Google Cloud Code - Duet AI): Google Cloud Code - Duet AI otomatik tamamlamayı kullanarak kullanıcı girişinden temel bir dosya getirme işlevi oluşturmaya çalışalım. Duet AI'nin işlev ve rota adlarımıza göre kodumuzu otomatik olarak tamamlamasına izin vereceğiz -
Gri renkte de görebileceğimiz gibi otomatik tamamlama önerisi, Flask'ın temel dosya işleme işlevi olan “ send_file ” işlevinin kullanılmasıdır.
Ancak Flask'ın belgelerinde bile " Bir kullanıcı tarafından sağlanan dosya yollarını asla aktarma " ifadesi yer alır; bu, kullanıcı girdisini doğrudan "send_file" işlevine eklerken, örneğin dizin geçiş karakterlerini kullanarak dosya sistemindeki herhangi bir dosyayı okuma yeteneğine sahip olacağı anlamına gelir. dosya adında “../” gibi.
Doğru Uygulama:
"Send_file" işlevini Flask'ın güvenli "send_from_directory" işleviyle değiştirmek, dizin geçiş riskini azaltacaktır. Yalnızca belirli bir sabit kodlu dizinden (bu durumda "dışa aktarmalar") dosyaların alınmasına izin verecektir.
PHP ve NodeJS gibi bazı programlama dillerinde, iki farklı değişken türü arasında karşılaştırma yapmak mümkündür ve program, eylemi tamamlamak için perde arkasında bir tür dönüşümü gerçekleştirir.
Gevşek karşılaştırmalar perde arkasındaki değişkenin türünü kontrol etmez ve bu nedenle tür hokkabazlığı saldırısına daha yatkındır. Bununla birlikte, gevşek karşılaştırmaların kullanılması tek başına güvenli olmayan bir kodlama uygulaması olarak kabul edilmez; bu, kodun bağlamına bağlıdır. Ve yine yapay zeka modellerinin vakaları birbirinden ayırması zor.
AI Araç Önerisi (Amazon CodeWhisperer): PHP türü hokkabazlığın en yaygın örneği, bir JSON isteği aracılığıyla okunan kullanıcı girişinin (giriş türünün kontrolünü mümkün kılan) gevşek bir karşılaştırmaya ulaştığı gizli belirteçlerin/karmaların gevşek karşılaştırmalarıdır (" " ) katı bir (" =") yerine .
Göründüğü gibi CodeWhisperer, otomatik tamamlama önerilerinde gevşek karşılaştırma koşulları oluşturuyor:
Secret_token'ın gevşek karşılaştırması, bir rakibin $data[“secret_token”] == “secret_token” karşılaştırmasını atlamasına olanak tanır. “secret_token” değeri True (boolean) olan bir JSON nesnesi gönderilirken, gevşek karşılaştırma sonucu da True olur (daha yeni PHP sürümlerinde bile).
Araç, kontrolü "güvenli bir şekilde" yazmak için "ipucu verirken" (bir yorum kullanarak) bile, katı bir karşılaştırma içeren bir kod pasajı oluşturmadı -
Doğru Uygulama:
Yalnızca kesin bir karşılaştırma ("===") belirttiğimizde tür hokkabazlığı saldırılarına karşı korunuruz.
"Şifremi Unuttum" mekanizmasındaki güvenlik açıkları SaaS uygulamalarında çok yaygındır ve CVE'lerin arkasındaki temel nedendir.
Özellikle, bir Unicode Durum Eşleme Çakışma güvenlik açığı, bir karşılaştırma ifadesinde kullanıcı girişinin büyük veya küçük harfle yazılması ve orijinal değerinin de kodda kullanılması durumunda ortaya çıkar. Bazı farklı karakterler dönüştürüldüğünde aynı karakter koduyla sonuçlanacaktır. Örneğin “ß” ve “SS” büyük harfle yazıldığında “0x00DF”ye dönüşecektir.
Bu tür durumlar genellikle karşılaştırma kontrolünü kandırarak ve daha sonra beklenenden farklı olan orijinal değeri kullanarak bazı güvenlik kontrollerini atlamak/yanlış yönlendirmek için kullanılır. Bu durumların anlaşılması oldukça zordur, özellikle de birçok uygulamanın mümkün olduğu durumlarda.
Yapay Zeka Aracı Önerisi (GitHub Copilot): Bu güvenlik açığı türüne karşı özellikle duyarlı olan bir mekanizma, parolayı unutma mekanizmasıdır . İstenmeyen uyumsuzlukları önlemek amacıyla, kontrol yapılırken kullanıcının girişini büyük veya küçük harfe (e-posta adresleri veya alan adlarında) normalleştirmek yaygın bir uygulamadır.
Örnek olarak, şifremi unuttum işlevi için Copilot tarafından oluşturulan koda bakmak (aşağıda), bu soruna karşı savunmasız olduğunu gösterir.
Copilot'un kodu ilk önce küçük harfli e-posta adresini arar:
Daha sonra sürecin geri kalanını takip ederken aşağıdakileri önerir:
Gördüğümüz gibi otomatik tamamlama önerisi rastgele bir şifre oluşturuyor ve bunu kullanıcının e-posta adresine gönderiyor. Ancak, kullanıcı hesabını almak için başlangıçta kullanıcının e-postasının küçük harfli bir sürümünü kullanır ve daha sonra, kurtarma e-postasının hedefi olarak orijinal kullanıcının e-postasını 'olduğu gibi' (küçük harfe dönüştürme olmadan) kullanmaya devam eder.
Örneğin, saldırganın "[email protected]" ("K" bir Kelvin İşareti unicode karakteridir) gelen kutusuna sahip olduğunu ve bu e-postayı "Şifremi Unuttum" mekanizması için kullandığını varsayalım. “[email protected]” ve “[email protected]” e-postaları 'olduğu gibi' eşdeğer değildir , ancak küçük harf dönüşümünden sonra -
“[email protected]” e-posta adresinin kullanılması, “[email protected]” için hesap bilgilerini getirecektir ancak sıfırlama şifresi, saldırganın gelen kutusuna (“[email protected]”) gönderilecek ve “[email protected]” adresinin ele geçirilmesine olanak sağlanacaktır. [email protected]” hesabı.
Doğru Uygulama: Kullanıcı hesabını almak için kullanılan e-posta adresi, kurtarma e-posta adresiyle tam olarak aynı olmalıdır (yani send_email parametresi aynı zamanda email.lower() işlevini de kullanacaktır).
Ayrıca önlem olarak kullanıcı tarafından sağlanan değer yerine sunucuda kayıtlı olan değerin kullanılması tavsiye edilir.
Otomatik tamamlama araçlarının kafasını karıştırabilecek bir diğer konu da, özellikle karmaşık bulut altyapıları için yapılandırma dosyalarının yazılmasıdır.
Bunun temel nedeni, güvenlik için en iyi uygulama yönergelerinin mevcut olması, ancak herkesin bunları takip etmemesi ve bazı durumlarda bunlara karşı çıkmak gerekmesidir. Bu tür kod örnekleri yapay zeka eğitim veri kümesine girebilir. Sonuç olarak, bazı otomatik tamamlama çıktıları önerilen güvenlik yönergelerini ihlal edecektir.
Aşağıdaki örnekte Kubernetes'teki en küçük yürütme birimi olan Kubernetes Pod için bir yapılandırma dosyası oluşturacağız.
AI Araç Önerisi (Blackbox AI Code Generation): Bu örnekte Pod yapılandırma dosyası oluşturmaya başlıyoruz.
Öneri, yetenekler bölümünü oluşturur ve kaba, aslında bölmeyi kök kullanıcı olarak çalıştırmaya eşdeğer olan bir Linux çekirdek yeteneği (SYS_ADMIN) ekler.
Doğru Uygulama: SecurityContext'i atlamak o zaman daha mı iyi olur? Hayır - çünkü daha sonra diğer birçok yetenek varsayılan olarak eklenecek ve bu da en az ayrıcalık ilkesini ihlal edecektir.
Docker'ın en iyi güvenlik uygulamalarına göre en güvenli kurulum, öncelikle tüm Linux çekirdeği yeteneklerini bırakmak ve ancak daha sonra konteyneriniz için gerekli olanları eklemektir.
Yukarıda belirtilen sorunları düzeltmek için yetenekler bölümü tüm yetenekleri bırakarak başlar ve ardından konteynerimiz için gerekli olanları yavaş yavaş ekleyecektir.
Kullanım Örneği: Yapılandırma Nesneleri - Güvenli Olmayan Seri Durumdan Çıkarmaya Yol Açan Tutarsızlıklar
Pek çok güvenlik açığı, uygulamanın gerekli bileşeni nasıl işleyeceğine karar veren bir yapılandırma nesnesinin tanımlanmasını gerektirir.
Seçtiğimiz örnek, JsonSerializerSettings nesnesinin yapılandırmasına ve özellikle TypeNameHandling'e bağlı olarak güvenli veya güvensiz bir şekilde kullanılabilen Newtonsoft'un C# dilindeki JSON seri durumdan çıkarma kitaplığıdır.
Seri durumdan çıkarma kodunu test ederken, yapılandırma nesnesinin tanımının oldukça rastgele olduğunu ve ince değişikliklerin farklı bir yapılandırma kümesi oluşturulmasına yol açabileceğini fark ettik.
AI Araç Önerileri (Amazon CodeWhisperer): Aşağıdaki örneklerde yalnızca geliştirici tarafından kullanılan yöntem adlarına dayalı tutarsız bir davranış gösterilmektedir:
TypeNameHandling özelliğinin “Auto” ve “ALL” olması nedeniyle her ikisinin de güvenli olmayan JSON seri durumdan çıkarılmasıyla sonuçlanan iki farklı konfigürasyon görebiliriz. Bu özellikler, JSON belgesinin seri durumdan çıkarılan sınıfı tanımlamasına olanak tanıyarak saldırganların rastgele sınıfları seri durumdan çıkarmasına olanak tanır. Bu, örneğin "System.Diagnostics.Process" sınıfının seri durumdan çıkarılmasıyla uzaktan kod yürütme için kolayca kullanılabilir. Geliştiricinin orijinal kodundaki tek fark yöntem adlarıdır.
Doğru Uygulama:
Varsayılan olarak bir JsonSerializerSettings nesnesi, güvenli olduğu düşünülen "TypeNameHandling = TypeNameHandling.None" ile başlatılır. Bu nedenle, güvenli bir TypeNameHandling değeriyle sonuçlanacak JsonSerializerSettings'in varsayılan yapıcısını kullanırız.
Yapay Zeka Aracı Önerisi (GitHub Copilot):
Güvenlik kontrolünün gerçekten saf olduğunu, yalnızca dizin geçiş girişimlerini yürütmek için gereken nokta-nokta-eğik çizgi dizilerinden kaçındığını görebiliriz. Yol parametresi, sistem üzerinde istenen herhangi bir yola işaret eden mutlak bir yol olabilir (örneğin, /etc/passwd), bu da güvenlik kontrolünün amacını boşa çıkarır.
Doğru Uygulama:
Burada, secure_file_read işlevi, dosya adının bulunması gereken (ve kaçış yapılmaması gereken) bir dizin (safe_dir) ile birlikte (göreceli) bir dosya adı parametresini alır. Safe_dir ve dosya adını birleştirerek mutlak bir yol oluşturur ve realpath'i çağırarak standartlaştırılmış biçimini almaya devam eder. Daha sonra Safe_dir klasörünün standart hale getirilmiş biçimini alır. Daha sonra, dosya içerikleri yalnızca standart hale getirilmiş yol standart hale getirilmiş güvenli_dir ile başlıyorsa döndürülür.
Yapay Zeka Aracı Önerisi (Blackbox Yapay Zeka Kod Oluşturma): Aşağıdaki örnekte, yapay zeka otomatik tamamlayıcısından tehlikeli dosya uzantılarını filtrelemekle görevli bir işlev oluşturmasını istedik.
Önerilen Python kodu dosya adını alır, uzantıyı ayırır ve onu tehlikeli uzantılar listesiyle karşılaştırır.
İlk bakışta bu kod pasajı güvenli görünüyor. Ancak, Windows dosya adı kuralları , noktayla biten dosya adlarını yasaklar ve dosya oluşturma sırasında nokta (“.”) ile biten bir dosya adı sağlanırken nokta atılır. Bu, kötü amaçlı bir uzantıya ve ardından bir noktaya (ör. "example.exe") sahip bir dosya gönderilirken, oluşturulan filtrenin Windows'ta atlanabileceği anlamına gelir.
Doğru Uygulama: Genellikle daha iyi yaklaşım, dosya uzantısını yalnızca izin verilen uzantılarla karşılaştıran bir beyaz liste kullanmaktır. Ancak araçlar kara liste yaklaşımını benimsediğinden (ki bu bazı durumlarda gereklidir) daha güvenli bir kara liste uygulamasının ana hatlarını çizeceğiz:
Aşağıdaki kod parçasında, uzantıyı alfasayısal olmayan tüm karakterlerden çıkararak ve onu yeni oluşturulan bir dosya adıyla birleştirerek kullanıcının giriş üzerindeki kontrolünün tamamını ortadan kaldırıyoruz.
Sonuç olarak - dikkatli kullanın Otomatik yardımcı programlayıcılar fikir önermek, kodu otomatik tamamlamak ve yazılım geliştirme sürecini hızlandırmak için mükemmeldir. Bu araçların zaman geçtikçe gelişmeye devam etmesini bekliyoruz, ancak şimdilik bu yazıdaki kullanım örneklerinde de gösterildiği gibi, otomatik tamamlamalı yapay zeka çözümlerinin, zihnimizi rahatlatana ve çıktılarını tekrar kontrol etmeden çıktılarına güvenene kadar aşılması gereken birçok zorluk var. böcekler.
Güvenlik açıklarının ortaya çıkma olasılığını azaltmanın olası bir yolu, yapay zeka kod oluşturma aracından güvenli kod oluşturmasını bilinçli olarak talep etmektir. Bu, bazı kullanım durumlarında yararlı olsa da kusursuz değildir; "güvenli görünen" çıktı yine de yazılım güvenliği konusunda uzman bir kişi tarafından manuel olarak incelenmelidir.
JFrog Güvenlik Araştırma Ekibi Önerileri Yazılımınızın güvenliğinin sağlanmasına yardımcı olmak için, hem yapay zeka üreten araçlar tarafından üretilen kodu manuel olarak incelemenizi hem de güvenlik açıklarını güvenle keşfedebilecek Statik Uygulama Güvenlik Testi (SAST) gibi güvenlik çözümlerini birleştirmenizi öneririz. Yukarıdaki örnekte görüldüğü gibi, SAST araçları, kullanım senaryosu #3'te açıklanan unicode durum eşleme çarpışmasını uyarabilir ve yakalayabilir. Bu proaktif yaklaşım, yazılımınızın güvenliğini sağlamak için çok önemlidir.
JFrog Güvenlik Araştırması ile güncel kalın Güvenlik araştırma ekibinin bulguları ve araştırmaları, JFrog Platformunun uygulama yazılımı güvenlik yeteneklerinin geliştirilmesinde önemli bir rol oynamaktadır.
JFrog Güvenlik Araştırma ekibinin en son keşiflerini ve teknik güncellemelerini araştırma web sitemizden ve X @JFrogSecurity adresinden takip edin.