Chào các bác, chắc các bác cũng nghe qua về kỹ thuật tấn công XSS này rùi chứ hả.
Hôm nay mình xin giới thiệu cũng như cách tấn công ứng dụng web sử dụng kỹ thuật XSS này.
Phần 1: TÌM HIỂU VỀ XSS
XSS là gì?
Cross-Site Scripting hay còn được gọi tắt là XSS (thay vì gọi tắt là CSS
để tránh nhầm lẫn với CSS-Cascading Style Sheet của HTML) là một kĩ
thuật tấn công bằng cách chèn vào các website động (ASP, PHP, CGI, JSP
…) những thẻ HTML hay những đoạn mã script nguy hiểm có thể gây nguy
hại cho những người sử dụng khác. Trong đó những đoạn mã nguy hiểm được
chèn vào hầu hết được viết bằng Client-Site Script như javascript,
Jscript, DHTML và cũng có thể là các thẻ HTML.
XSS là một lỗi phổ biến, có rất nhiều trang web bị mắc phải lỗi này, chính vì thế ngày càng có nhiều người quan tâm đến lỗi này.
XSS hoạt động như thế nào?
XSS cho phép attacker chèn các đoạn mã vào link của đường dẫn, để thực
hiện trên trình duyệt của người dùng, dẫn đến việc mất cookies, mật
khẩu, session hay chèn virus…
Thường thì XSS có dạng như sau:
http://www.xxx.vn//index.php?pg=news&cat=<script>alert(1)</script>.
Và nội dung xuất hiện trên trình duyệt là một cái popup có thông tin là ‘1’.
Phần 2: TRUY TÌM LỖ HỔNG XSS CỦA ỨNG DỤNG WEB
Cách 1: Sử dụng nhiều chương trình dò quét lỗi của ứng dụng web, ví dụ
như chương trình Web Vulnerability Scanner để dò quét lỗi XSS.
Cách 2: Thực hiện 5 bước:
Bước 1: Mở website cần kiểm tra
Bước 2: Xác định các chỗ (phần) cần kiểm tra XSS. 1 Site bất kỳ bao giờ cũng có các phần:
Search, error message, web form. Chủ yếu lỗi XSS nằm ở phần này, nói
chung XSS có thể xảy ra ở chỗ nào mà người dùng có thể nhập dữ liệu vào
và sau đó nhận được một cái gì đó. Ví dụ chúng ta nhập vào chuỗi ‘XSS’
Bước 3: Xác minh khả năng site có bị lỗi XSS hay không bằng cách xem các
thông tin trả về. Ví dụ chúng ta thấy thế này: ‘Không tìm thấy XSS…’ ,
hay là ‘Tài khoản XSS không chính xác’, ‘Đăng nhập với XSS không thành
công’… thì khi đó khả năng chỗ đó bị dính XSS là rất cao.
Bước 4: Khi đã xác định chỗ có khả năng bị dính lỗi XSS thì chúng ta sẽ
chèn những đoạn code của chúng ta vào để thử tiếp, ví dụ như sau:
Chèn đoạn code này: < script>alert(‘XSS’)< /script> vào ô bị
lỗi và nhấn nút Login, nếu chúng ta nhận được một popup có chữ ‘XSS’
thì 100% bị dính XSS. Nhưng xin chú ý , thỉnh thoảng vẫn có trường hợp
website đó bị dính XSS nhưng vẫn không xuất hiện cái popup thì buộc lòng
bạn phải VIEW SOURCES (mổ bụng) nó ra để xem . Khi view sources nhớ
kiếm dòng này < script>alert(‘XSS)< /script> , nếu có thì
hết chạy , XSS đây rồi.
Gọi http://websitebiloi.com/
là site bị dính lỗi XSS và ta tìm được nơi bị lỗi như thế này :
http://websitebiloi.com/index.php?page=<script…</ script> ,
nghĩa là ta có thể chèn code ngay trên thanh ADDRESS.
Bước 5: Lên kế hoạch kịch bản tấn công
Phần 3: TẤN CÔNG
Thật ra thì có rất nhiều kỹ thuật tấn công dựa trên lỗi XSS này, chủ yếu
là sau khi đã biết cách tìm lỗ hổng thì mỗi người sẽ có một mưu mô cho
cách tấn công của mình. Ở đây mình xin giới thiệu đến các bạn một kỹ
thuật mà mình đã thực hiện thành công trên trang moodle của khoa công
nghệ thông tin KHTN. Kỹ thuật ăn cắp password.
Sau khi đã xác minh một điều chắc chắn rằng trang moodle bị lỗi XSS ở chỗ đăng nhập
Tôi lập tức viết ngay một ứng dụng nhỏ rồi up lên một cái host free, ứng
dụng này sẽ có nhiệm vụ nhận thông tin về mssv và password gửi về và
ghi xuống file txt. Còn nhận thế nào thì mời các bạn xem tiếp…
Sau đó:
Bước 1: Tôi tạo một mail giả dạng nói là: Diễn đàn tuyển dụng của Intel,
mời các bạn nào quan tâm thì tham gia.Rồi tạo ra một cái đường link
giả:
http://ĐườnglinkGiongThatYChang
nhưng tôi là reference nó tới một cái trang giả của tui. Trong tích tắc
trang này sẽ gắn một cái đoạn script độc có nhiệm vụ lấy về username và
password sau khi đăng nhập và gắn vào cái trang thật(Vì trang thật bị
lỗi XSS nên cho phép chúng ta gắn mã độc lên, gắn ở đây có nghĩa là khi
chúng ta view source code của trang lên, chúng ta sẽ thấy có một đoạn
script của chúng ta nằm ở đâu đó), rồi sau đó redirect sang trang thật
ngay lập tức để khỏi bị nghi ngờ.
Bước 2: Người dùng vào mail, tưởng thật, click vào link và thấy chạy
đúng trang moodle (Họ đâu ngờ rằng, trang thật đã bị gắn mã độc lên,
trong thời gian quá nhanh nên họ không nghi ngờ gì cả, nhưng nếu ai để ý
sẽ thấy link không đúng).
Bước 3: Họ đăng nhập, khi đó ứng dụng sẽ chạy biên dịch từ trên xuống,
và tất nhiên sẽ chạy luôn cả script mà chúng ta đã cài, khi đó MSSV và
password sẽ được lấy về để gửi cho một cái trang trên server mà chúng ta
đã dựng ra.
Bước 4: Ứng dụng server của ta nhận được mssv và password, ghi ra file txt.
Bước 5: Kết thúc quá trình tấn công, chúng ta có một danh sách các tài khoản của sinh viên
Phần 4: PHÒNG CHỐNG
Như đã đề cập ở trên, một tấn công XSS chỉ thực hiện được khi gửi một
trang web cho trình duyệt web của nạn nhân có kèm theo mã script độc của
kẻ tấn công. Vì vậy những người phát triển web có thể bảo vệ website
của mình khỏi bị lợi dụng thông qua những tấn công XSS này, đảm bảo
những trang phát sinh động không chứa các tag của script bằng cách lọc
và xác nhận hợp lý các dữ liệu đầu vào từ phía người dùng hoặc mã
hóa(endcoding) và lọc các giá trị xuất cho người dùng.
Lọc
Luôn luôn lọc các dữ liệu nhập từ phía người dùng bằng cách lọc các kí
tự meta (kí tự đặc biệt) được định nghĩa trong đặc tả của 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ể tránh được khi máy chủ Web đảm bảo những trang phát sinh
được mã hóa (encoding) thích hợp để ngăn chạy chạy các script không mong
muốn.
Mã hóa phía máy chủ là một tiến trình mà tất cả nội dung phát sinh động
sẽ đi qua một hàm mã hóa nơi mà các thẻ script sẽ được thay thể bởi mã
của nó.
Nói chung, việc mã hóa(encoding) được khuyến khích sử dụng vì nó không
yêu cầu bạn phải đưa ra quyết định những kí tự nào là hợp lệ hoặc không
hợp lệ.Tuy nhiên việc mã hóa tất cả dữ liệu không đáng tin cậy có thể
tốn tài nguyên và ảnh hưởng đến khả năng thực thi của một số máy chủ
Phần 5: Phạm vi và tính khả thi của phương pháp tấn công bằng XSS
Mã JavaScript độc có thể truy cập bất cứ thông tin nào sau đây:
• Cookie cố định (của site bị lỗi XSS) được duy trì bởi trình duyệt.
• RAM Cookie (của site bị lỗi XSS)
• Tên của tất cả các cửa sổ được mở từ site bị lỗi XSS
• Bất cứ thông tin mà có thể truy cập được từ DOM hiện tại (như value, mã HTML…)