HTTP Durum Kodları Bir Bilgisayar Korsanını Nasıl İhbar Edebilir?


HTTP Durum Kodları

İnternet dünyasında, istemcinin sunucuya yaptığı isteğin sonucunu belirtmek için kullanılan HTTP durum kodları için beş farklı kategori vardır. Hem istemcinin (web tarayıcınız veya uygulamanız gibi) hem de sunucunun iletişim sırasında ne olduğunu anlamasına yardımcı olurlar.

Bu kategoriler arasında en yaygın olanları şunlardır:

Hizmet Olarak SIEM

  • Kategori 2xx – İsteğin başarıyla alındığı, anlaşıldığı ve kabul edildiği başarı.
  • Kategori 3xx – İstemcinin isteği tamamlamak için ek işlem yapması gerektiğini belirten yönlendirmeler. Bu kodlar genellikle kullanıcıları farklı bir URL’ye veya kaynağa yönlendirmek için kullanılır.
  • Kategori 4xx – İstemci Hatası, istemcinin isteği nedeniyle bir şeylerin ters gittiğini gösterir (yanlış yazılmış bir URL gibi).
  • Kategori 5xx – Sunucu Hatası, sunucu tarafında bir şeylerin ters gittiğini gösterir.

Bu makalede iki spesifik HTTP durum koduna odaklanacağız:

  • “401 Yetkisiz”, istemcinin kimliğinin doğrulanmadığını ve bu nedenle kaynağa erişim yetkisinin olmadığını gösterir.
  • “403 Yasak”, bu, istemcinin kimliğinin doğrulandığı ancak kaynağa erişim izninin olmadığı anlamına gelir.

Varsayımsal Bir Spor Salonu Uygulamasında API Güvenliğini Keşfetmek

Şimdi, yakın zamanda mahallenizdeki bir spor salonuna katıldığınızı ve tesise erişim sağlamak ve grup derslerine kaydolmak için kullanmanız gereken özel bir web uygulamasına sahip olduklarını hayal edelim.

Eğer teknoloji insanıysanız ve benim gibi meraklıysanız ilk yapacağınız şeylerden biri trafiği keserek ne tür taleplerin geldiğini görmek olacaktır.

Yani, giriş yaptıktan ve Burp Suite gibi bir araç kullandıktan sonra uygulama isteklerini ve bunlara karşılık gelen yanıtları yakalayabilirsiniz. Birkaç isteği analiz ettikten sonra ilginç bir istek açılır: Uygulamadaki belirli bir kullanıcı hakkındaki bilgileri listeleyen API isteğini görebilirsiniz.

API kavramına aşina olmayanlar için, Uygulama Programlama Arayüzü anlamına gelir ve bunu bir programdan istek alan, başka bir programa neyin gerekli olduğunu söyleyen ve ardından yanıtı geri getiren bir mesajlaşma aracı olarak düşünebilirsiniz.

API Yanıtları ve Bilgilerin Gösterimi

Şimdi kullanıcının bilgilerine ulaşmak için ihtiyacınız olan tek bilginin kullanıcının e-posta adresi olduğunu varsayalım. Bu durumda API uç noktası şöyle görünecektir: https://mygymapp.com/api/users/[email protected].

Giriş yaptığınız için API yanıtında görüntülenen bilgiler, uygulamada mevcut olan kişisel verilerinizdir; yani üyelik numaranız, tam adınız, telefon numaranız ve doğum tarihiniz. Bu senaryoda 200 OK!

Peki ya e-postayı şu şekilde değiştirirseniz: [email protected] ve başkalarının kullanıcı bilgilerine erişip erişemediğinizi kontrol edin? Bu durumda API isteği şöyle görünecektir: https://mygymapp.com/api/users/[email protected].

Ancak bu kullanıcının bilgilerine erişmeye çalıştığınızda “404 Bulunamadı” mesajı alıyorsunuz, bu da spor salonu uygulamasında o e-postaya kayıtlı bir kullanıcı olmadığı anlamına geliyor.

Üçüncü seferin çekiciliği olduğundan ve şans eseri sizinle aynı spor salonuna giden bir arkadaşınız olduğundan, onun bilgilerini görüp göremediğinizi görmek için API isteğinde onun e-postasını kullanmayı denemeye karar verirsiniz.

Ancak şaşkınlıkla, daha önce aldığınız koddan farklı bir “403 Yasak” koduyla karşılaşıyorsunuz.

Bu ne anlama gelir? Bu, arkadaşınızın e-postasının uygulamada geçerli olduğu ancak onun bilgilerine erişmek için yeterli izniniz olmadığı anlamına gelir.

İlginç. Spor salonu uygulamasından çıkıp aynı istekleri tekrar yaparsanız ne olur? Bu senaryoda, kendinizin veya arkadaşınızın bilgilerine erişmeye çalıştığınızda “401 Yetkisiz” hatası alırsınız..

Ancak erişmeye çalıştığınızda [email protected] bilgi, yine “404 Bulunamadı” mesajı alırsınız!

Bir Hacker’ın bakış açısına göre, aynı API isteğini kullanarak birden fazla kaynağa erişmeye çalışırken hem “401 Yetkisiz” hem de “403 Yasak” ve “404 Bulunamadı” kodlarını almak son derece değerlidir.

Bu yaklaşım, spor salonu uygulamasında hangi hesapların geçerli, hangilerinin geçerli olmadığını belirlemeyi kolaylaştırır. Bu tekniğe kullanıcı numaralandırma adı verilir.

Belki spor salonu uygulamasında hangi hesapların geçerli olduğunu ve hangilerinin olmadığını bilmenin bir Hacker için neden ilginç bir bilgi olduğunu merak ediyorsunuzdur. Gerçek şu ki, küçük şeyleri bir araya getirdiğinizde çok daha büyük bir şeye dönüşebilirler.

Bilgisayar korsanları, güvenliği artırmayı amaçlayan yapıcı eylemlerden, kişisel kazanç veya kesintiye yönelik kötü niyetli faaliyetlere kadar çok çeşitli hedeflerle çalışır.

OSINT ve Kimlik Avı Stratejilerinden Yararlanma

Bu durumda, Hacker için olası bir yol, Açık Kaynak İstihbaratı (OSINT) araçlarını kullanarak uzun bir e-posta adresi listesi oluşturarak başlayabilir.

OSINT, eyleme geçirilebilir istihbarat üretmek için çeşitli kaynaklardan kamuya açık bilgilerin toplanması ve analiz edilmesi sürecini ifade eder.

İnternette, alan adına göre e-posta adreslerinin bir listesini almaya olanak tanıyan çok sayıda OSINT aracı bulunmaktadır.

Bu senaryonun başarılı olması için Hacker’ın spor salonu uygulamasında hangi e-posta adreslerinin geçerli olduğunu doğrulaması gerekir.

Bunu başarmak için Hacker, API isteğindeki e-posta adresini yeni oluşturulan listedeki her girişle değiştirir. Bu değişikliğin saniyeler gibi kısa bir zaman dilimi içinde tekrar tekrar gerçekleştirilmesi, Kaba Kuvvet saldırısı olarak bilinir.

Bilgisayar Korsanı, spor salonu uygulamasındaki geçerli e-posta adreslerini doğruladıktan sonra, başka bir makul yol, kimlik avı e-postası hazırlamak olabilir.

Kimlik avı, bireyleri kullanıcı adları, şifreler, kredi kartı numaraları veya diğer kişisel veriler gibi hassas bilgileri ifşa etmeleri için kandırmayı amaçlayan bir tür sosyal mühendislik saldırısıdır.

Bu e-posta adresleri arasında şu ana kadar tek ortak noktanın spor salonu uygulaması olduğu göz önüne alındığında, kimlik avı e-postasının ilgi çekici konu satırı “Ücretsiz Bir Ay Kazanın!” olabilir. veya “Ücretsiz Kişisel Eğitim Seansı Alın”.

Kullanıcının, maket çekilişine katılmak için yalnızca bir düğmeye tıklaması ve oturum açma bilgilerini girmesi yeterlidir.

Artık Hacker tek bir kullanıcıyı hedeflemek isterse kullanıcının e-posta adresiyle ilişkili sosyal medya profillerini bulmak için OSINT araçlarını kullanabilir.

Hacker, bu profillerdeki bilgilerden yararlanarak kullanıcıya yaklaşabilir, bağlantı kurabilir ve ardından hedeflenen kimlik avı mesajları gönderebilir.

OSINT araçlarını kullanarak belirli bir kullanıcının telefon numarasını ortaya çıkarmak da mümkündür.

Hacker’ın kullanıcının hem e-posta adresine hem de telefon numarasına sahip olduğu bu durumda, sosyal mühendislik saldırısını gerçekleştirmek için hem kimlik avı hem de vishing taktiklerini birleştirmek mümkündür. Vishing, sesli aramaları kullanan bir kimlik avı biçimidir.

API Güvenliğini Güçlendirmek İçin En İyi Uygulamalar

Peki “401 İzinsiz” ve “403 Yasak” olaylarının daha büyük bir soruna dönüşmesini nasıl önleyebiliriz? HTTP durum kodları geliştiriciler için web uygulamaları oluştururken ve sorun giderirken son derece değerli olsa da, şu ana kadar gördüğümüz gibi Bilgisayar Korsanlarına da yararlı ipuçları sağlayabilir.

Potansiyel bir önleyici tedbir, GitHub’un tekniğini takip etmek ve “401 Yetkisiz” veya “403 Yasak” yerine “404 Bulunamadı” sonucunu döndürmek olabilir. Bu teknik, erişim izinsiz veya yasak olduğunda bir kaynağın var olup olmadığını açığa çıkarmayarak güvenliğin artırılmasına yardımcı olur.

Bununla birlikte, bu teknik geliştiricilerin kafasını karıştırabilir; bu nedenle, onların bu konuda bilgilendirildiğinden emin olmak için bunu API belgelerine dahil etmek iyi bir uygulamadır.

Başka bir olası önleyici tedbir, API isteğinde kullanıcının e-posta adresinin harf ve rakamlardan oluşan rastgele ve sıralı olmayan bir tanımlayıcıyla değiştirilmesi olabilir. Bu önlemi öncekiyle birleştirmeyi de seçebilirsiniz.

Ayrıca, hiçbir hassas bilginin ifşa edilmediğinden emin olmak için kullanıcıları kimlik avı ve vishing saldırılarının varlığı ve tehlikeleri konusunda eğitmek de önemlidir. Ayrıca, bir kimlik avı e-postası durumunda arayanın veya bir kimlik avı e-postası durumunda gönderenin kimliğini her zaman doğrulamak önemlidir.

Arayanın kimliğini doğrulamak için kullanıcılar telefonu kapatabilir ve doğrudan spor salonunu arayarak aramanın meşru olup olmadığını belirleyebilir. Kimlik avı e-postası durumunda kullanıcılar, e-postanın gerçekten spor salonunda çalışan biri tarafından gönderildiğini doğrulamadan herhangi bir bağlantıya tıklamamalı veya hassas bilgiler vermemelidir.

Gerçek Dünya İhlali: Duolingo Örneği

Bu yazımızda bir spor salonu uygulamasına odaklandık; ancak örnek olarak rezervasyon uygulamasından dil öğrenme uygulamasına kadar başka herhangi bir uygulama türünü de seçebilirdik.

Son yıllarda, bilgisayar korsanlarının yalnızca e-posta adreslerini alarak kullanıcıların bilgilerine erişebildiği birçok veri ihlaline tanık olduk.

Dikkate değer bir örnek, Duolingo API’sine gönderilen geçerli bir e-postanın kullanıcıya ilişkin genel hesap bilgilerini döndürdüğü Duolingo veri ihlalidir.

Bu güvenlik açığı bulunan API, bir bilgisayar korsanlığı forumunda 2,6 milyon Duolingo kullanıcısının verilerinin sızdırılmasına yol açtı. Duolingo’ya aşina değilseniz, aylık 74 milyondan fazla kullanıcısı olan, yaygın olarak kullanılan bir dil öğrenme uygulamasıdır.

Gerçek adları, oturum açma adlarını, e-posta adreslerini ve hizmetle ilgili diğer dahili ayrıntıları içeren ele geçirilen veriler, ilk olarak Ocak 2023’te bir bilgisayar korsanlığı forumunda 1500 ABD doları karşılığında satışa sunuldu.

Bu durumda Duolingo kullanıcılarının kimlik avı e-postalarının hedefi olması durumunda dikkatli olmaktan başka yapacak bir şey yoktu.

İşlevsellik ve Güvenliği Dengeleme

Sonuç olarak, isteklerin sonuçlarını ilettikleri ve sorun gidermeye yardımcı oldukları için HTTP durum kodlarını anlamak geliştiriciler için çok önemlidir. Ancak geliştiricilerin anlamlı yanıtlar sunma ile uygulama güvenliğini sağlama arasında bir denge kurması gerekiyor.

Geliştiriciler, ayrıntılı durum mesajlarıyla ilişkili potansiyel risklerin farkında olarak, olumlu bir kullanıcı deneyimi sunarken uygulamaları ve kullanıcılarını koruyabilirler.

Bu makale Siemens Energy Siber Tehdit Avcısı Teresa Pereira tarafından yazılmıştır..



Source link