- 29 Eki 2018
- 2,702
- 568
Web Cache Poisoning
Bu konuda, Web Cache Poisoning nedir ve web cache poisoning açıkları neden oluşur sorularına cevap vereceğiz. Ayrıca, bu güvenlik açıklarını nasıl sömürebileceğinizden ve onları nasıl engelleyebileceğinizden bahsedeceğiz.
Web Cache Poisoning yani Web önbellek zehirlenmesi, bir saldırganın, önbelleğin davranışından faydalanıp başka kullanıcılara zararlı bir HTTP yanıtı sunmasını sağlayan gelişmiş bir tekniktir.
Temel olarak, web önbellek zehirlenmesi iki aşamadan oluşur. İlk olarak saldırgan, backend serverdan tehlikeli payload içeren bir yanıtı nasıl tetikleyeceğini bulmalıdır. Başarılı olursa, yanıtlarının önbelleğe alınmasını ve ardından hedeflenen kullanıcılara sunulmasını sağlamalıdırlar.
Biz bu sadırganın başarılı olduğu durumda önbelleğe zehirlenmiş diyelim. Bu zehirlenmiş önbelleği XSS, JavaScript enjeksiyonu, Open redirection gibi güvenlik açıklarını kullanarak çok sayıda farklı saldırının kombine edilmesine yardımcı olabilir.
Bu arada zaten bu konuyu biliyorsanız konu sonundaki yorumlardan lablere gidin ve onları çözmeye çalışın.
Web Cache Poisoning Araştırması
Bu teknik ilk olarak 2018 yılında bir araştırma makalesi olan "Practical Web Cache Poisoning" ile popüler hale geldi ve 2020 yılında ikinci bir araştırma makalesi olan "Web Cache Entanglement: Novel Pathways to Poisoning" ile daha da geliştirildi. Bu güvenlik açıklarının internet ortamında nasıl keşfettiğimizi ve faydalandığımızı ayrıntılı olarak öğrenmek istiyorsanız detaylı makalelere ulaşabileceğiniz konu sonunda 2 link bıraktım.
Web önbelleği nasıl çalışır?
Web cache poisoning açıklarının nasıl ortaya çıktığını anlamak için, web önbelleklerinin nasıl çalıştığını bilmek gerekli.
Bir sunucu her HTTP isteğine ayrı bir yeni yanıt göndermek zorunda olsaydı bu muhtemelen sunucuda aşırı yüklenmeye neden olurdu ve bu da birçok soruna ve özellikle yoğun dönemlerde kötü bir kullanıcı deneyimine neden olur. Caching bu tür sorunlara çözüm olarak vardır.
Önbellek, sunucu ve kullanıcı arasında belirli isteklerin yanıtlarını (önbelleğe) kaydeder. Başka bir kullanıcı daha sonra eşdeğer bir istek gönderirse, Backend server ile herhangi bir etkileşim olmaksızın önbellek yalnızca önbelleğe alınmış yanıtın bir kopyasını doğrudan kullanıcıya sunar. Bu, sunucu üzerindeki yükü büyük ölçüde azaltır ve serverın işlemesi gereken yinelenen isteklerin sayısını azaltır.
Önbellek anahtarları (Cache keys)
Önbellek bir HTTP isteği aldığında, önce önbelleğe alınmış doğrudan çalışabilecek bir yanıt olup olmadığını veya isteği backend sunucusuna iletmek zorunda olup olmadığını belirlemelidir. Önbellekler, bir isteğin yapısının önceden tanımlanmış mı diye karşılaştırma yaparak o isteğe eşdeğer istekleri belirler. İşte bu noktada işin içerisine cache key yani önbellek anahtarı giriyor. Genellikle istek satırını ve Host headerını içerirler. Cache keye dahil edilmeyen istek bileşenleri anahtarsız(unkeyed) olarak adlandırılır.
Gelen isteğin önbellek anahtarı önceki isteğin anahtarıyla eşleşirse, önbellek bunları eşdeğer olarak kabul eder. Sonuç olarak, orijinal istek için oluşturulan önbelleğe alınmış yanıtın bir kopyasını sunar. Bu, eşleşen önbellek anahtarına sahip tüm sonraki istekler için de geçerli olur ta ki önbelleğe alınmış yanıtın süresi dolana kadar. İsteğin diğer bileşenleri önbellek göz ardı edilir. Bunun etkisinden de ilerde bahsedeceğiz.
Web Cache Poisoning saldırısının etkisi nedir?
Bu saldırının etkisi iki temel faktöre bağlıdır:
_____________________________________________________
Bir önbellek girdisinin süresinin web önbellek zehirlenmesinin etkisini etkilemediğini unutmayın. Bir saldırı genellikle önbelleği süresiz olarak yeniden zehirleyecek şekilde senaryolaştırılabilir.
Web önbelleği zehirleme saldırısı oluşturma
Anahtarlanmamış girdileri tanımlama ve değerlendirme
Herhangi bir web önbellek zehirleme saldırısı, başlıklar gibi anahtarlanmamış girdilerin manipülasyonuna dayanır. Web önbellekleri, kullanıcıya önbelleğe alınmış bir yanıt sunulup sunulmayacağına karar verirken anahtarlanmamış girdileri göz ardı eder. Bu davranış, payload'ı enjekte etmek ve önbelleğe alınırsa istekleri eşleşen önbellek anahtarına sahip tüm kullanıcılara sunulacak "zehirli" bir yanıt ortaya çıkarmak için bunları kullanabileceğiniz anlamına gelir. Bu nedenle, bir web önbelleği zehirleme saldırısı oluştururken ilk adım, sunucu tarafından desteklenen anahtarsız girdileri belirlemektir.
Anahtarlanmamış girdileri, isteklere rastgele girdiler ekleyerek ve bunların yanıt üzerinde bir etkisi olup olmadığını gözlemleyerek manuel olarak belirleyebilirsiniz. Bu, girdiyi doğrudan yanıta yansıtmak veya tamamen farklı bir yanıtı tetiklemek gibi açık olabilir. Bununla birlikte, bazen etkiler daha inceliklidir ve anlamak için biraz dedektiflik çalışması gerektirir. Yanıtı enjekte edilen girdi ile ve girdi olmadan karşılaştırmak için Burp Comparer gibi araçlar kullanabilirsiniz, ancak bu yine de önemli miktarda manuel çaba gerektirir.
Param Miner
Neyse ki, BApp mağazasından Burp'a Param Miner uzantısını ekleyerek anahtarlanmamış girdileri belirleme sürecini otomatikleştirebilirsiniz. Param Miner'ı kullanmak için, araştırmak istediğiniz bir isteğe sağ tıklamanız ve "Guess headers" seçeneğine tıklamanız yeterlidir. Param Miner daha sonra arka planda çalışır ve kapsamlı, yerleşik başlık listesinden farklı girdiler içeren istekler gönderir. Enjekte edilen girdilerden birini içeren bir istek yanıt üzerinde bir etkiye sahipse, Param Miner bunu Burp Suite Professional kullanıyorsanız "Issues" bölmesinde veya Burp Suite Community Edition kullanıyorsanız uzantının "Output" sekmesinde ("Extensions" > "Installed" > "Param Miner" > "Output") Burp'ta günlüğe kaydeder.
Dikkat: Canlı bir web sitesinde anahtarsız girdileri test ederken, yanlışlıkla önbelleğin, oluşturduğunuz yanıtları gerçek kullanıcılara sunmasına neden olma riski vardır. Bu nedenle, isteklerinizin hepsinin benzersiz bir önbellek anahtarına sahip olduğundan emin olmanız önemlidir, böylece yalnızca size sunulurlar. Bunu yapmak için, her istekte bulunduğunuzda istek satırına manuel olarak bir cache buster (benzersiz bir parametre gibi) ekleyebilirsiniz. Alternatif olarak, Param Miner kullanıyorsanız, her isteğe otomatik olarak bir önbellek buster ekleme seçenekleri vardır.
Back-end sunucudan zararlı bir yanıt alma
Anahtarlanmamış bir girdi belirledikten sonra, bir sonraki adım web sitesinin bunu tam olarak nasıl işlediğini değerlendirmektir. Bunu anlamak, zararlı bir yanıtı başarılı bir şekilde ortaya çıkarmak için çok önemlidir. Bir girdi düzgün bir şekilde sterilize edilmeden sunucudan gelen yanıta yansıtılırsa veya dinamik olarak başka veriler oluşturmak için kullanılırsa, bu web önbelleği zehirlenmesi için potansiyel bir giriş noktasıdır.
Yanıtı önbelleğe alın
Zararlı bir tepki ortaya çıkarmak için girdileri manipüle etmek gerçekten zorlu bir çabadır. Ancak şunu unutmamak gerekir ki bunu tek başına başarmak önemli sonuçlar doğurmaz. Gerçekten bir etki yaratmak için kişinin, oluşan yanıtın önbelleğe alınmasını sağlaması gerekir. Ancak bu görev bazen oldukça karmaşık olabiliyor.
Bir yanıtın önbelleğe alınması, dosya uzantısı, içerik türü, rota, durum kodu ve yanıt başlıkları dahil ancak bunlarla sınırlı olmamak üzere çok sayıda faktöre bağlıdır. Önbelleğin davranışını titizlikle gözlemleyerek çeşitli sayfalardaki istekleri denemeye önemli miktarda zaman ayırmanız gerekmesi muhtemeldir. Bunu yaparak, kötü niyetli girdileri içeren bir yanıtın başarılı bir şekilde önbelleğe alınmasına ilişkin değerli bilgiler elde edilebilir. Bu bilgi edinildikten sonra, istismar potansiyel kurbanlara güvenle ulaştırılabilir.
GAULORAN RESİM BURAYA
Web Cache Poisoning ile Zaafiyet Sömürme
Bu süreç çok yönlüdür ve çeşitli web cache poisoning güvenlik açıklarını ortaya çıkarmak ve bunlardan yararlanmak için uygulanabilir.
Bu tür güvenlik açıkları, önbellek tasarımındaki doğal kusurlardan veya belirli bir web sitesinin önbelleğini uygulama biçimindeki tuhaflıklardan kaynaklanabilir. Kapsamlı bir anlayış sağlamak için her iki senaryonun en yaygın örneklerini sunacağız. Ek olarak, bu güvenlik açıklarını gözlemleme ve kullanma konusunda uygulamalı deneyime olanak tanımak için etkileşimli lablar ekledik.
Web Cache Poisoning Zaafiyetleri Nasıl Önlenir?
Web Cache Poisoning Zaafiyetlerini etkili bir şekilde önlemek için en kesin yaklaşım, önbelleğe almayı tamamen devre dışı bırakmak olacaktır. Birçok web sitesi için pratik bir çözüm olmasa da, uygun bir seçenek olabileceği bazı durumlar vardır. Örneğin, bir İçerik Dağıtım Ağı (CDN) uyguladığınızda önbelleğe alma yalnızca varsayılan olarak etkinleştirilmişse, varsayılan önbelleğe alma ayarlarının özel gereksinimlerinize gerçekten uygun olup olmadığını değerlendirmek akıllıca olacaktır.
Bununla birlikte, önbelleğe alma gerçekten gerekliyse, oldukça etkili bir önlem, bunu yalnızca statik yanıtlarla sınırlamaktır. Ancak neyin "statik" bir kaynak oluşturduğunu tanımlarken dikkatli olmak çok önemlidir. Kötü niyetli kişilerin, arka uç sunucuyu, orijinal kaynak yerine, sözde statik bir kaynağın kötü amaçlı sürümünü alma konusunda kandırmamalarını sağlamak zorunludur.
Bu konu aynı zamanda daha geniş bir konu olan web güvenliğiyle de ilgilidir. Günümüzde web sitelerinin çoğunluğu hem geliştirme süreçlerinde hem de günlük operasyonlarında bir dizi üçüncü taraf teknolojisini kullanıyor. Dahili güvenlik önlemlerinizin gücü ne olursa olsun, üçüncü taraf teknolojisini ortamınıza dahil ettiğiniz anda, söz konusu teknolojiyi geliştiricilerin sizinle eşit düzeyde güvenlik bilincine sahip olmalarına bağımlı hale gelirsiniz. Güvenlik seviyenizin yalnızca en zayıf noktanız kadar güçlü olduğu göz önüne alındığında, herhangi bir üçüncü taraf teknolojisinin entegrasyonundan önce ilgili güvenlik etkilerine ilişkin kapsamlı bir anlayışa sahip olduğunuzdan emin olmanız son derece önemlidir.
Web Cache Poisoning özel bağlamında, önbelleğe almanın varsayılan olarak etkinleştirilip etkinleştirilmeyeceğini dikkatlice düşünmek zorunludur. Ayrıca İçerik Dağıtım Ağınız (CDN) tarafından desteklenen başlıkları incelemek de çok önemlidir. Bu özellikle önemlidir çünkü web cache poisoning ile ilgili çeşitli güvenlik açıkları, saldırganların bir dizi belirsiz istek başlığını manipüle etme yeteneğinden kaynaklanmaktadır. Bu başlıkların çoğu, web sitesinin düzgün çalışması için tamamen gereksizdir. Bu gereksiz girdileri varsayılan olarak destekleyen bir teknolojiyi uyguladığınız için farkında olmadan kendinizi bu tür saldırılara maruz bırakabileceğinizi belirtmekte fayda var. Bu nedenle, web sitesinin etkili bir şekilde çalışması için gerekli olmayan başlıkların devre dışı bırakılması tavsiye edilir.
Önbelleğe alma işlemi sırasında aşağıdaki önlemleri de almalısınız:
1-Performans nedenleriyle bir şeyi önbellek anahtarından hariç tutmayı düşünüyorsanız, bunun yerine request'i yeniden yazmak daha iyi olur.
2- Büyük GET isteklerini kabul etmeyin. 3. Parti yazılımların default ayarının böyle olmasına karşı uyanık olun
3-İstemciye bağlı kullanılamaz bile görünen o zaafiyetleri giderin çünkü o zaafiyetler öngörülemez başka zaafiyetlere sebep olabilir ve kötü niyetli birinin de bunu fark etmesi an meselesidir.
daha da detayına girmek isterseniz 2 araştırma makalesi bırakıyoruz:
Bu konuda, Web Cache Poisoning nedir ve web cache poisoning açıkları neden oluşur sorularına cevap vereceğiz. Ayrıca, bu güvenlik açıklarını nasıl sömürebileceğinizden ve onları nasıl engelleyebileceğinizden bahsedeceğiz.
Web Cache Poisoning yani Web önbellek zehirlenmesi, bir saldırganın, önbelleğin davranışından faydalanıp başka kullanıcılara zararlı bir HTTP yanıtı sunmasını sağlayan gelişmiş bir tekniktir.
Temel olarak, web önbellek zehirlenmesi iki aşamadan oluşur. İlk olarak saldırgan, backend serverdan tehlikeli payload içeren bir yanıtı nasıl tetikleyeceğini bulmalıdır. Başarılı olursa, yanıtlarının önbelleğe alınmasını ve ardından hedeflenen kullanıcılara sunulmasını sağlamalıdırlar.
Biz bu sadırganın başarılı olduğu durumda önbelleğe zehirlenmiş diyelim. Bu zehirlenmiş önbelleği XSS, JavaScript enjeksiyonu, Open redirection gibi güvenlik açıklarını kullanarak çok sayıda farklı saldırının kombine edilmesine yardımcı olabilir.
Bu arada zaten bu konuyu biliyorsanız konu sonundaki yorumlardan lablere gidin ve onları çözmeye çalışın.
Web Cache Poisoning Araştırması
Bu teknik ilk olarak 2018 yılında bir araştırma makalesi olan "Practical Web Cache Poisoning" ile popüler hale geldi ve 2020 yılında ikinci bir araştırma makalesi olan "Web Cache Entanglement: Novel Pathways to Poisoning" ile daha da geliştirildi. Bu güvenlik açıklarının internet ortamında nasıl keşfettiğimizi ve faydalandığımızı ayrıntılı olarak öğrenmek istiyorsanız detaylı makalelere ulaşabileceğiniz konu sonunda 2 link bıraktım.
Web önbelleği nasıl çalışır?
Web cache poisoning açıklarının nasıl ortaya çıktığını anlamak için, web önbelleklerinin nasıl çalıştığını bilmek gerekli.
Bir sunucu her HTTP isteğine ayrı bir yeni yanıt göndermek zorunda olsaydı bu muhtemelen sunucuda aşırı yüklenmeye neden olurdu ve bu da birçok soruna ve özellikle yoğun dönemlerde kötü bir kullanıcı deneyimine neden olur. Caching bu tür sorunlara çözüm olarak vardır.
Önbellek, sunucu ve kullanıcı arasında belirli isteklerin yanıtlarını (önbelleğe) kaydeder. Başka bir kullanıcı daha sonra eşdeğer bir istek gönderirse, Backend server ile herhangi bir etkileşim olmaksızın önbellek yalnızca önbelleğe alınmış yanıtın bir kopyasını doğrudan kullanıcıya sunar. Bu, sunucu üzerindeki yükü büyük ölçüde azaltır ve serverın işlemesi gereken yinelenen isteklerin sayısını azaltır.
Önbellek anahtarları (Cache keys)
Önbellek bir HTTP isteği aldığında, önce önbelleğe alınmış doğrudan çalışabilecek bir yanıt olup olmadığını veya isteği backend sunucusuna iletmek zorunda olup olmadığını belirlemelidir. Önbellekler, bir isteğin yapısının önceden tanımlanmış mı diye karşılaştırma yaparak o isteğe eşdeğer istekleri belirler. İşte bu noktada işin içerisine cache key yani önbellek anahtarı giriyor. Genellikle istek satırını ve Host headerını içerirler. Cache keye dahil edilmeyen istek bileşenleri anahtarsız(unkeyed) olarak adlandırılır.
Gelen isteğin önbellek anahtarı önceki isteğin anahtarıyla eşleşirse, önbellek bunları eşdeğer olarak kabul eder. Sonuç olarak, orijinal istek için oluşturulan önbelleğe alınmış yanıtın bir kopyasını sunar. Bu, eşleşen önbellek anahtarına sahip tüm sonraki istekler için de geçerli olur ta ki önbelleğe alınmış yanıtın süresi dolana kadar. İsteğin diğer bileşenleri önbellek göz ardı edilir. Bunun etkisinden de ilerde bahsedeceğiz.
Web Cache Poisoning saldırısının etkisi nedir?
Bu saldırının etkisi iki temel faktöre bağlıdır:
- Saldırganın önbelleğe ne koyabildiği: Zehirlenmiş önbellek, bir saldırıdan ziyade bir dağıtım işlevi gördüğünden, bu saldırının etkisi enjekte edilen yükün ne kadar zararlı olduğuna bağlıdır. Çoğu saldırı türünde olduğu gibi, potansiyel zararı artırmak için web cache poisoning de diğer saldırılarla beraber kullanılabilir.
_____________________________________________________
- Etkilenen sayfadaki trafik miktarı:
Bir önbellek girdisinin süresinin web önbellek zehirlenmesinin etkisini etkilemediğini unutmayın. Bir saldırı genellikle önbelleği süresiz olarak yeniden zehirleyecek şekilde senaryolaştırılabilir.
Web önbelleği zehirleme saldırısı oluşturma
Anahtarlanmamış girdileri tanımlama ve değerlendirme
Herhangi bir web önbellek zehirleme saldırısı, başlıklar gibi anahtarlanmamış girdilerin manipülasyonuna dayanır. Web önbellekleri, kullanıcıya önbelleğe alınmış bir yanıt sunulup sunulmayacağına karar verirken anahtarlanmamış girdileri göz ardı eder. Bu davranış, payload'ı enjekte etmek ve önbelleğe alınırsa istekleri eşleşen önbellek anahtarına sahip tüm kullanıcılara sunulacak "zehirli" bir yanıt ortaya çıkarmak için bunları kullanabileceğiniz anlamına gelir. Bu nedenle, bir web önbelleği zehirleme saldırısı oluştururken ilk adım, sunucu tarafından desteklenen anahtarsız girdileri belirlemektir.
Anahtarlanmamış girdileri, isteklere rastgele girdiler ekleyerek ve bunların yanıt üzerinde bir etkisi olup olmadığını gözlemleyerek manuel olarak belirleyebilirsiniz. Bu, girdiyi doğrudan yanıta yansıtmak veya tamamen farklı bir yanıtı tetiklemek gibi açık olabilir. Bununla birlikte, bazen etkiler daha inceliklidir ve anlamak için biraz dedektiflik çalışması gerektirir. Yanıtı enjekte edilen girdi ile ve girdi olmadan karşılaştırmak için Burp Comparer gibi araçlar kullanabilirsiniz, ancak bu yine de önemli miktarda manuel çaba gerektirir.
Param Miner
Neyse ki, BApp mağazasından Burp'a Param Miner uzantısını ekleyerek anahtarlanmamış girdileri belirleme sürecini otomatikleştirebilirsiniz. Param Miner'ı kullanmak için, araştırmak istediğiniz bir isteğe sağ tıklamanız ve "Guess headers" seçeneğine tıklamanız yeterlidir. Param Miner daha sonra arka planda çalışır ve kapsamlı, yerleşik başlık listesinden farklı girdiler içeren istekler gönderir. Enjekte edilen girdilerden birini içeren bir istek yanıt üzerinde bir etkiye sahipse, Param Miner bunu Burp Suite Professional kullanıyorsanız "Issues" bölmesinde veya Burp Suite Community Edition kullanıyorsanız uzantının "Output" sekmesinde ("Extensions" > "Installed" > "Param Miner" > "Output") Burp'ta günlüğe kaydeder.
Dikkat: Canlı bir web sitesinde anahtarsız girdileri test ederken, yanlışlıkla önbelleğin, oluşturduğunuz yanıtları gerçek kullanıcılara sunmasına neden olma riski vardır. Bu nedenle, isteklerinizin hepsinin benzersiz bir önbellek anahtarına sahip olduğundan emin olmanız önemlidir, böylece yalnızca size sunulurlar. Bunu yapmak için, her istekte bulunduğunuzda istek satırına manuel olarak bir cache buster (benzersiz bir parametre gibi) ekleyebilirsiniz. Alternatif olarak, Param Miner kullanıyorsanız, her isteğe otomatik olarak bir önbellek buster ekleme seçenekleri vardır.
Back-end sunucudan zararlı bir yanıt alma
Anahtarlanmamış bir girdi belirledikten sonra, bir sonraki adım web sitesinin bunu tam olarak nasıl işlediğini değerlendirmektir. Bunu anlamak, zararlı bir yanıtı başarılı bir şekilde ortaya çıkarmak için çok önemlidir. Bir girdi düzgün bir şekilde sterilize edilmeden sunucudan gelen yanıta yansıtılırsa veya dinamik olarak başka veriler oluşturmak için kullanılırsa, bu web önbelleği zehirlenmesi için potansiyel bir giriş noktasıdır.
Yanıtı önbelleğe alın
Zararlı bir tepki ortaya çıkarmak için girdileri manipüle etmek gerçekten zorlu bir çabadır. Ancak şunu unutmamak gerekir ki bunu tek başına başarmak önemli sonuçlar doğurmaz. Gerçekten bir etki yaratmak için kişinin, oluşan yanıtın önbelleğe alınmasını sağlaması gerekir. Ancak bu görev bazen oldukça karmaşık olabiliyor.
Bir yanıtın önbelleğe alınması, dosya uzantısı, içerik türü, rota, durum kodu ve yanıt başlıkları dahil ancak bunlarla sınırlı olmamak üzere çok sayıda faktöre bağlıdır. Önbelleğin davranışını titizlikle gözlemleyerek çeşitli sayfalardaki istekleri denemeye önemli miktarda zaman ayırmanız gerekmesi muhtemeldir. Bunu yaparak, kötü niyetli girdileri içeren bir yanıtın başarılı bir şekilde önbelleğe alınmasına ilişkin değerli bilgiler elde edilebilir. Bu bilgi edinildikten sonra, istismar potansiyel kurbanlara güvenle ulaştırılabilir.
GAULORAN RESİM BURAYA
Web Cache Poisoning ile Zaafiyet Sömürme
Bu süreç çok yönlüdür ve çeşitli web cache poisoning güvenlik açıklarını ortaya çıkarmak ve bunlardan yararlanmak için uygulanabilir.
Bu tür güvenlik açıkları, önbellek tasarımındaki doğal kusurlardan veya belirli bir web sitesinin önbelleğini uygulama biçimindeki tuhaflıklardan kaynaklanabilir. Kapsamlı bir anlayış sağlamak için her iki senaryonun en yaygın örneklerini sunacağız. Ek olarak, bu güvenlik açıklarını gözlemleme ve kullanma konusunda uygulamalı deneyime olanak tanımak için etkileşimli lablar ekledik.
Web Cache Poisoning Zaafiyetleri Nasıl Önlenir?
Web Cache Poisoning Zaafiyetlerini etkili bir şekilde önlemek için en kesin yaklaşım, önbelleğe almayı tamamen devre dışı bırakmak olacaktır. Birçok web sitesi için pratik bir çözüm olmasa da, uygun bir seçenek olabileceği bazı durumlar vardır. Örneğin, bir İçerik Dağıtım Ağı (CDN) uyguladığınızda önbelleğe alma yalnızca varsayılan olarak etkinleştirilmişse, varsayılan önbelleğe alma ayarlarının özel gereksinimlerinize gerçekten uygun olup olmadığını değerlendirmek akıllıca olacaktır.
Bununla birlikte, önbelleğe alma gerçekten gerekliyse, oldukça etkili bir önlem, bunu yalnızca statik yanıtlarla sınırlamaktır. Ancak neyin "statik" bir kaynak oluşturduğunu tanımlarken dikkatli olmak çok önemlidir. Kötü niyetli kişilerin, arka uç sunucuyu, orijinal kaynak yerine, sözde statik bir kaynağın kötü amaçlı sürümünü alma konusunda kandırmamalarını sağlamak zorunludur.
Bu konu aynı zamanda daha geniş bir konu olan web güvenliğiyle de ilgilidir. Günümüzde web sitelerinin çoğunluğu hem geliştirme süreçlerinde hem de günlük operasyonlarında bir dizi üçüncü taraf teknolojisini kullanıyor. Dahili güvenlik önlemlerinizin gücü ne olursa olsun, üçüncü taraf teknolojisini ortamınıza dahil ettiğiniz anda, söz konusu teknolojiyi geliştiricilerin sizinle eşit düzeyde güvenlik bilincine sahip olmalarına bağımlı hale gelirsiniz. Güvenlik seviyenizin yalnızca en zayıf noktanız kadar güçlü olduğu göz önüne alındığında, herhangi bir üçüncü taraf teknolojisinin entegrasyonundan önce ilgili güvenlik etkilerine ilişkin kapsamlı bir anlayışa sahip olduğunuzdan emin olmanız son derece önemlidir.
Web Cache Poisoning özel bağlamında, önbelleğe almanın varsayılan olarak etkinleştirilip etkinleştirilmeyeceğini dikkatlice düşünmek zorunludur. Ayrıca İçerik Dağıtım Ağınız (CDN) tarafından desteklenen başlıkları incelemek de çok önemlidir. Bu özellikle önemlidir çünkü web cache poisoning ile ilgili çeşitli güvenlik açıkları, saldırganların bir dizi belirsiz istek başlığını manipüle etme yeteneğinden kaynaklanmaktadır. Bu başlıkların çoğu, web sitesinin düzgün çalışması için tamamen gereksizdir. Bu gereksiz girdileri varsayılan olarak destekleyen bir teknolojiyi uyguladığınız için farkında olmadan kendinizi bu tür saldırılara maruz bırakabileceğinizi belirtmekte fayda var. Bu nedenle, web sitesinin etkili bir şekilde çalışması için gerekli olmayan başlıkların devre dışı bırakılması tavsiye edilir.
Önbelleğe alma işlemi sırasında aşağıdaki önlemleri de almalısınız:
1-Performans nedenleriyle bir şeyi önbellek anahtarından hariç tutmayı düşünüyorsanız, bunun yerine request'i yeniden yazmak daha iyi olur.
2- Büyük GET isteklerini kabul etmeyin. 3. Parti yazılımların default ayarının böyle olmasına karşı uyanık olun
3-İstemciye bağlı kullanılamaz bile görünen o zaafiyetleri giderin çünkü o zaafiyetler öngörülemez başka zaafiyetlere sebep olabilir ve kötü niyetli birinin de bunu fark etmesi an meselesidir.
daha da detayına girmek isterseniz 2 araştırma makalesi bırakıyoruz:
Moderatör tarafında düzenlendi:
