Net güvenlik görüşmesinin bu yardımında, Nokod Security’deki CTO Amichai Shulman, kodsuz ortamlardaki soyutlama katmanının veri akışını, kimlik yayılmasını ve kontrol mantığını gizleyerek güvenliği nasıl karmaşıklaştırdığını tartışıyor.
Shulman ayrıca, kodsuz uygulamalardaki güvenlik açıklarının neden basit yanlış yapılandırmaların veya güvensiz varsayılanların çok ötesine geçtiğini de ele alıyor.
Kodsuz ortamlardaki soyutlama katmanı, veri akışı, kimlik yayılımı veya kontrol mantığına karşı görünürlüğü nasıl karmaşıklaştırır?
İşletmelerde özel uygulamalar oluşturmak için kodsuz araçların kullanılması, geliştiriciye yansıtılan yazılımın temsili ile uygulamayı uygulayan gerçek makine kodu arasında daha büyük bir mesafe oluşturur. Bu mesafe görünürlük için bir takım zorluklar yaratır:
- Veri akışları, kimlikler ve kontrol mantığı, hepsinin düşük kod uygulama platformu (LCAP) tarafından kullanılan uygulamanın tescilli temsili üzerinde çıkarılması ve analiz edilmesi gerekir. Bu, herkese açık belgelenmiş sözdizimi ve yapısı olan standart programlama dillerini incelemekten farklıdır. Ayrıca, bilgiler LCAP tarafından maruz kalan birden fazla API uç noktasından toplanmalı ve standart yazılımlarda olduğu gibi bir git deposunda merkezileştirilmemelidir.
- Bu tür ortamlarda dinamik analiz son derece zordur, çünkü basit kanca için platform satıcıları tarafından yerleşik mekanizmalar sağlanmaz. Sonuç olarak, parametrelerin çalışma zamanı değeri, gerçek kimlikler vb. Hakkında dinamik bilgilerle statik analizi zenginleştirmek bir zorluktur.
- Uygulamanın orijinal temsili ile gerçek yürütme ortamı arasında birden fazla yorum ve derleme katmanı olduğu için dinamik analiz bilgilerinin (gerçek veri erişimi ve kimliği gibi) geliştiricinin temsili ile ilişkilendirilmesi zorlaşıyor.
Kodsuz ortamlarda ne tür yanlış yapılandırmalar veya güvensiz varsayılanlar en çok sömürülebilir olarak görüyorsunuz?
Sorunun ifadesi, kodsuz uygulama güvenliği ile en büyük sorunun mükemmel bir örneğidir-tartışmayı “varsayılan ayarlar ve yanlış yapılandırmalara güvensiz” olarak azaltmak. Kodsuz platformlar tarafından oluşturulan uygulamalar her şeyden önce uygulamalardır. Bu nedenle, sömürülebilirlikleri her şeyden önce geliştiricileri tarafından getirilen güvenlik açıklarına atfedilmektedir. Kodsuz uygulamalar için işleri daha da kötüleştirmek için, geliştirme ve dağıtım ortamlarının yanlış yakınlaştırılmasıyla da tehlikeye girerler. Kodsuz uygulamalarda en yaygın bulduğumuz güvenlik açıkları şunlardır:
- Sabit kodlanmış sırlar: Geliştiriciler, uygulamalarında kimlik bilgileri, API anahtarları, gizli jetonlar ve daha fazlasını içerir. Bunlar çoğunlukla kurumsal sistemler ve harici API’lerle entegrasyonun bir parçası olarak kullanılır. Bu tür uygulamalara gömülü sırlar, uygulamaları kullanan kişilere maruz kalır ve bunları sürekli olarak (önerildiği gibi) veya maruz kalma (gerektiği gibi) döndürülmesi çok zordur.
- HTML enjeksiyon güvenlik açıkları: Kodsuz uygulamaların en yaygın kullanımlarından biri, çeşitli durumlarda otomatik mesajlaşma içindir, e-postalar ve Microsoft ekipleri en önemli kanallardır. Tasarruf edilmemiş kullanıcı girişiyle (sıklıkla olduğu gibi) mesajlar oluştururken, HTML enjeksiyonu tehdidi yakınlaşır, bu da saldırganların bir kimlik avı kampanyasının ve hatta kötü amaçlı kod taşıyıcılarının bir parçası haline geldikleri noktaya kadar mesajların içeriğini potansiyel olarak yıkmalarına izin verir.
- Veri erişimi ile ilgili enjeksiyon güvenlik açıkları: SQL enjeksiyonu, OData enjeksiyonu, DAX enjeksiyonu ve SOQL enjeksiyonu, işletmelerde kullanılan ortak veri erişim yöntemlerini kötüye kullanan güvenlik açıklarıdır. Bunlar, tasarlanmamış kullanıcı girdisine dayanan veri erişim eylemleri oluşturan deneyimsiz geliştiricilerin sonucudur. Bu güvenlik açıklarından yararlanmak, saldırganlara hassas verilere yetkisiz erişim sağlayabilir ve verilere müdahale etme yeteneği sağlayabilir
Yukarıdaki güvenlik açıkları, kimlik doğrulanmamış kullanıcı girişine (kasıtlı veya kasıtsız olarak) doğrudan maruz kalma ile birleştirildiğinde, bir işletmenin veri güvenliği en kötü kabusu haline gelirler.
Sevilmemiş veri çıkışı veya Gölge API’leriyle entegrasyon gibi yüksek riskli otomasyon kalıplarını önlemek için hangi korkuluklar platform seviyesine gömülebilir?
Çoğu platform, konektörlerin beyaz listelemesine / kara listelemesine izin veren çeşitli seviyelerde kontrol sağlar. Bu, “standart entegrasyonlar” kullanımı etrafında korkuluklar koymayı mümkün kılar. Bu listelerin sekmelerini çok sayıda geliştiriciye sahip dinamik bir ortamda tutmak büyük bir zorluktur.
Gölge API’lerinin izlenmesi ve yönetilmesi daha da zordur, özellikle de bazı uç noktalar sadece çalışma zamanında belirlendiğinde. Çoğu platform, gölge API’lerinin kullanımı üzerinde ayrıntılı kontrol sağlamaz, ancak kullanımları için tamamen bir öldürme anahtarı sağlar.
Doğru kullanılırsa uygulamaların ve otomasyonların güvenli bir şekilde geliştirilmesine izin veren tüm platformlarda mekanizmalar mevcuttur. Enjeksiyon güvenlik açıklarını, geçiş güvenlik açıklarını ve diğer hata türlerini önlemeye yardımcı olabilecek bu mekanizmalar, geliştiricilerin kullanımları açısından farklı karmaşıklık seviyelerine sahiptir.
Sessiz veri çıkışı, genel kurumsal ortamlarda olduğu gibi bu ortamlarda da büyük bir sorundur. Genel iyileştirme yoktur ve koruma mekanizmaları çoğunlukla kanala özgüdür.
Kodsuz ortamların onaylama, denetim veya resmi doğrulama için yerel destek sunduğu bir gelecek görüyor musunuz?
Bunun olmasını önlemek için genellikle teknik bir engel yoktur. Bununla birlikte, tarih, IDE satıcıları tarafından geliştirme ortamlarına gömülü çok az güvenli geliştirme kontrolü olduğunu göstermektedir. Standart yazılım mühendisliği ile bile, güvenli geliştirme ağır kaldırma işlemlerinin çoğu üçüncü taraf, uzmanlaşmış güvenlik satıcıları tarafından gerçekleştirilir.
Tahminimce, platform satıcıları güvenli gelişimi destekleyen mekanizmalar getirmeye devam edecekler, ancak geliştiriciler tarafından kullanımlarının değerlendirilmesi veya kullanımlarının uygulanması hala üçüncü taraf güvenlik satıcılarıyla birlikte kalacaktır.