Tại sao iframe được coi là nguy hiểm và là rủi ro bảo mật?

124

Tại sao iframe được coi là nguy hiểm và là rủi ro bảo mật? Ai đó có thể mô tả một ví dụ về một trường hợp mà nó có thể được sử dụng một cách ác ý không?

html  security  iframe 
— Daniel T.
nguồn
5
Nghe như một câu chuyện về những người vợ cũ. Cửa sổ trình duyệt của bạn về cơ bản chỉ là một iframe lớn.
— Bill Criswell
1
Nó đã được hỏi trên stackoverflow
— Samich
1
@Samich - Không, đó là về thực hành tốt nhất, chứ không phải đặc biệt vấn đề an ninh (và các vấn đề an ninh duy nhất tôi có thể nghĩ đến phát sinh từ các bên thứ ba sử dụng iframe)
— Quentin
Không quá nhiều bảo mật vì nó không được coi là phương pháp hay nhất, hãy xem: stackoverflow.com/questions/1081315/why-developers-hate-iframes Chúng phổ biến hơn rất nhiều khi mọi người cũng thiết kế bảng, chia tất cả nhưng loại bỏ nhu cầu về iframe.
— RandomUs1r
Thật thú vị là một bài báo xuất hiện gần một thập kỷ sau đó gợi ý rằng việc đặt bất kỳ thứ gì có chứa biểu mẫu trong iframe, tách biệt khỏi tất cả javascript của bên thứ ba, v.v., có thể cần thiết để bảo vệ biểu mẫu khỏi bị thu thập. hackernoon.com/…
— GordonM

Câu trả lời:

83

Ngay sau khi bạn hiển thị nội dung từ một miền khác, về cơ bản bạn tin tưởng rằng miền đó không chứa phần mềm độc hại.

Không có gì sai với iframe. Nếu bạn kiểm soát nội dung của iframe, chúng hoàn toàn an toàn.

— Diodeus - James MacFarlane
nguồn
19
Ngay sau khi bạn liên kết đến nội dung từ một miền khác, vv ... Không có iframe nào cụ thể về điều này.
— Quentin
5
Một trình duyệt được triển khai đúng cách (còn gọi là Tác nhân người dùng) sẽ không cho phép nội dung iframe rò rỉ ra bên ngoài iframe. Nếu tài liệu lưu trữ (tài liệu chứa <iframe>phần tử) có kiểu dáng phù hợp và gợi ý iframe chứa nội dung không đáng tin cậy, không có vấn đề gì. Tất nhiên, các lỗ hổng thực tế của Modulo trong trình duyệt. Trong ngắn hạn, an <iframe>là khoảng an toàn như a <a href>.
— Mikko Rantalainen 11/12/12
2
Điều gì về một iframe ẩn thuộc cùng một miền? Điều này có hoàn toàn an toàn không?
— Ciaran Gallagher
2
Bị ẩn <iframe>khỏi cùng một miền có thể gây ra rủi ro bảo mật nếu kẻ tấn công có thể sửa đổi nội dung bên trong iframe ẩn. Điều đó sẽ cho phép kẻ tấn công mở rộng cuộc tấn công XSS bên trong ẩn <iframe>đến bất kỳ trang nào trên trang web của bạn đề cập đến <iframe>nội dung d đã nói . Xem stackoverflow.com/a/9428051/334451 để biết chi tiết.
— Mikko Rantalainen
Điều thú vị là, iFrame thực sự có thể là một biện pháp bảo vệ hữu ích khỏi trường hợp ngược lại. Nếu bạn có nhiều tập lệnh của bên thứ ba trên trang web của mình, bạn cần phải tách các biểu mẫu khỏi chúng. Một cách được đề xuất để làm điều đó là đặt biểu mẫu trong trang tối thiểu của riêng nó mà không có javascript của bên thứ ba và hiển thị nó trong iframe trong trang chủ. hackernoon.com/…
— GordonM
140

Phần IFRAMEtử có thể là một rủi ro bảo mật nếu trang web của bạn được nhúng bên trong một IFRAMEtrang web thù địch . Google "clickjacking" để biết thêm chi tiết. Lưu ý rằng nó không quan trọng nếu bạn sử dụng <iframe>hay không. Cách bảo vệ thực sự duy nhất khỏi cuộc tấn công này là thêm tiêu đề HTTP X-Frame-Options: DENYvà hy vọng rằng trình duyệt biết công việc của nó.

Ngoài ra, phần tử IFRAME có thể là một rủi ro bảo mật nếu bất kỳ trang nào trên trang web của bạn chứa lỗ hổng XSS có thể bị khai thác . Trong trường hợp đó, kẻ tấn công có thể mở rộng cuộc tấn công XSS sang bất kỳ trang nào trong cùng một miền có thể được thuyết phục tải trong một <iframe>trang có lỗ hổng XSS. Điều này là do nội dung từ cùng một nguồn gốc (cùng một miền) được phép truy cập DOM nội dung mẹ (thực tế thực thi JavaScript trong tài liệu "máy chủ"). Các phương pháp bảo vệ thực sự duy nhất khỏi cuộc tấn công này là thêm tiêu đề HTTP X-Frame-Options: DENYvà / hoặc luôn mã hóa chính xác tất cả dữ liệu do người dùng gửi (nghĩa là không bao giờ có lỗ hổng XSS trên trang web của bạn - nói thì dễ hơn làm).

Đó là mặt kỹ thuật của vấn đề. Ngoài ra, có vấn đề về giao diện người dùng. Nếu bạn dạy người dùng của mình tin tưởng rằng thanh URL sẽ không thay đổi khi họ nhấp vào liên kết (ví dụ: trang web của bạn sử dụng iframe lớn với tất cả nội dung thực tế), thì người dùng sẽ không nhận thấy bất kỳ điều gì trong tương lai trong trường hợp bảo mật thực sự sự dễ bị tổn thương. Ví dụ: bạn có thể có lỗ hổng XSS trong trang web của mình cho phép kẻ tấn công tải nội dung từ nguồn thù địch trong iframe của bạn. Không ai có thể phân biệt được vì thanh URL trông vẫn giống với hành vi trước đó (không bao giờ thay đổi) và nội dung "có vẻ" hợp lệ mặc dù đó là từ miền thù địch yêu cầu thông tin đăng nhập của người dùng.

Nếu ai đó tuyên bố rằng việc sử dụng một <iframe>phần tử trên trang web của bạn là nguy hiểm và gây ra rủi ro bảo mật, thì người đó không hiểu <iframe>phần tử đó có tác dụng gì hoặc anh ta đang nói về khả năng xuất hiện các <iframe>lỗ hổng liên quan trong trình duyệt. Bảo mật của <iframe src="...">thẻ ngang bằng <img src="..."hoặc <a href="...">miễn là không có lỗ hổng trong trình duyệt. Và nếu có một lỗ hổng bảo phù hợp, nó có thể là có thể kích hoạt nó ngay cả khi không sử dụng <iframe>, <img>hoặc <a>yếu tố, do đó, nó không đáng kể cho vấn đề này.

Tuy nhiên, hãy lưu ý rằng nội dung từ <iframe>có thể bắt đầu điều hướng cấp cao nhất theo mặc định . Nghĩa là, nội dung bên trong <iframe>được phép tự động mở liên kết qua vị trí trang hiện tại (vị trí mới sẽ hiển thị trong thanh địa chỉ). Cách duy nhất để tránh điều đó là thêm sandboxthuộc tính mà không có giá trị allow-top-navigation. Ví dụ <iframe sandbox="allow-forms allow-scripts" ...>,. Thật không may, sandbox cũng luôn vô hiệu hóa tất cả các plugin. Ví dụ: không thể sandbox nội dung Youtube vì trình phát Flash vẫn được yêu cầu để xem tất cả nội dung Youtube. Không có trình duyệt nào hỗ trợ sử dụng plugin và không cho phép điều hướng cấp cao nhất cùng một lúc.

Lưu ý rằng điều đó X-Frame-Options: DENYcũng bảo vệ khỏi cuộc tấn công kênh bên hiệu suất hiển thị có thể đọc nội dung chéo nguồn gốc (còn được gọi là "Cuộc tấn công định thời điểm hoàn hảo ").

— Mikko Rantalainen
nguồn
Tốt, nhưng không "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)."nên diễn đạt lại theo hướng của tài liệu (cha) có chứa lỗ hổng XSS đối với tài liệu (con) trong iframe?
— Shuzheng
@Shuzheng lỗ hổng bảo mật xảy ra theo cả hai cách và nếu bạn sử dụng <iframe>trên một trang, nó cho phép mở rộng lỗ hổng bảo mật từ nội dung bên trong iframe sang tài liệu lưu trữ. Câu hỏi là về <iframe>sự nguy hiểm và nếu tài liệu lưu trữ có lỗ hổng XSS, bạn thực sự không cần <iframe>phần tử.
— Mikko Rantalainen
13

Tôi giả định iFrame tên miền chéo vì có lẽ rủi ro sẽ thấp hơn nếu bạn tự kiểm soát nó.

  • Clickjacking là một vấn đề nếu trang web của bạn được bao gồm dưới dạng iframe
  • IFrame bị xâm nhập có thể hiển thị nội dung độc hại (hãy tưởng tượng iFrame hiển thị hộp đăng nhập thay vì quảng cáo)
  • Một iframe đi kèm có thể thực hiện một số lệnh gọi JS nhất định như cảnh báo và lời nhắc có thể làm phiền người dùng của bạn
  • Một iframe được bao gồm có thể chuyển hướng qua location.href (bạn có thể tưởng tượng khung 3p chuyển hướng khách hàng từ bankofamerica.com đến bankofamerica.fake.com)
  • Phần mềm độc hại bên trong khung 3p (java / flash / activeX) có thể lây nhiễm sang người dùng của bạn
— Joe Zack
nguồn
2

"Nguy hiểm" và "Rủi ro bảo mật" không phải là những điều đầu tiên mà mọi người nghĩ đến khi nhắc đến iframe… nhưng chúng có thể được sử dụng trong các cuộc tấn công bằng clickjacking .

— Quentin
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.