Web9: Các Kiểu Khai Thác XSS – Phần 2: Stored XSS

• Tin Tức Tin tức An ninh mạng Bản tin WhiteHat
• Thành viên
• Có gì mới
• Video
• Wargame
• Vinh Danh

Đăng nhập

Tìm kiếm

Toàn bộ Chủ đề Diễn đàn này This thread Chỉ tìm trong tiêu đề Bởi: Tìm Tìm nâng cao…

• Hoạt động gần đây
• Đăng ký

Đăng nhập Đăng ký Giới thiệu Liên hệ

CỘNG ĐỒNG AN NINH MẠNG VIỆT NAM

@ 2009 - 2021 Bkav Corporation

Install the app Install

• Thảo luận
• Web Security

You are using an out of date browser. It may not display this or other websites correctly.You should upgrade or use an alternative browser. Web9: Các kiểu khai thác XSS – Phần 2: Stored XSS

• Bắt đầu ping
• Ngày bắt đầu 10/06/2014

Chia sẻ: Facebook Twitter Reddit Pinterest Tumblr WhatsApp Email Chia sẻ Liên kết

ping

VIP Members

19/06/2013 58 101 bài viết Web9: Các kiểu khai thác XSS – Phần 2: Stored XSS Trong bài trước, tôi đã giới thiệu qua về lỗi XSS(Cross Site Scripting) và hướng khai thác thực tế của XSS Reflected. Có một thể loại khác của XSS được xem là nguy hiểm hơn, Stored XSS. Khác với Reflected tấn công trực tiếp vào một số nạn nhân mà hacker nhắm đến, Stored XSS hướng đến nhiều nạn nhân hơn. Lỗi này xảy ra khi ứng dụng web không kiểm tra kỹ lưỡng dữ liệu đầu vào trước khi lưu vào cơ sở dữ liệu(ở đây tôi dùng khái niệm này để chỉ database, file hay những khu vực khác lưu trữ dữ liệu của ứng dụng web). Với kỹ thuật Stored XSS , hacker không khai thác trực tiếp mà phải thực hiện tối thiểu qua 2 bước. Đầu tiên hacker thông qua các điểm đầu vào(form, input, textarea...) không lọc kỹ để chèn vào CSDL các đoạn mã nguy hiểm. Tiếp theo, Khi người dùng truy cập vào ứng dụng web và thực hiện các thao tác liên quan đến dữ liệu được lưu này,đoạn mã của hacker sẽ được thực thi trên trình duyệt người dùng. Đến đây hacker coi như đã đạt được mục đích của mình. Vì lí do này mà kỹ thuật Stored XSS còn được gọi là second-order XSS. Kịch bản khai thác được mô tả như hình sau: Reflected XSS và Stored XSS có 2 sự khác biệt lớn trong quá trình tấn công.

• Thứ nhất, để khai thác Reflected XSS, hacker phải lừa được nạn nhân truy cập vào URL của mình. Còn Stored XSS không cần phải thực hiện việc này, sau khi chèn được mã nguy hiểm vào CSDL của ứng dụng, hacker chỉ việc ngồi chờ nạn nhân tự động truy cập vào. Với nạn nhân, việc này là hoàn toàn bình thường vì họ không hề hay biết dữ liệu mình truy cập đã bị nhiễm độc.
• Thứ 2, mục tiêu của hacker sẽ dễ dàng đạt được hơn nếu tại thời điểm tấn công nạn nhân vẫn trong phiên làm việc(session) của ứng dụng web. Với Reflected XSS, hacker có thể thuyết phục hay lừa nạn nhân đăng nhập rồi truy cập đến URL mà hắn ta cung cấp để thực thi mã độc. Nhưng Stored XSS thì khác, vì mã độc đã được lưu trong CSDL Web nên bất cứ khi nào người dùng truy cập các chức năng liên quan thì mã độc sẽ được thực thi, và nhiều khả năng là những chức năng này yêu cầu phải xác thực(đăng nhập) trước nên hiển nhiên trong thời gian này người dùng vẫn đang trong phiên làm việc.

Từ những điều này có thể thấy Stored XSS nguy hiểm hơn Reflected XSS rất nhiều, đối tượng bị ảnh hưởng có thế là tất cả nhưng người sử dụng ứng dụng web đó. Và nếu nạn nhân có vai trò quản trị thì còn có nguy cơ bị chiếm quyền điều khiển web. Chỉnh sửa lần cuối bởi người điều hành: 15/09/2014 Bạn phải đăng nhập hoặc đăng ký để phản hồi tại đây. Bài viết liên quan

Web Pentest - Bài 7: Tìm kiếm các lỗ hổng liên quan đến File Upload

• Ngày bắt đầu 10/09/2021
• 7

Web Pentest - Bài 6: Tìm kiếm, xây dựng các môi trường luyện tập

• Ngày bắt đầu 14/07/2021
• 2

Web Pentest - Bài 4: Các lỗ hổng phía client, các cơ chế bảo vệ, và bypass

• Ngày bắt đầu 29/05/2021
• 0

Phát hiện và phòng ngừa WebShells theo cách của NSA

• Ngày bắt đầu 30/04/2020
• 0

Tìm hiểu các loại tấn công bằng Burp Suite Intruder

• Ngày bắt đầu 31/08/2019
• 0

Một vài cách vượt qua tường lửa ứng dụng web (WAF) để tìm lỗ hổng SQLi

• Ngày bắt đầu 08/07/2019
• 0

Bên trên