API Security & OWASP API TOP 10–1

8 min readDec 5, 2022

API Security

Web teknolojilerinin gelişmesiyle API kavramı ortaya çıkmıştır. API iki yazılım bileşeninin belirli tanımlar ve protokoller aracılığıyla birbiriyle iletişim kurmasına imkan sağlayan mekanizmalardır. Örneğin Hava durumu bilgisini cep telefonumuzda görüntülemek istediğimizde meteoroloji müdürlüğünün API servisi aracılığıyla bu verileri okuyup telefonumuzdan görüntüleyebiliriz. Bu veri iletişiminin sağlıklı bir şekilde yapılması, herhangi bir sızıntı veyahut güvenlik ihlaline sebebiyet vermemesi adına güvenliğinin sağlanması ve gerekli best practices takibi yapılması gerekmektedir.

Günümüzde pek çok kurum/kuruluş zero-trust modeline geçmiş olup yetkilendirme ( authorized ) yapılıncaya kadar hiçbir insan veya sistem bir kaynağa erişememesi gerekmektedir. Yetkilendirme yapıldığında bile ağ için tehdit izleme ve önleme önem arz etmektedir.

API’lar her gün sınırsız tehdit ve saldırıyla karşı karşıya kaldığı için zero-trust modelini uygulamak önemlidir. Kimlik doğrulama, yetkilendirme ve tehdit önleme stratejisiyle API’ların güvenliği arttırabilirsiniz.

API Güvenliği Neleri İçermektedir?

API güvenliği bir kullanıcının doğrudan veya dolaylı olarak kullandığı API’lerin güvenliği sağlamaya odaklanmaktadır. API güvenlik uygulamalarının yürütülmesi birden fazla ekip ve sistemi içerdiği için, rate limiting ve throttling network güvenlik ilkeleri, kimlik tabanlı güvenlik ve analiz gibi temel veri güvenliği kavramları da API güvenliğinin bir parçasıdır.

Bunu bir tablo ile özetleyecek olursak şayet;

API Protokolleri

API’lar ihtiyaçlar doğrultusunda farklı biçimlerde ve stillerde kullanılabilir. Seçilen API tipine göre, (REST, SOAP, GraphQL, gRPC, Websocket veya Webhooks), API güvenliğinin nasıl uygulanacağına ve yürütüleceğine karar verilir. Web API’ler ortaya çıkmadan önce SOAP web servisleri kullanılırdır. 2000–2010 yılları arasında XML yaygın oalrak kullanılmaktaydı. Tarihsel dizilimine bakıcak olursak;

API Protokol Karşılaştırması

API Güvenlik Aşamaları

API Güvenliği birden çok aşaması olan yapıdadır. Her aşamanın odak noktası belirli API güvenliğine işaret eder, belirli ve güçlü bir koruma düzeyi elde etmek için tasarlanmıştır.

API Keşfi

API güvenliğinin ilk aşaması API’ların keşfini kapsamaktadır. API gruplara ayrılması bazen keşfi zorlaştırmaktadır. Bunun önüne geçmek için iyi bir envanter listesi tutulması lazımdır.

Shadow API diye tabir edilen API’lar, API keşif açısından en büyük engeldir.Geliştirmenin bir parçasıdır ve kendisini uygulamanın bir parçası olarak gösterir. Shadow API’lar bir uygulamanın bir parçası olarak geliştirildiklerinde ortaya çıkar, sadece developerlar tarafından bilinen bu API’lar, uygulama ayrıntılarına ilişkin görünürlükleri olmadığı için güvenlik testleri sırasında gözden kaçabilir.

Bazen API’lar görevlerini tamamlarlar işlevlikleri son bulur ve yeni versiyonu çıkabilir. Uyuumluluk kapsamında geçici bir süre daha hizmet vermeye devam eder ve çok az trafik ürettiği için unutulabilirler. Bu tür API’lar eğer erişimleri kaldırılmaz ve operasyonlarını yürütmeye devam ederlerse saldırganlar için bulunmaz nimettir.

API’ların keşfedilmesi önemlidir çünkü saldırganlar sürekli olarak araştırma yapmaktadırlar. Bunun için API envanter listesi tutulması ve yürürlüğe alma, yürürlükten kaldırma operasyon adımlarının düzgün takip edilmesi önemlidir.

API Authentication/Authorization Tipleri

Kullanıcıların kimliğini doğrulaması, API’ın kötüye kullamını engellediği ve API güvenliği için kullanıcının kimlik doğrulaması yapmaya zorlaması API’ın verilere erişim izni vermemesini sağlar. API kullanarak görünteleme ve düzenleme yapmaya çalışan birinin kimliğin doğrulanması bu nedenle önemlidir

Host Based Authentication

Host based authentication yöntemi genellikle IOT cihazları ve network authentication için kullanılmakta olup Spoofing ile bypasslanabildiği için web teknolojileri için önerilmemektedir. Bu işlem, sunucularda ki verilere erişebilmesi için host yada server doğrulaması işlemini kapsamaktadır. İşlemin gerçekleşe bilmesi için herhangi bir anahtara ihtiyaç yoktur. RSA’ya benzeyen bu yapıda kullanılan argünan evet yada hayırdır. Varsayılan olarak herhangi bir bağımsız değişken ayarlanmamıştır.

Basic Authentication

En basit API kimlik doğrulama yöntemlerinden biri olan bu yöntem, kimlik doğrulama işlemi için HTTP protokolünü kullanır. HTTP Headerının içerisine Authorazation başlığının içerisinde giden kullanıcı-adı:parola bilgisiyle doğrulama işlemini gerçekleştirir. Örnek bir header;

Authorization: Basic YWRtaW46cGFzc3dvcmQxMjMK

Buradaki önemli bir husus var, base64 kolayca decode edilebilen bir şifreleme türüdür. Bu yüzden farklı yapılarda kullanarak (HTTPS veya SSL) şifrelenmiş verinin okunmasini engellenebilir.

Basic authentication ile HTTP’de gerçekleşen aşamalar yukarıda görselleştirilsede şu şekilde;

İstemci HTTP Get isteğini gönderir.
Sunucu “401 Unauthorized WWW-Authenticate : Basic realm=”…” şeklinde cevap verir. Bu aslında bana kullanıcı + şifreni gönder anlamına gelir.
İstemci tekrar Get isteği gönderir ancak bu sefer Authorization : Basic Base64 olarak kodekli kullanıcı: şifre bilgisini gönderir
Sunucu Http 200 OK veya Http 403 Forbidden ile cevap verir.

OpenID Connect (OIDC)

Gelişen dünyamızla beraber artık pek çok siteye üye oluyor ve her yerde farklı parolalar kullanmaya çalışıyoruz. Aklımızda tutmamız gereken o kadar kullanıcı adı ve şifremiz var ki bunları saklamak için password manager uygulamaları kullanmamız gerekiyor. Bu karmaşayı gidermek için 2005 yılında Brad Fitzpatrick tarafından OpenID isimli bir kimlik doğrulama protokolü için çalışıyordu. Yaklaşım şuydu, her üyelik sistemi gerektiren siteye yeni bir kullanıcı adı/şifresi yaratmak yerine OpenID’de yaratılan bir kimlikle tüm diğer sitelerde üyelik ve login gerçekleştirilebilecekti.

Kullanıcı bir foruma üye olmak istediğinde OpenID kimliğiyle üye olacaktı. Kullanıcı sonraki her login isteğinde siteye OpenID ile login olmak istediğini söyleyecek, site kullanıcıyı OpenID’ye yönlendirip oradan doğruladığı kimliğiyle geçerli bir sertifika aracılığıyla tekrar kendisine gelmesini isteyecekti. Böylelikle kullanıcı adı/şifresi kaosu artık yaşanmayacaktı. OpenID bir Federated Authentication örneğidir.

OAuth 2.0 spesifikasyonlarını uygulayan ve REST/JSON istek akışlarını kullanarak kimlik sağlayıcılarını uygulamalara entegre etmeyi kolaylaştıran kimlik doğrulama protokolü olan OpenID, bir yetkilendirme sunucusu tarafından gerçekleştirilen kimlik doğrulamasına dayalı olarak istemcilerin, son kullanıcının kimliğini doğrulamasına ve temel profil bilgilerini ve mevcut oturum bilgilerini elde etmesine imkan sağlar. Böylece sistemin kimlik ve erişim yönetimini üçüncü parti bir servise delege etmiş olursunuz.

OIDC, OpenID ve OpenID Connect aynı anlamları taşır. Farklı farklı yerlerde bu isimlendirmelerinin türevlerini görebilirsiniz.

OAuth

OpenID’de boş kalan authorization boşluğunu OAuth Protokolü’nün Token’lı yapısı sayesinde uygulamalar doldurmaya başladı. Artık bir web sayfasında yeni kullanıcı yaratmak istediğinizde sertifika yerine belirli kapsamda sınırlandırılmış yetkiler için onay alınıyor. OAuth protokolü Web, Mobil ve Masaüstü uygulamalarına basit ve standart bir yöntemle uygulamalara güvenli yetkilendirme imkanı sunan açık bir protokoldür. OAuth sayesinde erişim izni sınırlı olan verilerin yani korunmuş verilerin güvenli bir şekilde hizmete sunulması basitleştirilmiştir. OAuth protokolü, birden fazla servis veya sunucu arasında kimlik doğrulama veya yetkilendirme amacıyla kullanılır. Kullanıcıya herhangi bir parola ve hassas bilgi sormadığından ötürü daha güvenli olduğu düşünülmektedir ve sıkça kullanılmaktadır. Karşımıza genelde “Google ile Giriş Yap”, “Uygulamanın Aşağıdaki Bilgilerinize Erişmesine İzin Verin” gibi örneklerle çıkmaktadır.

OAuth’un basitçe işleyişine değinmek gerekirse, iki internet adresi olduğunu düşünelim, birisi Facebook, diğeri ise OAuth bağlantısı kurulacak site (medium.com) olsun. Basit bir senaryoyla, kullanıcı medium.com adresine üyelik kaydı yaptırmak istemektedir, fakat sayfada çok fazla form verisi olduğu için üyelik kaydını Google aracılığıyla yapmaya karar vermiştir. Bu durumda üyeliğin tamamlanabilmesi için aşağıdaki eylemler gerçekleşecek:

1- Kullanıcı, “Google ile Kaydol” butonuna bastığı an medium.com arkaplanda Google’un OAuth API’ıyla iletişime geçecektir.

2- Google, bir açılan pencerede kullanıcıya “Bu uygulama şu bilgilere erişebilecek:” diyip işlemlere devam edip etmek istemediğini sorarak kullanıcının onayını alacaktır.

3- Kullanıcının “Tamam”, “İzin Ver” gibi uygulamaya güvendiğini belirtecek şekilde aksiyon alması halinde Google bir token kodu üretecektir ve bu kod sayesinde uygulama ilgili kullanıcının adı, e-posta adresi, doğum tarihi gibi bilgilere erişebilecek, bu bilgileri veritabanına kaydedecektir.

Özetle, kullanıcı üyelik formunu doldurmadı ama daha önceden bu bilgilerin aynılarını Google hesabına girmişti ve Google aracılığıyla bu bilgileri medium.com adresine kopyalamış oldu. Yani formu kullanıcının yerine Google doldurmuş oldu desek yanlış olmaz.

Kayıt işlemini Google aracılığıyla gerçekleştiren kullanıcı, ilerleyen zamanlarda hesabına tekrar girmek isteyecektir ve bu sefer “Google ile Giriş Yap” seçeneğini kullanacaktır. Bu durumda yine Google, medium.com adresine giriş için eşsiz bir token kodu üretecek ve arka planda gereken doğrulamalar yapıldıktan sonra kullanıcı hesabına erişebilecektir. Burada önemli olan konu, üretilen token kodlarında parola gibi hassas bilgiler barındırılmamasıdır.

OAuth 2.0

2012 yılında ortaya çıkan 2.0 versiyonu OAuth 1.0 üzerinde geliştiricilere yönelik kolaylıklar sağlamak amacıyla yapılan bir dizi düzenlemeler sonrası çıkmıştır. OAuth 2.0 uygulamaların birbirleri arasında veri erişimine olanak sağlayan açık bir yetkilendirme protokolüdür. Burada vurgulamak isterim ki OAuth, kullanıcı doğrulama amaçlı değil uygulama yetkilendirme amaçlı bir protokoldür. Bir uygulamanın başka bir uygulama tarafından doğrulanmış kullanıcılara izin vermesidir. OAuth 2.0, farklı uygulamaları ve gereksinimleri destekleyen altı adımlı yapılya tasarlanmıştır. OAuth tokenları bir uç noktadan diğerine gönderildiğinde şifrelenmesi gerekmez. Bunun nedeni, aktarım sırasında şifrelenmiş olmalarıdır.

SAML

SAML, bir kimlik sağlayıcının (IdP) kullanıcıların kimliklerini doğrulamasına ve kimlik doğrulama belirtecini hizmet sağlayıcı (SP) olarak bilinen bir diğer uygulamaya iletmesini sağlayan OASIS tarafından geliştirilmiş bir standartdır. SAML, servis sağlayıcının kendi kimlik doğrulamasını gerçekleştirmek zorunda kalmadan çalışmasını, kimliği iç ve dış kullanıcıları entegre etmek üzere iletmesini sağlar. Güvenlik kimlik bilgilerinin bir ağ genelinde, genellikle bir uygulama veya hizmette servis sağlayıcı ile paylaşılmasına olanak tanır. SAML, genel bulutla SAML özellikli diğer sistemlerin yanı sıra şirket içinde veya farklı bir bulutta bulunan bir dizi diğer kimlik yönetim sistemi arasında güvenli ve etki alanları arası iletişim sağlar. SAML sayesinde, kullanıcılarınıza SAML protokolünü ve hizmetlerini destekleyen iki uygulama arasında tek adımlı oturum açma (SSO) deneyimi sunabilirsiniz. Tek SSO’nun, bir veya daha fazla uygulama adına çeşitli güvenlik fonksiyonları gerçekleştirmesine olanak tanınır.

SAML bu bilgileri kodlamak için kullanılan XML varyant dilidir. Ayrıca standardın bir kısmını oluşturan çeşitli protokol mesajlarını ve profilleri içerebilir. SAML içim kimlik doğrulama iki farklı yöntemle yapılabilir;

Identity Provider (IdP) Tarafından Başlatılan (IdP Initiated)

Bu metodda kullanıcı ilk olarak IdP ye erişip kimlik doğrulama işlemlerini gerçekleştirir. Yetkilendirme işlemlerini de gerçekleştirdikten sonra IdP tarafından kullanıcıya SAML Assertion sağlanır. İnternet tarayıcı aracılığı ile SAML Assertion servis sağlayıcıya iletilir. Servis sağlayıcı bu bileti doğrularsa erişim sağlanır ve oturum başlar.

2. Service Provider (SP) Tarafından Başlatılan (SP Initiated)

Kullanıcı ilk olarak servis sağlayıcıya gidip erişmeye çalışır. Servis sağlayıcı kullanıcıyı kimlik doğrulama isteği ile beraber IdP ye yönlendirir. Kullanıcı burada kimlik doğrulama ve yetkilendirme işlemlerini gerçekleştirdikten sonra elde edilen bilet internet tarayıcısı aracılığı ile servis sağlayıcıya gönderilir ve eğer bilet doğrulanırsa erişim sağlanır.

Servis Sağlayıcı lar ve IdP ler arasında SAML Assertion(IDP tarafından kimliği doğrulanmış kullanıcılara, SP a erişebilmeleri için verilen bilet)’ lar ve mesajlar SAML2.0 Bindings denilen metotlarla iletilir. Bunlardan önemli olan birkaç tanesine örnek vermek gerekirse HTTP redirect binding, servis sağlayıcı tarafından IdP ye iletilen kimlik doğrulama istekleri için kullanılır. HTTP Post binding ise en sık kullanılandır. Hem SAML Assertion ların iletilmesinde hem de kimlik doğrulama isteklerinde kullanılabilir.

Tek bir tabloda karşılaştırma yapacak olursak;

API Güvenlik Checklist

Eğer tam olarak API güvenliğinde nerede olduğun hakkında fikrin yoksa open source olarak github üzerinden paylaşılan API Security Checklist veyahut başka uygulamalar ile takip edebilirsin.

API Security & OWASP API TOP 10–2

Owasp API Top 10

medium.com