Phương pháp Pentest tổng quan phần 1

Chương 21 Phương pháp Pentest Chương này trình bày phương pháp chi tiết từng bước phương pháp tấn công một ứng dụng web, gồm các loại lỗ hổng và kỹ thuật tấn công được trình bày trong các chương trước Tuy rằng phương pháp này không giúp tìm ra tất cả các lỗ hổng ứng dụng nhất định nhưng sẽ đảm bảo được rằng kiểm thử tất cả khu vực cần thiết trên ứng dụng và đảm bảo tìm thấy nhiều vấn đề nhất với tài nguyên hiện có Hình 1 dưới đây minh họa các công việc chính mà phương pháp luận này mô tả Chương.

Chương 21 Phương pháp Pentest Chương trình bày phương pháp chi tiết bước phương pháp công ứng dụng web, gồm loại lỗ hổng kỹ thuật cơng trình bày chương trước Tuy phương pháp khơng giúp tìm tất lỗ hổng ứng dụng định đảm bảo kiểm thử tất khu vực cần thiết ứng dụng đảm bảo tìm thấy nhiều vấn đề với tài ngun có Hình minh họa cơng việc mà phương pháp luận mô tả Chương bám sát sơ đồ chia nhỏ nhiệm vụ liên quan Số thứ tự tương ứng sơ đồ thứ tự bước phương pháp luận Phương pháp luận trình bày dạng chuỗi nhiệm vụ tổ chức xếp phụ thuộc lẫn Trong phương pháp, phụ thuộc nêu mô tả nhiệm vụ Tuy nhiên thực tế, người kiểm thử thường xuyên phải đưa định hướng đánh giá theo trường hợp cụ thể Ví dụ: - Thơng tin thu thập thời điểm khiến bạn quay lại bước trước để hình thành cơng tập trung Ví dụ: lỗi kiểm soát truy cập cho phép liệt kê danh sách người dùng để thực công chức xác thực - Việc phát lỗ hổng chức ứng dụng giúp bỏ qua một vài giai đoạn kiểm tra chức khác Ví dụ: lỗ hổng lộ mã nguồn chương trình cho phép đánh giá chức ứng dụng theo hướng white box thay black box thường lệ - Kết kiểm tra chức giúp phát lỗ hổng định chức khác để chuyển hướng kiểm thử Ví dụ: lỗi chung xác thực đầu vào giúp việc tìm cách bỏ qua biện pháp phịng thủ ứng dụng nhanh chóng Hình 1.0 Các cơng việc phương pháp luận Quy trình phương pháp luận giúp cho cơng việc kiểm thử tránh khỏi sơ suất khơng đáng có, không bắt buộc tuân thủ cứng nhắc Các nhiệm vụ mô tả phương pháp luận phần lớn tiêu chuẩn thống, cơng khơng có Hướng dẫn chung Khi thực kiểm thử ứng dụng web, người kiểm thử cần tuân thủ số lưu ý chung, áp dụng cho tất khu vực, chức khác ký thuật cần thực Một số ký tự coi đặc biệt HTTP request encode Khi sửa đổi nội dung request, cần sử dụng URL encode ký tự để đảm bảo chúng diễn giải ý nghĩa: - & dùng để phân tách tham số chuỗi truy vấn URL nội dung message Để chèn ký tự & cần encode thành %26 - = dùng để phân tách tên giá trị tham số chuỗi truy vấn nội dung message Để chèn ký tự = cần encode thành %3d - ? dùng để đánh dấu bắt đầu chuỗi truy vấn URL Để chèn ký tự ? cần encode thành %3f - Khoảng trắng (space) dùng để đánh dấu kết thúc URL request cho biết phần cuối giá trị cookie Cookie Header Để chèn khoảng trắng cần encode thành %20 + - + encode khoảng trắng nên để chèn ký tự + cần encode thành %2b - ; dùng để tách cookie riêng lẻ Cookie header Để chèn ký tự ; cần encode thành %3b - # dùng để đánh dấu phân đoạn URL Nếu nhập ký tự vào URL, giúp cắt bớt URL gửi đến máy chủ Để chèn ký tự # cần encode thành %23 - % dùng làm tiền tố giá trị mã URL Để chèn ký tự % cần encode thành %25 - Mọi ký tự null byte enter phải encode URL thành %00 %0a tương ứng Hơn nữa, việc nhập liệu URL encode vào form khiến trình duyệt thực lớp encode khác Ví dụ, gửi %00 form kết encode cuối thành %2500 gửi đến máy chủ Vì lý này, thông thường nên sử dụng proxy chặn bắt request Trong nhiều trường hợp kiểm thử, người kiểm thử cần thực gửi chuỗi tạo thủ công, theo dõi phàn hồi ứng dụng để tìm điểm bất thường từ phát lõ hổng bảo mật Trong số trường hợp, phản hồi ứng dụng với request cụ thể chứa dấu hiệu lỗ hổng lỗ hổng kích hoạt hay chưa Trong trường hợp đầu vào cụ thể dẫn đến hành vi bất thường, cần kiểm tra lại xem việc gửi request lành tính có gây kết tương tự hay khơng Nếu có, khơng thể kết luận lỗ hổng bảo mật Các ứng dụng thường tích lũy trạng thái từ request trước gây ảnh hưởng đến việc phản hồi request khác Đôi khi, muốn khai thác lỗ hổng dự kiến xác định nguyên nhân hành vi bất thường cần phải loại bỏ ảnh hưởng trạng thái tích lũy Để làm điều đó, thơng thường cần bắt đầu phiên làm việc mới, điều hướng đến điểm bất thường request lành tính sau khai thác thác lại Thơng thường, lặp lại bước refresh cách điều chỉnh phần cookie request container thông tin nhớ đệm ngồi ra, sử dụng cơng cụ Burp Repeater để cô lập request, thực điều chỉnh gửi lại request nhiều lần Một số ứng dụng sử dụng cân tải HTTP request liên tiếp xử lý máy chủ khác Các máy chủ có khác biệt nhỏ nội dung cấu hình ảnh hưởng đến kết khai thác Ngoài ra, số công thành công dẫn đến thay đổi trạng thái máy chủ chẳng hạn tạo file Để phân biệt ảnh hưởng, người kiểm thử phải thực gửi liên tiếp request giống hệt nhau, kiểm tra kết request nhận kết từ máy chủ liên quan Khi triển khai kiểm thử ứng dụng web, người kiểm thử phải xác định xác tên máy chủ, URL, chức sử dụng hạn chế đội ngũ kiểm thử Người kiểm thử cần cho chủ sở hữu nhận thức xác rủi ro liên quan đến việc thực kiểm thử xâm nhập Khuyên chủ sở hữu lưu liệu quan trọng trước bắt đầu công việc Xác định chức ứng dụng Hình 1.1 Xác định chức ứng dụng 1.1 Xác định chức hiển thị (Explore Visible Content) Cấu hình để trình duyệt sử dụng proxy / spidering tool Cả Burp WebScarab sử dụng để giám sát phân tích nội dung trang web đươc chặn pproxy Có thể cấu hình trình duyệt sử dụng tiện ích mở rộng IEWatch để theo dõi phân tích nội dung HTTP va HTML trình duyệt xử lý Sử dụng ứng dụng bình thường, truy cập liên kết URL, hoàn thành tất form chức nhiều bước Thử với JavaScript cho phép chặn cookie cho phép chặn nhiều ứng dụng xử lý cấu hình trình duyệt khác nhau, người dùng truy cập nội dung đường dẫn mã nguồn khác ứng dụng Nếu ứng dụng sử dụng xác thực, yêu cầu chủ sở hữu cung cấp tài khoản tạo tài khoản, sử dụng tài khoản để truy cập chức bảo vệ Khi kiểm tra, theo dõi request response bị proxy chặn lại để hiểu liệu trao đổi cách ứng dụng phía client sử dụng để kiểm sốt hành vi ứng dụng phía máy chủ Kiểm tra lại kiến trúc trang web tạo công cụ spider xác định nội dung chức chưa dùng (kiểm tra) qua Từ kiến trúc trang web xác định vị trí chức chưa kiểm tra (ví dụ: Burp Spider, kiểm tra Linked From details) Truy cập chức trình duyệt để spider phân tích cú pháp phản hồi máy chủ để xác định thành phần khác Lặp lại bước không xuất thành phần chức khác Khi duyệt web theo cách thủ cơng thụ động, người kiểm thử chủ động thu thập thông tin ứng dụng công cụ quét với URL biết bước làm xuất nội dung bổ sung thu thập thông tin theo cách thủ công Trước thực thu thập thông tin thủ công, cần xác định URL phá vỡ phiên ứng dụng, loại chúng khỏi phạm vi kiểm tra 1.2 Consult Public Resources (sử dụng nguồn công khai) Sử dụng công cụ tìm kiếm internet (như Wayback Machine) để xác định nội dung công khai đối tượng Sử dụng tùy chọn tìm kiếm nâng cao để cải thiện hiệu kiểm tra Ví dụ: Google, dùng site: để truy xuất tất kết cho đối tượng, link: truy xuất trang khác liên kết đến đối tượng Nếu kết tìm kiếm khơng cịn xuất ứng dụng xem cache cơng cụ tìm kiếm nội dung chứa liên kết đến tài ngun bổ sung chưa bị xóa Thực tìm kiếm tên, địa email xuất nội dung ứng dụng, chẳng hạn thông tin liên hệ bao gồm thông tin không hiển thị HTML comment Ngồi ra, cần tìm kiếm nhóm kênh tin tức tìm kiếm chi tiết kỹ thuật liên quan đến mục tiêu sở hạ tầng hỗ trợ đăng tải diễn đàn Xem lại tệp WSDL (Web Service Description Language) để tạo danh sách hàm tham số mà ứng dụng sử dụng 1.3 Tìm kiếm chức ẩn (Discover Hidden Content) Xác định cách ứng dụng xử lý request liên quan đến mục không tồn thực số request thủ công tài nguyên hợp lệ không hợp lệ, so sánh response máy chủ để xác định đối tượng không tồn Xác định danh sách thư mục, file phổ biến phần mở rộng tên tệp phổ biến thêm vào danh sách tên tồn tên suy Xác định quy ước đặt tên nhà phát triển ví dụ: có trang AddDocument.jsp ViewDocument.jsp có trang EditDocument.jsp RemoveDocument.jsp Kiểm tra code phía client để xác định manh mối chức ẩn máy chủ HTML comment hay thành phần form bị vô hiệu hóa Sử dụng kỹ thuật tự động hóa mô tả chương 14, thực hàng loạt request với thư mục, file phần mở rộng file, theo dõi phản hồi máy chủ để xác định thư mục/file tồn có khả truy cập Thực lặp lại bước thu thập thông tin với chức khác 1.4 Tìm kiếm thành phần mặc định Chạy Nikto để xác định nội dung mặc định Sử dụng tùy chọn Nikto để tối đa hóa hiệu Ví dụ: sử dụng –root để định thư mục/khu vực kiểm tra nội dung mặc định -404 định chuooixdaanx đến trang thông báo lỗi File Not Found Kiểm tra lại kết băng phương pháp thủ công, loại bỏ kết giả Request đến thư mục, định IP Host header, xác định xem ứng dụng có phản hồi khơng, có, chạy Nikto với IP máy chủ Request đến thư mục, định danh sách User-Agent headers www.useragentstring.com/pages/useragentstring.php 1.5 Liệt kê chức định danh Xác định hàm truy cập định danh (ví dụ: /admin.jsp?action=editUser hay /main.php?func=A21) Áp dụng kỹ thuật mục 1.3 chức riêng lẻ ví dụ: ứng dụng sử dụng tham số chứa tên hàm Trước tiên, xác định hành vi ứng dụng tên hàm không hợp lệ hợp lệ xác định danh sách tên hàm phổ biến chu trình thơng qua phạm vi cú pháp định danh sử dụng thử liệt kê chức hợp lệ tự động Xây dựng kiến trúc ứng dụng dựa đường dẫn chức thay URL Kiểm tra chức năng, luồng logic phụ thuôc chúng (xem chương 4) 1.6 Kiểm tra thông số debug (Test for Debug Parameters) Chọn trang/chức có khả chứa tham số debug ẩn (chẳng hạn debug = true) Chúng có khả xuất chức đăng nhập, tìm kiếm, tải lên tải xuống Sử dụng danh sách tham số gỡ lỗi phổ biến (như debug, test, hide, source) giá trị chung (như true, yes, on, 1) Đối với cặp tên tham số/giá trị Gửi cặp cho hàm mục tiêu Đối với POST request, cấp tham số truy vấn URL nội dung request Sử dụng kỹ thuật mô tả chương 14 để thực tự động hóa Ví dụ: sử dụng cơng bomb Burp Intruder để kết hợp tất hoán vị payload Kiểm tra phản hồi bất thường ứng dụng để xác định trường hợp mà thông số thêm vào có ảnh hưởng đến q trình xử lý ứng dụng Phân tích ứng dụng Hình 2.2 phân tích ứng dụng 2.1 Xác định hàm Xác định chức cốt lõi ứng dụng hoạt động chức chúng hoạt động bình thường Xác định chế bảo mật cốt lõi ứng dụng sử dụng cách chúng hoạt động Hiểu chế xác thực, quản lý phiên kiểm soát truy cập chức hỗ trợ chúng, chẳng hạn đăng ký người dùng khôi phục tài khoản Xác định chức hành vi rộng hơn, chẳng hạn chuyển hướng, liên kết ngoài, thông báo lỗi chức quản trị, ghi nhật ký Xác định chức khác với giao diện GUI tiêu chuẩn, đặt tên tham số chế điều hướng sử dụng vị trí khác, chọn để kiểm tra chuyên sâu 2.2 Xác định đầu vào liệu Xác định tất vị trí người dùng đưa liệu vào q trình xử lý ứng dụng URL, tham số truy vấn, POST data, cookie HTTP header khác ứng dụng xử lý Kiểm tra chế mã hóa truyền liệu tùy chỉnh ứng dụng sử dụng, ví dụ định dạng chuỗi truy vấn khơng chuẩn xem xét liệu gửi có gồm tên giá trị tham - Chờ khoảng thời gian khơng sử dụng đến token này, sau request đến trang bảo vệ (chẳng hạn Thông tin tôi) token - Nếu trang hiển thị bình thường chứng tỏ token hoạt động - Thử để xác định thời gian phiên hết hạn token sử dụng sau nhiều ngày so với request trước Sử dụng Burp Intruder cấu hình để tăng khoảng thời gian request để tự động hóa tác vụ Kiểm tra xem chức đăng xuất có tồn khơng Nếu có, kiểm tra xem có khiến phiên hết hạn khơng Sau đăng xuất, sử dụng lại token cũ xác định xen cịn hợp lệ khơng Nếu hoạt động, người dùng dễ bị công chiếm quyền người dùng đăng xuất người kiểm thử sử dụng Burp Repeater để gửi lại request từ lịch sử proxy để kiểm tra ứng dụng có phản hồi sau người dùng đăng xuất không 5.8 Kiểm tra cố định phiên Nếu ứng dụng cung cấp session token cho người dùng chưa xác thực, sử dụng để thực đăng nhập ứng dụng không cung cấp token sau đăng nhập thành công, ứng dụng dễ bị cố định phiên Ngay ứng dụng không cấp token cho người dùng chưa xác thực, lấy token cách đăng nhập, sau quay lại trang đăng nhập ứng dụng trả lại trang người dùng xác thực, sử dụng thông tin đăng nhập với tư cách người dùng khác sử dụng token Nếu ứng dụng không cấp token sau lần đăng nhập này, ứng dụng dễ bị cố định phiên Xác định định dạng token mà ứng dụng sử dụng sửa token cấp thành giá trị tự tạo theo định dạng cố gắng đăng nhập ứng dụng cho phép tạo phiên token tự tạo, dễ bị cố định phiên Nếu ứng dụng không hỗ trợ đăng nhập xử lý thông tin nhạy cảm người dùng (chẳng hạn thơng tin cá nhân tốn) cho phép hiển thị thông tin sau request (chẳng hạn trang xác minh đơn hàng), thực ba kiểm tra trước liên quan đến trang hiển thị liệu nhạy cảm Nếu token ẩn danh trình sử dụng dùng vào việc truy xuất liệu nhạy cảm người dùng ứng dụng dễ bị cố định phiên 5.9 Kiểm tra CSRF Nếu ứng dụng dựa vào HTTP cookie làm phương pháp truyền token phiên, ứng dụng dễ bị công CSRF Kiểm tra lại chức ứng dụng, xác định request gửi thực hành động nhạy cảm Nếu tác nhân độc hại có khả thay đổi (các) thơng số request (có nghĩa request khơng chứa token, liệu khơng thể đốn hay liệu bí mật khác) gần chắn ứng dụng bị cơng Tạo trang HTML tạo request mong muốn mà không cần người dùng tương tác Đối với GET request, đặt thẻ có tham số src mang giá trị URL tồn lỗ hổng Đối với POST request, tạo form chứa trường ẩn tham số cần thiết để công target đặt thành URL tồn lỗ hổng Người cơng sử dụng JavaScript để tự động gửi form tải trang Đăng nhập vào ứng dụng, sử dụng trình duyệt để tải trang HTML tạo, xác minh lại hành động mong muốn thực ứng dụng Nếu ứng dụng sử dụng token bổ sung request nhằm chặn công CSRF, kiểm tra chúng kiểm tra token phiên Đồng thời kiểm tra ứng dụng bị cơng giao diện người dùng hay không, để bỏ qua biện pháp phòng thủ CSRF (xem chương 13) 5.10 Kiểm tra phạm vi cookie Nếu ứng dụng sử dụng HTTP cookie để truyền session token (hoặc liệu nhạy cảm khác), kiểm tra Set-Cookie header thuộc tính tên miền hay đường dẫn dùng để kiểm sốt phạm vi cookie Nếu ứng dụng khơng đặt phạm vi cho cookie miền mẹ thư mục mẹ ứng dụng có khả bị công thông qua ứng dụng web khác lưu trữ miền thư mục mẹ Nếu ứng dụng đặt phạm vi tên miền cookie thành tên miền riêng (hoặc khơng định thuộc tính tên miền) có nguy bị cơng thơng qua ứng dụng lưu trữ miền phụ Đây hệ cách thức hoạt động phạm vi cookie Khơng thể tránh cơng ngồi việc khơng lưu trữ ứng dụng khác miền phụ Xác định phụ thuộc nội dung vào đường dẫn, chẳng hạn /site/main hay /site/demo, công CSRF Xác định tất tên miền đường dẫn nhận cookie mà ứng dụng cấp Xác định ứng dụng web truy cập thông qua tên miền đường dẫn để lấy cookie mà ứng dụng cấp cho người dùng mục tiêu không Kiểm tra luồng logic 6.1 Hiểu yêu cầu kiểm soát truy cập Dựa chức cốt lõi triển khai ứng dụng, hiểu yêu cầu kiểm soát truy cập theo chiều dọc (các cấp độ người dùng khác có quyền truy cập vào loại chức khác nhau) theo chiều ngang (người dùng cấp đặc quyền có quyền truy cập đến tập hợp liệu khác nhau) Thông thường, hai kiểu phân ly có mặt Ví dụ: người dùng bình thường truy cập liệu riêng họ, quản trị viên truy cập liệu người Xác định vùng chức loại tài ngun có ích cho cơng leo thang đặc quyền cách kiểm tra lại kết ánh xạ ứng dụng Để thực kiểm tra hiệu lỗ hổng kiểm soát truy cập, điều kiện lý tưởng có tài khoản với đặc quyền khác Để có tài khoản có đặc quyền theo chiều ngang, đăng ký để có tài khoản có đặc quyền theo chiều dọc cần có chấp thuận chủ sở hữu cần khai thác số lỗ hổng để có quyền truy cập vào tài khoản có đặc quyền cao Tính khả dụng tài khoản khác ảnh hưởng đến loại thử nghiệm thực (sẽ mô tả sau) 6.2 Kiểm tra nhiều tài khoản Nếu ứng dụng thực thi kiểm soát truy cập theo chiều dọc, trước tiên sử dụng tài khoản có đặc quyền cao để xác định tất chức mà ứng dụng truy cập Sau đó, sử dụng tài khoản đặc quyền cố gắng truy cập mục chức - Sử dụng Burp xác định tất chức ứng dụng ngữ cảnh người dùng - Kiểm tra lại sơ đồ chức trang web, đảm bảo xác định đầy đủ chức trang web Đăng xuất khỏi ứng dụng đăng nhập lại với vai trò người dùng khác Sử dụng sơ đồ nội dung chọn tính “compare site maps” để xác định người dùng có đặc quyền thấp truy cập chức đặc quyền cao (xem chương 8) Nếu ứng dụng kiểm soát truy cập theo chiều ngang, thực kiểm tra tương đương cách sử dụng hai tài khoản cấp đặc quyền thử dùng tài khoản để truy cập thông tin tài khoản Việc thực cách thay đổi id người dùng (hoặc ID tài liệu) request đến tài nguyên người dùng khác Thực kiểm tra thủ cơng khóa logic kiểm soát truy cập - Đối với đặc quyền người dùng, kiểm tra tài nguyên có sẵn Thử truy cập trái phép cách phát lại request sử dụng token người dùng Thực kiểm tra bước chức nhiều tầng riêng lẻ để đảm bảo kiểm soát truy cập triển khai cách giai đoạn, liệu ứng dụng có giả định người dùng vào giai đoạn sau vượt qua kiểm tra thực trước Ví dụ: trang quản trị chứa form, kiểm tra xem việc gửi form có kiểm sốt truy cập khơng? Trong số trường hợp ứng dụng xác thực người dùng trang đăng nhập, có nghĩa người dùng hồn tồn bỏ qua trang đăng nhập vào thẳng trang profile mà không cần xác thực lại 6.3 Kiểm tra với quyền truy cập hạn chế Nếu quyền truy cập trước vào tài khoản cấp đặc quyền khác có quyền truy cập vào liệu khác nhau, việc kiểm tra kiểm sốt truy cập trở nên khó khăn Nhiều lỗ hổng khó xác định hơn, khơng biết tên URL, id tham số cần thiết để khai thác điểm yếu Trong xác đinh sơ đồ chức ứng dụng, sử dụng tài khoản có đặc quyền thấp, xác định chức đặc quyền giao diện quản trị, phán đốn chúng không bảo vệ đầy đủ Kiểm tra client xác định tham chiếu đến chức phía server Hầu hết liệu chịu kiểm soát truy cập ngang truy cập cách sử dụng id, chẳng hạn số tài khoản tham chiếu đơn đặt hàng Để kiểm tra xem biện pháp kiểm sốt truy cập có hiệu sử dụng tài khoản hay không, phải cố gắng đoán xác định id liên kết với liệu người dùng khác Nếu có thể, tạo loạt id (ví dụ: cách tạo số đơn đặt hàng mới) Cố gắng xác định mẫu cho phép dự đoán id cấp cho người dùng khác Nếu khơng có cách để tạo id mới, việc đoán hay xác định id trở nên khó khăn Nếu tìm cách đoán id người dùng khác, sử dụng kỹ thuật mô tả chương 14 để thực công tự động nhằm thu thập liệu người dùng khác Sử dụng chức Extract Grep Burp Intruder xác định thông tin liên quan từ phản hồi ứng dụng 6.4 Kiểm tra phương thức khơng an tồn Một số ứng dụng triển khai kiểm soát truy cập theo tham số cố định khơng an tồn Kiểm tra tham số edit = false access = read request, sửa đổi chúng để can thiệp vào logic kiểm soát truy cập ứng dụng Một số ứng dụng kiểm soát truy cập dựa HTTP Referer header Ví dụ: ứng dụng kiểm sốt quyền truy cập vào /admin.jsp chấp nhận request có Referer /admin.jsp Để kiểm tra hành vi này, thực số hành động đặc quyền mà bạn ủy quyền gửi thiếu sửa Referer header Nếu thay đổi khiến ứng dụng chặn yêu cầu bạn, sử dụng Referer header khơng an toàn Thử thực hành động tương tự với người dùng đặc quyền thấp, có đủ Referer header xem liệu hành động có thành cơng hay khơng Nếu ứng dụng cho phép phương thức HEAD hoạt động, kiểm tra khả kiểm soát truy cập vùng chứa URL khơng an tồn Sử dụng request với phương thức HEAD xem ứng dụng có cho phép hay khơng Kiểm tra lỗ hổng xuất dựa liệu đầu vào Nhiều lỗ hổng quan trọng kích hoạt người dùng nhập liệu không theo logic ứng dụng, lỗ hổng xuất đâu ứng dụng Cách hiệu để kiểm tra ứng dụng có tồn tài lỗ hổng hay không thử tất tham số với chuỗi công 7.1 Xác định tất tham số Xem lại kết lập sơ đồ chức ứng dụng, xác định request có chứa tham số client gửi cho server xử lý Các tham số cần kiểm tra gồm mục chuỗi truy vấn URL, tham số request cookie HTTP Ngồi ra, cịn có tham số khác ảnh hưởng đến hành vi ứng dụng, chẳng hạn Referer header hay User-Agent header Để xác định tất tham số, sử dụng tập lênh sử dụng cơng cụ fuzzing có sẵn Burp Intruder Chặn request Burp Proxy chọn Send to Intruder click phải vào mục Burp Proxy history để chọn Cấu hình nội dung request Burp Intruder gửi đến máy chủ Ngoài ra, chức cịn sử dụng để tự động đánh dấu giá trị tham số dạng payload để thực fuzzing Sử dụng tab payload, cấu hình tập hợp payload phù hợp để thăm dị lỗ hổng ứng dụng Có thể nhập trọng tải theo cách thủ công, tải chúng từ tệp chọn danh sách Fuzzing tham số yêu cầu ứng dụng thường đòi hỏi phải đưa số lượng lớn yêu cầu xem xét kết để tìm điểm bất thường Nếu tập hợp tải trọng lớn, điều phản tác dụng khiến thời gian số lượng đầu lớn Do đó, cách tiếp cận hợp lý nhắm mục tiêu loạt lỗ hổng phổ biến thường dễ dàng phát phản hồi đầu vào cụ thể chúng thường tự xuất đâu ứng dụng chức cụ thể Dưới payload sử dụng để kiểm tra số loại lỗ hổng phổ biến: SQL Injection ‘ ‘-‘; waitfor delay ‘0:30:0’-1; waitfor delay ‘0:30:0’-XSS and Header Injection xsstest “>alert(‘xss’) OS Command Injection || ping -i 30 127.0.0.1 ; x || ping -n 30 127.0.0.1 & | ping –i 30 127.0.0.1 | | ping –n 30 127.0.0.1 | & ping –i 30 127.0.0.1 & & ping –n 30 127.0.0.1 & ; ping 127.0.0.1 ; %0a ping –i 30 127.0.0.1 %0a ` ping 127.0.0.1 ` Path Traversal / / / / / / / / / /etc/passwd / / / / / / / / / /boot.ini \ \ \ \ \ \ \ \ \ \etc\passwd \ \ \ \ \ \ \ \ \ \boot.ini Script Injection ;echo 111111 echo 111111 response.write 111111 :response.write 111111 File Inclusion http:/// http:/// Tất payload hiển thị dạng chữ Các ký tự “?”, “;”, “&”, “+”, “=” dấu cách phải encode chúng có ý nghĩa đặc biệt HTTP request Theo mặc định, Burp Intruder thực encode cần thiết chưa bị tắt (Để khôi phục tất tùy chọn mặc định sau tùy chỉnh trước đó, chọn Khơi phục mặc định.) Trong hàm Grep Burp Intruder, định cấu hình tập hợp chuỗi phù hợp để xử lý số thông báo lỗi phổ biến phản hồi Ví dụ: error exception illegal invalid fail stack access directory file not found varchar ODBC SQL SELECT 111111 Chuỗi 111111 dùng để kiểm tra script injection thành công Cũng chọn tùy chọn Payload Grep để gắn cờ response có chứa payload, chứng minh XSS tiềm ẩn lỗ hổng header injection Thiết lập máy chủ web netcat listener máy chủ lưu trữ để giám sát kết nối nhận từ máy chủ công bao gồm tệp từ xa thành công Bắt đầu công Sau hồn tất q trình, kiểm tra kết để xác định bất thường – dấu hiệu lỗ hổng Kiểm tra HTTP status code, độ dài phản hồi, thời gian phản hồi, xuất biểu thức thiết lập xuất tải trọng Click vào tiêu đề cột bảng kết để xếp kết theo giá trị cột (và nhấn Shift-click để xếp ngược lại kết quả) Điều cho phép xác định bất thường để từ xác định lỗ hổng Đối với lỗ hổng tiềm ẩn từ kết fuzzing, tham khảo phần sau phương pháp Chúng mô tả bước chi tiết thực liên quan đến loại vấn đề để xác minh tồn lỗ hổng khai thác thành công Sau cấu hình Burp Intruder để thực fuzzing request, lặp lại kiểm tra tương tự request khác ứng dụng Thể thực đồng thời nhiều công lúc kiểm tra thủ công kết thúc kiểm tra tự động Nếu hoạt động lập đồ chức ứng dụng phát kênh băng tần, đầu vào người dùng đưa vào trình xử lý ứng dụng, cần thực kiểm tra đầu vào Gửi liệu tạo thủ công khác để kích hoạt lỗ hổng phổ biến xử lý ứng dụng web Tùy thuộc vào chất kênh đầu vào, cần tạo tập lệnh tùy chỉnh cách khai thác khác cho mục đích Ngồi việc fuzzing, có quyền truy cập vào ứng dụng scanner, bạn nên chạy ứng dụng đích để tạo sở so sánh với lỗi phát 7.2 SQL Injection Nếu chuỗi công SQL liệt kê phần 7.1 xuất phản hồi bất thường, kiểm tra cách xử lý ứng dụng tham số liên quan thủ công để xác định xem lỗ hổng SQL injection có tồn hay khơng Nếu ứng dụng trả thông báo lỗi sở liệu, điều tra ý nghĩa chúng Sử dụng phần “Tham chiếu cú pháp lỗi SQL” Chương để hiểu thông báo lỗi số tảng sở liệu phổ biến Nếu việc gửi dấu ngoặc kép tham số gây lỗi hành vi bất thường khác, gửi hai dấu ngoặc kép Nếu đầu vào làm cho lỗi hành vi bất thường biến mất, ứng dụng dễ bị công SQL injection Hãy thử sử dụng hàm nối chuỗi SQL phổ biến để tạo chuỗi tương đương với số đầu vào lành tính Nếu điều gây phản ứng giống đầu vào lành tính ban đầu, ứng dụng dễ bị cơng Ví dụ: đầu vào ban đầu biểu thức FOO, bạn thực kiểm tra cách sử dụng mục sau (trong ví dụ thứ ba, lưu ý khoảng cách hai dấu ngoặc kép): ‘||’FOO ‘+’FOO ‘ ‘FOO Như lần, cần đảm bảo sử dụng URL encode cho ký tự có ý nghĩa đặc biệt request Nếu đầu vào ban đầu số, thử sử dụng biểu thức toán học tương đương với giá trị ban đầu Ví dụ: giá trị ban đầu 2, thử gửi + 3–1 Nếu ứng dụng phản hồi theo cách tương tự, dễ bị công, đặc biệt giá trị biểu thức số có ảnh hưởng có hệ thống đến hành vi ứng dụng Nếu kiểm tra trước thành cơng, bạn đảm bảo thêm lỗ hổng SQL injection có liên quan cách sử dụng biểu thức toán học SQL cụ thể để xây dựng giá trị cụ thể Nếu logic ứng dụng thao tác cách có hệ thống theo cách này, gần chắn dễ bị cơng SQL injection Ví dụ: hai mục sau tương đương với số 2: 67-ASCII(‘A’) 51-ASCII(1) Nếu hai trường hợp fuzzing sử dụng lệnh waitfor dẫn đến thời gian trễ bất thường trước ứng dụng phản hồi, dấu hiệu cho thấy loại sở liệu MS-SQL ứng dụng dễ bị SQL injection Lặp lại kiểm tra theo cách thủ công, định giá trị khác tham số chờ đợi xác định xem thời gian cần thiết để phản hồi có thay đổi cách có hệ thống với giá trị hay không Lưu ý payload chèn vào nhiều truy vấn SQL, đó, độ trễ thời gian quan sát bội số cố định giá trị cụ thể Nếu thực ứng dụng dễ bị công SQLi, kiểm tra kiểu công khả thi thực mục tiêu Xem chương để biết bước chi tiết: - Sửa đổi điều kiện mệnh đề WHERE để thay đổi logic ứng dụng (ví dụ: cách chèn = 1-để bỏ qua đăng nhập) - Sử dụng toán tử UNION để đưa vào truy vấn SELECT tùy ý kết hợp kết với kết truy vấn ban đầu ứng dụng - Đối với CSDL cần sử dụng cú pháp dành riêng cho CSDL - Nếu loại sở liệu MS-SQL ứng dụng trả thông báo lỗi ODBC phản hồi nó, tận dụng thơng báo để liệt kê cấu trúc sở liệu truy xuất liệu tùy ý - Nếu bạn tìm cách trực tiếp truy xuất kết truy vấn, sử dụng kỹ thuật nâng cao sau để trích o o o xuất liệu: Truy xuất liệu chuỗi dạng số, lần byte Sử dụng kênh ngồi băng tần Nếu bạn gây phản hồi ứng dụng khác dựa điều kiện tùy ý, sử dụng Absinthe để trích xuất liệu tùy ý bit o Nếu bạn kích hoạt độ trễ thời gian dựa điều kiện tùy ý, khai thác điều kiện để truy xuất liệu bit - Nếu ứng dụng chặn ký tự biểu thức định mà bạn yêu cầu để thực công cụ thể, thử kỹ thuật bỏ qua khác mô tả Chương để phá vỡ lọc đầu vào - Nếu có thể, leo thang công chống lại sở liệu máy chủ cách tận dụng lỗ hổng chức mạnh mẽ sở liệu 7.3 XSS response injection 7.3.1 Xác định tham số có giá trị sử dụng phản hồi ứng dụng Sắp xếp kết fuzzing cách click vào cột Payload Grep xác định kết phù hợp với XSS payload liệt kê phần trước Đây trường hợp mà payload trả phản hồi ứng dụng Đối với mối trường hợp trên, kiểm tra lại phản hồi ứng dụng để xác định vị trí tham số Nếu tham số xuất nội dung phản hồi, thực kiểm tra lỗ hổng XSS Còn liệu đầu vào xuất HTTP header, kiểm tra HTTP header injection 10 11 12 13 7.3.2 Kiểm tra Reflected XSS 7.3.3 Kiểm tra HTTP Header Injection 7.3.4 Kiểm tra Open Redirection 7.3.5 Kiểm tra Stored Attack 7.4 OS Command injection 7.5 Path traveral 7.6 Script injection 7.7 File inclusion Xác định tất tham số Kiểm tra vấn đề với chức cụ thể Kiểm tra vấn đề chia sẻ hosting Kiểm tra web server Kiểm tra khác Kiểm tra rị rỉ thơng tin ... etcpasswd oot.ini Script Injection ;echo 11 111 1 echo 11 111 1 response.write 11 111 1 :response.write 11 111 1 File Inclusion http:/// http://