3. Cấu trúc luận văn
2.6.6Sự 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ử dụng thao tác UPDATE. Bước 1 máy quét V khởi động trình thu thập thông tin và tìm một biểu mẫu. Nó tiêm mẫu tiêm A như một địa chỉ email. Trình thu thập thông tin chuyển sang bước 2 và gửi biểu mẫu. Tiếp tục, bước 3 theo liên kết liên kết “ Continue... ".
Khi tất cả ba trang được thu thập thông tin, các mô-đun tấn công được bắt đầu. Trong bước 1 nó tìm thấy một biểu mẫu trong đó các thông số đầu vào có thể bị tiêm. Các mô-đun tấn công tiêm mẫu B vào trường email, gửi biểu mẫu và lưu trữ các phản hồi mà không chứa các mẫu tiêm. Làm như vậy, mẫu tiêm A ghi đè lên địa chỉ email hiện có. Sau đó, giống như vậy, mẫu tiêm C ghi đè lên mẫu tiêm B như địa chỉ email. Các phản hồi trả về không chứa bất kỳ mẫu tiêm nào. Bằng cách quét bước 3, máy dò tìm chỉ tìm thấy mẫu tiêm C vì đây là mẫu tiêm mới nhất được tiêm.
Vấn đề trong kịch bản này là việc phát hiện lỗ hổng này phụ thuộc vào thứ tự của các mẫu tiêm. Nếu vì một lý do nào đó, các mô-đun tấn công tiêm (inject) một mô hình không độc hại như A ,cuối cùng lỗ hổng không bao giờ phát hiện. Trong thực tế, một số Web Vulnerability Scanners "kết thúc" cuộc kiểm tra với kết quả là không phát hiện ra lỗ hổng.
Chương 3
PHƯƠNG PHÁP PHÁT HIỆN VÀ PHÒNG TRÁNH XSS WORM. 3.1 Khái niệm XSS Worm
- XSS worm là một sâu XSS, một dạng virus, một loại mã độc hại thường được viết bằng Javascript, tự động nhân bản, được lan truyền qua những trang web bởi người dùng. Nó thu thập các thông tin người dùng ( mật khẩu, cookie,… ) và gửi lại cho kẻ tấn công.Tác hại là không thể lường trước được.
Phần 3.2 nhóm nghiên cứu sẽ mô tả cách lan truyền một sâu. Phần 3.3 nhóm cung cấp cách nhìn tổng quan về cách phát hiện các hành vi lan truyền của một sâu XSS.Phần 3.4 báo cáo sẽ mô tả chi tiết kỹ thuật phát hiện sâu.
3.2 Phương pháp lan truyền của sâu
- Một worm hoặc một sâu để lây lan được nhanh cần có một cách thức lan truyền mới.Một sâu có thể được lan truyền nhanh thông qua phương thức gửi email hoặc chia sẻ trên mạng xã hội bằng cách sử dụng các đường liên kết do người sử dụng đưa lên mới.Nếu trình duyệt người dùng bị nhiễm sâu, nó sẽ tự động gửi các đường liên kết chứa mã độc hại cho các người dùng khác đang cùng sử dụng chung tiện ích nào đó.Bằng phương pháp lây lan như vậy, một sâu có thể lây lan rất nhanh mà người dùng không hay biết.
- DOM là chữ viết tắt của từ Document Object Model ("Mô hình Đối tượng Tài liệu"), là một giao diện lập trình ứng dụng (API). Thường thường DOM, có dạng một cây cấu trúc dữ liệu, được dùng để truy xuất các tài liệu dạng HTML và XML. Mô hình DOM độc lập với hệ điều hành và dựa theo kỹ thuật lập trình hướng đối tượng để mô tả tài liệu.
Ban đầu, chưa có chuẩn thống nhất nên các thành phần trong một tài liệu HTML mô tả bằng các phiên bản khác nhau của DOM được hiển thị bởi các chương trình duyệt web thông qua JavaScript. Điều này buộc World Wide Web Consortium (W3C) phải đưa ra một loạt các mô tả kĩ thuật về tiêu chuẩn cho DOM để thống nhất mô hình này.
Mặc dù một tài liệu hay văn bản có cấu trúc chặt chẽ (well-structured document) luôn luôn có thể được mô hình hóa bằng một cấu trúc dạng cây, DOM không có giới hạn về cấu trúc dữ liệu của một tài liệu.
Hầu hết các bộ phân tích XML (XML parsers) (ví dụ: Xerces) và bộ xử lí XSL (ví dụ: Xalan) đã được phát triển để sử dụng cấu trúc cây này. Những hiện thực như vậy đòi hỏi toàn bộ nội dụng của một văn bản phải được phân tích và lưu trong bộ nhớ. Vì thế,
DOM được sử dụng tốt nhất trong các ứng dụng mà trong đó các thành phần của tài liệu có thể được truy xuất và thao tác một cách ngẫu nhiên. Với các ứng dụng dựa trên XML, bao gồm yêu cầu đọc/ghi có chọn lọc cho mỗi lần phân tích (one-time selective read/write per parse), DOM cho thấy được sự tối ưu về mặt bộ nhớ. Trong các trường hợp đó thì giao diện lập trình ứng dụng SAX trở nên rất tiện lợi về cả mặt tốc độ và bộ nhớ.Mỗi nút trong cây DOM đại diện cho một đối tượng hoặc một tài liệu tương ứng.Với DOM, chương trình và các script có thể tự động truy cập hoặc cập nhật nội dung, cấu trúc, và định dạng tài liệu một cách đơn giản hơn.
- Trên thực tế việc xây dựng một trang web hoàn hảo, an toàn, không có lỗi, là một công việc vô cùng khó khăn, do người lập trình không lường trước được các tình huống không an toàn có thể xảy ra, cũng như do sự bất cẩn của người dùng.Sâu XSS thường được lưu trên các máy chủ của các ứng dụng web dễ bị tấn công.Quy trình lây lan điển hình của một sâu XSS có thể mô tả như sau :
- Một người dùng A nào đó, bị lôi kéo truy cập vào một trang web độc hại, trang web này là một ứng dụng web đã dính lỗi XSS.Ví dụ, trang web đó có thể là hồ sơ, thông tin cá nhân người bạn của A.
- Tin tặc sẽ nhúng một sâu XSS dưới dạng một payload.Khi A truy cập, trình duyệt tự động tải về payload (do tưởng nhầm là Javascript Engine thông thường).Trong quá trình này, nó tự sao chép bản thân và tự động gửi đi dưới dạng HTTP request nào đó.
- HTTP request này được gửi đi đến máy chủ web với danh nghĩa của A.Do HTTP request này đã được xác thực cho nên nó có thể thay đổi nội dung hồ sơ của A.Khi người dùng khác ( bạn của A ) truy cập vào hồ sơ của A, người dùng đó, tài khoản đó cũng bị lây nhiễm.
Một đoạn mã ví dụ về XSS worm viết bằng Javascript :
Hình 3.1 : Đoạn mã xss worm viết bằng Javascript 3.3 Phương pháp phát hiện XSS worm
Việc phát hiện lỗ hổng XSS đã được nghiên cứu từ lâu, đã có nhiều bài báo, tác giả nghiên cứu về vấn đề này.Tuy nhiên các bài báo nghiên cứu về việc phát hiện và ngăn chặn XSS worm còn chưa nhiều.Lý do là chưa có nhiều người nghiên cứu tường tận về Xss worm.Một lý do nữa là sâu này rất khó phát hiện vì trình duyệt nhầm tưởng nó là các đoạn mã Javascript thông thường.
Spectator là giải pháp phát hiện worm đầu tiên. Nó hoạt động bằng cách giám sát đường truyền giữa trình duyệt và một ứng dụng web cụ thể. Tuy nhiên nó chỉ có thể phát hiện JavaScript worm mà đã lây lan đủ nhiều và không thể chặn một XSS worm trong giai đoạn ban đầu của nó. Ngoài ra, Spectator yêu cầu sự hợp tác của máy chủ và nó không dễ để triển khai. (adsbygoogle = window.adsbygoogle || []).push({});
Để phát hiện XSS Worm lây lan trong quá trình triển khai, nhóm nghiên cứu tập trung vào quá trình sâu XSS tự sao chép.Việc sao chép này diễn ra khi XSS worm muốn nhân bản, và gửi đi một yêu cầu HTTP. Bằng cách nào đó mà ta so sánh được sự tương tự mà HTTP gửi đi so với yêu cầu mà DOM được nạp thì ta có thể phát hiện ra được sự lây lan của Worm.
Ta có thể xây dựng các chương trình plugin cho các trình duyệt nhằm hỗ trợ việc kiểm soát dữ liệu đầu vào, các HTTP request gửi đến và gửi đi. Từ đó phân tích và mã hóa chúng tránh sự tấn công của tin tặc.Cụ thể, với giải pháp nhằm kiểm soát các HTTP request, các plugin phải bắt được các gói tin gửi đi và gửi về trước khi gói tin được trình duyệt và server xử lý.Mô hình cụ thể đề xuất như sau :
phát tán của XSS worm.
Sở dĩ nhóm nghiên cứu chọn trình duyệt người dùng (client side) làm mục tiêu nghiên cứu bởi vì XSS worm chỉ lan truyền được nhờ trình duyệt của người sử dụng, mặt khác, việc triển khai phát hiện XSS worm được tiến hành cài đặt đơn giản hơn là cài đặt trên phía máy chủ.Các bước tiến hành phát hiện sâu XSS lây lan như sau :
1. Vì không thể biết được một yêu cầu http được gửi bởi 1 xâu XSS hay bởi một người dùng hợp lệ, nên ứng dụng này sẽ chặn tất cả yêu cầu http gửi đi ( có thể chứa các payload XSS) . Trích xuất các tham số URI từ mỗi yêu cầu http bị chặn và từ các URI này, bóc tách ra các liên kết có thể trỏ đến javascript độc hại.
2. Nếu tồn tại các liên kết này, chương trình tự động gửi các AJAX request đến các máy chủ từ xa và chờ yêu cầu trả về. Chương trình sẽ chờ đến khi nhận được toàn bộ các yêu cầu trả về ( AJAX response) hoặc một tín hiệu timeout từ máy chủ từ xa.Chúng ta gọi tập các tham số giá trị đã nhận là tập D.
3.Mặt khác chương trình vẫn gửi các yêu cầu http ban đầu đến máy chủ và nhận các gói tin HTTP trả về.Bóc tách các gói tin trả về thành các DOM script ( các script lấy từ DOM tree) và các tập tin Javascript bên ngoài.Chúng ta gọi tập các DOM script và các file javascript là tập P.
4. Sử dụng một bộ giải mã tự động cả 2 tập D, P và lặp lại quá trình này đến khi nào không tìm thấy đoạn văn bản mã hóa nào nữa thì dừng lại.
5. Cuối cùng sử dụng máy dò tương tự để so sánh các đoạn giải mã từ 2 tập D, P và chỉ ra tiềm năng lan truyền của một XSS Worm. Nếu phát hiện các đoạn mã tương tự, chương trình tự động chuyển hướng yêu cầu HTTP và cảnh báo người dùng.
* Mô tả chi tiết cách tiếp cận :
Trong phần này, nhóm nghiên cứu mô tả chi tiết cách phát hiện XSS worm dựa trên thuật toán đã nêu, và nói rõ hơn bằng cách nào có thể bóc tách các tham số đầu ra và các các liên kết URI có trong yêu cầu HTTP, và chỉ ra thuật toán so sánh sự tương đồng các sâu tương tự.
- Lấy các giá trị tham số và liên kết URI từ yêu cầu HTTP
Đoạn payload của sâu XSS worm có thể được gửi đi dưới dạng một plain-text (văn bản) hay một liên kết URI trỏ tới một file bên ngoài, lưu trữ trên một máy chủ từ xa nào đó.Trong cả hai trường hợp này, một văn bản hay một liên kết URI cần được nhúng vào tham số nào đó của yêu cầu HTTP dùng để lan truyền sâu.
Vì vậy, bằng cách trích suất tham số HTTP và lấy nội dung file lưu trữ từ xa, ta có được một tập văn bản. Gọi tập đó là P.
Vì trình duyệt không thể xác định được một HTTP request gửi đi có phải là của người dùng hay của sâu XSS, cho nên chương trình sẽ chặn từng HTTP request một và xử lý chúng. Đầu tiên bóc tách các giá trị tham số, nếu có, của thuộc tính path trong URI gửi đi. Sau đó, ta sẽ kiểm tra xem phương thức HTTP gửi đi là phương thức gì. Nếu phương thức POST được sử dụng, ta sẽ lấy nội dung yêu cầu gửi đi, và bóc tách thêm những giá trị tham số từ nó.
Kẻ tấn công có thể lưu trữ XSS worm trên một máy chủ từ xa nào đó và thực hiện lây lan liên kết URI thay vì plain-text( văn bản), ta có thể bóc các liên kết URI từ HTTP request bằng việc sử dụng biểu thức chính quy trong Javascript. Sau đó gửi yêu cầu URI này đến server từ xa để lấy được nội dung file.
- DOM Script và các file ngoài của trang web
Để liệt kê ra những khu vực mà các script có thể tồn tại, chúng tôi nghiên cứu mã nguồn của một vài XSS worm trong XSS Sheet Cheat ( http://ha.ckers.org/xss.html) và một số tài liệu khác.Chúng tôi phân loại ra một số khu vực nơi mà các script có thể tồn tại như sau :
- Script elements: Một script có thể định nghĩa trong các thẻ script của DOM tree. - Event handlers: Tổ chức W3C quy định 18 event handlers nội tại.Ngoài ra còn có một số event handlers đặc biệt do các trình duyệt tự định nghĩa.
- HTML attributes: Kẻ tấn công khai thác thuộc tính chuẩn trong DOM element để tự động tải các file ngoài về trang web
- Các script đặc biệt trong các thuộc tính hay thẻ đặc biệt của trình duyệt : Một vài trình duyệt cho phép thực hiện các script trong các thẻ đặc biệt.