Merhabalar,
Günümüz dünyasında API’ leri her yerde görebilmemiz mümkün, bu kadar yaygın kullanılan bir mimarinin güvenlik zafiyetleri olmazsa olmaz değil mi ? :)
Gelin hep beraber API’lerde bilinen OWASP API TOP 10 listesine bir göz atalım ve bu zafiyetlere Apinizer ürünü ile nasıl önüne geçebileceğimizi tartışalım. Tartışmaya başlamadan önce Apinizer ürünü ile nasıl müdahele edebileceğimizi mantık çerçevesinde anlayabilmek için kısaca API Gateway mimarisine bir göz atalım.
Gördüğümüz gibi API Gateway, istemci ile backend API’nin tam ortasında konumlandırılmaktadır. Böylece API’lere erişim tek bir nokta üzerinden yapılmaktadır. Bu, API’leri kullanmak isteyen uygulamaların ve kullanıcıların sadece belirli ve izin verilen işlemleri yapmasını sağlar ve böylece API’lerin güvenliğini arttırır. Ayrıca, API Gateway; Trafik Yönetimi, Güvenlik, Authentication ve Authorization, Ölçeklendirme, Monitoring and Analytics, Routing ve Mediation, Cache, Transformation gibi faydalar sağlar.
Temel olarak mimariyi kafamızda canlandırdığımıza göre artık Apinizer ile OWASP API TOP 10 listesindeki risklere nasıl çözümler getirebileceğimize detaylı olarak değinebiliriz.
A1: Broken Object Level Authorization
IDOR(Insecure Direct Object Reference) saldırısı olarak da bilinen Broken Object Level Authorization zafiyeti kısaca bir kullanıcının yetkisi olmadığı bir objeye ait bilgilere erişebilmesi şeklinde özetlenebilir. Bu durum yetkilendirmenin eksik veya yetkilendirmenin olmadığı durumlarda ortaya çıkmaktadır.
Alınabilecek Önlemler;
Apinizer “Authorization(Yetkilendirme)” işlemi yapılabilir. Yetkilendirme, kimlik doğrulama kontrolünden sonra bir seviye daha güvenlik katmanı koymayı sağlar. Authorization eklenmesi bizlere, kullanıcının sahip olduğu roller metot/endpoint’in beklediği rolleri karşılamıyorsa mesajın akışı kesilerek hata döndürmeyi, kullanıcının sahip olduğu roller metot/endpoint’in beklediği rolleri karşılıyor ise mesaj yoluna devam etmesini sağlayarak “Broken Object Level Authorization” zafiyetinin önüne geçebilmeyi sağlamaktadır.
A2: Broken Authentication
Bu zafiyette, kimlik doğrulaması fonksiyonlarının yanlış kullanımı veya brute force saldırıları sonucunda açığa çıkan kullanıcı bilgileri ile ilgili sorunlar yer almaktadır.
Bir kaç madde içerisinde özetleyecek olursak;
- Kimlik doğrulaması bulunmayan API’ler,
- Tokenlarda validasyon, tokenların “expires” süresi kontrollerinin yapılmaması
- Brute Force saldırıları sonucunda açığa çıkan kullanıcı bilgileri
Temel olarak yukarıdaki maddeler ile Broken Authentication saldırılarını özetlemeye çalışmış olduk.
Alınabilecek Önlemler;
- Kesinlikle API’lerimize kimlik doğrulama mekanizması kurulması gerekmektedir. Apinizer ürünü içerisinden bu işlemi poliçeler bölümünde bulunan ; “Plain-Text Authentication”,” Basic (Base64) Authentication ”, “Digest Authentication”, “OAuth2” , “JWT Authentication” poliçeleri kullanarak bu adımı tamamlayabiliriz.
- Token validasyon ve expires süresini “OAuth2” ve “JWT” poliçe ayarlarından kod yazma gereksinimi duymadan tamamlayabiliriz.
- Brute Force saldırılarının bir adım önüne geçebilmek için “API Based Quato” poliçesi kullanılarak; API’lere ay, gün, saat bazlı limit konulabilir veya istekler belirli ip bloklarından geliyor ise “Allowed Ip List” poliçesi ile belirli ip’lere API’lerimizi açabiliriz. Bir diğer seçeneğimiz ise, Credential(kullanıcı) bazlı Quota(Kota) ve Throttling(Daraltma) işlemi yaparak belirli kullanıcılara belirli sınırlandırmalar getirebiliriz.
A3: Excessive Data Exposure
Genellikle API’ler, genel anlamda UI tabanında bilgilerin kısıtlanacağını varsayarak tüm bilgileri response(yanıt) cevabında iletebilmektedir. Örnek olarak bir öğrenci bilgilerini dönderen bir API düşünelim, bu API öğrencinin adı, soyadı, okul numarası, telefon gibi tüm bilgileri iletebilir. Fakat uygulama içerisinde, öğrencinin sadece adı veya gerekli olan daraltılmış bir bilgi alınmak istenebilir. API ise tüm objeyi geriye dönderdiği için burada bir zafiyet doğmaktadır. Saldırgan proxy ile araya girebilir ve filtrelenmemiş tüm bilgileri alabilir.
Alınabilecek Önlemler;
Apinizer ürünü bir api gateway ürünü olduğu için mesaj istemciye dönmeden mesajı kendi içinde filtreleyerek sadece gerekli olan bilgileri response olarak dönderebilmektedir, bu filtrelemeyi “JSON Transformation”, “XML Transformation”, “Script” poliçeleri uygulanarak yapılabilmekte olup aynı zamanda da “Redaction” Poliçesi ile Backend API’den dönen mesajın içindeki herhangi bir başlık (header), parametre (parameter) ya da gövde (body) alanına ya da bu alanların değerlerine göre response (yanıt) özelleştirmesi yapılabilir. Yukarıda anlatılan işlemleri daha iyi anlayabilmek adına gelin hep beraber bir senaryo kurgulayalım; hastahane için bir API servisimiz olsun, bu API servisimizde mesaj içerisinde üç polikinliğe ait veri dönmekte olduğunu ve bu verilerin Body içerisinde Genel Cerrahi, Göz Hastalıkları ve Diş Polikinliği alanlarında kendi bölümlerine ait bilgiler içerdiğini varsayalım. Bu servisimize Genel Cerrahi Polikinliği kendileri için oluşturulmuş Credential bilgileri ile istekte bulunsun bu durumda Genel Cerrahi Polikinliği response(yanıt)’da diğer iki polikinliğinde verilerini görüntülemekte olacaktır. “Redaction” Poliçesi uygulanarak credential bilgilerini esas alarak diğer iki bölümün verilerini silebiliriz veya düzenleyebiliriz.
A4: Lack of Resource & Rate Limiting
API çağrıları yapılırken mutlaka bir istek sınırlandırması bulunması gerekmektedir. Bir sınırlandırma bulunmadığı takdirde ise saldırgan sunucu kaynaklarını tüketmek adına bir çok çağrı gerçekleştirebilir ve API servislerimizin cevap veremeyecek duruma düşürebilir bununla birlikte bir aksama söz konusu olabilir. Örnek olarak ise bir sms API’miz olduğunu varsayalım, burada kuyruk prensibi olduğu için aynı kişi birden fazla istekte bulunursa diğer kullanıcılar kuyruğa girecektir ve bir gecikme süresi ile karşılaşacaktır.
Alınabilecek Önlemler;
Apinizer üzerinden “ Credential Based Limit ve Quota(Kimlik bazlı limit) ” eklenebilir bu sayede belirli endpointlere izin verilen kullanıcılar dışında erişim engellenerek, Kaynağa erişim kısıtlanmış olur veya Apinizer’da API tabanlı olan “API Based Quato” , “API Based Throttling” poliçesi kullanılarak belirli bir değişken üzerinden( variable ) ip, username gibi header veya body içerisinden alanları alarak beklediğimiz duruma göre kontrol ederek endpointimize belirli bir kısıtlama koyabiliriz(Burada olabildiğince özgürüz :) ).Bu police ile ay, gün veya saatlik bir sınırlandırma yapabilmekteyiz.
A5: Broken Function Level Authorization
Büyük ölçekli uygulamarda bu zafiyet ile karşılaşılabilmektedir. Bu tür uygulamalarda belirli roller ve bu rollerin erişebileceği çeşitli sınırlar bulunmaktadır. Yetkilendirmenin uygun bir şekilde kontrol edilmediği durumlarda bu zafiyet ortaya çıkmaktadır. Örneğin normal bir kullanıcı yetki kontrolünün hatalı veya eksik olması nedeniyle admin’in erişebileceği methotlara erişebilmektedir.
Alınabilecek Önlemler;
Apinizer üzerinde yazımızın başında da bahsettiğimiz gibi Authentication işlemi yapılarak belirli roller oluşturabilir ve bu roller belirli kurallara göre Authentication işlemi yapılarak sınırları belirlenebilir ve bu şekilde bu zafiyetin önüne geçilebilir.
A6: Mass Assignment
“Mass Assignment” zafiyetinin temel mantığı, API üzerinden alınan verilerin veritabanımız da veya kodlarımızdaki sınıfımıza kontrol işlemlerinin gerçekleştirilmeden eşleştirilmesinden ortaya çıkmaktadır. Bir senaryo üzerinden devam etmek gerekirse, veritabanımız’da username, password ve rol olarak field(sütun)’larımız olsun. Senaryo gereği biz servisimizle username ve password alıyoruz ve rol sütunumuza default olarak 0 değerini veriyoruz, peki kullanıcı art niyetli bir şekilde rol parametresini gönderir ve bu değeri “1” diye gönderirse ne olur ? kendini admin statüsüne taşımış olur.
Alınabilecek Önlemler;
Bu zafiyetin önüne geçmek için ise client tarafında bu verinin hiç bir şekilde alınmaması gerekmektedir. Bu noktada Apinizer ürünü ile “Schema Validation” işlemi yapılabilir. Json formatı için “ JSON Schema Validation ”, Xml formatı için ise “ XML Schema Validation “ poliçeleri uygulayarak, mesaj içeriği kısıtlanarak veya “Business Rule” poliçesi ile istek veya yanıt mesajının üzerinde belirli kuralların doğrulanması yapılarak bu zafiyetin önüne geçilebilir.
A7: Security Misconfiguration
OWASP’ a göre en yaygın güvenlik zafiyetlerinden birdir. Bu zafiyet servis ayarlarının yanlış yapılandırılması veya eksik olmasından kaynaklanabilmektedir. Güncel olmayan sistemlerden, güvenlik sistemi eksik yada güvenlik sistemi olmayan dosya veya dizinlerden kaynaklanabilir. Bir diğer seçenek ise “CORS” yapılandırılmasında tüm sistemleri güvenilir saymak gibi çeşitli hatalar yapılması durumunda “Security Misconfiguration” zafiyeti ortaya çıkabilmektedir.
Alınabilecek Önlemler;
- Servis ve sistemlerin güncel tutmak
- Default parolaları kullanmamak
- SSL/TLS Sertifikalarını düzgün yapılandırmak
- Kullanılmayan servisleri kaldırmak
Yukarıda bulunan maddelere dikkat edilmesi gerekmektedir. Bunun yanı sıra Apinizer üzerinden CORS ayarları kolayca ayarlanabilmektedir. Bu saydığımız maddeler haricinde bir çok sebeple bu zafiyet ortaya çıkabilmektedir, “ Security Misconfiguration “ zafiyetini detaylı ve derinlemesine araştırma yapmanızı öneririm.
A8: Injection
İnjection çok geniş olan bir zafiyet çeşidir, günümüzde SQL, LDAP, NoSQL, OS Command gibi injection çeşitleri mevcuttur. Injection query stringler ile sorguya müdahale edilmesi olarak özetlenebilir. API’lerde özetleyecek olursak, parametre değerleri içerisinde saldırganlar querystring ile sorgunun devamı gibi queryler yazmayı hedefler.
Alınabilecek Önlemler;
- Injection ataklarına karşı gönderilen değerleri bazı kriterlere göre filtrelemek gerekir. Saldırı çeşitlerine göre filtreleme yaparak Injection saldırılarının önüne geçilebilir. Apinizer üzerinde ise “ Filter Rules ” bulunmaktadır içerisinde temel injectionlar için default filtreler bulunmaktadır. Aynı zamanda bu filtreler özelleştirilebilir ve uygulanabilir.
- Bunun yanı sıra Encoding tekniği uygulanmalıdır.
A9: Injection Improper Assets Management
Bu zafiyette temel esas test ortamıdır, prod ortamında genel olarak bir çok güvenlik testleri gerçekleştirerek canlıya alınır fakat test ortamları prod ortamı kadar güvenlik üst seviyede tutulmayabilir örnek vermek gerekirse de test ortamında hata mesajları filtrelenmeden gösteriliyor olabilir. Bu nedenle saldırganlar test ortamlarını hedef alabilmektedirler.
Alınabilecek Önlemler;
Bu zafiyetin önüne geçebilmenin en önemli adımı test ortamına sadece test işlerini yapan yetkili kişilerin erişmedir yani ip kısıtlaması veya credential oluşturarak belirli kullanıcıların ulaşabileceği test ortamı oluşturabilir ve bu sayede bir çok saldırının önüne geçilebilecektir. Apinizer’da poliçelerde bulunan “Allowed Ip List” poliçesi ile sadece test ortamına izin verilen iplerin API’ye ulaşması sağlanılabilir ve bu saldırının önüne büyük oranda geçilebilir.
A10: Insufficient Logging & Monitoring
Saldırganlar, kayıt ve izleme eksikliklerinden faydalanarak, uzun süre fark edilmeden hedefledikleri işlemleri gerçekleştirebilir. Servisimiz’ de mutlaka loglama ve izleme işlerini yapmalı ve belirli durumlarda ise hızlı bir şekilde aksiyon alabilmeliyiz.
Alınabilecek Önlemler;
Tam burada Apinizer devreye girmektedir , Apinizer API trafiği ile ilgili her şeyi loglamaktadır. (İstemciden gelen veriyi, Apinizer üzerinden manipulasyona uğrayan veri varsa ilk ve son hali gibi tüm verileri loglar). Bununla beraber Apinizerin bir avantajı ise monitör alanından “Anomaly Detector by Query “ ile loglar belirli anamolilere karşı duyarlı hale getirebilir ve belirli olayların yaşanması durumunda mail alma gibi anlık aksiyon alınabilmektedir. Bunların yanı sıra Apinizer üzerinden API Trafik sekmesinde tüm trafiğin loglandığını ve bu loglanan trafik içerisinde, istek yapan kullanıcının ip’si hangi method(get,post vs)’u kullandığı veya kaç saniye içerisinde cevap aldığı gibi detaylı bir Log izleme imkanları bulunmaktadır.
Sonuç olarak Apinizer, geliştiricilerin OWASP API Güvenliği Top 10 önerilerine uymasına yardımcı olmak için gerekli tüm araçları ve özellikleri sunar, güvenli bir API oluşturmak için gerekli olan tüm adımları otomatik olarak yapar ve geliştiricilerin sadece önemli olan uygulamaları yazmasına odaklanmasına izin verir.
Apinizer hakkında detaylı bilgi için web sitesini ziyaret edebilirsiniz.
