3. Cấu trúc luận văn
2.6.1. Thực thi nội tuyến (inline)
Thực thi nội tuyến (inline execution) có nghĩa là nhúng các payload vào những form hay các thẻ html ngay trong quá trình thực hiện
Hình 2.12 : Thực hiện kiểu nội tuyến ( inline execution)
Nếu số lượng payload nhiều, quá trình sẽ được lặp đi lặp lại như hình 2.12.Các form sẽ được lưu vào bộ nhớ đệm để có thể sử dụng lại cho các lần tiếp theo.
Bằng cách nghiên cứu phương pháp mà iStar triển khai thực hiện nội tuyến trong phương pháp tiếp cận mô phỏng công việc của nó, vấn đề khác có thể được tìm thấy. Quan sát hình 2.13 mô tả quá trình thâm nhập inline. Ở bên trái, các lệnh Selenium được liệt kê. Các thâm nhập được hoạch định và thực hiện ngay trước khi lệnh thứ ba (type "Hello World!") là đạt. Sau đó, nhóm lệnh thực thi sau khi thâm nhập đã được thực hiện. Trong
trường hợp của một lỗ hổng XSS bậc hai để sử dụng các hoạt động UPDATE, trước đây trong các mẫu tiêm được ghi đè và lỗ hổng không thể được tìm thấy.
Hình 2.13. Thực thi Inline trong iStar 2.6.2. Thực thi hoàn chỉnh
Để thực hiện chiến lược hoàn chỉnh, cấu trúc dữ liệu của iStar cần được thay đổi.
Khi nó thoát ra, sự thay đổi này tạo ra một cơ sở vững chắc để phát hiện các cuộc tấn công phía máy chủ như SQL injection. Cấu trúc mới của iStar với một chiến lược thực hiện hoàn chỉnh được thể hiện trong hình 2.13. Sự thay đổi chính là thâm nhập không được thực hiện ngay lập tức, mà bị trì hoãn. Đầu tiên thực hiện chạy các trường hợp sử dụng toàn bộ script nhúng không chuẩn (non-destructive). Hiểu một cách đơn giản, thực thi tất cả payload vào một form, một tham số khi được tìm thấy.Khi nào thực hiện xong, mới chuyển sang các tham số khác. Phương pháp này có nhược điểm: chậm.
Trong hình 2.13, các lệnh Selenium trong trường hợp người sử dụng duy nhất được liệt kê ở bên trái. Toàn bộ kiểm tra an toàn cho một ứng dụng Web được gọi là MissionRun.Trong MissionRun, các lệnh Selenium được thực hiện và thâm nhập được lên kế hoạch.Mỗi MissionRun bao gồm một Run cơ sở (BasRun) và một hoặc nhiều Run thâm nhập (PenetrationRuns), cả hai loại bao gồm một hoặc nhiều vị trí MissionPositions (MPs) .Trong bức ảnh, hai PenetrationRun) được hiển thị với hai vectơ tấn công khác nhau (được gọi là Actions Penetration) . Các tương ứng với các lệnh Selenium theo trình duyệt hoặc các sự kiện tương ứng.
Khi một MissionRun mới được khởi động, đầu tiên toàn bộ các trường hợp sử dụng được thực thi bằng cách tiêm các vectơ tấn công phá hủy. Do đó bao gồm đầy đủ các giá trị mặc định cho các trường đầu vào. Ví dụ như “Hello Word” ở MissionPositions 3. Bất cứ khi nào một dạng hay bất kỳ thông số sửa đổi khác là gặp phải, một PenetrationRun ( Run thâm nhập) mới được lên kế hoạch cho mỗi vector tấn công có sẵn.
Trong trường hợp này co 2 vectơ tấn công và vì vậy hai PenetrationRun được lên kế hoạch ở MisstionPositions 4. Quá trình thực thi không phá hoại được lưu trữ như BaseRun và phục vụ như tài liệu tham khảo cho sau này. Sau đó, việc thực thi của PenetrationRun bắt đầu. Vectơ tấn công <script>alert (1) </script> được nhúng vào trường đầu vào của PenetrationRun để thực hiện kế hoạch. Sau khi nhúng thành công PenetrationRun thứ nhất, Penetration thứ hai sẽ thực hiện.
Hình 2.14. Thực thi Complete trong iStar
Một trong những thế mạnh của iStar là những thay đổi nhỏ trong ứng dụng Web tự động được xem xét. Ví dụ, khi một trường đầu vào mới được thực hiện dưới các hình thức, nó được tự động thâm nhập tốt (miễn là lĩnh vực này đầu vào không yêu cầu dữ liệu đặc biệt - trong trường hợp này, có dây trường hợp sử dụng phải được điều chỉnh).
2.6.3. Hạn chế của máy quét lỗ hổng Web hiện nay
Bộ phận thu thập dữ liệu của một máy quét lỗ hổng bảo mật Web là thành phần hạn chế nhất. Các rào cản về dữ liệu hợp lý(ví dụ như mã đã được mã hóa) đã được đề cập trong phần 2.4. Khi không có một cơ chế thích hợp, một ứng dụng web không thể thu thập toàn bộ thông tin cần thiết. Đây là rào cản trong quá trình thu thập thông tin. Ngày càng nhiều ứng dụng Web sử dụng trang web động bằng JavaScript và AJAX. Hầu hết các trình thu thập dữ liệu trên các phản hồi của HTTP. Nội dung của một phản hồi HTTP được quét các thẻ <a>, form, frame, những thứ có thể được đặt trong một hàng đợi để thu
thập thêm thông tin. Rõ ràng, như vậy một số dữ liệu JavaScript bị bỏ qua bởi các trình thu thập thông tin. Vì lý do này, một số các trình thu thập thông tin của máy quét lỗ hổng Web có một công cụ phân tích cú pháp JavarScrip cơ bản, hoạt động tốt cho các trường hợp đơn giản.
Tuy nhiên, với sự tiến bộ của các thư viện JavaScript như jQuery5, sự phức tạp của JavaScript trong các ứng dụng web tăng đáng kể, nó làm cho các công cụ phân tích, về cơ bản bị lỗi (chúng ta sẽ thấy điều này trong việc đánh giá trong chương 3). Không chỉ thẻ <a> phục vụ (serve) được dùng để liên kết, mà còn tất cả các thành phần HTML khác có thể được sử dụng cho tương tác người dùng.Ví dụ, một thẻ <div> đơn giản có thể được sử dụng để kích hoạt yêu cầu AJAX hoặc tải các trang web khác. Cách duy nhất để giữ được trạng thái là hoàn trả toàn bộ trang web. Tuy nhiên, điều này sẽ làm ảnh hưởng đến hiệu suất.
Thu thập dữ liệu một ứng dụng Web hiện đại là sự kết hợp giữa đầy đủ và hiệu quả. Mesbah et al. trình bày một cách thu thập thông tin của các ứng dụng web sử dụng AJAX trong một tài liệu được công bố [MBD08]. Công cụ Crawljax của họ sử dụng một trình duyệt Web bình thường, chẳng hạn như Mozilla Firefox 6, để phân tích và làm cho các trang Web, bao gồm cả mã JavaScript phức tạp. Crawljax quan sát cây DOM cho sự thay đổi trạng thái và phát hiện các yêu cầu AJAX, nhưng nó rất chậm. Trong khi Crawljax cũng có giới hạn của nó - các trạng thái cần thu thập có thể phát triển theo cấp số nhân, làm giảm tối đa khả năng thu thập theo chiều sâu của các ứng dụng Web - nó cho thấy một cách tiếp cận thú vị để thu thập nội dung động.
Những hạn chế của các trình thu thập thông tin biện minh cho việc thực thi các quy trình làm việc thông qua một ứng dụng Web. Hầu hết các ứng dụng web có ít nhất một chức năng, một quy trình làm việc là cần thiết - đăng nhập người dùng. Vì vậy, máy quét lỗ hổng Web tự động có khả năng ghi lại một chuỗi đăng nhập mà các công việc như sau. Người sử dụng vào các ứng dụng web và mọi yêu cầu của HTTP về tất cả các thông số được ghi lại cho lần sử dụng sau. Sau đó, tên người dùng và mật khẩu có thể được cung cấp và liên kết như “đăng xuất " (logout) có thể được đặt trong một danh sách các liên kết bị loại trừ, sẽ không được theo dõi bởi các module thu thập thông tin, để trạng thái ứng dụng không phải lập lại. Tính năng này cũng có thể được sử dụng để chỉ đạo các thành phần thu thập thông tin hướng tới vùng khác của các ứng dụng Web.
Bằng cách này, ghi lại một trình tự đăng nhập đáp ứng hai mục đích: (i) Để chỉ định các trình thu thập các khu vực nó không thể truy cập tự động, bởi vì một trình tự nhất định của các bước được yêu cầu, và (ii) để thiết lập các ứng dụng vào các trạng thái “ đăng nhập " (login). Chúng ta sẽ kiểm tra một máy ghi trình tự điển hình trong mục 2.6.4.
Tuy nhiên, mục đích chính của việc ghi trình tự là để nâng cao các thành phần thu thập thông tin. Nó không được thiết kế để thực hiện các cuộc tấn công bằng nhiều cách mà đưa chúng ta đến một giới hạn khác của máy quyét lỗ hổng Web hiện tại. Trong máy quét hiện nay, các cuộc tấn công đáp ứng yêu cầu. Các mẫu được tiêm trong một yêu cầu và đáp ứng được phân tích ngay lập tức. Lý do chính của chiến lược này thực hiện tương đối đơn giản là để đạt được một hiệu suất tốt bằng cách thực hiện thâm nhập càng nhanh càng tốt. Thông thường, nhiều vectơ tấn công được nhúng cùng một lúc, trong khi trình tự ghi được sử dụng để quan sát trạng thái của ứng dụng.
Trình tự ghi tăng cường tỷ lệ phát hiện của một WVS bằng cách cải thiện bộ phận thu thập thông tin. Điều này có thể hữu ích trong việc tìm các lỗ hổng XSS khi các sự kiện JavaScript được kích hoạt có thể bỏ qua trình thu thập dữ liệu truyền thống. Trong khi trình thu thập dữ liệu truyền thống có thể bỏ qua các lỗ hổng XSS thì một WVS (Web Vulnerability Scanner - Máy quét lỗ hổng Web) có thể tìm thấy các lỗ hổng XSS (khi các sự kiện JavaScript được kích hoạt) nhờ vào việc cải thiện bộ phận thu thập thông tin. Nhưng bởi vì hầu hết các máy quét lỗ hổng Web hiện tại có một sự tách biệt rõ ràng giữa các thành phần thu thập thông tin và module tấn công, cho nên các lỗ hổng XSS bậc hai không được phát hiện một cách hiệu quả. Ngược lại, các phương pháp tiếp cận dựa trên công việc của iStar sử dụng trình tự ghi để tăng cường thực hiện các cuộc tấn công. Trong phần 3.6, chúng ta sẽ thấy máy quét công việc hiện tại như thế nào và lý do tại sao họ không phát hiện các lỗ hổng XSS bậc hai. Trong chương 5, chúng ta sẽ tìm hiểu làm thế nào một cách tiếp cận dựa trên công việc tăng cường thực hiện tấn công.
2.6.4. Một máy ghi trình tự điển hình.
Máy ghi trình tự đăng nhập là để đưa các ứng dụng Web vào trạng thái "đăng nhập". Vì vậy, một máy ghi trình tự điển hình có ba thành phần:
Trình tự hành động: Máy WVS cho thấy một cửa sổ trình duyệt mà trong đó pentester thực hiện đăng nhập. Tất cả các yêu cầu HTTP bao gồm các thông số đều được lưu cho lần đăng nhập sau đó.
Liên kết hạn chế: Một trình thu thập thông tin vô tình truy cập nút “ logout " sẽ thay đổi trạng thái của ứng dụng Web. Để ngăn chặn điều này, một liên kết nào có thể được loại trừ từ trình thu thập thông tin.
Máy phát hiện trạng thái: Mục đích của thành phần thứ ba là để phát hiện xem ứng dụng Web có ở trạng thái đăng nhập hay không. Điều này có thể được xác định qua các phần tử HTML, ví dụ như một liên kết. Sự hiện diện của một liên kết đăng xuất thường là một dấu hiệu chứng tỏ các ứng dụng Web trong trạng thái đăng nhập.Trình tự hành động là tập hợp một hay nhiều các yêu cầu HTTP được tái hiện lại. Điều này có nghĩa rằng, một số giá trị tham số được tái hiện lại. Trong hầu hết các ứng dụng web, điều này hoạt động khá tốt. Tuy nhiên, cơ chế bảo mật như thẻ phòng ngừa CSRF có thể gây ra rắc rối nghiêm trọng, nếu các yêu cầu HTTP chỉ đơn giản là trả lời được tái hiện lại. Trong trường hợp này, một HTTP lưu trữ có thể không bao giờ được sử dụng cho đăng nhập. Nếu các mã thông báo không được làm mới và lấy lại từ các ứng dụng web trước khi đăng nhập.
2.6.5. Phát hiện các lỗ hổng bảo mật trên lớp mạng
Phân tích mã, pentesting thủ công và tự động được thực hiện trên lớp ứng dụng của mô hình OSI (lớp 5-7). Các ứng dụng web có thể dễ bị tấn công, nếu các thành phần cơ bản là lỗ hổng nào đó (ví dụ như: các máy chủ Web, TCP / IP-stack của hệ điều hành, các vấn đề an ninh chính, vv...). Trong năm 2008, các nhà phát triển của máy chủ Web Apache Tomcat đã phát hiện một lỗi trong đường dẫn mã hóa UTF-8 của nhiều Máy ảo Java (JVM) 8. Các lỗi tạo cơ hội cho các thư mục thư mục thực hiện tấn công. Ví dụ như các thư được bảo vệ có thể bị truy cập khi. Khi mã UTF-8 không chuẩn bị bỏ qua giống như tham số đến máy chủ.
Để phát hiện các lỗ hổng trong các máy chủ Web, trong việc triển khai giao thức TCP, trong hệ điều hành, hoặc trong các mô-đun hạt nhân, có thể sử dụng kỹ thuật fuzzing. Fuzzing cung cấp dữ liệu không hợp lệ, cho trước hoặc ngẫu nhiên các yếu tố đầu vào của một chương trình. Nếu chương trình không thành công lỗi đã được xác nhận.
2.6.6 Sự phát hiện tự động các lỗ hổng bảo mật XSS loại 2 (thế hệ thứ 2)
Phần này giải thích cách Web Vulnerability Scanners tiếp cận các lỗ hổng XSS bậc hai – các lỗ hổng mà trong đó các vector tấn công không được trả về ngay lập tức. Chương 2 giới thiệu bản chất của lỗ hổng XSS bậc hai và cho thấy hai khía cạnh quan trọng phải được xem xét khi chúng ta muốn tự động phát hiện ra chúng. Khía cạnh đầu
tiên là các rào cản logic chẳng hạn như dữ liệu hoặc một chuỗi các bước riêng biệt. Khía cạnh khác là cách làm thế nào dữ liệu được xử lý. Đó có thể là một sự thay đổi dữ liệu (UPDATE) hoặc chèn dữ liệu mới (INSERT).
Chúng ta đã thấy rằng các trình thu thập thông tin là thành phần cơ bản nhất trong Máy quét lỗ hổng bảo mật Web. Chiến lược cơ bản của một WVS là thu thập các trang trong bước đầu tiên và tiêm mẫu trong bước thứ hai (các bước có thể được pha trộn nhưng nguyên tắc là như nhau - một module thu thập dữ liệu các trang, các mô-đun khác tấn công chúng).
Hầu hết các Máy quét lỗ hổng bảo mật Web có một tập hợp các vectơ tấn công khác nhau để tiêm và quét mã tiêm đưa ra thông số xác định các cuộc tấn công có thể. Giả sử rằng Web Vulnerability Scanner V tiêm ba mẫu khác nhau, hai mẫu XSS phá hoại, B và C, và một mẫu không phá hủy A, mẫu này phục vụ như là dữ liệu hợp lệ cho ứng dụng Web. Hình 2.6 liệt kê tất cả ba mẫu.
Mục đích của mẫu tiêm A là để giúp trình thu thập thông tin tiến tới bước tiếp theo. Nếu một mô hình phá hoại được tiêm ngay trong quá trình thu thập thông tin, các trang kết quả có thể là một thông báo lỗi, làm hạn chế độ sâu mà trình thu thập thông tin có thể tiếp cận.
Hình 2.15. Các mẫu tiêm độc hại
Ví dụ (hình ảnh chú giải) không có rào cản quy trình công việc và chèn dữ liệu vào cơ sở dữ liệu. Bước 1 máy quét V khởi động trình thu thập thông tin. Trình thu thập thông tin bắt gặp một biểu mẫu, đó là lựa chọn duy nhất để xử lý khi không có các liên kết khác trên trang này, đặt bước 1 trong danh sách của các trang tìm thấy và tiếp tục bước 2. Nó tìm thấy liên kết duy nhất có nhãn “ continue... ", đặt bước 2 trong danh sách của các trang tìm thấy và liên kết đi kèm. Bước 3 không có thêm bất kỳ liên kết nào nữa , quá trình tìm danh sách các trang trên trang web kết thúc.
Sau đó, máy quét V khởi động mô-đun tấn công. Duyệt qua danh sách các trang được tìm thấy, tìm bước 1 với một biểu mẫu và mẫu tiêm B. Các mô-đun tấn công lưu các phản hồi cho các lần phân tích sau này và tiêm mẫu tiêm C trong các biểu mẫu ở bước 1. Sau đó, không có bước nào chứa một tham số thay đổi và do đó các mô-đun tấn
công được thực hiện. Máy phân tích kiểm tra tất cả các phản hồi lưu các mẫu tiêm phá hoại. Trong bước 3, máy quét tìm thấy hai mẫu tiêm (B và C) và báo cáo tìm thấy lỗ hổng. Trong thực tế, một số Máy quét lỗ hổng bảo mật Web không chỉ quét các phản hồi được lưu trữ, mà còn tải về tất cả các trang danh sách trang thu thập để kiểm tra lại chúng.
Ví dụ 2 (danh sách thư gửi): không có một rào cản tiến trình công việc nhưng sử