Mengapa iframe dianggap berbahaya dan berisiko keamanan?

125

Mengapa iframe dianggap berbahaya dan berisiko keamanan? Dapatkah seseorang menggambarkan contoh kasus yang dapat digunakan secara jahat?

html  security  iframe 
— Daniel T.
sumber
5
Kedengarannya seperti dongeng istri tua. Jendela browser Anda pada dasarnya hanyalah satu iframe besar.
— Bill Criswell
1
Itu sudah ditanyakan pada stackoverflow
— Samich
1
@ Samich - Tidak, itu tentang praktik terbaik, bukan secara khusus masalah keamanan (dan satu-satunya masalah keamanan yang dapat saya pikirkan muncul dari pihak ketiga yang menggunakan iframe)
— Quentin
Tidak terlalu aman karena tidak dianggap sebagai praktik terbaik, lihat: stackoverflow.com/questions/1081315/why-developers-hate-iframes Mereka jauh lebih populer ketika orang-orang mendesain tabel juga, semua div tetapi menghilangkan kebutuhan akan iframe.
— RandomUs1r
Lucunya, sebuah artikel muncul hampir satu dekade kemudian yang menunjukkan bahwa meletakkan apa pun yang berisi formulir dalam iframe, terisolasi dari semua javascript pihak ketiga Anda, dll., Mungkin diperlukan untuk melindungi formulir agar tidak dipanen. hackernoon.com/…
— GordonM

Jawaban:

84

Segera setelah Anda menampilkan konten dari domain lain, pada dasarnya Anda mempercayai domain itu untuk tidak menyajikan malware.

Tidak ada yang salah dengan iframe itu sendiri. Jika Anda mengontrol konten iframe, mereka sangat aman.

— Diodeus - James MacFarlane
sumber
19
Segera setelah Anda menautkan ke konten dari domain lain, dll.… Tidak ada iframe yang spesifik tentang ini.
— Quentin
5
Browser yang diterapkan dengan benar (alias Agen Pengguna) tidak akan mengizinkan konten iframe bocor di luar iframe. Jika dokumen host (yang berisi <iframe>elemen) memiliki gaya yang sesuai dan memberi petunjuk bahwa iframe berisi konten yang tidak tepercaya, tidak ada masalah. Kerentanan nyata Modulo di browser, tentu saja. Singkatnya, sebuah <iframe>adalah sebagai aman sebagai <a href>.
— Mikko Rantalainen
2
Bagaimana dengan iframe tersembunyi milik domain yang sama? Apakah ini benar-benar aman?
— Ciaran Gallagher
2
Tersembunyi <iframe>dari domain yang sama dapat menyebabkan risiko keamanan jika konten di dalam iframe tersembunyi dapat dimodifikasi oleh penyerang. Itu akan memungkinkan penyerang untuk memperpanjang serangan XSS di dalam yang tersembunyi <iframe>ke halaman mana pun di situs Anda yang merujuk ke <iframe>konten tersebut. Lihat stackoverflow.com/a/9428051/334451 untuk detailnya.
— Mikko Rantalainen
Yang cukup menarik, iFrame sebenarnya bisa menjadi perlindungan yang berguna dari casing sebaliknya. Jika Anda memiliki banyak skrip pihak ketiga di situs Anda, Anda perlu memisahkan formulir dari mereka. Salah satu cara yang disarankan untuk melakukan itu adalah meletakkan formulir di halaman minimalnya sendiri tanpa javascript pihak ketiga, dan menampilkannya dalam iframe di halaman host. hackernoon.com/…
— GordonM
140

The IFRAMEelemen dapat menjadi resiko keamanan jika situs Anda tertanam dalam sebuah IFRAMEsitus bermusuhan . Google "clickjacking" untuk lebih jelasnya. Perhatikan bahwa tidak masalah jika Anda menggunakan <iframe>atau tidak. Satu-satunya perlindungan nyata dari serangan ini adalah menambahkan header HTTP X-Frame-Options: DENYdan berharap browser mengetahui tugasnya.

Selain itu, elemen IFRAME dapat menjadi risiko keamanan jika ada halaman di situs Anda yang memiliki kerentanan XSS yang dapat dieksploitasi . Dalam hal ini, penyerang dapat memperluas serangan XSS ke halaman mana pun dalam domain yang sama yang dapat dibujuk untuk memuat dalam <iframe>halaman dengan kerentanan XSS. Ini karena konten dari asal yang sama (domain yang sama) diizinkan untuk mengakses DOM konten induk (secara praktis menjalankan JavaScript dalam dokumen "host"). Satu-satunya metode perlindungan nyata dari serangan ini adalah dengan menambahkan header HTTP X-Frame-Options: DENYdan / atau selalu dengan benar menyandikan semua data yang dikirimkan pengguna (artinya, tidak pernah memiliki kerentanan XSS di situs Anda - lebih mudah diucapkan daripada dilakukan).

Itulah sisi teknis dari masalahnya. Selain itu, ada masalah antarmuka pengguna. Jika Anda mengajari pengguna Anda untuk mempercayai bahwa bilah URL seharusnya tidak berubah ketika mereka mengeklik tautan (misalnya, situs Anda menggunakan iframe besar dengan semua konten aktual), maka pengguna tidak akan melihat apa pun di masa mendatang baik dalam kasus keamanan aktual kerentanan. Misalnya, Anda mungkin memiliki kerentanan XSS dalam situs Anda yang memungkinkan penyerang memuat konten dari sumber yang tidak bersahabat dalam iframe Anda. Tidak ada yang bisa membedakannya karena bilah URL masih terlihat identik dengan perilaku sebelumnya (tidak pernah berubah) dan konten "terlihat" valid meskipun berasal dari domain bermusuhan yang meminta kredensial pengguna.

Jika seseorang mengklaim bahwa menggunakan <iframe>elemen di situs Anda berbahaya dan menyebabkan risiko keamanan, dia tidak memahami fungsi <iframe>elemen tersebut, atau dia berbicara tentang kemungkinan <iframe>kerentanan terkait di browser. Keamanan <iframe src="...">tag sama dengan <img src="..."atau <a href="...">selama tidak ada kerentanan di browser. Dan jika ada kerentanan yang sesuai, mungkin dapat dipicunya bahkan tanpa menggunakan <iframe>, <img>atau <a>elemen, jadi tidak perlu dipertimbangkan untuk masalah ini.

Namun, berhati-hatilah karena konten dari <iframe>dapat memulai navigasi tingkat atas secara default . Artinya, konten di dalam <iframe>diizinkan untuk secara otomatis membuka tautan di atas lokasi halaman saat ini (lokasi baru akan terlihat di bilah alamat). Satu-satunya cara untuk menghindarinya adalah dengan menambahkan sandboxatribut tanpa nilai allow-top-navigation. Misalnya <iframe sandbox="allow-forms allow-scripts" ...>,. Sayangnya, sandbox juga selalu menonaktifkan semua plugin. Misalnya, konten Youtube tidak dapat di-sandbox karena Flash player masih diperlukan untuk melihat semua konten Youtube. Tidak ada browser yang mendukung penggunaan plugin dan melarang navigasi tingkat atas pada saat yang bersamaan.

Perhatikan bahwa X-Frame-Options: DENYjuga melindungi dari serangan saluran sisi kinerja rendering yang dapat membaca konten lintas asal (juga dikenal sebagai " Pixel perfect Timing Attacks ").

— Mikko Rantalainen
sumber
Bagus, tetapi tidak "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)."boleh diubah ke arah dokumen (induk) yang berisi kerentanan XSS ke dokumen (anak) di iframe?
— Shuzheng
@Shuzheng, kerentanan terjadi dalam dua cara dan jika Anda menggunakan <iframe>di halaman, ini memungkinkan perluasan kerentanan dari konten dalam iframe ke dokumen host. Pertanyaannya adalah tentang <iframe>menjadi berbahaya dan jika dokumen host memiliki kerentanan XSS, Anda benar-benar tidak memerlukan <iframe>elemen tersebut.
— Mikko Rantalainen
13

Saya berasumsi iFrame lintas domain karena kemungkinan risikonya akan lebih rendah jika Anda mengendalikannya sendiri.

  • Clickjacking menjadi masalah jika situs Anda disertakan sebagai iframe
  • IFrame yang disusupi dapat menampilkan konten berbahaya (bayangkan iFrame menampilkan kotak masuk alih-alih iklan)
  • Iframe yang disertakan dapat membuat panggilan JS tertentu seperti peringatan dan prompt yang dapat mengganggu pengguna Anda
  • Iframe yang disertakan dapat dialihkan melalui location.href (astaga, bayangkan bingkai 3p mengarahkan pelanggan dari bankofamerica.com ke bankofamerica.fake.com)
  • Malware di dalam bingkai 3p (java / flash / activeX) dapat menginfeksi pengguna Anda
— Joe Zack
sumber
2

"Berbahaya" dan "Risiko keamanan" bukanlah hal pertama yang muncul dalam pikiran ketika orang menyebutkan iframe… tetapi mereka dapat digunakan dalam serangan clickjacking .

— Quentin
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.