Owasp Top 10 API 2019

API (Application Programing Interface) günümüz web mimarisinde çok kritik bir role sahiptir. Kullanım ve yaygınlığı artan her teknoloji gibi API yaklaşımı ile geliştirilen uygulamalar için bulunan tehditlerin sayılarında artış olmaktadır. Bu nedenle Owasp tarafından API Top 10 dokümanının ilk versiyonu yayınlanmıştır.

Bu doküman içerisinde bulunan 10 başlık aşağıdaki şekildedir.

Broken Object Level Authentication

Geliştirilen uygulamalar içerisindeki temel iki bileşen, kullanıcılar ve kullanıcılara ait nesnelerdir. Kullanıcılar, geliştirilen uygulamaları kullanarak kendisine veya üyesi olduğu gruba ait nesneler üzerinde işlemler gerçekleştirebilmektedir. Fakat bu noktada gerçekleştirilen yetki kontrolleri genel olarak yetersizdir.

Konuyu bir örnek ile açıklamak gerekirse, bilgilerinizi güncelleyebildiğiniz bir API işlemi olduğunu ve “/api/info/3456” adresine gönderilen POST isteği ile işlemin gerçekleştiğini hayal edelim. Bu noktada “kullanıcı bilgileri” size ait, farklı bir kullanıcı tarafından erişilmemesi gereken bir nesne olarak tanımlanmaktadır. Fakat istek adresine dikkat edildiğinde “3456” şeklinde sayısal bir ifade bulunduğu görülmektedir. Bu değer neyi ifade edebilir? Genel olarak üzerinde işlem gerçekleştirilen nesnenin ID değerini temsil etmektedir.

Peki, bir önceki POST isteğini “/api/info/3457” adresine gönderirsek nasıl bir sonuç meydana gelir? Bu durum gerekli kontroller sağlanmamış ise, “3457” ID değerine sahip ve size ait olmayan bir nesneyi güncellemenize olanak verecektir. Tabi bu sistem üzerinde bulunan farklı bir kullanıcıda sizin nesneleriniz üzerinde işlem gerçekleştirebilecektir.

Broken Authentication

Geliştirilen sistem tarafından sunulan API metotları içerdikleri bilgilere göre, herkes tarafından erişilebilir veya sadece sisteme giriş yapmış kişiler tarafından erişilebilir şeklinde ikiye ayrılmaktadır. Bu noktada iki problem oluşabilmektedir.

  1. Gizli bilgi içeren bir işlem için kimlik doğrulama kontrolü unutulabilmektedir.
  2. Kullanılan kimlik doğrulama yöntemi yetersiz/güçsüz/zafiyetli olabilmektedir.

Her iki durum sonucunda da kimliği sistem tarafından bilinmeyen bir kullanıcı, gizli olması gereken bilgi/bilgilere erişim sağlanabilmektedir.

Konuyu bir örnek ile açıklamak gerekirse, kullanıcıların sisteme girişi sonrasında “kullanıcı adı, rolü ve kullanıcı bilgilerine ait bir imza” değerine sahip token değerinin sunucu tarafından oluşturulduğunu hayal edelim. Fakat API tarafında bulunan işlemlerin gerçekleştirilmesi esnasında token değerinin doğrulunun kontrol edilmediği bir senaryoda, sisteme giriş yapmamış bir kullanıcı tarafından rastgele değerler ile oluşturulan token değeri kullanılarak, gizli olması gereken bilgilere erişim sağlanabilecektir.

Excessive Data Exposure

Geliştirme süreçlerinde kullanılan yöntemler ve araçlardaki değişmeler geliştirici alışkanlıklarının da değişmesine neden olmaktadır. Özellikler ORM – Object Relation Mapping araçları sayesinde geliştiriciler neredeyse tüm işlemleri nesne seviyesinde gerçekleştirmektedirler. Kullanıcıdan alınan veriler direk olarak nesneye dönüştürülürken, gerçekleştirilen bir veri tabanı sorgusu sonucunda dönen verilerde yine bir nesneye dönüştürülebilmektedir. Tamda bu nedenden ötürü gizli olması gereken verilerin dışarıya sızabildiği durumlar meydana gelmektedir.

Bir örnek ile açıklamak gerekirse; “Account” isimli bir nesneniz olduğunu varsayalım. Kullanıcı adınız, şifreniz ve bir çok veriniz bu nesne içerisinde tutulmaktadır. ORM aracı ile Code-First yaklaşımı kullanarak “Account” sınıfı üzerinden “Account” isimli veri tabanı tablosu oluşturulmasını sağladığınızı varsayalım. Sistem içerisindeki bir başka işlemde ise tüm kullanıcıları listeleyebildiğiniz hayal edelim. Eğer bu noktada  “Account” tablosu içerisinde bulunan bilgiler, “Account” nesnesine aktarıldıktan sonra “deserialize” edilerek kullanıcıya gönderilirse büyük bir problem oluşacaktır. Çünkü tüm kullanıcılara ait şifre bilgisi de bu cevap içerisinde yerini alacaktır.

Lack of Resource & Rate Limit

Kullanıcılar tarafından uygulama sunucusuna gönderilen istekler, sunucu kaynaklarını (Ram, CPU, Network) kullanmaktadır. Bu durum, kullanıcı tarafından gönderilen isteklerin büyüklükleri, kullanıcıya döndürülmeye çalışılan cevap büyüklükleri, timeout süresi ve bir kullanıcı tarafından aynı anda erişilmeye çalışılan kaynakların sayısı vb. senaryoların ele alınmaması sonucunda DOS etkisi yaratacak zafiyetlere neden olabilmektedir.

Broken Function Level Authorization

Uygulamalar içerisinde tanımlanan metotlara uygulanan erişim politikalarının karmaşıklaştığı ve bilinçsiz kopyala/yapıştır işlemler sonucunda yetkilendirme kontrolünün atlandığı durumlar meydana gelebilmektedir. Gerekli kontrollerin bulunmuyor olması ise kullanıcılara yetkisi dışında bulunan kaynaklara erişim imkanı sağlayarak büyük bir güvenlik sorununa neden olmaktadır.

Mass Assignment

Geliştiriciler tarafından kullanılan Framework yapılarının bir çoğu “serialization/deserialization” yeteneğine sahiptir. Bu yetenek sayesinde, client üzerinden gönderilen JSON türündeki verilerin direkt olarak uygulama tarafında bulunan bir nesneye dönüştürülmesi sağlanabilmektedir. İşlem içerisindeki kritik nokta, istek içerisindeki parametreleri “key” alanları ile aktarılması hedeflenen sınıf içerisindeki parametre isimlerinin uyuşması gereksinimidir.

Fakat bu durum, istenmeyen verilerin kullanıcı tarafından uygulamaya aktarılmasına neden olabilmektedir. Örneklemek gerekirse; “Account” isimli bir sınıfınız olduğunu düşünelim. Bu sınıf içerisinde ise

  • Username
  • Password
  • Role

Bilgilerinin bulunmaktadır. Sisteme kayıt esnasında kullanıcıya verilecek rol bilgisi yetkili kişi tarafından seçilebilir olup, kullanıcının kendi rol bilgisini değiştirmesine izin verilmemektedir.

Bu uygulama üzerinde kullanıcının kendi bilgilerini güncelleyebildiği bir ekran bulunmaktadır ve bu ekran üzerinden

  • Username
  • Password

Bilgileri alınmaktadır. Bu noktaya kadar her şey normaldir. Fakat kullanıcı bilgilerinin güncellenmesi esnasında, alınan parametreler direkt olarak “Account” nesnesine “serialize” ediliyorsa ve bu nesne direkt olarak veri tabanı üzerine kayıt ediliyor, bu noktada zafiyet bulunmaktadır.

Zafiyetin sebebi, client üzerinden gönderilen istek içerisinde “Role” parametresinin bulunması durumunda, hiçbir kontrol uygulanmaksızın kullanıcı tarafından rol bilgisinin güncellenebilecek olmasıdır.

Security Misconfiguration

Geliştirilen uygulamalar üzerinde bulunan özelliklerin kontrol edilmeden veya gerek duyulmadan kullanıldığı durumlar güvenlik problemlerine yol açabilmektedir. Örneğin; uygulama içerisinde meydana gelen hataların geliştirici tarafından ele alınmaması, bilgi sızıntısına neden olabilecek bir konfigürasyon hatası olarak tanımlanabilir. Buna benzer olarak bir çok örnek verilebilir:

  • Önemli “Response Header” bilgilerinin kullanılmaması
  • Gerekli olamayan “HTTP” metot türlerinin kullanılması

Son zamanlarda API kullanımının yaygınlaşması, client uygulamalarının geliştirme süreçlerinin backend yapısından tamamen ayrılmasına neden olmuştur. Bu noktada ReactJs, AngularJs, VueJs vb. yöntemler çok büyük popülerite kazanmıştır. Bu yöntemler ile geliştirilen uygulamalar, herhangi bir backend bileşenine ihtiyaç duymadan, lokal sistem üzerinde ayağa kaldırılan bir “nodejs” sunucusu yardımı ile geliştiricilere sunulabilmektedir.

Fakat uygulama servislerinin sunulduğu API ile client uygulamanın çalıştırıldığı “nodejs” uygulaması farklı “origin” değerlerine sahiptir. Bu nedenle client uygulama üzerinden gönderilen isteklere, backend tarafından dönenen cevapların okunması mümkün olamamaktadır. “CORS” güvenlik başlığının API içerisinden dönen cevaplar içerisine eklenmesi ile yaşanan problem çözülebilmektedir ama geliştirme ortamında uygulanan bu konfigürasyon, canlı ortama çıkarken değiştirilmemektedir. Bu durum, canlı ortamda çalışan uygulamanıza farklı “origin”  alanları üzerinden istek gönderilmesine ve istekler doğrultusunda elde edilen cevapların okunabilmesi yeteneğini saldırganlara sağlamaktadır

Injection

Web tabanlı uygulamaların vazgeçilmez saldırısı olan “Injection” yöntemleri her zaman ilk 10 içerisindeki yerini korumaktadır. Fakat 2013 ve 2017 yıllarında yayınlanan Owasp Top 10 listesinde ilk sıra yer alan “Injection” saldırıları Owasp Top 10 API 2019 içerisinde sekizinci sırada yer bulabilmektedir.

Bu başlık altında SQL, NOSQL, LDAP, OS, XML Parser ve ORM araçlarına yönelik gerçekleştirilen saldırılardan bahsedilmektedir. Kullanıcıdan alınan girdilerin kontrolsüz bir şekilde yukarıda bahsedilen işlemlere dahil edilmesi sonucunda “Injection” zafiyetleri meydana gelmektedir.

Improper Assets Management

API tabanlı geliştirilen uygulamaların, API uçlarını kullanacak kişiler tarafından anlaşılabilmesi adına güncel ve detaylı dokümanlarının bulunması gerekmektedir. Swagger sayfaları bu gereksinimler için çok idealdir. Fakat verilmesi gerekli olan bu bilgilerin sadece gerekli kişilere verildiğinden emin olunmalıdır. Ayrıca yeni versiyonu yayınlanmış, eski API uçlarının kullanıma kapatılması gerekmektedir. Aksi taktirde güncel ve zafiyet barındırmayan bir metot yerine, ilgili metodun eski, zafiyetli versiyonu kullanılarak sistem üzerinde bilgi sızdırılması, yetkisiz işlem yapılması gibi durumlara neden olunabilir.

Insufficient Logging & Monitoring

 Geliştirilen uygulamalar içerisinde gerçekleştirilen işlemlerin doğru bir şekilde sınıflandırılarak kayıt altına alınmasının gerekliliğinden her zaman bahsedilmektedir. Fakat kayıt altına alınan bu bilgiler düzenli bir şekilde, yetkin personeller tarafından takip edilmediği durumlarda hiçbir anlam içermeyecektir. Bu nedenle hem işlem adımlarının güvenli bir şekilde kayıt altına alındığı hemde düzenli olarak bu kayıtların incelendiğinden emin olunmalıdır.

Yapılan bağımsız bir araştırma sonucuna göre, geliştirilen uygulamalar içerisinde meydana gelen veri sızıntılarının genellikle 200 günden fazla bir süre zarfında tespit edildiği, bu tespitinde uygulama özelindeki ekip tarafından değil, dış kaynaklı ekipler tarafından yapıldığı görülmektedir.

Genel hatları ile Owasp Top 10 API dokümanı bu şekildedir. Açıkçası bu başlıklar arasına “XSS – Cross Site Scripting” maddesinin dahil edilmesi ile Owasp Top 10 2019 dokümanı elde edilebilecektir.

Yazar: Ahmet Akan

2016 Karabük Üniversitesi Bilgisayar Mühendisliği Mezunu. Kariyerine Uygulama Güvenliği Analisti olarak başladı ve bu alanda görev almaya devam etmekte.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir