PDF jeneratörlerinde SSRF güvenlik açıklarını bulmak için eksiksiz bir rehber


PDF jeneratörleri uygulamalarda yaygın olarak uygulanır. Geliştiriciler, bu bileşenleri, örneğin veritabanından sağlanan dinamik verilere dayalı belgeler oluşturmak için kullanma eğilimindedir. Ne yazık ki, her geliştirici bu işlevselliği entegre ederken tanıtabileceği potansiyel risklerin de farkında değildir.

Bu makalede, PDF jeneratörlerinde tasarlanmamış kullanıcı tarafından kontrol edilebilen girdilerin işlenmesinin, bu özellikleri nasıl kullanabileceğimize ve daha fazla etki için ilk bulgularımızı nasıl artırabileceğimize derinlemesine dalacağız.

Hadi dalalım!

PDF jeneratörleri, bir web uygulamasında, parametrelerden, veritabanı içeriğinden veya diğer veri kaynaklarından alınan dinamik verilere dayanan PDF belgelerinin oluşturulmasına izin veren bir bileşendir. PDF jeneratörleri, makbuz ve fatura üretiminden rapor ve sertifika vermeye kadar birçok uygulamaya sahiptir.

Geliştiriciler genellikle dinamik PDF belgeleri oluşturmak için popüler (açık kaynak) kütüphaneler ve üçüncü taraf hizmetleri kullanmaya başvururlar. Bu kütüphaneler, dinamik PDF belgeleri oluşturmak için çeşitli yöntemleri kullanır.

Hedefinizin sizin için bir PDF ihracatı oluşturabilmesinin 3 ortak yolunu keşfedelim.

HTML – PDF (en yaygın yaklaşım)

Bu işlem genellikle başsız bir web tarayıcısının (krom gibi) dağıtılmasını, HTML şablonunu dinamik verilerle oluşturmayı ve PDF belgesini oluşturmak için bir tarayıcı API’sını çağırmayı içerir. Bu belge üretim sürecinin tamamı, PDF dosya dışa aktarma oluşturma zamanının zaman aldığı için genellikle sunucu tarafında gerçekleşir.

Kullanıcı tarafından kontrol edilebilir giriş doğrudan HTML şablonuna doğru birleştirilirse, uygun sanitizasyon olmadan, çoğu durumda sunucu tarafı isteği ameliyatı (SSRF), yerel dosya ifşa (LFD) ve diğer HTML enjeksiyonuna duyarlı olabilir. Güvenlik açığı türleri.

Şablon tabanlı nesil

Bazı kütüphaneler belirli bir şablon dilinde tanımlanmış önceden yapılandırılmış şablonlara güvenir. Dinamik veriler daha sonra son belge oluşturulup dışa aktarılmadan önce şablon alanlarına eşlenir.

Önceki yöntemde olduğu gibi, kullanıcı tarafından kontrol edilebilir giriş doğrudan şablona birleştirilirse, basit içerik enjeksiyonundan kod enjeksiyonlarına ve uzaktan kod yürütülmesine kadar çok çeşitli güvenlik açıklarıyla sonuçlanan enjeksiyon saldırılarına duyarlı olabilir.

UÇ! CVE-2023-33733 enjeksiyon sorununuzu bir kod enjeksiyon güvenlik açığı haline getirmenin nasıl mümkün olduğunu gösteren mükemmel bir örnektir!

Üçüncü taraf hizmet

Bazı uygulamalar harici hizmetlerden yararlanır. Bu işlem genellikle dinamik verilerin üçüncü taraf API’sına gönderilmesine ve API yanıtında PDF dosyasını almaya dayanır. Yönetilen PDF üretimi sunan üçüncü taraf hizmetleri genellikle enjeksiyon saldırılarına daha az duyarlıdır.

Bu yöntem daha az yaygın olarak kullanılır, çünkü bu yaklaşım, özellikle hassas veriler (faturalar ve makbuzlar gibi) gönderirken gizliliği her zaman garanti etmez.

Bu makalede, esas olarak ilk ve en yaygın PDF üretici yöntemi kapsayacağız.

PDF jeneratörleri, web uygulamalarında yaygın olarak kullanılır: şu şekilde dinamik belgeler oluşturmak için kullanılır:

  • Raporlar (örneğin, analiz raporları veya diğer rapor türleri)

  • Makbuzlar ve Faturalar (özellikle e-ticaret hedeflerinde)

  • Hesap Arşivleri

  • Banka Hesap İfadeleri

  • Sertifikalar (Eğitim ve Eğitim Platformlarında daha yaygın)

PDF üretim özelliği örneği

Şimdi sunucu tarafı isteği ampudu elde etmek ve ilk bulgularımızı daha da artırmak için PDF jeneratörlerinin nasıl kullanacağına ayrıntılı bir bakalım!

PDF üretimi zaman alabilir ve bu nedenle genellikle eşzamansız olarak (daha sonra bu konuda) ve sunucu tarafında olur. Kullanıcı tarafından kontrol edilebilen veriler güvensiz bir şekilde işlendiğinde ve doğrudan bir HTML şablonunda birleştirildiğinde, HTML veya keyfi JavaScript kodu enjekte etmek mümkün olabilir.

Birkaç örneğe bir göz atalım.

Tam SSRF güvenlik açıklarından yararlanmak

Aşağıdaki kod snippet’ine bir göz atın:

API uç noktası faturalanma Vücut parametresi ve kullanıcı tarafından kontrol edilebilir HTML’yi uygun sanitasyon olmadan oluşturur. Bu, komut dosyası etiketleri de dahil olmak üzere, JavaScript’in sunucu tarafında yürütülmesine izin veren keyfi HTML etiketleri oluşturabileceğimiz anlamına gelir.

Bu bilgilerle, hedef sunucu adına herhangi bir kaynağın yanıtını oluşturmak için bir yük oluşturabiliriz. Örneğin, aşağıdaki isteği göndermek, oluşturulan yanıtla bir PDF dosyasını almamıza izin verecektir:

POST /api/invoice/export HTTP/2
Host: app.example.com
Content-Type: application/json
Content-Length: 106

{
    "invoiceData": ""
}

Oluşturulan bir PDF dosyası örneği

Ne yazık ki, IFrame etiketi her durumda çalışmaz. Bazı hedefler zaten XSS gibi enjeksiyon saldırılarına karşı aktif önlemler kullanmıştır. Komut dosyası etiketinizin engellenmesi durumunda, hedefiniz adına harici içerik istemek için aşağıdaki yüklerden birini deneyin:








Kör SSRF güvenlik açıklarından yararlanmak

Bazı durumlarda, örneğin agresif XSS filtreleri nedeniyle tam SSRF mümkün olmayacaktır. Bu durumda, kör bir XSS yükü enjekte ederek sunucu adına harici kaynaklar talep etmeye çalışabiliriz:








Source link