Việc liệt kê ứng dụng và bề mặt tấn công của nó là tiền đề quan trọng trước khi tiến hành bất kỳ thử nghiệm kỹ lưỡng nào, vì nó cho phép người thử nghiệm xác định các khu vực có thể có điểm yếu. Phần này nhằm giúp xác định và vạch ra các khu vực trong ứng dụng cần được điều tra sau khi hoàn thành việc điều tra và lập bản đồ.
Mục tiêu phương pháp này
Xác định các điểm nhập và điểm có thể có thông qua phân tích yêu cầu và phản hồi.
Làm thế nào để thực hiện
Trước khi bất kỳ thử nghiệm nào bắt đầu, người thử nghiệm phải luôn hiểu rõ về ứng dụng cũng như cách người dùng và trình duyệt giao tiếp với nó. Khi người kiểm tra lướt qua ứng dụng, họ nên chú ý đến tất cả các yêu cầu HTTP cũng như mọi trường tham số và biểu mẫu được chuyển đến ứng dụng. Họ cần đặc biệt chú ý đến thời điểm các yêu cầu GET được sử dụng và khi nào các yêu cầu POST được sử dụng để truyền các tham số cho ứng dụng. Ngoài ra, họ cũng cần chú ý đến thời điểm sử dụng các phương pháp khác cho dịch vụ RESTful.
Các bài viết liên quan:
Lưu ý rằng để xem các tham số được gửi trong nội dung yêu cầu, chẳng hạn như yêu cầu ĐĂNG, người thử nghiệm có thể muốn sử dụng một công cụ như proxy chặn (Xem công cụ). Trong yêu cầu ĐĂNG, người thử nghiệm cũng cần lưu ý đặc biệt về bất kỳ trường biểu mẫu ẩn nào đang được chuyển đến ứng dụng, vì những trường này thường chứa thông tin nhạy cảm, chẳng hạn như thông tin trạng thái, số lượng mặt hàng, giá của mặt hàng mà nhà phát triển không bao giờ dành cho bất kỳ ai để xem hoặc thay đổi.
Theo kinh nghiệm của tác giả, việc sử dụng proxy chặn và bảng tính cho giai đoạn thử nghiệm này rất hữu ích. Proxy sẽ theo dõi mọi yêu cầu và phản hồi giữa người thử nghiệm và ứng dụng khi họ khám phá nó. Ngoài ra, tại thời điểm này, người kiểm tra thường bẫy mọi yêu cầu và phản hồi để họ có thể thấy chính xác mọi tiêu đề, tham số, v.v. đang được chuyển đến ứng dụng và những gì đang được trả về. Điều này đôi khi khá tẻ nhạt, đặc biệt là trên các trang web tương tác lớn (hãy nghĩ đến một ứng dụng ngân hàng). Tuy nhiên, kinh nghiệm sẽ chỉ ra những gì cần tìm và giai đoạn này có thể giảm đi đáng kể.
Khi người thử nghiệm lướt qua ứng dụng, họ nên ghi lại bất kỳ thông số thú vị nào trong URL, tiêu đề tùy chỉnh hoặc nội dung của các yêu cầu / phản hồi và lưu chúng vào bảng tính. Bảng tính phải bao gồm trang được yêu cầu (có thể tốt nếu thêm số yêu cầu từ proxy, để tham khảo trong tương lai), các tham số thú vị, loại yêu cầu (GET, POST, v.v.), nếu quyền truy cập được xác thực / chưa xác thực, nếu TLS được sử dụng, nếu nó là một phần của quy trình nhiều bước, nếu WebSockers được sử dụng và bất kỳ ghi chú liên quan nào khác. Sau khi đã vạch ra mọi khu vực của ứng dụng, họ có thể xem qua ứng dụng và kiểm tra từng khu vực mà họ đã xác định và ghi chú lại những gì hiệu quả và những gì không hiệu quả. Phần còn lại của hướng dẫn này sẽ xác định cách kiểm tra từng lĩnh vực quan tâm, nhưng phần này phải được thực hiện trước khi bất kỳ thử nghiệm thực tế nào có thể bắt đầu.
Dưới đây là một số điểm quan tâm cho tất cả các yêu cầu và phản hồi. Trong phần yêu cầu, hãy tập trung vào các phương thức GET và POST, vì chúng xuất hiện phần lớn các yêu cầu. Lưu ý rằng các phương pháp khác, chẳng hạn như PUT và DELETE, có thể được sử dụng. Thông thường, những yêu cầu hiếm hơn này, nếu được cho phép, có thể làm lộ ra các lỗ hổng. Có một phần đặc biệt trong hướng dẫn này dành riêng cho việc kiểm tra các phương thức HTTP này.
Request
Xác định nơi GET được sử dụng và nơi POST được sử dụng.
Xác định tất cả các tham số được sử dụng trong một yêu cầu POST (những tham số này nằm trong phần nội dung của yêu cầu).
Trong yêu cầu ĐĂNG, hãy đặc biệt chú ý đến bất kỳ thông số ẩn nào. Khi một ĐĂNG được gửi, tất cả các trường biểu mẫu (bao gồm cả các tham số ẩn) sẽ được gửi trong phần nội dung của thông báo HTTP tới ứng dụng. Chúng thường không được nhìn thấy trừ khi sử dụng proxy hoặc chế độ xem mã nguồn HTML. Ngoài ra, trang tiếp theo được hiển thị, dữ liệu và cấp độ truy cập có thể khác nhau tùy thuộc vào giá trị của (các) thông số ẩn.
Xác định tất cả các tham số được sử dụng trong yêu cầu GET (tức là URL), cụ thể là chuỗi truy vấn (thường sau dấu?).
Xác định tất cả các tham số của chuỗi truy vấn. Chúng thường ở định dạng cặp, chẳng hạn như foo = bar. Cũng lưu ý rằng nhiều tham số có thể nằm trong một chuỗi truy vấn, chẳng hạn như được phân tách bằng dấu &, \ ~,:, hoặc bất kỳ ký tự hoặc mã hóa đặc biệt nào khác.
Một lưu ý đặc biệt khi nói đến việc xác định nhiều tham số trong một chuỗi hoặc trong một yêu cầu POST là một số hoặc tất cả các tham số sẽ cần thiết để thực hiện các cuộc tấn công. Người thử nghiệm cần xác định tất cả các tham số (ngay cả khi được mã hóa hoặc mã hóa) và xác định những tham số nào được ứng dụng xử lý. Các phần sau của hướng dẫn sẽ xác định cách kiểm tra các thông số này. Tại thời điểm này, chỉ cần đảm bảo rằng từng người trong số họ đã được xác định.
Cũng chú ý đến bất kỳ tiêu đề loại tùy chỉnh hoặc bổ sung nào thường không được nhìn thấy (chẳng hạn như debug: false).
Response
Xác định vị trí đặt cookie mới (tiêu đề Set-Cookie), modified, hoặc thêm vào.
Xác định nơi có bất kỳ chuyển hướng nào (mã trạng thái HTTP 3xx), 400 mã trạng thái, cụ thể là 403 Bị cấm và 500 lỗi máy chủ nội bộ trong các phản hồi bình thường (tức là các yêu cầu chưa được sửa đổi).
Cũng lưu ý nơi bất kỳ tiêu đề thú vị nào được sử dụng. Ví dụ: Máy chủ: BIG-IP cho biết rằng trang web được cân bằng tải. Do đó, nếu một trang web được cân bằng tải và một máy chủ được định cấu hình không chính xác, thì người kiểm tra có thể phải thực hiện nhiều yêu cầu để truy cập vào máy chủ dễ bị tấn công, tùy thuộc vào loại cân bằng tải được sử dụng.
Blackbox testing
Kiểm tra điểm đầu vào ứng dụng
Sau đây là hai ví dụ về cách kiểm tra điểm đầu vào của đơn đăng ký.
ví dụ 1
Ví dụ này cho thấy một yêu cầu GET sẽ mua một mặt hàng từ một ứng dụng mua sắm trực tuyến.
Ở đây, người kiểm tra sẽ lưu ý tất cả các tham số của yêu cầu như CUSTOMERID, ITEM, PRICE, IP và Cookie (có thể chỉ là các tham số được mã hóa hoặc được sử dụng cho trạng thái phiên).
Ví dụ 2
Ví dụ này cho thấy một yêu cầu ĐĂNG sẽ đăng nhập bạn vào một ứng dụng.
Trong ví dụ này, người kiểm tra sẽ lưu ý tất cả các tham số như trước đây, tuy nhiên, phần lớn các tham số được chuyển vào phần nội dung của yêu cầu chứ không phải trong URL. Ngoài ra, hãy lưu ý rằng có một tiêu đề HTTP tùy chỉnh (CustomCookie) đang được sử dụng.
Thử nghiệm graybox
Kiểm tra các điểm đầu vào của ứng dụng thông qua phương pháp hộp xám sẽ bao gồm mọi thứ đã được xác định ở trên với một lần bổ sung. Trong trường hợp có các nguồn bên ngoài mà từ đó ứng dụng nhận dữ liệu và xử lý nó (chẳng hạn như bẫy SNMP, thông báo nhật ký hệ thống, thông báo SMTP hoặc SOAP từ các máy chủ khác), cuộc họp với nhà phát triển ứng dụng có thể xác định bất kỳ chức năng nào sẽ chấp nhận hoặc mong đợi người dùng đầu vào và cách chúng được định dạng. Ví dụ: nhà phát triển có thể giúp hiểu cách tạo một yêu cầu SOAP chính xác mà ứng dụng sẽ chấp nhận và nơi dịch vụ web cư trú (nếu dịch vụ web hoặc bất kỳ chức năng nào khác chưa được xác định trong quá trình thử nghiệm hộp đen).
OWASP Attack Surface Detector
OWASP Attack Surface Detector (ASD) điều tra mã nguồn và phát hiện ra các điểm cuối của ứng dụng web, các tham số mà các điểm cuối này chấp nhận và kiểu dữ liệu của các tham số đó. Điều này bao gồm các điểm cuối không được liên kết mà trình thu thập thông tin sẽ không thể tìm thấy hoặc các tham số tùy chọn hoàn toàn không được sử dụng trong mã phía máy khách. Nó cũng có khả năng tính toán những thay đổi về bề mặt tấn công giữa hai phiên bản của một ứng dụng.
Công cụ phát hiện bề mặt tấn công có sẵn dưới dạng một plugin cho cả ZAP và Burp Suite, đồng thời cũng có sẵn một công cụ dòng lệnh. Công cụ dòng lệnh xuất bề mặt tấn công dưới dạng đầu ra JSON, sau đó có thể được sử dụng bởi plugin ZAP và Burp Suite. Điều này rất hữu ích cho các trường hợp mã nguồn không được cung cấp trực tiếp cho người kiểm tra thâm nhập. Ví dụ: người kiểm tra thâm nhập có thể lấy tệp đầu ra json từ một khách hàng không muốn tự cung cấp mã nguồn.
Cách sử dụng
Tệp jar CLI có sẵn để tải xuống từ https://github.com/secdec/attack-surface-detector-cli/releases.
Bạn có thể chạy lệnh sau cho ASD để xác định điểm cuối từ mã nguồn của ứng dụng web đích.
java -jar attack-surface-detector-cli-1.3.5.jar <source-code-path> [flags]
Bạn cũng có thể tạo tệp đầu ra JSON bằng cách sử dụng cờ -json, có thể được plugin này sử dụng cho cả ZAP và Burp Suite.
