Lỗ hổng XSS và các biện pháp khắc phục (P2)

03/11/2015 20:48
Theo dõi ICTVietnam trên

Hiện tại, ứng dụng web đã trở thành một phần không thể thiếu trong cuộc sống của chúng ta. Nhưng các trang web này thường tồn tại nhiều lỗ hổng và dễ bị tấn công.

File API trong HTML5

Lỗ hổng này hiện đang được thực thi trong Webkit (mới nhất của Google Chrome) và có thể bị khai thác để chuyển đổi trình duyệt chrome Google vào một file server. File API trong HTML5 cho phép các JavaScript truy cập các file khi nó được lựa chọn bởi người sử dụng (tức là trước khi tải lên nó). Ngoài việc cung cấp kinh nghiệm để các file upload tốt hơn, nó cũng có thể được sử dụng một cách độc hại như ăn cắp các file của bạn trong tấn công XSS. Với cách thức thông minh bạn có thể ẩn inputtype=fíle điều khiển để người dùng không hề biết việc tải lên các tập tin. Trong trường hợp này, các tập tin được lựa chọn bởi người sử dụng trong hộp thoại 'Open File' là người duy nhất có thể được truy cập. Tuy nhiên, inputtype=directory file là một tính năng tuyệt vời cho phép người dùng tải lên nội dung của một thư mục được lựa chọn, do đó kẻ tấn công có thể được phép truy cập vào toàn bộ thư mục.

Bản đồ XSS

Google trong khi thu thập dữ liệu cho các Xem Google Street cũng đã thu thập dữ liệu của các mạng không dây trong vùng lân cận và địa chỉ vật lý (MAC) của các router, sau đó phối hợp ánh xạ chúng vào GPS. Ở đây, một XSS khai thác có thể được sử dụng để lập bản đồ vị trí của người dùng. Việc khai thác XSS có thể lấy địa chỉ vật lý (MAC) của router mục tiêu và sau đó phối hợp sử dụng Google Maps để xác định GPS. Một trang độc hại bạn đang truy cập có thể thực hiện một XSS để khai thác và phục hồi tọa độ GPS từ Google Maps. Các bộ định tuyến và trình duyệt web tự chúng không chứa bất kỳ dữ liệu vị trí địa lý/GPS. Nó hoạt động thông qua Router XSS mà có được địa chỉ MAC của router thông qua AJAX. Địa chỉ MAC sau đó được gửi đến kẻ tấn công và chuyển nó đến địa điểm dựa vào dịch vụ của Google, từ đó có thể biết được tọa độ gần đúng của người sử dụng.

NAT PINNING - IRC Over HTTP

Trong một cuộc tấn công XSS, một trang web buộc router của người dùng hoặc tường lửa gửi đến cổng bất kỳ số cổng của máy người dùng thông qua cơ chế dịch địa chỉ (NAT). Khi nạn nhân nhấp chuột vào một URL XSS có lỗ hổng có một hình thức ẩn kết nối với http://attacker.com:6667 (port IRC), người dùng submit form mà không biết. Một kết nối HTTP được tạo ra bởi kẻ tấn công tới máy chủ IRC (kết nối giả) chỉ đơn giản là lắng nghe. Router của nạn nhân nhìn thấy một "kết nối IRC" (mặc dù khách hàng của mình đang nói trong HTTP) và một nỗ lực tại một 'DCC Chat". Direct Client- to-Client (DCC) là một giao thức IRC nhỏ cho phép trao đổi các tập tin và thực hiện các cuộc trò chuyện không chuyển tiếp bằng cách cho phép các Peers kết nối với nhau bằng cách sử dụng một máy chủ IRC cho tín hiệu bắt tay. Chat DCC yêu cầu mở một cổng local trên máy trạm mà được kết nối ngược. Khi router ngăn chặn tất cả các kết nối từ bên trong, nó quyết định chuyển tiếp lưu lượng đến cổng Chat DCC ngược về máy của nạn nhân cho phép NAT traversal cho những kẻ tấn công để kết nối trở lại và trò chuyện với anh ta. Tuy nhiên, kẻ tấn công có chỉ định cổng; Ví dụ cổng 21 (FTP), các cổng router chuyển tiếp 21 trở lại hệ thống nội bộ của nạn nhân. Kẻ tấn công có một con đường rõ ràng để kết nối với các nạn nhân trên cổng 21 và khởi động một cuộc tấn công.

Các khai thác trên trình duyệt

Bất kỳ ai cũng có thể khai thác các ngăn xếp ứng dụng trình duyệt và thực hiện một mã shell hoặc mở một phiên Meterpreter bằng cách sử dụng lỗi bộ nhớ liên quan đến lỗ hổng XSS. Những lỗ hổng khác cũng có thể trả về phiên Meterpreter mà không tấn công các ứng dụng stack một cách trực tiếp. Ví dụ như java applet của ký tự có thể được sử dụng để download các mã độc và thực hiện một tập tin exe.

BIỆN PHÁP KHẮC PHỤC XSS

Hiện nay, các ứng dụng web đang được phổ biến rộng rãi để cung cấp các dịch vụ trực tuyến khác nhau. Nhưng đồng thời lỗ hổng ứng dụng đang được phát hiện và công bố với tốc độ đáng báo động. Trên thế giới, bảo mật web có thể dễ dàng bị xâm nhập. Do đó, bảo mật trở thành bắt buộc để bảo vệ người dùng trước các cuộc tấn công. Các biện pháp khác nhau có thể được áp dụng để tránh bị thành nạn nhân của XSS. Các cơ chế ngăn ngừa (XSS Cheat Sheet - OWASP, 2013) có thể được thực hiện ở phía máy chủ hoặc phía khách hàng.

Bảo vệ máy chủ

Để bảo vệ khỏi các lỗ hổng XSS, các biện pháp sau đây có thể được thực hiện bởi nhà phát triển tại phía máy chủ. Các khuyến nghị cơ bản đó là: Không nên quá tin tưởng vào những gì server yêu cầu cung cấp (bao gồm cả các tập tin cookie) của người dùng; Người sử dụng cần được xác nhận và xác nhận trước khi cho phép truy cập vào nó; Bảo vệ có thể được thực hiện bằng cách hạn chế các miền và đường dẫn để chấp nhận cookie, thiết lập chúng như HttpOnly, sử dụng SSL và không bao giờ lưu trữ dữ liệu bí mật trong các cookie; Có thể vô hiệu hóa việc sử dụng các Script một cách an toàn từ các trang web khách hàng.

Các Header nội dung Chính sách An ninh cũng có thể được sử dụng để bảo mật chống lại việc khai thác lỗ hổng XSS. Ngoài ra, mã hóa một cách thích hợp các ký tự điều khiển HTML, JavaScript, CSS và URL nên được thực hiện để làm cho chúng vô hại trước khi chúng được hiển thị trong trình duyệt. Sử dụng các bộ lọc để làm sạch đầu vào người dùng: filter_ sanitize_encoded (để mã hóa URL), htmlentities (lọc HTML), ilter_sanitize_magic_quotes (áp dụng addslashes ()). Các bộ lọc này giữ một chiếc đồng hồ đầu vào người sử dụng và kiểm tra javascript hoặc HTTP POST trong các đầu vào và sau đó ngăn chặn các script được thực thi. Ngoài ra có thể sử dụng một số thư viện bảo mật có sẵn để mã hóa người dùng nhập vào như "Project OWASP Encoding“ tại Google Code, lọc HTML hoặc Htmlawed cho PHP Anti-XSS Class, các ứng dụng thuần AntiSamy API cho Net hoặc XSS-HTML -Bộ lọc cho Java.

Bảo vệ điểm cuối

Người dùng có thể thực hiện các bước ngăn chặn để không trở thành nạn nhân của XSS bằng cách cài đặt các tiện ích trình duyệt hoặc sử dụng các bộ lọc XSS để ngăn chặn việc thực hiện các script. Ví dụ, các tiện ích bao gồm NoScript cho FireFox; NotScripts cho Chrome và Opera trong khi IE 8 đã có sẵn các add-ons này.

KẾT LUẬN

Hiện tại, ứng dụng web đã trở thành một phần không thể thiếu trong cuộc sống của chúng ta. Nhưng các trang web này thường tồn tại nhiều lỗ hổng và dễ bị tấn công. Trong đó lỗ hổng XSS đang là một trong những lỗ hổng gây ra các cuộc tấn công tiêm mã tiền chi phối làm cơ sở để khai thác các lỗ hổng rất mạnh mẽ. Nó có thể được kết hợp với các lỗ hổng khác để thực hiện các cuộc tấn công quan trọng hơn nữa. Vì thế cần có cơ chế bảo vệ trên server hoặc client để hạn chế các cuộc tấn công XSS.

Tài liệu tham khảo

[1].http://santoshdudhade.blogspot.in/2012/07/x ssf-v22- cross-site-scripting-framework.html\.
[2].ABRAHAN, A., Detecting and Exploiting XSS with Xenotix XSS Exploit Framework, 2012.
[3].CANNON, T.,AndroidDataStealing Vulnerability, november 23, thomascannon.net.
[4]. Cross-site Scripting (XSS)- OWASP.(n.d), Retrieved February 2013, from www.owasp.org.
[5].KUMAR, M., iPhone Skype XSS Vulnerability Lets Hackers Steal Phonebook, november, 2011.

KS. Nguyễn Ngọc Quân

Nổi bật Tạp chí Thông tin & Truyền thông
Đừng bỏ lỡ
Lỗ hổng XSS và các biện pháp khắc phục (P2)
POWERED BY ONECMS - A PRODUCT OF NEKO