Web14: HTTP protokolündeki güvenlik sorunları

Bu makalede, RFC 7230 ve RFC 7231 adlı iki belgede dile getirilen, HTTP protokolündeki bazı güvenlik sorunları sunulmaktadır . Makalede belirli hatalara ilişkin örneklere OWASP'den başvurulmaktadır.

1. Ara faktörlerden kaynaklanan riskler

HTTP, aracıların bir dizi bağlantı aracılığıyla isteklere yanıt vermesine olanak tanır. Üç ortak aracı öğe vardır: proxy, ağ geçidi ve tünel.

Bir istek veya yanıtın A, B ve C noktalarından geçmesi gerekecektir. Kullanıcıların veya kuruluşların kişisel bilgileri gibi iletilen hassas bilgilere erişebilirler. Aracıların güvenliğe ve mahremiyete yeterince dikkat etmemesi, çok çeşitli potansiyel saldırılara yol açabilir.

Sistem geliştiricileri ve geliştiricileri, sistem tasarımı, kodlama ve dağıtım sürecinde gizlilik ve güvenlik faktörlerini dikkate almalıdır.

Kullanıcıların güvenilmeyen proxy'ler veya ağ geçitleri kullanmanın tehlikelerinin farkında olması gerekir.

2. Yanıt Bölme

Yanıt bölme (CRLF enjeksiyonu olarak da bilinir) popüler bir web istismar tekniğidir. Saldırgan, bazı istek parametrelerinde kodlanmış veriler gönderir ve bu veriler daha sonra kodu çözülür ve yanıt başlığının belirli bir alanında tekrarlanır.

Bu veri, yanıtın sonunu temsil eden bir sembol ise ve ardından bir yanıt başlatıldıysa, orijinal yanıt ikiye bölünecek ve ikinci yanıtın içeriği saldırgan tarafından kontrol edilecektir. Saldırgan daha sonra aynı kalıcı bağlantı içinde başka bir istekte bulunabilir ve alıcıyı (aracılar dahil) bu ikinci yanıtın ikinci isteğe yanıt olduğuna inandırarak kandırabilir.

3. Kaçakçılık Talebi

İstek kaçakçılığı, orijinal isteğe eklenen zararsız görünen istekleri gizlemek için farklı türdeki sunucular tarafından isteklerin işlenmesindeki farklılıklardan yararlanan bir tekniktir.

Aşağıdaki örneği ele alalım:

Bir POST isteğinin başlıkta iki farklı değere sahip iki "İçerik uzunluğu" alanı içerdiğini varsayalım. Bazı sunucular bu isteği reddeder (IIS ve Apache), ancak diğerleri reddetmez. Örneğin, SunONE W/S 6.1 ilk olarak İçerik uzunluğu alanını kullanırken, sunONE Proxy 3.6 İçerik uzunluğu alanını ikinci olarak alır.

SITE'ın, SunONE Proxy'nin arkasında bulunan SunONE W/S'nin DNS'si olduğunu varsayarsak, SunONE W/S'de bir zehir.html dosyası bulunur. İki sunucu arasındaki işlemlerdeki tutarsızlıklara dayalı olarak HTTP İstek Önerisinden nasıl yararlanabileceğiniz aşağıda açıklanmıştır:

[10. satır hariç her satırın CRLF (“”) ile bittiğini unutmayın]

Proxy sunucusu aracılığıyla W/S'ye bir istek gönderildiğinde ne olacağına bakalım. İlk olarak proxy, 1'den 7'ye kadar olan satırlardaki (mavi) isteği analiz edecek ve iki İçerik-Uzunluk alanıyla karşılaşacaktır. Yukarıda belirtildiği gibi ilk alanı göz ardı edecek ve istek gövdesinin 44 bayt uzunluğunda olduğunu anlayacaktır. Bu nedenle, 8'den 10'a kadar olan satırlardaki verileri ilk istek gövdesi olarak ele alır (8'den 10'a kadar olan satırlardaki veriler tam olarak 44 bayt uzunluğundadır). Proxy daha sonra müşterinin ikinci isteği olarak 11'den 14'e kadar olan satırları (kırmızı) analiz edecektir.

Şimdi proxy'den iletilen yukarıdaki verileri W/S'nin nasıl yorumladığını görelim. Proxy'lerden farklı olarak W/S, ilk Content-Length alanını kullanacak ve bunu şu şekilde yorumlayacaktır: ilk isteğin gövdesi yoktur ve ikinci istek 8. satırdan başlar (W/S'nin 11. satırdan itibaren değer olarak ayrıştırılacağını unutmayın). Bla alanının).

Sonra, yanıtın müşteriye nasıl döndürüldüğünü görelim. W/S'nin anladığı istek "POST /foobar.html" (1. satırdan) ve "GET /poison.html"dir (8. satırdan), yani müşteriye foobar sayfasının içeriğini içeren 2 yanıt gönderecektir. html ve zehir.html. Proxy, bu 2 yanıtın 2 isteğe karşılık geldiğini anlar: "POST /foobar.html" (1. satırdan) ve "GET /page_to_poison.html" (11. satır). Proxy, “page_to_poison.html” URL'sine karşılık gelen zehir.html sayfasının içeriğini önbelleğe alır (önbellek zehirlenmesi). Oradan, istemci "page_to_poison.html" isteğinde bulunduğunda, zehir.html sayfasının içeriğini alacaktır.

4. Dosya yoluna dayalı saldırı

Web sunucuları, URI'lerdeki dosya adlarının sunucudaki gerçek kaynaklarla eşlenmesini yönetmek için sıklıkla yerel dosya sistemlerini kullanır. Çoğu dosya sistemi, kötü amaçlı dosya yollarına karşı koruma sağlayacak şekilde tasarlanmamıştır. Bu nedenle sunucunun önemli sistem dosyalarına erişimden kaçınması gerekir.

Örneğin, UNIX, Microsoft Windows ve diğer birçok işletim sistemi, geçerli dosyanın/dizinin bir düzey üzerindeki bir dizini temsil etmek için yol öğesi olarak “..” kullanır. Uygun giriş kontrolü ve yetkilendirme olmadan, sistemin hassas dosyalarına/klasörlerine, bu dosyalara/klasörlere işaret eden yollar girilerek erişilebilir.

5. Saldırı türleri: Komut Enjeksiyonu, Kod Enjeksiyonu, Sorgu Enjeksiyonu

[Web sunucuları genellikle sistem komutlarını ve veritabanı sorgularını yürütmek için URI'deki parametreleri girdi olarak kullanır. Ancak istekte alınan verilere her zaman güvenilemez. Saldırgan, sistem komutlarını yürütmek, veritabanını sorgulamak için istekteki bileşenleri (yöntemler, başlıktaki alanlar, gövde... gibi) oluşturabilir ve değiştirebilir...

Örneğin, SQL Enjeksiyonu, web sunucusunun URI'de SQL sorgusunun parçası olan parametreleri aldığı yaygın bir saldırıdır. Bu nedenle, bir saldırgan veritabanını çalmak veya sabote etmek amacıyla web sunucusunu yasa dışı SQL sorguları yürütmesi için kandırabilir.
Genel olarak kullanıcılar tarafından gönderilen veriler doğrudan sunucu üzerinde işlem gerçekleştirmek için kullanılmamalıdır. Bu verilerin, neyin geçerli, neyin geçersiz olduğunu tanımlayan ve böylece istenmeyen verileri ortadan kaldıran filtrelerden geçmesi gerekir.

6. Kişisel bilgilerin ifşa edilmesi

İstemciler genellikle, kullanıcı tarafından sunucuyla etkileşimde bulunmak için sağlanan bilgiler (kullanıcı adı, şifre, konum, e-posta adresi vb.) ve kullanıcının web tarama etkinlikleriyle ilgili bilgiler (geçmiş, yer imleri, vb.) dahil olmak üzere birçok kişisel bilgi içerir. vesaire.). Uygulama sırasında bu özel bilgilerin açığa çıkmasına neden olabilecek noktaların önlenmesine dikkat edilmelidir.

7. URI'deki hassas bilgilerin açığa çıkarılması

URI'lerin tasarımı gereği tüm kullanıcılarla paylaşılması amaçlanmıştır ve güvenli oldukları garanti edilmez. URI'ler genellikle web sitesinin kaynak kodunda görüntülenir ve koruma mekanizmaları olmadan yer imlerinde saklanır. Bu nedenle URI'nin hassas bilgiler, kişisel bilgiler vb. içermesi güvenli olmayacaktır.

Kişisel bilgileri sunucuya göndermek için GET yöntemini kullanmaktan kaçının; zira bu bilgiler URI'de görüntülenecektir. Bunun yerine POST yöntemini kullanın.

8. Kullanılan yazılım bilgilerinin ortaya çıkarılması

Başlıktaki User-Agent, Via, Server alanları genellikle gönderenin kullandığı yazılım hakkında bilgi sağlar. Teorik olarak bu, saldırganların bu yazılımlardaki bilinen güvenlik açıklarından daha kolay yararlanmasına olanak tanır.