Hacker destekli 7. güvenlik raporuna göre Idor, Hackerone platformu aracılığıyla bildirilen güvenlik açıklarının% 7’sini oluşturuyor. Devlet kurumları ve otomotiv örgütleri, Idor raporlarının özellikle yüksek olayları gördü ve devlet kurumlarına raporların% 15’ini ve otomotiv sektöründeki raporların% 11’ini oluşturdu.
Idor güvenlik açıkları, aşağıdakiler dahil olmak üzere çeşitli bileşenlerde ortaya çıkabilir:
URL sorgu parametreleri
Bir URL adresindeki sorgu parametreleriyle ilişkili kaynaklar son kullanıcılar tarafından kolayca değiştirilebilir. Örneğin:
| https://example.com/account?id=3 |
Hangi kullanıcı hesabının görüntülendiğini belirten kimlik parametresinin sayısal değerini değiştirerek, bir kullanıcı, verilen numara bir hesapla ilişkilendirildiği sürece başka bir kullanıcının hesaplarına erişebilir. Kullanıcı izinlerini doğrulamayan eksik erişim kontrolü kontrolleri nedeniyle oluşur. Hız sınırlama uygulamasının yokluğunda, otomatik takımlar kısa sürede büyük miktarda potansiyel sayısal değerlerle yineleyebilir.
Dosya adları ayrıca Idor güvenlik açığı sömürüsü için olası bir saldırı vektörü olabilir. Doğrudan aynı dizin içindeki dosyalara veya kullanılarak referans verilebilirler. dizin geçişi Teknikler (veya sadece mutlak yolu tedarik etmek), tüm dosya sistemi ortaya çıkabilir.
HTTP istekleri
Hipermetin Taşıma Protokolü (HTTP) istekleri, Idor sömürüsüne yol açabilecek birden fazla farklı unsur içerir, örneğin:
Başlıklar: Çerezler gibi, kullanıcıya özgü kaynaklara hizmet etmek için kullanıcı tanımlayıcıları olarak hizmet veriyor. Değerler yeterli entropi yoksa, geçerli değerler kolayca tahmin edilebilir. Açıklamak için, aşağıdaki örnek sadece altı karakter uzunluğunda bir SessionID çerezi kullanır. Her seansID, son üç endeksi dolduran sayılarla aynı üç küçük harf formatına bağlı kalırsa, olası benzersiz kombinasyonların toplam sayısı 17.576.000’dir. Yine, oran sınırlama ile sunulan korumalar olmadan, aktif kullanıcı oturumlarını numaralandırmak için otomatik araçlar kullanılarak büyük miktarlarda istek gönderilebilir ve hesap devralmasına yol açar.
| HTTP /1.1’i al /yüklüyor Host: Örnek.com Çerez: seansId = ABC123 |
Vücut Verileri: Vücut verileri, çoklu tiplerinde savunmasız parametreler içerebilir. Örneğin, ilişkili e -posta adresini bir hesaba değiştirmek için aşağıdaki form gönderme talebi, bir mağdur hesabı üzerinde kontrol sahibi olmak için kötü niyetli saldırganlar tarafından kullanılabilir:
| Post /Change-Account-Email HTTP /1.1 Host: Örnek.com İçerik Türü: Uygulama/X-WWW-Form-Urlence kodlu İçerik uzunluğu: 44 Kullanıcı Adı = Johndoe & E -posta = Johndoe%40Example.com |
API isteklerinde gönderilen JSON verileri de bir güvenlik açığı kaynağı olabilir:
| Post/API/V2/USER-DATA HTTP/1.1 Host: Örnek.com İçerik Türü: Uygulama/JSON İçerik uzunluğu: 64 { |
HTTP yanıtları
Yanıtlar ayrıca savunmasız başlıklar ve vücut verilerini de içerebilir. Örneğin, kullanıcının rolüne bağlı olarak kullanıcı arayüzünün farklı öğelerini görüntülemek için özellik bayraklarını kullanarak bir web uygulaması düşünün. Eşleşme ve yerine kuralları kullanmak, idor güvenlik açıklarını kolaylaştırabilir. Yanıtta sunulan HTML dosyası, aşağıdakilere benzer bir parametre içerebilir:
Isadmin’in değerini True olarak ayarlamak, kullanıcı arayüzünün yalnızca meşru web sitesi yöneticileri için tasarlanmış bölümlerini etkinleştirebilir.
İstismar
27 Eylül 2022’de Güvenlik Araştırmacısı ReachAxis, keşfettikleri bir idor güvenlik açığını açıklayan bir rapor sundu. https://mtnmobad.mtnbusiness.com.ng/. Yetkilendirme doğrulama eksikliği nedeniyle, uzak kullanıcılar başka bir kullanıcının hesap bilgilerini değiştirebildiler.
Değiştirilebilen bilgiler, kullanıcı adı, şirket adı, adres, şirket büyüklüğü ve ilişkili hesabın cep telefonu numarasını eleştirel olarak içermektedir.
Bu web uygulaması reklam ortakları için hesaplar sağladığından, bir saldırgan verilen telefon numarasını kullanarak etkilenen şirketi olumsuz taklit edebilirdi. Bu nedenle, bulgu ciddiyet olarak kritik olarak derecelendirildi.
Üreme Adımları
1. İki hesap oluşturuldu: Biri kurbanın temsilcisi, diğeri bir saldırganın rolünü üstlenerek.
2. Her iki hesap da oturum çatışması sorunlarından kaçınmak için ayrı tarayıcılar kullanılmak üzere kaydedildi.
3.. Post talebine yanıt olarak /app/gösterge paneli verileri uç nokta, hesap kimliği ve diğer hesaplarla ilişkili e -posta alınabilir.
4. Hesap bilgilerini güncellemek için kullanılan form şu adreste bulunuyordu. https://mtnmobad.mtnbusiness.com.ng/#/userprofile. Formun gönderilmesi, /app/updateuser uç nokta.
5. Formu saldırganın oturumuna göndererek ve sonraki talebi ele alarak /app/updateuser Bir HTTP proxy aracı kullanılarak istek değiştirilebilir.
| Post/App/UpdateUser HTTP/1.1 Host: mtnmobad.mtnbusiness.com.ng -snip– “Güncellemeler”:[ { “param”:”user”, “value”:{ “id”:”/333″, “contact”:{ “name”:”ABC”, “address”:”ABC” “mobile”:”0000000123″ “email”:”[email protected]” }, “companyName”:”ABC”, “companySize”:”<50" }, “op”:”a” } ]- -snip– |
6. Mağdurlarla eşleşecek hesap kimliğini ve e -postasını değiştirerek, kurbanın hesabıyla ilişkili kullanıcı adı, şirket adı, adres, şirket büyüklüğü ve cep telefonu numarası keyfi değerlerle değiştirilebilir.
| HTTP/1.1 200 Tamam Sunucu: Nginx/1.4.6 (Ubuntu) -snip– { |
İdor saldırılarına karşı korumak
İdor güvenlik açıkları erişim kontrolü güvenlik açıklarının bir alt kümesi olarak kabul edildiğinden, uygun yetkilendirme mekanizmalarının uygulanması bu güvenlik açığını önleyebilirdi.
Diğer hesapların hesap tanımlayıcısı ve e -posta adresi gibi hassas verilerin tüm kullanıcılara açıklanması, bu güvenlik açığından yararlanmada anahtardı. Mağdurun hesabıyla ilişkili e -posta adresini bilmeden, bir düşman bu güvenlik açığından yararlanmak için çok daha zor bir zaman geçirirdi.
Öte yandan, saldırgan sadece mağdurun hesabının e -posta adresini bilseydi, hesap tanımlayıcısının sadece üç basamak uzunluğunda olduğunu belirtmek gerekir, yani sadece 1000 olası benzersiz kombinasyon vardı. Bir saldırgan, otomatik araç kullanılarak geçerli bir e -posta adresi sağladıysa, eşleşen hesap tanımlayıcısı çok kısa sürede keşfedilmiş olabilir.
Benzer nitelikte ortaya çıkan idor güvenlik açıklarını düzeltmek için, aşağıdaki en iyi uygulamalara uyulmalıdır:
- Otomatik takımlara yalnızca olası idor güvenlik açıklarını belirlemek için güvenilmemelidir. Manuel inceleme, uygulamanızın, uygulamanızın altında yatan mantığın derin bir şekilde anlaşılması gerektiğinden, bu sorunların kaynağı olabilecek alanları tanımlamak için en iyi yöntemdir.
- Geliştiriciler, nesnelere referansları kamuya açıklamaktan kaçınmalıdır, bu durumda olduğu gibi, yalnızca iki nesnenin numaralandırılmasını gerektirir (Hedef kimlik ve e -posta) bir saldırı yapmak için.
- Kaynaklara yapılan herhangi bir referans, kısa uzunlukta sayısal, muhtemelen sıralı değerlerden ziyade kriptografik olarak güçlü rastgele değerler olmalıdır. Bu gizlenmiş değerler daha sonra uygulama ikisiyle eşleşebilmesi için orijinal referanslarına geri eşlenebilir. Bunun derinlemesine bir savunma önlemi olarak kabul edildiğini ve yalnızca güvenilmemesi gerektiğini unutmayın.
- Otomatik takımlara karşı koymak için, isteklerin normal kullanıcı etkinliği seviyelerine gerçekçi bir oranda işlenmesini sağlamak için hız sınırı korumaları entegre edilebilir.
- Yetkilendirme, doğru kullanıcıların yalnızca kendileri için amaçlanan kaynaklara eriştiğini doğrulamak için kontrol eder. Uygun kaynakları bir kullanıcının oturumuyla ilişkilendirerek, ek kaynaklara yetkisiz erişim hafifletilebilir. Bunu kolaylaştırmak için genellikle yollar sağlayan web çerçeveleri vardır.
Çözüm
Idor güvenlik açıklarının varlığı, bir kuruluş ve kullanıcıları için ciddi sonuçlara yol açabilir. Güvenlik en iyi uygulamalarına bağlı kalarak, bu tür bir saldırıya kurban düşme riski büyük ölçüde azaltılabilir. Nasıl meydana geldiklerini ve nasıl sömürüldüğünü anlayarak, siz ve ekibiniz, idor güvenlik açığı ile sonuçlanacak potansiyel koşulları belirleyebileceksiniz.