Kiểm tra xác nhận đầu vào của LDAP, XML, SSI, ORM đánh giá an toàn hệ thống

31 189 0
Kiểm tra xác nhận đầu vào của LDAP, XML, SSI, ORM đánh giá an toàn hệ thống

Đ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

ĐÁNH GIÁ VÀ KIỂM ĐỊNH AN TOÀN HỆ THỐNG THÔNG TIN Đề tài :Kiểm tra xác nhận đầu vào Kiểm tra tiêm LDAP Giao thức truy cập thư mục nhẹ (LDAP) là một giao thức dịch vụ thư mục mở và trung lập với nhà cung cấp chạy trên một lớp phía trên ngăn xếp TCP IP. Nó cung cấp cơ chế thích hợp để thực hiện các điều khiển xác thực và ủy quyền, những thứ thường được sử dụng trong khi phát triển các ứng dụng mạng nội bộ và internet (web). II. Thử nghiệm tiêm ORM ORM Injection là một cuộc tấn công sử dụng SQL Injection đối với mô hình đối tượng truy cập dữ liệu được tạo bởi ORM. Từ quan điểm của một người thử nghiệm, cuộc tấn công này gần như giống hệt với cuộc tấn công SQL Injection. Tuy nhiên, lỗ hổng tiêm tồn tại trong mã được tạo bởi công cụ ORM. Kiểm tra tiêm XML là khi người kiểm tra cố gắng tiêm tài liệu XML vào ứng dụng. Nếu trình phân tích cú pháp XML không xác thực dữ liệu theo ngữ cảnh, thì thử nghiệm sẽ cho kết quả dương tính. SSI là các chỉ thị có trên các ứng dụng Web được sử dụng để cung cấp trang HTML có nội dung động. Chúng tương tự như CGI, ngoại trừ việc các SSI được sử dụng để thực hiện một số hành động trước khi trang hiện tại được tải hoặc trong khi trang đang được trực quan hóa. Để làm như vậy, máy chủ web sẽ phân tích SSI trước khi cung cấp trang cho người dùng.

BAN CƠ YẾU CHÍNH PHỦ HỌC VIỆN KỸ THUẬT MẬT Mà ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ĐÁNH GIÁ VÀ KIỂM ĐỊNH AN TOÀN HỆ THỐNG THÔNG TIN Đề tài 10:Kiểm tra xác nhận đầu vào Ngành: Cơng nghệ thơng tin Chun ngành: An tồn thơng tin Hà Nội, 2019 BAN CƠ YẾU CHÍNH PHỦ HỌC VIỆN KỸ THUẬT MẬT Mà ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ĐÁNH GIÁ VÀ KIỂM ĐỊNH AN TỒN HỆ THỐNG THƠNG TIN Đề tài 10:Kiểm tra xác nhận đầu vào Sinh viên thực 1.Nguyễn K T 2.Nguyễn Q K 3.Trương A T 4.Vương Đ B 5.Mạc Đức N K 6.Nguyễn V L Giảng viên hướng dẫn: Hà Nội, 2019 MỤC LỤC I I.1 Kiểm tra tiêm LDAP Tóm lượt kiểm tra tiêm LDAP Giao thức truy cập thư mục nhẹ (LDAP) giao thức dịch vụ th mục mở trung lập với nhà cung cấp chạy lớp phía ngăn xếp TCP / IP Nó cung cấp chế thích hợp để thực điều khiển xác thực ủy quyền, thứ thường sử dụng phát triển ứng dụng mạng nội internet (web) Tiêm LDAP máy chủ LDAP lưu trữ thông tin khách hàng truy cập phiên LDAP (thường có thời gian chờ xác định trước) Các hành động thực sau phiên bắt đầu thêm, xóa sửa đổi mục Các hoạt động khác thường thực bao gồm: • Ràng buộc - để xác thực định LDAP phiên giao th ức LDAP • Tìm kiếm - để xác định vị trí truy xuất mục thư mục LDAP • So sánh - để kiểm tra xem mục nhập tên có chứa giá trị thuộc tính cho khơng • Hoạt động mở rộng - hoạt động sử dụng để xác định hoạt động độc đáo • Hủy kết nối - đóng kết nối Một ứng dụng web sử dụng LDAP phép người dùng xác thực tìm kiếm thơng tin người dùng khác cấu trúc công ty Mục tiêu công tiêm LDAP tiêm ký t ự tìm kiếm lọc tìm kiếm LDAP truy vấn ứng dụng thực thi [ Rfc2254 ] xác định ngữ pháp cách xây dựng lọc tìm kiếm LDAPv3 mở rộng [ Rfc1960 ] (LDAPv2) Bộ lọc tìm kiếm LDAP xây dựng theo ký hiệu Ba Lan, gọi [ ký hiệu tiền tố ] Điều có nghĩa điều kiện mã giả lọc tìm kiếm nh th ế này: Ví dụ: find(“cn = John & userPassword =mypass”) Sẽ đại diện sau” find(“ (& (cn = John) ( userPassword =mypass))”) Các điều kiện Boolean tập hợp nhóm lọc tìm kiếm LDAP áp dụng cách sử dụng siêu ký t ự sau: Metachar Ý nghĩa & Boolean VÀ | Boolean HOẶC ! Boolean KHÔNG == Bằng ~= Xấp xỉ >= Lớn 0s4tan@hell.com Trong trường hợp này, sở liệu XML cuối là: gandalf !c3 0 gandalf@middleearth.com Stefan0 w1s3c 500 Stefan0@whysec.hmm tony Un6R34kb!e 500 >0s4tan@hell.com Nút userid ban đầu nhận xét, để lại nút tiêm Tài liệu tuân thủ quy tắc DTD 17 IV Kiểm thử tiêm SSI IV.1 Tóm lượt tiêm SSI SSI thị có ứng dụng Web sử dụng để cung cấp trang HTML có nội dung động Chúng tương tự CGI, ngoại trừ việc SSI sử dụng để thực số hành động trước trang tải trang trực quan hóa Để làm vậy, máy chủ web phân tích SSI trước cung cấp trang cho ng ười dùng Các máy chủ web thường cung cấp cho nhà phát triển kh ả thêm đoạn mã động nhỏ bên trang HTML tĩnh mà không ph ải xử lý ngôn ngữ phía máy chủ máy khách th ức Tính bao gồm Server-Side Bao gồm ( SSI ) Trong thử nghiệm tiêm SSI, kiểm tra xem tiêm vào liệu ứng dụng gi ải thích chế SSI hay không Việc khai thác thành công lỗ hổng cho phép kẻ công tiêm mã vào trang HTML chí th ực thực thi mã từ xa Đặt thị SSI vào tài liệu HTML tĩnh dễ viết đoạn mã sau: để in thời gian để bao gồm đầu tập lệnh CGI để bao gồm nội dung tệp liệt kê tệp th mục. Một cách khác để khám phá xem ứng dụng bị cơng hay không xác minh diện trang có phần m rộng stm, shtm shtml Tuy nhiên, việc thiếu loại trang khơng có nghĩa ứng dụng bảo vệ chống lại cơng SSI Sau đó, hỗ trợ SSI máy chủ web bật, máy ch ủ phân tích thị Trong cấu hình mặc định, thông thường, hầu hết máy chủ web không cho phép sử dụng lệnh exec để thực thi lệnh hệ thống Như tình xác thực đầu vào xấu, vấn đề phát sinh người dùng ứng dụng web phép cung cấp d ữ liệu khiến ứng dụng máy chủ web hoạt động theo cách không lường tr ước Liên quan đến việc tiêm SSI, kẻ cơng cung cấp đầu vào, 18 ứng dụng (hoặc trực tiếp máy chủ) đưa vào trang tạo động, phân tích cú pháp dạng nhiều ch ỉ thị SSI Các yếu tối rủi ro IV.2 Ví dụ 1: Các lệnh sử dụng để tiêm SSI khác tùy theo hệ điều hành máy chủ sử dụng Các lệnh sau biểu thị cú pháp nên sử dụng để thực thi lệnh OS Linux: Liệt kê tập tin thư mục: Truy cập thư mục: Kịch thực thi: Các cửa sổ: Liệt kê tập tin thư mục: Truy cập thư mục : Ví dụ Các ví dụ khác SSI sử dụng để truy cập thiết l ập thông tin máy chủ: Để thay đổi đầu thông báo lỗi: 19 Để hiển thị tên tệp tài liệu tại: Để hiển thị đường dẫn ảo tên tệp: Sử dụng lệnh cấu hình thơng số thời gian, có th ể ki ểm soát định dạng đầu ngày giờ: Sử dụng lệnh Fsize, in kích thước tệp chọn: IV.3 Cách kiểm thử SSI IV.3.1 Kiểm thử hộp đen Điều cần làm thử nghiệm theo kiểu Hộp đen tìm xem máy chủ web có thực hỗ trợ thị SSI hay không Thông thường, câu trả lời có, hỗ trợ SSI phổ biến Để tìm hiểu, chúng tơi cần khám phá loại máy chủ web ch ạy mục tiêu chúng tôi, sử dụng kỹ thuật thu thập thông tin cổ điển Cho dù chúng tơi có thành cơng hay không việc khám phá m ẩu thông tin này, chúng tơi đốn xem liệu SSI có đ ược h ỗ tr ợ hay không cách xem nội dung trang web mục tiêu Nếu chứa tệp shtml , có lẽ SSI hỗ trợ, phần mở rộng đ ược s d ụng để xác định trang có chứa thị Thật không may, việc sử dụng tiện ích mở rộng shtml khơng bắt buộc, đó, khơng tìm thấy tệp shtml khơng thiết có nghĩa mục tiêu khơng dễ bị công tiêm SSI Bước bao gồm xác định xem cơng tiêm SSI có thực khả thi hay không, vậy, điểm đầu vào mà sử dụng để tiêm mã độc Hoạt động kiểm tra cần thiết để thực việc hoàn toàn giống với hoạt động kiểm tra lỗ hổng tiêm mã khác Cụ thể, chúng tơi cần tìm trang nơi người dùng phép gửi số loại đầu vào xác minh xem ứng dụng có xác thực xác đầu vào gửi hay không Nếu 20 vệ sinh không đủ, cần kiểm tra xem chúng tơi cung cấp d ữ liệu hiển thị khơng thay đổi hay khơng (ví dụ: thông báo l ỗi đăng diễn đàn) Bên cạnh liệu người dùng cung cấp, vectơ đầu vào phải xem xét tiêu đề yêu cầu HTTP n ội dung cookie, chúng dễ dàng giả mạo Khi chúng tơi có danh sách điểm tiêm tiềm năng, chúng tơi kiểm tra xem đầu vào có xác thực xác hay khơng sau tìm nơi đầu vào cung cấp lưu trữ Chúng tơi cần đảm bảo chúng tơi tiêm ký tự sử dụng th ị c SSI: /src/read_body.php?mailbox=INBOX "& Pass_id = 46106 & startMessage = • Loại bỏ tham số: http: // /src/read_body.php? passed_id=46106&startMessage=1 Kết cuối thử nghiệm mang đến cho người kiểm tra ba tình xảy ra: S1 - Ứng dụng trả mã lỗi / thông báo S2 - Ứng dụng không trả mã lỗi / thông báo, khơng nhận thao tác u cầu S3 - Ứng dụng thực không trả lại mã lỗi / thông báo nh ận thao tác yêu cầu bình thường Tình S1 S2 đại diện cho việc tiêm IMAP / SMTP thành công Mục tiêu kẻ công nhận phản hồi S1, m ột báo cho thấy ứng dụng dễ bị công thao túng n ữa Giả sử người dùng truy xuất tiêu đề email cách s dụng yêu cầu HTTP sau: http: // /src/view_header.php? mailbox=INBOX&passed_id=46105&passed_ent_id=0 27 Kẻ cơng sửa đổi giá trị tham số INBOX cách nhập ký tự "(% 22 cách sử dụng mã hóa URL): http: // /src/view_header.php?mailbox=INBOX %22&passed_id=46105&passed_ent_id=0 Trong trường hợp này, câu trả lời ứng dụng là: LRI: Yêu cầu xấu không định dạng Truy vấn: CHỌN "INBOX" " Máy chủ trả lời: Đối số phụ không mong muốn để Ch ọn Tình S2 khó kiểm tra thành công Người kiểm tra cần sử dụng lệnh tiêm mù để xác định xem máy chủ bị cơng khơng Mặt khác, tình cuối (S3) không tiết lộ đo ạn Kết dự kiến: • Danh sách thơng số dễ bị tổn thương • Chức bị ảnh hưởng • Loại tiêm (IMAP / SMTP) Hiểu luồng liệu cấu trúc triển khai máy khách Sau xác định tất tham số dễ bị tổn thương (ví dụ: "pass_id"), người kiểm tra cần xác định mức độ tiêm có th ể sau thiết kế kế hoạch kiểm tra để khai thác thêm ứng dụng Trong trường hợp thử nghiệm này, phát tham số "pass_id" ứng dụng dễ bị công sử dụng yêu cầu sau: http: // /src/read_body.php? mailbox=INBOX&passed_id=46225&startMessage=1 Sử dụng trường hợp kiểm tra sau (cung cấp giá trị theo th ứ t ự ch ữ cần giá trị số): 28 http: // /src/read_body.php? mailbox=INBOX&passed_id=test&startMessage=1 Sẽ tạo thông báo lỗi sau: LRI: Yêu cầu xấu không định dạng Truy vấn: Kiểm tra FETCH: kiểm tra CƠ THỂ [ĐẦU] Máy chủ trả lời: Lỗi lệnh IMAP mà máy chủ nhận Trong ví dụ này, thông báo lỗi trả tên lệnh thực tham số tương ứng Trong tình khác, thơng báo lỗi ("khơng kiểm sốt" ứng dụng) chứa tên lệnh thực thi, đọc RFC phù h ợp (xem đoạn "Tham khảo") cho phép người kiểm tra hiểu lệnh khác có th ể thực thi Nếu ứng dụng không trả thông báo lỗi mô tả, người kiểm tra cần phân tích chức bị ảnh hưởng để suy tất lệnh (và tham số) liên quan đến chức đề cập Ví dụ: tham số dễ bị tổn thương phát chức tạo hộp th ư, hợp lý cho lệnh IMAP bị ảnh hưởng "TẠO" Theo RFC, l ệnh CREATE chấp nhận tham số định tên hộp th tạo Kết dự kiến: Danh sách lệnh IMAP / SMTP bị ảnh hưởng Loại, giá trị số lượng tham số mong đợi lệnh IMAP / SMTP bị ảnh hưởng Tiêm lệnh IMAP / SMTP: Khi người kiểm tra xác định tham số dễ bị tổn thương phân tích bối cảnh chúng thực thi, giai đoạn khai thác chức Giai đoạn có hai kết xảy ra: Việc tiêm xảy trạng thái không xác th ực: ch ức bị ảnh hưởng không yêu cầu người dùng phải xác th ực Các 29 lệnh chèn (IMAP) có sẵn giới hạn ở: CAPABILITY, NOOP, AUTHENTICATE, LOGIN, and LOGOUT Việc tiêm trạng thái xác thực: việc khai thác thành công đòi hỏi người dùng phải xác th ực đầy đủ trước th nghi ệm tiếp tục Trong trường hợp, cấu trúc điển hình Tiêm IMAP / SMTP sau: • Tiêu đề: kết thúc lệnh dự kiến; • Thân: tiêm lệnh mới; • Footer: bắt đầu lệnh dự kiến Điều quan trọng cần nhớ là, để thực thi lệnh IMAP / SMTP, lệnh trước phải kết thúc chuỗi CRLF (% 0d% 0a) Giả sử giai đoạn ("Xác định tham số dễ bị tổn thương"), kẻ công phát tham số "message_id" yêu cầu sau dễ bị công: http: // /read_email.php?message_id=4791 Chúng ta giả sử kết phân tích th ực giai đoạn ("Tìm hiểu luồng liệu cấu trúc triển khai c máy khách") xác định lệnh đối số liên kết v ới tham số là: FETCH 4791 BODY[HEADER] Trong trường hợp này, cấu trúc tiêm IMAP là: http:///read_email.php?message_id=4791 BODY[HEADER] %0d%0aV100 CAPABILITY%0d%0aV101 FETCH 4791 Mà tạo lệnh sau: ???? FETCH 4791 BODY[HEADER] V100 CAPABILITY V101 FETCH 4791 BODY[HEADER] Header = 4791 BODY[HEADER] 30 Body = %0d%0aV100 CAPABILITY%0d%0a Footer = V101 FETCH 4791 Kết dự kiến: Tiêm lệnh IMAP / SMTP tùy ý 31 ... VI.3 Để phát tham số dễ bị tổn thương, người kiểm tra phải phân tích khả ứng dụng việc xử lý đầu vào Kiểm tra xác nhận đầu vào yêu cầu người kiểm tra gửi yêu cầu khơng có thật độc hại đến máy... password/text()='!c3']/account/text()) Nếu ứng dụng không lọc đầu vào người dùng, người kiểm tra tiêm mã XPath can thiệp vào kết truy vấn Chẳng hạn, người kiểm tra nhập giá trị sau: Username: ' or '1' = '1 Password:... th ức có th ể chấp nhận tham số đầu vào không xác nh ận Cách thức kiểm tra II.2 II.2.1 Kiểm thử hộp đen Kiểm thử hộp đen cho lỗ hổng tiêm ORM giống hệt với kiểm tra SQL Injection Trong hầu hết

Ngày đăng: 03/10/2019, 17:07

Từ khóa liên quan

Mục lục

  • I. Kiểm tra tiêm LDAP

    • I.1. Tóm lượt kiểm tra tiêm LDAP

    • I.2. Cách kiểm tra

      • I.2.1. Bộ lọc tìm kiếm

      • I.2.2. Đăng nhập

      • I.3. Làm thế nào để ngăn chặn các cuộc tấn công tiêm LDAP?

      • II. Thử nghiệm tiêm ORM

        • II.1. Tóm lượt về thử nghiệm tiêm ORM

        • II.2. Cách thức kiểm tra

          • II.2.1. Kiểm thử hộp đen

          • II.2.2. Kiểm thử hộp xám

          • III. Kiểm tra tiêm XML

            • III.1. Tóm lượt

            • III.2. Cách kiểm tra tiêm XML

            • III.3. Tấn công tiêm XML

            • IV. Kiểm thử tiêm SSI

              • IV.1. Tóm lượt tiêm SSI

              • IV.2. Các yếu tối rủi ro

                • Ví dụ 2

                • IV.3. Cách kiểm thử SSI

                  • IV.3.1. Kiểm thử hộp đen

                  • IV.3.2. Kiểm thử hộp xám

                  • V. Kiểm tra tiêm XPath

                    • V.1. Tóm lượt về kiểm tra tiêm XPath

                    • V.2. Làm thế nào để kiểm tra tiêm XPath

                    • VI. Kiểm tra tiêm IMAP / SMTP

                      • VI.1. Tóm lượt về kiểm tra tiêm IMAP/SMTP

                      • VI.2. Làm thế nào để kiểm tra

                      • VI.3. Xác định các thông số dễ bị tổn thương

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

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

Tài liệu liên quan