Cơ chế tấn công Để tìm hiểu về XSS, trước hết ta hãy xét một ví dụ đơn giản: giả sử rằngtrong website viết bằng ngôn ngữ PHP có một trang index.php chứa đoạn mãsau: Ví dụ: Trang web có t
TẤN CÔNG XSS
Cơ chế tấn công
Để hiểu rõ về XSS, chúng ta bắt đầu bằng ví dụ đơn giản, giả sử một trang index.php trong website PHP chứa đoạn mã sau.
Trang web có thể bị tấn công XSS khi mã độc được chèn vào trang web thông qua các yêu cầu từ người dùng Ví dụ, người dùng gửi một yêu cầu GET tới trang index.php với tham số name chứa tên của họ, như “John” Máy chủ sẽ trả về một trang chào mừng kèm theo liên kết đến http://examples.com Nếu không được kiểm soát, kẻ tấn công có thể chèn mã độc vào tham số này, dẫn đến các cuộc tấn công XSS và ảnh hưởng đến an ninh của trang web.
Dòng lệnh echo đầu tiên đã in ra dữ liệu người dùng mà không thực hiện bất kỳ biện pháp kiểm tra nào, khiến trang web dễ bị tấn công XSS Thay vì gửi tên thông thường như John hay Bob, kẻ tấn công có thể chèn đoạn mã script độc hại vào tham số name để khai thác lỗ hổng.
Khi đó, thay vì nhận được dòng chào mừng như đã biết, trình duyệt sẽ đưa ra thông báo:
Hình 2 1 Thông báo cho thấy website có thể bị tấn công XSS
Hộp thoại hiển thị trên máy của kẻ tấn công nhằm chứng minh rằng website có thể bị tấn công bằng kỹ thuật XSS, gây nguy hiểm cho người dùng Kẻ tấn công có thể lợi dụng điểm yếu này để thay đổi liên kết trong các thông báo như "Click to Download" từ "http://examples.com" thành địa chỉ độc hại như "http://a-fake-site.com." Để thực hiện điều đó, họ gửi email dụ dỗ nạn nhân mở liên kết độc hại và khai thác lỗ hổng XSS để thực hiện các hành động gây hại cho website và người dùng.
Khi đó, kết quả hiển thị trên cửa sổ trình duyệt sẽ không khác gì so với khi gửi yêu cầu với tham số name đơn giản là John. Ở đây cần lưu ý rằng đoạn scirpt phải được thực hiện với sự kiện window.onload Đó là vì đoạn script này được xuất ra trước khi có cặp thẻ
Thành ra, trình duyệt sẽ báo lỗi nếu chúng ta chèn đoạn script như sau: index.php?name=var link=document.getElementsByTagName("a");link[0].href="h ttp://a
Mặt khác, để tránh nạn nhân nhìn thấy đoạn script và đoán được hậu quả, kẻ tấn công sẽ mã hóa (encode) các kí tự ASCII về dạng hexa như sau: index.php?%6e%61%6d%65%3d%4a%6f%68%6e%3c
Cách biểu diễn trên đây tương đương với index.php? name=Johnwindow.onload=functio()
0].href=" http://a-fake-site.com/";}
Tức là mỗi kí tự ASCII (có mã là 1 byte) được mã hóa thành 2 kí tự hexa
Dấu phần trăm (%) được sử dụng trong URL để báo cho trình xử lý biết rằng ký tự sau đó là mã hexa của ký tự đặc biệt, giúp mã hóa chính xác các ký tự trong liên kết Ví dụ, ký tự "n" trong "index.php?" có mã ASCII là 110 và được chuyển đổi thành mã hexa là %6e, giúp đảm bảo đường liên kết hoạt động đúng khi truyền qua internet Bạn có thể tham khảo các trang web như http://www.url-encode-decode.com/ để mã hóa và giải mã các ký tự đặc biệt trong URL, hoặc http://www.asciitohex.com/ để mã hóa các ký tự thông thường bằng hệ thập lục phân Ngoài ra, để quy đổi các dấu cách thành định dạng phù hợp trong URL, cần thay thế chúng bằng dấu phần trăm (%).
Các tấn công XSS có thể được chia thành hai loại: Reflected XSS và Persistent XSS.
Reflected XSS được thực hiện và có hiệu lực trong một cặp truy vấn và phản hồi HTTP Trong 0, khi gửi tới website một truy vấn là index.php?name=Johnalert('This site is vulnerable to XSS')
Reflected XSS là dạng tấn công không có trạng thái, trong đó kết quả truy vấn tiếp theo không phụ thuộc vào các truy vấn trước đó Khi nhận phản hồi từ website, trình duyệt sẽ hiển thị thông báo lỗi phù hợp, đồng thời trong tấn công Reflected XSS, trình duyệt gửi payload thì chính trình duyệt đó sẽ chịu tác động của payload Để thực hiện loại tấn công này, kẻ tấn công thường cần phải sử dụng kỹ năng xã hội để thuyết phục nạn nhân nhấn vào liên kết độc hại đã chuẩn bị sẵn, khiến nạn nhân vô tình tiết lộ lỗ hổng bảo mật.
Hình 2 Kịch bản tấn công XSS đơn giản
Trong các trường hợp đơn giản, kẻ tấn công có thể giả mạo tổ chức hoặc bạn bè để lừa nạn nhân nhấp vào liên kết chứa mã độc Tấn công Persistent XSS (Stored XSS) cho phép kẻ tấn công lưu mã độc trên máy chủ, như trong bài viết diễn đàn hoặc bình luận, gây nguy cơ bị đánh cắp phiên HTTP khi người dùng truy cập.
Session ID là yếu tố quan trọng để duy trì trạng thái xác thực của người dùng trong một phiên làm việc, và việc đánh cắp thông tin này có thể dẫn đến truy cập trái phép vào các tài khoản email, game, ví điện tử, hoặc ngân hàng của nạn nhân Các cuộc tấn công XSS không chỉ giúp kẻ xấu đoán và khai thác Session ID mà còn có thể được sử dụng để quét mạng LAN, cấu hình lại router, thêm bạn bè giả mạo trên mạng xã hội hoặc phối hợp với tấn công CSRF để thực hiện các hành vi gây hại.
Mọi cuộc tấn công XSS đều dựa trên khả năng thay đổi cấu trúc DOM (Document Object Model) của trang web để chèn mã độc Mục tiêu chính của các hacker là người dùng, khi họ truy cập vào các trang bị tấn công, dẫn đến việc khai thác thông tin cá nhân hoặc tài khoản của người dùng một cách trái phép.
Biện pháp phòng chống
Một ứng dụng web dễ bị tấn công XSS khi nó tiếp nhận và xử lý dữ liệu từ người dùng, đặc biệt tại các vị trí như ô tìm kiếm, ô nhập liệu, định danh người dùng, mật khẩu, và các khu vực cho phép đăng tải bình luận hoặc bài viết trên diễn đàn, mạng xã hội Kẻ tấn công thường nhắm tới việc đánh cắp phiên làm việc hoặc thông tin tài khoản người dùng để có thể thực hiện các hành động trái phép Các website có cơ hội bị tấn công XSS cao nếu không có các biện pháp bảo vệ phù hợp trong quá trình xử lý dữ liệu đầu vào.
Các chế xác thực dựa trên User ID và mật khẩu là những mục tiêu chính trong các cuộc tấn công XSS, đặc biệt là tại các ô nhập liệu chứa thông tin người dùng Các lỗ hổng này có thể bị khai thác để chèn mã độc, gây nguy hiểm cho dữ liệu cá nhân và hệ thống bảo mật Việc bảo vệ các form đăng nhập và xác thực quan trọng giúp giảm thiểu rủi ro tấn công XSS, đảm bảo an toàn cho người dùng và hệ thống Chính vì vậy, cần triển khai các biện pháp phòng chống XSS hiệu quả cho các trường hợp chứa thông tin nhạy cảm này.
Để thực hiện tấn công XSS, kẻ tấn công nhắm vào các vị trí trên website nơi người dùng cung cấp dữ liệu để chèn mã độc Mục tiêu của họ là đánh cắp thông tin cá nhân hoặc phiên làm việc của nạn nhân qua việc khai thác các lỗ hổng bảo mật này Do đó, việc kiểm tra và bảo vệ các điểm nhập dữ liệu trên website là vô cùng cần thiết để ngăn chặn các cuộc tấn công XSS có thể xảy ra.
Bước đầu tiên, truy cập vào website mục tiêu và xác định các vị trí phù hợp để nhập dữ liệu, như ô tìm kiếm, ô bình luận và ô đăng nhập Việc này giúp xác định các điểm tương tác chính trên trang web để thực hiện các thao tác tự động một cách hiệu quả.
Bước 2 Xác định khả năng website mục tiêu có chứa lỗi XSS Chọn một vị trí nhập dữ liệu và nhập vào một chuỗi kí tự nào đó, ví dụ "Test for XSS" và kiểm tra kết quả trả về Nếu trong kết quả trả về có các dòng như
"Your search for 'Test for XSS' did not find any items"
"Your search for 'Test for XSS' returned the following results"
"User 'Test for XSS' is not valid"
"Invalid login 'Test for XSS' " hoặc thông báo bất kì mà có chứa "Test for XSS" thì website trên có khả năng có lỗi XSS.
Ngoài việc nhập dữ liệu kiểm tra vào các vị trí trên website, kẻ tấn công còn có thể nhập dữ liệu trực tiếp vào dòng địa chỉ trình duyệt Các truy vấn có dạng này cho phép thay thế các giá trị như value1, value2 bằng chuỗi kiểm tra nhằm khai thác lỗ hổng hoặc xác định các phản hồi của hệ thống Điều này nhấn mạnh khả năng tấn công qua dòng địa chỉ trình duyệt, đòi hỏi các biện pháp phòng chống phù hợp để bảo vệ website.
Trong bước 3 của quá trình kiểm tra bảo mật, cần chèn mã vào vị trí có khả năng chứa lỗi Sau khi xác định chính xác các vị trí dễ bị tấn công, kẻ tấn công sẽ nhập đoạn mã độc hại vào đó để khai thác lỗ hổng Việc này giúp đánh giá điểm mạnh, điểm yếu của hệ thống và cải thiện khả năng phòng chống các cuộc tấn công qua mã độc.
alert('Test for XSS') Nếu sau đó trình duyệt đưa ra một hộp thoại thông báo "Test for XSS" thì chắc chắn là website có chứa lỗi XSS Cũng cần lưu ý rằng, vẫn có trường hợp website có chứa lỗi XSS nhưng không có hộp thoại nào xuất hiện Khi đó, cần phải duyệt mã nguồn (view source code) của webpage trả về để kiểm tra Nếu trong mã nguồn có chứa dòng alert('Test for XSS') thì chứng tỏ website có chứa lỗi XSS. Điểm khác nhau giữa Bước 2 và Bước 3 là gì? Liệu có thể bỏ qua Bước
Việc chuyển trực tiếp sang Bước 3 mà không qua Bước 2 có thể cho thấy chuỗi ký tự sử dụng trong Bước 2 không chứa đoạn mã độc, giúp kẻ tấn công vượt qua các bộ lọc phía server Thành công ở Bước 2 cho thấy website có khả năng bị lỗi XSS, trong khi thành công tại Bước 3 xác nhận chắc chắn rằng website đang gặp vấn đề về lỗi XSS, đòi hỏi các biện pháp phòng ngừa và xử lý kịp thời để bảo vệ an toàn dữ liệu.
Bước 4 Khai thác Việc khai thác lỗi sẽ rất khác nhau khi mục đích là khác nhau.
Như vậy, yếu tố quan trọng đảm bảo thành công của một tấn công XSS là kẻ tấn công phải chèn mã kịch bản (hoặc mã DHTML) vào kết quả mà website trả về cho trình duyệt Do đó, phòng chống tấn công XSS thì việc cần thiết là phát hiện và vô hiệu hóa các đoạn mã như thế Cần phải nhấn mạnh rằng, lỗi XSS xuất phát từ sự bất cẩn của người lập trình Đó là khi ứng dụng web thực hiện xuất dữ liệu người dùng (trả về cho trình duyệt) mà không có sự kiểm tra thỏa đáng.
Việc phát hiện và vô hiệu hóa các đoạn mã độc trong ứng dụng web có thể thực hiện nhờ các bộ lọc phòng chống tấn công Khi ký tự đặc biệt như '' xuất hiện trong định danh người dùng, chúng có thể biểu hiện dấu hiệu của tấn công hoặc lỗi bảo mật Để đảm bảo an toàn, cần thay thế các ký tự có thể gây hại này bằng mã HTML tương ứng, ví dụ như thay '' bằng ">", giúp ngăn chặn các lỗ hổng bảo mật Các công cụ lập trình web như PHP hỗ trợ việc thay thế ký tự nhạy cảm trong chuỗi thông qua các hàm như str_replace, giúp xử lý an toàn dữ liệu đầu vào của người dùng.
Bạn có thể sử dụng thư viện HTML Purifier (http://htmlpurifier.org) để ngăn chặn mã độc XSS trong website của mình HTML Purifier là thư viện mạnh mẽ, có khả năng lọc và làm sạch mã HTML nhằm bảo vệ hệ thống khỏi các lỗ hổng bảo mật Được xây dựng theo mô hình OSS, thư viện này rất dễ tích hợp, chỉ cần bao gồm thư viện, tạo instance của đối tượng HTML Purifier và gọi phương thức purify() để xử lý dữ liệu đầu vào an toàn và hiệu quả.
Ngôn ngữ ASP hỗ trợ hai phương thức URLEncode và HTMLEncode của đối tượng Server cho phép chuyển đổi các kí tự đặc biệt trong URL và trong mã HTML:
Tuy nhiên, việc lọc các kí tự trên đây có thể dễ dàng bị kẻ tấn công qua mặt nhờ vào kỹ thuật mã hóa Ví dụ, kí tự '' có thể được mã hóa thành '%e3' Như vậy, cần có một quy tắc lọc phức tạp hơn để chống lại kỹ thuật mã hóa này Sử dụng biểu thức chính quy (regular expression) sẽ rất hữu ích trong trường hợp này Một biểu thức chính quy dùng để phát hiện tấn công XSS dạng đơn giản:
((\%3C)|) - kiểm tra dấu ngoặc đóng ( > )
TẤN CÔNG CSRF
Giới thiệu
Cross-Site Scripting (XSS), hay còn gọi là kịch bản liên trang, là một kỹ thuật tấn công phổ biến và nguy hiểm đối với bảo mật web XSS cho phép kẻ tấn công chèn mã độc như JavaScript, JScript, hoặc DHTML vào các website động như ASP, PHP, CGI, JSP, gây hại cho người dùng nếu không được kiểm tra và xử lý chặt chẽ Được phát hiện lần đầu vào năm 2002, XSS nhanh chóng trở thành một trong những lỗ hổng bảo mật phổ biến nhất trong các ứng dụng web, đe dọa nghiêm trọng đến an toàn người dùng.
2 Cơ chế tấn công Để tìm hiểu về XSS, trước hết ta hãy xét một ví dụ đơn giản: giả sử rằng trong website viết bằng ngôn ngữ PHP có một trang index.php chứa đoạn mã sau:
Ví dụ: Trang web có thể bị tấn công XSS Đoạn mã trên có ý nghĩa như sau: người ta mong đợi rằng người dùng sẽ gửi một request bằng phương thức GET tới trang index.php, trong request đó có một tham số là name chứa tên của người dùng Nhận được yêu cầu đó, máy chủ sẽ trả về một trang web, trong đó có lời chào mừng tới người dùng và một đường liên kết tới địa chỉ http://examples.com Nếu người dùng tên là John thì yêu cầu gửi đến máy chủ sẽ có dạng và phản hồi của máy chủ khi đó sẽ có dạng:
Dòng lệnh echo đầu tiên đã xuất ra dữ liệu người dùng mà không thực hiện kiểm tra, gây nguy cơ trang web bị tấn công XSS Thay vì gửi tên thông thường như John hay Bob, kẻ tấn công có thể chèn mã script độc hại vào tham số name Đây là một ví dụ minh họa về lỗ hổng bảo mật tiềm ẩn trong ứng dụng web khi không kiểm soát dữ liệu đầu vào của người dùng Việc bỏ qua các biện pháp kiểm tra đầu vào có thể dẫn đến các cuộc tấn công mã độc, đe dọa an toàn của trang web và người dùng.
Khi đó, thay vì nhận được dòng chào mừng như đã biết, trình duyệt sẽ đưa ra thông báo:
Hình 2 1 Thông báo cho thấy website có thể bị tấn công XSS
Thực ra hộp thoại trên đây sẽ hiện lên trên chính máy của kẻ tấn công, và chẳng có gì nguy hiểm Tuy vậy, điều đó chứng tỏ là website có thể bị tấn công bằng XSS Và điểm yếu này có thể bị khai thác để thực hiện những hành động gây hại cho website và cho người dùng khác Ví dụ, kẻ tấn công có thể thay đường liên kết "http://examples.com" bên dưới dòng thông báo "Click to Download" bằng một địa chỉ khác, "http://a-fake-site.com" chẳng hạn Để thực hiện việc đó, kẻ tấn công sẽ gửi tới các nạn nhân một email có chứa liên kết: và dụ nhạn nhân mở liên kết này.
Khi đó, kết quả hiển thị trên cửa sổ trình duyệt sẽ không khác gì so với khi gửi yêu cầu với tham số name đơn giản là John. Ở đây cần lưu ý rằng đoạn scirpt phải được thực hiện với sự kiện window.onload Đó là vì đoạn script này được xuất ra trước khi có cặp thẻ
Thành ra, trình duyệt sẽ báo lỗi nếu chúng ta chèn đoạn script như sau: index.php?name=var link=document.getElementsByTagName("a");link[0].href="h ttp://a
Để tránh nạn nhân nhận biết đoạn script và đoán trước hậu quả, kẻ tấn công thường mã hóa các ký tự ASCII thành dạng hexa, ví dụ như trong URL: index.php?%6e%61%6d%65%3d%4a%6f%68%6e%3c, nhằm làm mask mã độc và tránh bị phát hiện.
Cách biểu diễn trên đây tương đương với index.php? name=Johnwindow.onload=functio()
0].href=" http://a-fake-site.com/";}
Tức là mỗi kí tự ASCII (có mã là 1 byte) được mã hóa thành 2 kí tự hexa
Dấu phần trăm (%) trong URL được sử dụng để mã hóa các ký tự đặc biệt bằng hệ thập lục phân (hexa) Ví dụ, ký tự "n" có mã ASCII là 110, được chuyển đổi thành %6e trong URL để đảm bảo tính khả chuyển và chính xác khi truyền dữ liệu Để dễ dàng mã hóa và giải mã các ký tự trong liên kết, bạn có thể tham khảo các công cụ như http://www.url-encode-decode.com/ hoặc http://www.asciitohex.com/ Ngoài ra, để sử dụng các ký tự thông thường trong URL, cần thay thế dấu cách bằng ký tự phần trăm (%) theo quy ước của mã hóa URL.
Các tấn công XSS có thể được chia thành hai loại: Reflected XSS và Persistent XSS.
Reflected XSS occurs when malicious scripts are embedded within a single HTTP query and response, exploiting vulnerabilities in web applications For example, sending a URL like index.php?name=Johnalert('This site is vulnerable to XSS') can trigger the execution of harmful scripts Addressing reflected XSS vulnerabilities is crucial for securing websites against cross-site scripting attacks Proper input validation and output encoding are essential measures to prevent reflected XSS from compromising user data and website integrity.
Reflected XSS là dạng tấn công không trạng thái, trong đó kết quả truy vấn phụ thuộc vào yêu cầu của trình duyệt và không liên quan đến các truy vấn trước đó Khi một website phản hồi có chứa mã độc, trình duyệt sẽ hiển thị thông báo lỗi phù hợp Trong các cuộc tấn công Reflected XSS, chính trình duyệt gửi payload sẽ là đối tượng bị tác động, yêu cầu nạn nhân phải nhấn vào liên kết do kẻ tấn công tạo sẵn Điều này có nghĩa kẻ tấn công cần có kỹ năng về kỹ nghệ xã hội để thuyết phục nạn nhân tương tác đúng cách, nhằm thực hiện thành công cuộc tấn công này.
Hình 2 Kịch bản tấn công XSS đơn giản
Trong các trường hợp đơn giản, kẻ tấn công có thể giả mạo một tổ chức hoặc bạn bè để lừa nạn nhân nhấp vào các liên kết chứa mã độc Tấn công Persistent XSS (Stored XSS) cho phép tội phạm lưu mã độc trực tiếp trên máy chủ, như trong các bài viết hoặc bình luận trên diễn đàn Khi người dùng truy cập vào các trang web chứa mã độc này, họ có thể bị tấn công, ví dụ như bị đánh cắp phiên HTTP (session) nhờ mã độc được chèn vào trang web.
Session ID giữ vai trò quan trọng trong việc duy trì trạng thái xác thực của người dùng trong các phiên làm việc, nhưng nếu bị đánh cắp, kẻ tấn công có thể truy cập vào các tài khoản như email, game, ví điện tử hoặc ngân hàng của nạn nhân Các cuộc tấn công XSS không chỉ lấy cắp Session ID mà còn có thể dùng để quét cổng mạng LAN, cấu hình lại router, thêm bạn bè trên mạng xã hội hoặc kết hợp với tấn công CSRF để mở rộng phạm vi ảnh hưởng và chiếm quyền kiểm soát hệ thống.
Mọi cuộc tấn công XSS đều dựa vào khả năng thay đổi cấu trúc DOM (Document Object Model) của trang web, nhằm mục đích kiểm soát nội dung và hành vi của trang Mục tiêu chính của các hacker là người dùng, khi họ truy cập vào các trang web chứa mã độc, từ đó khai thác thông tin cá nhân hoặc tài khoản của người dùng một cách trái phép.
Một ứng dụng web chỉ có thể bị tấn công XSS nếu nó tiếp nhận và xử lý dữ liệu từ người dùng Các vị trí phổ biến nhất là các ô tìm kiếm, các ô nhập liệu như định danh người dùng (user ID), mật khẩu, và các khu vực cho phép đăng tải bình luận, bài viết trên diễn đàn hoặc mạng xã hội Kẻ tấn công thường nhắm đến mục tiêu đánh cắp phiên làm việc hoặc thông tin tài khoản người dùng Các website có cơ
Các đối tượng chính bị tấn công XSS thường là các xác thực qua User ID và mật khẩu, đặc biệt là các ô nhập liệu liên quan đến thông tin người dùng Các lỗ hổng này có thể bị khai thác để chèn mã độc, gây nguy hiểm cho dữ liệu cá nhân và an ninh hệ thống Do đó, việc bảo vệ các ô nhập liệu liên quan đến thông tin người dùng là rất quan trọng để ngăn chặn các cuộc tấn công XSS Các biện pháp như xác thực chặt chẽ và kiểm tra đầu vào giúp giảm thiểu nguy cơ bị tấn công Việc hiểu rõ các đối tượng dễ bị tấn công sẽ giúp tăng cường bảo mật hệ thống và bảo vệ dữ liệu người dùng hiệu quả hơn.
TẤN CÔNG SQL INJECTION
Giới thiệu chung
Cross-site Request Forgery (CSRF), hay còn gọi là giả mạo yêu cầu liên trang, là một kỹ thuật tấn công nhằm lợi dụng thông tin xác thực của nạn nhân để thực hiện các thao tác trên website mà nạn nhân đã đăng nhập Giống như XSS, CSRF nhắm vào người dùng thay vì hệ thống Kẻ tấn công có thể lừa nạn nhân thực hiện các truy vấn không mong muốn tới web server trong phạm vi phiên làm việc hiện tại của họ, tận dụng việc trình duyệt tự động gửi session ID trong các truy vấn sau khi người dùng đã xác thực.
Sau khi người dùng đăng nhập thành công, tất cả các yêu cầu tiếp theo từ trình duyệt sẽ tự động kèm theo thông tin xác thực, giúp duy trì trạng thái đăng nhập và nâng cao trải nghiệm người dùng Việc này đảm bảo rằng hệ thống có thể nhận diện người dùng một cách dễ dàng và an toàn trên các phiên làm việc tiếp theo Tích hợp thông tin xác thực trong yêu cầu giúp cải thiện bảo mật và tối ưu hóa quá trình truy cập dịch vụ trực tuyến.
Kẻ tấn công lợi dụng kỹ thuật tạo ra yêu cầu giả mạo từ trang web khác để lừa trình duyệt của nạn nhân gửi yêu cầu không có sự nhận thức của người dùng Mục tiêu là thực hiện các hành động đã được xác thực, như chuyển tiền, thay đổi mật khẩu hoặc thực hiện các thao tác trái phép khác, gây thiệt hại cho người dùng và hệ thống mục tiêu.
Dịch vụ Internet Banking của ngân hàng cung cấp chức năng chuyển tiền giữa các tài khoản một cách tiện lợi Để thực hiện giao dịch chuyển tiền từ tài khoản A sang tài khoản B, khách hàng sử dụng một lệnh (HTTP request) gồm các tham số sender (người gửi), receiver (người nhận), và amount (số tiền chuyển) Chỉ người dùng sở hữu tài khoản A mới có quyền gửi yêu cầu chuyển tiền từ tài khoản của mình, do đó hệ thống web server cần có cơ chế xác thực để đảm bảo yêu cầu thực hiện đúng người dùng chủ sở hữu tài khoản.
Để tạo thuận lợi cho người dùng, web server chỉ yêu cầu xác thực một lần duy nhất và lưu trạng thái xác thực này dưới dạng cookie trong phiên làm việc Trình duyệt tự động gửi thông tin xác thực này tới server cho các yêu cầu tiếp theo, giúp người dùng truy cập không cần xác thực lại Tuy nhiên, nếu có ai đó lợi dụng cơ chế này, như B dụ dỗ A gửi truy vấn, thì tiền trong tài khoản của A có thể bị chuyển sang tài khoản của B một cách nhanh chóng.
Có nhiều cách thức khác nhau để B đạt được mục đích của mình Nếu như
B biết được rằng A có tham gia và đăng bài vào forum F thì B có thể đăng một bình luận cho bài viết của A:
Khi đó, thường thì A sẽ nhận được thông báo từ forum rằng có người đã bình luận về bài viết của anh ta Nếu A vào forum để xem bình luận trong khi đang làm việc với website www.xbank.com thì truy vấn trong thẻ sẽ được thực thi thành công và tiền từ tài khoản của A sẽ được chuyển sang tài khoản của B mà A không hề hay biết Bởi lẽ thuộc tính kích thước của ảnh được thiết lập là 0x0 nên A sẽ không nhận biết được sự có mặt của thẻ này.
Hoặc nếu B biết được địa chỉ email của A thì B có thể gửi cho A một email dạng mã HTML với nội dung
Mặc dù người dùng khó nhận biết bằng mắt thường về sự xuất hiện của truy vấn chuyển tiền trong trang web đang xem, nhưng khi xem mã nguồn của trang, họ sẽ dễ dàng phát hiện các đường liên kết đáng ngờ Tuy nhiên, B có thể che giấu các liên kết này bằng cách sử dụng các phương pháp liên quan, giúp làm giảm khả năng bị phát hiện và tăng cường bảo vệ trong quá trình truyền dữ liệu.
và cấu hình lại máy chủ:
