เหตุใด iframe จึงถือว่าเป็นอันตรายและมีความเสี่ยงด้านความปลอดภัย

125

เหตุใด iframe จึงถือว่าเป็นอันตรายและมีความเสี่ยงด้านความปลอดภัย ใครสามารถอธิบายตัวอย่างของกรณีที่สามารถนำไปใช้ในทางที่ผิด

html  security  iframe 
— แดเนียลที.
แหล่งที่มา
5
ฟังดูเหมือนเรื่องภรรยาเก่า หน้าต่างเบราว์เซอร์ของคุณโดยพื้นฐานแล้วเป็นเพียง iframe ขนาดใหญ่
— Bill Criswell
1
ถามไปแล้วใน stackoverflow
— Samich
1
@Samich - ไม่เกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดไม่ใช่เฉพาะปัญหาด้านความปลอดภัย (และปัญหาด้านความปลอดภัยเดียวที่ฉันคิดได้เกิดจากบุคคลที่สามที่ใช้ iframes)
— Quentin
ความปลอดภัยไม่มากนักเนื่องจากไม่ถือว่าเป็นแนวทางปฏิบัติที่ดีที่สุดโปรดดู: stackoverflow.com/questions/1081315/why-developers-hate-iframes พวกเขาได้รับความนิยมมากขึ้นเมื่อคนออกแบบตารางด้วย divs ทั้งหมด แต่ไม่จำเป็นต้องใช้ iframe
— RandomUs1r
น่าสนุกพอที่จะมีบทความโผล่ขึ้นมาในอีกเกือบทศวรรษต่อมาซึ่งชี้ให้เห็นว่าการวางสิ่งใดก็ตามที่มีรูปแบบใน iframe ซึ่งแยกออกจากจาวาสคริปต์ของบุคคลที่สามทั้งหมดของคุณเป็นต้นอาจจำเป็นเพื่อป้องกันไม่ให้มีการเก็บเกี่ยวแบบฟอร์ม hackernoon.com/…
— GordonM

คำตอบ:

84

ทันทีที่คุณแสดงเนื้อหาจากโดเมนอื่นคุณเชื่อมั่นว่าโดเมนนั้นจะไม่ให้บริการมัลแวร์

iframe ต่อ se ไม่มีอะไรผิดพลาด หากคุณควบคุมเนื้อหาของ iframe ก็จะปลอดภัยอย่างสมบูรณ์

— Diodeus - เจมส์ MacFarlane
แหล่งที่มา
19
ทันทีที่คุณเชื่อมโยงไปยังเนื้อหาจากโดเมนอื่น ฯลฯ ... ไม่มี iframe เฉพาะเกี่ยวกับเรื่องนี้
— Quentin
5
เบราว์เซอร์ที่ใช้งานอย่างถูกต้อง (หรือที่เรียกว่า User Agent) จะไม่อนุญาตให้เนื้อหาของ iframe รั่วไหลออกนอก iframe หากเอกสารโฮสต์ (หนึ่งที่มี<iframe>องค์ประกอบ) มีรูปแบบที่เหมาะสมและบอกเป็นนัยว่า iframe มีเนื้อหาที่ไม่น่าเชื่อถือก็ไม่มีปัญหา แน่นอนช่องโหว่ที่แท้จริงของ Modulo ในเบราว์เซอร์ กล่าวโดยย่อ<iframe>คือปลอดภัยพอ ๆ กับไฟล์<a href>.
— Mikko Rantalainen
2
แล้ว iframe ที่ซ่อนอยู่ซึ่งเป็นของโดเมนเดียวกันล่ะ? ปลอดภัยทั้งหมดหรือไม่?
— Ciaran Gallagher
2
การซ่อน<iframe>จากโดเมนเดียวกันอาจทำให้เกิดความเสี่ยงด้านความปลอดภัยหากผู้โจมตีสามารถแก้ไขเนื้อหาภายใน iframe ที่ซ่อนอยู่ได้ ซึ่งจะช่วยให้ผู้โจมตีสามารถขยายการโจมตี XSS ภายในที่ซ่อน<iframe>ไปยังหน้าใดก็ได้บนไซต์ของคุณที่อ้างถึง<iframe>เนื้อหา d ดังกล่าว ดูรายละเอียดในstackoverflow.com/a/9428051/334451
— Mikko Rantalainen
ที่น่าสนใจก็คือ iFrame อาจเป็นการป้องกันที่มีประโยชน์จากกรณีย้อนกลับ หากคุณมีสคริปต์ของบุคคลที่สามจำนวนมากในไซต์ของคุณคุณจำเป็นต้องแยกแบบฟอร์มออกจากสคริปต์เหล่านั้น วิธีหนึ่งที่แนะนำในการทำเช่นนี้คือการวางแบบฟอร์มในหน้าเล็ก ๆ ของตัวเองโดยไม่มีจาวาสคริปต์ของบุคคลที่สามและแสดงใน iframe ในหน้าโฮสต์ hackernoon.com/…
— GordonM
140

IFRAMEองค์ประกอบอาจมีความเสี่ยงด้านความปลอดภัยถ้าเว็บไซต์ของคุณจะถูกฝังอยู่ภายในIFRAMEสถานที่เดียวกันที่เป็นมิตร "clickjacking" ของ Google สำหรับรายละเอียดเพิ่มเติม โปรดทราบว่าไม่สำคัญว่าคุณจะใช้<iframe>หรือไม่ การป้องกันที่แท้จริงเพียงอย่างเดียวจากการโจมตีนี้คือการเพิ่มส่วนหัว HTTP X-Frame-Options: DENYและหวังว่าเบราว์เซอร์จะรู้หน้าที่ของมัน

นอกจากนี้องค์ประกอบ IFRAME อาจมีความเสี่ยงด้านความปลอดภัยหากหน้าใด ๆ บนไซต์ของคุณมีช่องโหว่ XSS ซึ่งสามารถใช้ประโยชน์ได้ ในกรณีนี้ผู้โจมตีสามารถขยายการโจมตี XSS ไปยังเพจใดก็ได้ภายในโดเมนเดียวกันที่สามารถชักชวนให้โหลดภายใน<iframe>เพจที่มีช่องโหว่ XSS เนื่องจากเนื้อหาจากแหล่งกำเนิดเดียวกัน (โดเมนเดียวกัน) ได้รับอนุญาตให้เข้าถึง DOM เนื้อหาหลัก (เรียกใช้ JavaScript ในเอกสาร "โฮสต์") วิธีการป้องกันที่แท้จริงเพียงวิธีเดียวจากการโจมตีนี้คือการเพิ่มส่วนหัว HTTP X-Frame-Options: DENYและ / หรือเข้ารหัสข้อมูลที่ผู้ใช้ส่งมาทั้งหมดอย่างถูกต้องเสมอ (นั่นคือไม่เคยมีช่องโหว่ XSS ในไซต์ของคุณ - พูดง่ายกว่าทำ)

นั่นคือด้านเทคนิคของปัญหา นอกจากนี้ยังมีปัญหาของอินเทอร์เฟซผู้ใช้ หากคุณสอนให้ผู้ใช้ของคุณเชื่อมั่นว่าแถบ URL ควรจะไม่เปลี่ยนแปลงเมื่อพวกเขาคลิกลิงก์ (เช่นไซต์ของคุณใช้ iframe ขนาดใหญ่ที่มีเนื้อหาจริงทั้งหมด) ผู้ใช้จะไม่สังเกตเห็นอะไรอีกในอนาคตไม่ว่าในกรณีของความปลอดภัยจริง ความอ่อนแอ ตัวอย่างเช่นคุณอาจมีช่องโหว่ XSS ภายในไซต์ของคุณที่อนุญาตให้ผู้โจมตีโหลดเนื้อหาจากแหล่งที่ไม่เป็นมิตรภายใน iframe ของคุณ ไม่มีใครสามารถบอกความแตกต่างได้เนื่องจากแถบ URL ยังคงดูเหมือนกับพฤติกรรมก่อนหน้านี้ (ไม่เคยเปลี่ยนแปลง) และเนื้อหา "ดู" ถูกต้องแม้ว่าจะมาจากโดเมนที่ไม่เป็นมิตรที่ขอข้อมูลรับรองผู้ใช้ก็ตาม

หากมีคนอ้างว่าการใช้<iframe>องค์ประกอบบนไซต์ของคุณเป็นอันตรายและก่อให้เกิดความเสี่ยงด้านความปลอดภัยเขาไม่เข้าใจว่า<iframe>องค์ประกอบใดทำหน้าที่อะไรหรือเขากำลังพูดถึงความเป็นไปได้ของ<iframe>ช่องโหว่ที่เกี่ยวข้องในเบราว์เซอร์ ความปลอดภัยของ<iframe src="...">แท็กเท่ากับ<img src="..."หรือ<a href="...">ตราบเท่าที่ไม่มีช่องโหว่ในเบราว์เซอร์ และถ้ามีช่องโหว่ที่เหมาะสมก็อาจจะเป็นไปได้ที่จะเรียกมันได้โดยไม่ต้องใช้<iframe>, <img>หรือ<a>องค์ประกอบจึงไม่มูลค่าการพิจารณาสำหรับปัญหานี้

แต่จะเตือนว่าเนื้อหาจาก<iframe>สามารถเริ่มต้นนำทางระดับบนสุดตามค่าเริ่มต้น นั่นคือเนื้อหาภายใน<iframe>ได้รับอนุญาตให้เปิดลิงก์บนตำแหน่งของเพจปัจจุบันโดยอัตโนมัติ (ตำแหน่งใหม่จะปรากฏในแถบที่อยู่) วิธีเดียวที่จะหลีกเลี่ยงที่จะเพิ่มแอตทริบิวต์โดยไม่คุ้มค่าsandbox allow-top-navigationตัวอย่างเช่น<iframe sandbox="allow-forms allow-scripts" ...>. น่าเสียดายที่แซนด์บ็อกซ์ปิดการใช้งานปลั๊กอินทั้งหมดเสมอ ตัวอย่างเช่นเนื้อหา Youtube ไม่สามารถแซนด์บ็อกซ์ได้เนื่องจากยังต้องใช้ Flash player เพื่อดูเนื้อหา Youtube ทั้งหมด ไม่มีเบราว์เซอร์ใดที่รองรับการใช้ปลั๊กอินและไม่อนุญาตการนำทางระดับบนสุดในเวลาเดียวกัน

โปรดทราบว่าX-Frame-Options: DENYยังช่วยป้องกันการแสดงผลการโจมตีด้านช่องสัญญาณที่สามารถอ่านเนื้อหาข้ามแหล่งที่มาได้ (หรือที่เรียกว่า " Pixel perfect Timing Attacks ")

— Mikko Rantalainen
แหล่งที่มา
ดี แต่ไม่ควร"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)."จัดเรียงใหม่ในทิศทางของเอกสาร (หลัก) ที่มีช่องโหว่ XSS ต่อเอกสาร (ลูก) ใน iframe?
— Shuzheng
@Shuzheng ช่องโหว่เกิดขึ้นได้ทั้งสองวิธีและหากคุณใช้<iframe>บนเพจช่องโหว่นี้จะอนุญาตให้ขยายช่องโหว่จากเนื้อหาภายใน iframe ไปยังโฮสต์เอกสาร คำถามเกี่ยวกับ<iframe>การเป็นอันตรายและหากเอกสารโฮสต์มีช่องโหว่ XSS คุณก็ไม่จำเป็นต้องใช้<iframe>องค์ประกอบนี้
— Mikko Rantalainen
13

ฉันคิดว่า iFrame ข้ามโดเมนเนื่องจากความเสี่ยงจะลดลงหากคุณควบคุมด้วยตัวเอง

  • Clickjackingเป็นปัญหาหากไซต์ของคุณรวมเป็น iframe
  • iFrame ที่ถูกบุกรุกอาจแสดงเนื้อหาที่เป็นอันตรายได้ (ลองนึกภาพว่า iFrame แสดงช่องล็อกอินแทนโฆษณา)
  • iframe ที่รวมอยู่สามารถทำการโทร JS บางอย่างเช่นแจ้งเตือนและแจ้งซึ่งอาจรบกวนผู้ใช้ของคุณ
  • iframe ที่รวมอยู่สามารถเปลี่ยนเส้นทางผ่าน location.href ได้ (ลองนึกภาพ 3p frame ที่เปลี่ยนเส้นทางลูกค้าจาก bankofamerica.com ไปยัง bankofamerica.fake.com)
  • มัลแวร์ภายในเฟรม 3p (java / flash / activeX) อาจติดผู้ใช้ของคุณได้
— โจแซค
แหล่งที่มา
2

"อันตราย" และ "ความเสี่ยงด้านความปลอดภัย" ไม่ใช่สิ่งแรกที่ต้องนึกถึงเมื่อมีคนพูดถึง iframe ... แต่สามารถใช้ในการโจมตีแบบคลิกแจ็กได้

— เควนติน
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.