Task 11 [Day 6] Web Exploitation Be careful with what you wish on a Christmas night
Năm nay, ông già Noel muốn chuyển sang kỹ thuật số hoàn toàn và đã phát minh ra "Hãy ước một điều!" hệ thống. Đó là một ứng dụng web cực kỳ đơn giản cho phép mọi người chia sẻ mong muốn của họ với người khác một cách ẩn danh. Thật không may, ngay sau cuộc tấn công của hacker, đội bảo mật đã phát hiện ra rằng ai đó đã xâm nhập vào mục "Make a wish!". Hầu hết các mong muốn đã biến mất và trang web hiện đang chuyển hướng đến một trang web độc hại. Kẻ tấn công có thể đã giả vờ gửi một điều ước và đưa một yêu cầu độc hại lên máy chủ! Nhóm bảo mật đã khôi phục một máy chủ dự phòng cho bạn trên MACHINE_IP:5000. Mục tiêu của bạn là tìm ra cách mà kẻ tấn công có thể đã khai thác ứng dụng.
Bởi Swafox
XSS là gì?
Cross-site scripting (XSS) là một lỗ hổng web cho phép kẻ tấn công xâm phạm các tương tác mà người dùng có với một ứng dụng dễ bị tấn công. Các lỗ hổng tập lệnh trên nhiều trang web thường cho phép kẻ tấn công giả dạng người dùng nạn nhân và thực hiện bất kỳ hành động nào mà người dùng có thể thực hiện. Nếu người dùng nạn nhân có quyền truy cập đặc quyền trong ứng dụng (tức là quản trị viên), thì kẻ tấn công có thể có toàn quyền kiểm soát tất cả các chức năng và dữ liệu của ứng dụng. Ngay cả khi người dùng là người có đặc quyền thấp, XSS vẫn có thể cho phép kẻ tấn công lấy được nhiều thông tin nhạy cảm.
Tại sao nó hoạt động như vậy?
XSS bị khai thác khi một số nội dung độc hại đang được gửi đến trình duyệt web, thường ở dạng tải trọng JavaScript, nhưng cũng có thể bao gồm HTML, Flash hoặc bất kỳ loại mã nào khác mà trình duyệt có thể thực thi. Sự đa dạng của các cuộc tấn công dựa trên XSS là gần như vô hạn, nhưng tất cả chúng đều có hai loại chính xác: được lưu trữ và phản ánh.
Phân loại XSS
XSS được lưu trữ hoạt động khi một JavaScript độc hại nhất định được gửi và sau đó được lưu trữ trực tiếp trên trang web. Ví dụ: nhận xét về bài đăng trên blog, biệt hiệu của người dùng trong phòng trò chuyện hoặc chi tiết liên hệ về đơn đặt hàng của khách hàng. Nói cách khác, trong bất kỳ nội dung nào tồn tại liên tục trên trang web và nạn nhân có thể xem được.
<!-- Normal comment--> <p> Your comment goes here </p> <!--Malicious comment--> <p> <script> evilcode() </script> </p>Giả sử chúng ta có một trang web với các nhận xét (Đoạn mã ở trên). Một bình luận bình thường được đặt dưới thẻ <p> </p> và hiển thị trên trang web. Người dùng độc hại có thể đặt các thẻ <script> </script> trong trường đó để thực thi hàm evilcode () mỗi khi người dùng nhìn thấy nhận xét này.
XSS được lưu trữ mang lại cho kẻ tấn công một lợi thế khi 'tiêm' JavaScript độc hại vào phía sau hình ảnh. Bằng cách sử dụng thuộc tính <img>, có thể thực thi mã JS tùy chỉnh khi hình ảnh được xem hoặc nhấp vào. Ví dụ:
<img src='LINK' onmouseover="alert('xss')">Trong trường hợp này, kẻ tấn công nhúng một hình ảnh sẽ thực thi alert ('xss') nếu chuột của người dùng đi qua nó.
Giả sử chúng tôi có một ứng dụng web cho phép người dùng đăng nhận xét của họ dưới bài đăng.
Kẻ tấn công có thể khai thác điều này bằng cách đặt trọng tải XSS thay vì nhận xét của họ và buộc mọi người thực thi mã javascript tùy chỉnh.
Đây là những gì sẽ xảy ra nếu chúng ta sử dụng mã độc trong thẻ <img> ở trên:
Một bức ảnh độc hại thực thi alert('xss') sau khi được xem. Đây là ví dụ phổ biến nhất về XSS được lưu trữ.
Reflected là một loại XSS khác được thực hiện trực tiếp trong yêu cầu HTTP và yêu cầu kẻ tấn công thực hiện thêm một chút công việc. Ví dụ về điều này có thể là javascript độc hại trong liên kết hoặc trường tìm kiếm. Mã không được lưu trữ trực tiếp trên máy chủ, có nghĩa là người dùng mục tiêu phải tự thỏa hiệp bằng cách nhấp vào liên kết.
Dưới đây là một ví dụ nhanh về một URL có bao gồm javascript độc hại:
<https://somewebsite.com/titlepage?id=> <script> evilcode() </script>Bất kỳ người dùng nào nhấp vào liên kết sẽ thực thi hàm evilcode(), cuối cùng sẽ bị tấn công XSS.
Giả sử một trang web đang sử dụng từ khóa chuỗi truy vấn trong URL của nó 10.10.100.27/reflected?keyword=hello giống như:
Một truy vấn tìm kiếm được đặt sau tham số từ khóa này. XSS có thể được khai thác bằng cách đặt một trọng tải thay vì truy vấn tìm kiếm.
Url bắt đầu bằng 10.10.100.27/reflected?keyword=. khi thêm văn bản vào từ khóa, chúng tôi có thể thực hiện XSS được phản ánh như 10.10.100.27/reflected?keyword=<script>alert(1)</script> dẫn đến một hộp cảnh báo có 1 trên màn hình của chúng ta.
Chơi lô tô! XSS đã được khai thác thành công!
Làm thế nào để phát hiện XSS?
Cả hai lỗ hổng XSS được phản ánh và lưu trữ đều có thể được phát hiện theo cách tương tự: thông qua việc sử dụng các thẻ HTML, chẳng hạn như <h1> </h1>, <b> </b> hoặc các thẻ khác. Ý tưởng là thử nhập văn bản bằng các thẻ đó và xem liệu điều đó có tạo ra bất kỳ sự khác biệt nào không. Bất kỳ thay đổi nào về kích thước hoặc màu sắc văn bản ngay lập tức chỉ ra lỗ hổng XSS.
Nhưng đôi khi, việc tìm chúng theo cách thủ công có thể là một thách thức và tất nhiên, chúng ta không thể quên lỗi cơ bản của con người. Thật hạnh phúc, có một giải pháp cho điều đó! OWASP ZAP là một trình quét bảo mật ứng dụng web mã nguồn mở. Nó có thể tự động phát hiện các lỗ hổng trên web.
Bạn có thể khởi chạy ZAP bằng cách đi tới 'Applications -> Web -> Owasp Zap' trên hộp tấn công:
Bạn sẽ thấy một giao diện khá đơn giản khi khởi chạy.
Ở bên phải, bạn có thể thấy một nút có tiêu đề 'Quét tự động'. Nhấp vào nó và nó sẽ đưa bạn đến trang cấu hình tấn công.
Bây giờ, chỉ cần đặt URL mục tiêu vào trường 'URL để tấn công' và nhấn 'Tấn công'!
Sau một thời gian, tất cả các lỗ hổng sẽ được hiển thị trong tab 'Cảnh báo':
Phần thưởng: Giảm thiểu XSS
Quy tắc rất đơn giản: tất cả đầu vào của người dùng phải được làm sạch ở cả phía máy khách và phía máy chủ để các ký tự độc hại tiềm ẩn bị loại bỏ. Có các thư viện để trợ giúp việc này trên mọi nền tảng.
Các nhà phát triển thông minh phải luôn triển khai bộ lọc cho bất kỳ trường nhập văn bản nào và tuân theo một bộ quy tắc nghiêm ngặt về xử lý dữ liệu đã nhập. Để biết thêm thông tin về điều này, hãy xem hướng dẫn của OWASP:
Thử Thách
- Vui lòng cho thêm thời gian để máy ảo này triển khai (hơn 5 phút thông thường) nếu bạn không phải là người đăng ký.
Tài nguyên
Check out this awesome guide about XSS: swisskyrepo/PayloadsAllTheThings
Common payload list for you to try out: payloadbox/xss-payload-list
For more OWASP Zap guides, check out the following room: Learn OWASP Zap
Triển khai AttackBox của bạn (nút "Bắt đầu AttackBox" màu xanh lam) và máy tác vụ (nút màu xanh lá cây trên tác vụ này) nếu bạn chưa triển khai. Sau khi cả hai đã được triển khai, hãy mở Firefox trên AttackBox và sao chép / dán IP của máy (http: // MACHINE_IP: 5000) vào thanh tìm kiếm của trình duyệt (máy chủ web đang chạy trên cổng 5000, vì vậy hãy đảm bảo điều này được bao gồm trong các yêu cầu web của bạn ).
Truy cập website
What vulnerability type was used to exploit the application?
What query string can be abused to craft a reflected XSS?
Launch the OWASP ZAP Application
Run a ZAP (zaproxy) automated scan on the target. How many XSS alerts are in the scan?
Chạy ZAP mục alert sẽ thấy số lượng cảnh báo XSS
Explore the XSS alerts that ZAP has identified, are you able to make an alert appear on the "Make a wish" website?
0 Comments