Web Pentest - Bài 4: Các lỗ hổng phía client, các cơ chế bảo vệ, và bypass

[bobby13689]

Chào các bạn.

Sau một loạt bài về thu thập thông tin, thì nay chúng ta sẽ bước vào một giai đoạn mới, đó là tìm hiểu một số dạng lỗ hổng của ứng dụng.

Bài hôm nay chủ yếu tìm hiểu các lỗ hổng liên quan đến Client-Side và tìm cách khai thác chúng.

Trong quá trình hoạt động của ứng dụng, không ít lần chúng gửi và nhận input từ người dùng, và không ít lần chúng sử dụng input từ người dùng để xử lý các thông tin này. Một số thông tin mà ứng dụng gửi cho người dùng, có thể ở dạng không đọc hiểu được (token), hoặc không thể chỉnh sửa được.

Thông thường thì lập trình viên sẽ ngầm định rằng những thông tin này đã được gửi cho người dùng và có kiểm tra ở trình duyệt, thì người dùng sẽ không thể sửa được, và tin tưởng các thông tin này trong request nhận từ người dùng. Trong vài phút tới, chúng ta sẽ thấy rằng, giả định đó là không hoàn toàn chính xác.

Chúng ta cùng điểm qua một số thông tin mà ứng dụng truyền cho người dùng và có thể nhận lại ở trong request.

1. Các trường ẩn trong ứng dụng
   
   Có bao giờ bạn vào một trang web mua hàng, ứng dụng cho bạn nhập số sản phẩm, giá tiền là 1 con số cố định, ứng dụng sẽ nhân số sản phẩm với giá để ra tổng tiền cuối cùng? Có bao giờ bạn tự hỏi rằng, mình có thể thay đổi giá tiền đó được không chưa?
   
   
   
   
   
   
   Đoạn code của trang tính tiền trên cũng khá đơn giản:
   

   <form method=”post” action=”Shop.aspx?prod=1”>
     Product: iPhone 5 <br/>
     Price: 449 <br/>
     Quantity: <input type=”text” name=”quantity”> (Maximum quantity is 50)
     <br/>
     <input type=”hidden” name=”price” value=”449”>
     <input type=”submit” value=”Buy”>
     </form>

   
   Và khi nhấn nút Buy, ứng dụng sẽ gửi request như sau:
   
   
   
   
   
   Đối với một người dùng bình thường, thì có vẻ là số 449 kia khó có thể thay đổi được, còn đối với 1 pentester? Không quá khó.
   
   Chúng ta có thể sử dụng:
   • Proxy (Burp/ZAP hoặc bất kì proxy nào), chỉnh sửa số này.
   • Developer Tools ngay trên chính trình duyệt của bạn. Mình để các bạn tự tìm hiểu phần này nhé. Nếu tìm không ra có thể ping mình hỗ trợ.
   
   
2. HTTP Cookies
   Một kênh khác mà ứng dụng có thể tận dụng để lưu trữ thông tin của user ở phía client-side, đó là cookie. Lợi thế của việc này là người dùng sẽ "khó" để nhìn thấy hơn, vì không hiển thị trên giao diện ứng dụng, tuy nhiên với Proxy hoặc Developer tools (như mình chia sẻ ở trên) thì không có gì khó cả.
   Một ví dụ bạn có thể hình dung về việc lưu trữ mã giảm giá của người dùng ở Cookie
   
   
   
3. Các tham số ở URL
   Cách này thì khá rõ ràng rồi, ở 2 ví dụ trên đều đang sử dụng param để lưu thông tin mà người dùng nhập vào, và giá tiền của sản phẩm.
4. Referer Header
   Một số ứng dụng tận dụng khả năng tracking của Referer header để kiểm tra xem user thực hiện request này đến từ đâu, ngoài mục đích thống kê, còn có một số ứng dụng, sử dụng thông tin này để hiển thị thông tin cho phù hợp với người dùng.
   
   Lấy ví dụ:
   • Nếu Referer header là https://example/auth/472/Admin.ashx, ứng dụng sẽ giả định là người dùng này đã login vào Admin portal, và hiển thị trang quản trị cho admin.
   • Nếu Referer header là https://example/auth/472/User.ashx, ứng dụng sẽ giả định là người dùng này chỉ là người dùng bình thường, và chỉ hiển thị trang quản trị tài khoản cho user.

Chúng ta có thể thấy rằng, toàn bộ các dạng data mà mình vừa đề cập ở trên, đều có thể dễ dàng sửa được bằng Proxy.

Nếu các bạn sử dụng Burp thì để thay đổi các giá trị này, các bạn chỉ cần sử dụng Repeater (mình đã có một hướng dẫn sử dụng ở bài 1 (ở đây). Cách sửa giá trị sử dụng Repeater sẽ rất dễ làm, tuy nhiên có một nhược điểm là nhiều khi các bạn chỉ muốn sửa 1 request chứ không cần toàn bộ, thì chúng ta sẽ sử dụng ngay tính năng sửa trong khi Intercept luôn.

Khi Burp đang bật chế độ Intercept, bạn để ý ở tab Intercept của tab Proxy

Trên ứng dụng khi bạn nhấn submit, thì ứng dụng sẽ gửi request này sang Burp, và chờ bạn xử lý trước khi gửi đi.

Ở đây, bạn chỉ việc thay đổi các giá trị mà mình muốn, sau đó nhấn "Forward" để gửi request đi, hoặc nếu muốn ứng dụng không gửi request nào đó, chỉ việc nhấn "Drop", rất dễ dàng phải không nào.


Với việc có các cơ chế để truyền thông tin như vậy, thì ứng dụng sẽ có một số biện pháp để bảo vệ khỏi việc thay đổi các thông tin này, có thể kể đến

1. Giới hạn chiều dài
   Trong khi sử dụng các ứng dụng, chắc hẳn không ít lần bạn sẽ gặp phải việc ứng dụng kiểm tra độ dài của chuỗi bạn nhập vào, và báo rằng bạn nhập quá độ dài cho phép?
   
   

   <form method=”post” action=”Shop.aspx?prod=1”>
     Product: iPhone 5 <br/>
     Price: 449 <br/>
     Quantity: <input type=”text” name=”quantity” maxlength=”1”> <br/>
     <input type=”hidden” name=”price” value=”449”>
     <input type=”submit” value=”Buy”>
     </form>

   
   Để bypass việc kiểm tra này, chúng ta chỉ cần sử dụng Developer Tools, và tìm đến field cần bỏ giới hạn, thường thì sẽ search theo keyword "maxlength" và sửa thành giá trị mà bạn muốn.
   
   
2. Sử dụng Javascript để kiểm tra input
   Ngoài việc kiểm tra theo dạng hardcode trong response, một số ứng dụng sử dụng Javascript để thực hiện kiểm tra input từ người dùng, ví dụ kiểm tra xem email đã đúng format hay chưa, mật khẩu đủ mạnh hay chưa, thậm chí là giá của một sản phẩm, ...
   
   

   <form method=”post” action=”Shop.aspx?prod=2” onsubmit=”return
     validateForm(this)”>
     Product: Samsung Multiverse <br/>
     Price: 399 <br/>
   Quantity: <input type=”text” name=”quantity”> (Maximum quantity is 50)
     <br/>
     <input type=”submit” value=”Buy”>
     </form>
     <script>function validateForm(theForm)
     {
         var isInteger = /^\d+$/;
         var valid = isInteger.test(quantity) &&
             quantity > 0 && quantity <= 50;
         if (!valid)
             alert(’Please enter a valid quantity’);
         return valid;
   } </script>

   
   Để bypass cơ chế này, có 2 cách:
   • Nếu bạn hiểu về javascript (mình khuyên là các bạn nên tìm hiểu), thì có thể sửa code Javascript ngay trên trình duyệt để chấp nhận input của bạn.
   • Nếu chưa hiểu về Javascript, thì chúng ta cần nhập các trường này đúng giá trị mà nó mong muốn, ví dụ đúng format của email, đúng giá trị, sau đó chỉnh sửa request này trong khi nó được gửi đi (Burp Repeater/Intruder).
   
   
3. Bật mode "disabled" cho các trường không cần thay đổi.
   Một số trường hợp, chúng ta sẽ có một ô input, nhưng không cho phép nhập/sửa (ví dụ như email, username chẳng hạn). Các trường này thường thì các ứng dụng sẽ không cho người dùng thay đổi khi đã tạo tài khoản xong, nhưng mình cũng gặp không ít trường hợp ứng dụng cho phép thay đổi, dẫn đến việc mình có thể đổi user của mình thành Administrator, và chiếm được quyền kiểm soát ứng dụng.
   
   

     <form method=”post” action=”Shop.aspx?prod=5”>
     Product: Blackberry Rude <br/>
     Price: <input type=”text” disabled=”true” name=”price” value=”299”>
     <br/>
     Quantity: <input type=”text” name=”quantity”> (Maximum quantity is 50)
     <br/>
     <input type=”submit” value=”Buy”>
     </form>

   
   
   Việc thay đổi các element đã bị tắt cũng dễ dàng để thực hiện, tương tự việc chỉnh giá trị maxlength, thì chúng ta chỉ cần xóa đoạn "disabled=”true”" ở trường mà chúng ta cần thay đổi. Lúc này ứng dụng sẽ cho bạn sửa giá trị của trường này, tương tự những trường khác.

Đến đây thì chắc hẳn các bạn sẽ tự hỏi rằng, thay đổi các thông tin này có giá trị gì?

Dưới đây là một số ví dụ điển hình, và ảnh hưởng cao(do mình tìm thấy):

• Mua món hàng bất kì với giá 0 đ (thay đổi giá trị đơn hàng).
• Mua nhiều hơn số lượng quy định (thay đổi giá trị số lương sản phẩm).
• Đổi tên user thành admin và chiếm được quyền kiểm soát ứng dụng (cập nhật thông tin user thành admin).
• Xem được thông tin cá nhân, đặc biệt là số dư tài khoản, của 1 người dùng khác (thay đổi id của mình thành id của người dùng khác).
• Và còn rất nhiều ví dụ như thế nữa.

Mình xin kết thúc bài 4 tại đây. Cảm ơn bạn đã đọc hết bài.
Note: Tham khảo: The Web Application Hacker's Handbook

Nếu có câu hỏi nào thì các bạn cứ comment ở dưới nhé.



Thank you all.




Happy Hacking.