İframe'ler neden tehlikeli ve güvenlik riski olarak kabul edilir?

125

İframe'ler neden tehlikeli ve güvenlik riski olarak kabul edilir? Birisi kötü niyetli olarak kullanılabileceği bir vaka örneğini tanımlayabilir mi?

html  security  iframe 
— Daniel T.
kaynak
5
Bu eski bir eş hikayesine benziyor. Tarayıcı pencereniz temelde yalnızca bir büyük iframe'dir.
— Bill Criswell
1
Stackoverflow'da zaten sorulmuştu
— Samich
1
@Samich - Hayır, bu en iyi uygulama ile ilgili, özellikle güvenlik sorunları değil (ve aklıma gelen tek güvenlik sorunu, iframe kullanan üçüncü şahıslardan kaynaklanıyor )
— Quentin
En iyi uygulama sayılmadığı için çok fazla güvenlik değil, bakınız: stackoverflow.com/questions/1081315/why-developers-hate-iframes İnsanlar tablolarla da tasarladıklarında, her şeyi böler ancak iframe ihtiyacını ortadan kaldırdıklarında çok daha popülerdi.
— RandomUs1r
Tuhaf bir şekilde, neredeyse on yıl sonra ortaya çıkan bir makale, form içeren herhangi bir şeyi bir iframe'e yerleştirmenin, tüm üçüncü taraf javascript'inizden vb. İzole edilmesinin muhtemelen formların toplanmasını önlemek için gerekli olduğunu düşündürür. hackernoon.com/…
— GordonM

Yanıtlar:

84

Başka bir etki alanından içerik görüntüler göstermez, temelde o etki alanına kötü amaçlı yazılım sunmayacağına güveniyorsunuz.

Kendi başına iframe'lerin hiçbir sorunu yoktur. İframe içeriğini kontrol ederseniz, bunlar tamamen güvenlidir.

— Diyot - James MacFarlane
kaynak
19
Başka bir etki alanından vb. İçeriğe bağlandığınız anda… Bununla ilgili özel bir iframe yoktur.
— Quentin
5
Doğru bir şekilde uygulanan tarayıcılar (Kullanıcı Aracısı olarak da bilinir), iframe içeriklerinin iframe dışına sızmasına izin vermez. Ana belge ( <iframe>öğeyi içeren ) uygun bir stile sahipse ve iframe'in güvenilmeyen içerik barındırdığına dair ipucu veriyorsa sorun olmaz. Tabii ki tarayıcıda Modulo gerçek zafiyetler. Kısacası bir <iframe>, bir <a href>.
— Mikko Rantalainen
2
Aynı alana ait gizli bir iframe ne olacak? Bu tamamen güvenli mi?
— Ciaran Gallagher
2
Gizli <iframe>gizli iframe içinde içerik saldırgan tarafından değiştirilebilir eğer güvenlik riski neden olabilir aynı etki alanından. Bu, saldırganın gizli olan XSS saldırısını <iframe>sitenizdeki söz konusu <iframe>d içeriğine başvuran herhangi bir sayfaya genişletmesine olanak tanır . Ayrıntılar için stackoverflow.com/a/9428051/334451 adresine bakın.
— Mikko Rantalainen
Yeterince ilginç bir şekilde, bir iFrame aslında ters duruma karşı yararlı bir koruma olabilir. Sitenizde çok sayıda üçüncü taraf komut dosyası varsa, formları bunlardan ayırmanız gerekir. Bunu yapmanın önerilen bir yolu, formu üçüncü taraf javascript içermeyen kendi minimal sayfasına yerleştirmek ve ana sayfadaki bir iç çerçevede görüntülemekti. hackernoon.com/…
— GordonM
140

IFRAMEEğer eleman bir güvenlik riski olabilir Siteniz bir iç gömülü olduğu IFRAMEdüşmanca sitesinde . Daha fazla ayrıntı için Google "tıklama hırsızlığı". Kullanıp kullanmamanın önemli olmadığını unutmayın<iframe> . Bu saldırıdan tek gerçek koruma, HTTP başlığı eklemek X-Frame-Options: DENYve tarayıcının işini bildiğini ummaktır.

Buna ek olarak, sitenizdeki herhangi bir sayfada yararlanılabilecek bir XSS güvenlik açığı bulunuyorsa , IFRAME öğesi bir güvenlik riski oluşturabilir . Bu durumda saldırgan, XSS saldırısını <iframe>, XSS zafiyeti olan bir sayfada yüklenmeye ikna edilebilecek aynı etki alanındaki herhangi bir sayfaya genişletebilir . Bunun nedeni, aynı kaynaktan (aynı etki alanı) gelen içeriğin üst içerik DOM'a erişmesine izin verilmesidir (JavaScript'i "ana bilgisayar" belgesinde pratik olarak çalıştırın). Bu saldırıdan tek gerçek koruma yöntemi, HTTP üstbilgisi eklemek X-Frame-Options: DENYve / veya kullanıcı tarafından gönderilen tüm verileri her zaman doğru şekilde kodlamaktır (yani, sitenizde hiçbir zaman bir XSS güvenlik açığına sahip olmayın - söylemesi yapmaktan daha kolay).

Sorunun teknik tarafı budur. Ek olarak, kullanıcı arayüzü sorunu var. Kullanıcılarınıza, URL çubuğunun bağlantıları tıkladıklarında değişmemesi gerektiğine güvenmelerini öğretirseniz (örneğin, siteniz tüm gerçek içeriğe sahip büyük bir iç çerçeve kullanır), gerçek güvenlik durumunda da kullanıcılar gelecekte hiçbir şey fark etmeyecektir. Güvenlik açığı. Örneğin, sitenizde saldırganın iframe'inizdeki düşman kaynaklardan içerik yüklemesine izin veren bir XSS güvenlik açığı olabilir. Hiç kimse farkı anlayamadı çünkü URL çubuğu önceki davranışla aynı görünüyor (asla değişmiyor) ve içerik, kullanıcı kimlik bilgilerini isteyen düşmanca bir etki alanından gelse bile "geçerli görünüyor".

Eğer birisi <iframe>sitenizde bir elementi kullanmanın tehlikeli olduğunu ve bir güvenlik riskine neden olduğunu iddia ederse , hangi <iframe>elementin işe yaradığını anlamıyor veya <iframe>tarayıcılarda ilgili güvenlik açıkları olasılığı hakkında konuşuyor . <iframe src="...">Etiketin güvenliği , tarayıcıda güvenlik açığı olmadığı sürece eşittir <img src="..."veya <a href="...">uzun süredir. Ve uygun bir güvenlik açığı varsa <iframe>, <img>veya <a>öğesi kullanmadan bile tetiklemek mümkün olabilir , bu nedenle bu konu için dikkate alınmaya değmez.

Bununla birlikte, içeriğinin <iframe>varsayılan olarak üst düzey gezinmeyi başlatabileceği konusunda uyarılmalıdır . Yani, içindeki içeriğin <iframe>geçerli sayfa konumu üzerinden otomatik olarak bir bağlantı açmasına izin verilir (yeni konum adres çubuğunda görünür olacaktır). Bundan kaçınmanın tek yolu, sandboxdeğeri olmayan nitelik eklemektir allow-top-navigation. Örneğin <iframe sandbox="allow-forms allow-scripts" ...>,. Ne yazık ki sandbox, her zaman tüm eklentileri de devre dışı bırakır. Örneğin, Youtube içeriği korumalı alana alınamaz çünkü Flash oynatıcı hala tüm Youtube içeriğini görüntülemek için gereklidir. Hiçbir tarayıcı aynı anda eklenti kullanmayı ve üst düzey gezinmeye izin vermeyi desteklemez.

Not X-Frame-Options: DENY(ayrıca "olarak bilinen içerik çapraz kökeni okuyabilir performans yan kanal saldırı oluşturma korur piksel mükemmel Zamanlama Attacks ").

— Mikko Rantalainen
kaynak
Güzel, ancak "This is because content from the same origin (same domain) is allowed to access the parent content DOM (practically execute JavaScript in the "host" document)."iframe'deki (alt) belgeye yönelik bir XSS güvenlik açığı içeren (ana) belge yönünde yeniden ifade edilmemeli ?
— Shuzheng
@Shuzheng güvenlik açığı her iki yönde de gider ve <iframe>bir sayfada kullanırsanız , güvenlik açığının iframe içindeki içerikten belgeyi barındıracak şekilde genişletilmesine izin verir. Soru <iframe>tehlikeli olmakla ilgiliydi ve ana belgede XSS güvenlik açığı varsa, bu <iframe>öğeye gerçekten ihtiyacınız yok .
— Mikko Rantalainen
13

Etki alanları arası iFrame'i varsayıyorum, çünkü muhtemelen kendiniz kontrol ederseniz risk daha düşük olacaktır.

  • Siteniz iframe olarak dahil edilmişse , tıklama korsanlığı bir sorundur
  • Güvenliği ihlal edilmiş bir iFrame, kötü amaçlı içerik görüntüleyebilir (iFrame'in bir reklam yerine bir oturum açma kutusu görüntülediğini hayal edin)
  • Dahil edilen bir iframe, kullanıcınızı rahatsız edebilecek uyarı ve bilgi istemi gibi belirli JS çağrıları yapabilir
  • Dahil edilen bir iframe, location.href aracılığıyla yeniden yönlendirebilir (evet, müşteriyi bankofamerica.com'dan bankofamerica.fake.com'a yönlendiren bir 3p çerçevesi hayal edin)
  • 3p çerçeve (java / flash / activeX) içindeki kötü amaçlı yazılım, kullanıcınıza bulaşabilir
— Joe Zack
kaynak
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.