Kiểm thử Deep Dive

Deep dive là mức cao nhất trong bốn cường độ kiểm thử của một lượt kiểm thử, chế độ tìm ra những lỗ hổng mà một lượt kiểm tra đơn lẻ bỏ sót: một người dùng truy cập được dữ liệu của tenant khác, một bước thanh toán có thể bị bỏ qua, hoặc hai điểm yếu nhỏ kết hợp thành một vụ chiếm quyền kiểm soát. Chế độ này tiếp tục điều tra sau những phát hiện đầu tiên, qua nhiều lượt kiểm tra trong một lượt chạy, và tốn nhiều thời gian và credit nhất.

​

Chọn đúng cường độ

Bạn chọn cường độ mỗi khi bắt đầu một lượt kiểm thử, và Deep dive là mức cao nhất. Deep dive chạy toàn bộ các bài kiểm thử của mức Full, sau đó kiểm tra thêm nhiều lượt nữa, dùng lại bằng chứng của các lượt trước để lần theo những lỗ hổng nhiều bước nối tiếp nhau. Đây là mức tốn thời gian và credit nhất, nên chỉ chạy trên staging với dữ liệu có thể bỏ đi. Ba mức còn lại được so sánh trong bảng cường độ. Chọn Deep dive khi:

• Ứng dụng của bạn có nhiều user role hoặc tenant và bạn cần biết liệu một bên có truy cập được dữ liệu của bên kia không.
• Workflow gồm nhiều bước (thanh toán, phê duyệt, lời mời) mà thứ tự và trạng thái đều quan trọng.
• Lượt chạy Full đã tìm thấy dấu hiệu của một lỗ hổng nhiều bước lớn hơn.
• Bản phát hành đã thay đổi logic xác thực, phân quyền hoặc thanh toán.

Để xem xét ban đầu một ứng dụng mới, hãy bắt đầu với lượt chạy Safe giới hạn trong các include path, rồi Aggressive. Chuyển sang Deep dive khi phạm vi và thông tin đăng nhập thử nghiệm đã được xác nhận.

​

Điều kiện tiên quyết

• Ứng dụng đã đăng ký trong Cyber với tên miền đã xác minh. Xem Chạy kiểm thử bảo mật.
• Vai trò Admin hoặc Developer của workspace. Cả hai vai trò đều có thể khởi chạy mọi cường độ, kể cả Deep dive. Không có cài đặt riêng chỉ dành cho Admin hay bước Approvals nào cho lượt chạy phá hủy: hộp thoại xác nhận là lớp chặn bổ sung duy nhất. Xem Vai trò.
• Đủ credit cho một lượt chạy dài. Nếu ứng dụng có các lượt chạy trước, hãy mở một lượt: activity feed của lượt chạy hiển thị credit mà mỗi lượt kiểm tra đã hoàn tất sử dụng. Nếu chưa có mốc tham chiếu, hãy đặt giới hạn credit cho lượt Deep dive đầu tiên. Xem Mức sử dụng.
• WAF, IDS và đội on-call của bạn biết lượt chạy sắp diễn ra, và bạn có sự chấp thuận để kiểm thử mọi tài sản không do bạn tự host. Xem Trước lượt chạy đầu tiên để biết về nguồn lưu lượng, mục tiêu riêng tư và giới hạn tốc độ.

​

Chuẩn bị ứng dụng

Deep dive chỉ kiểm thử được những gì truy cập được. Đầu vào nào bạn bỏ qua thì khu vực đó không được kiểm thử, và lượt chạy ghi nhận chúng là giới hạn, không phải là không có lỗi. Thông tin đăng nhập và repository bạn thêm từ hộp thoại chạy được lưu vào ứng dụng, giống như thêm trong Settings. Thông tin đăng nhập đã lưu không chứng minh được việc kiểm thử sau đăng nhập: mật khẩu được lưu mà không đăng nhập thử, và chỉ được thử lần đầu khi lượt chạy bắt đầu. Đăng nhập thất bại sẽ kết thúc lượt chạy với Failed. Hãy kiểm tra phần giới hạn trong báo cáo trước khi coi các khu vực được bảo vệ là đã được kiểm thử.

​

Bắt đầu lượt chạy Deep dive

​

Dừng lượt chạy

Mở lượt chạy từ tab Runs của ứng dụng, nhấn Stop run, rồi nhấn Stop run lần nữa trong hộp thoại Stop this run?. Lượt chạy bị hủy và không thể tiếp tục. Các phát hiện thu được đến lúc đó vẫn được giữ. Các yêu cầu đã gửi tới ứng dụng của bạn không được hoàn tác, nên hãy kiểm tra dữ liệu thử nghiệm sau đó. Nếu không ai dừng, lượt chạy kết thúc khi CloudThinker không còn việc hữu ích để làm, đạt đến một giới hạn, hoặc sau ba giờ.

​

Lên lịch Deep dive

Nhấn Schedule… thay vì chạy ngay, đặt chu kỳ lặp lại và xác nhận Schedule Deep dive. Lượt chạy theo lịch không thể có giới hạn credit. Cách kiểm soát chi tiêu duy nhất cho chúng là giới hạn credit hằng tháng của workspace. Lượt chạy theo lịch cũng chỉ đăng nhập bằng người dùng thử nghiệm dùng Long-lived token. Với các phương thức đăng nhập khác, Deep dive theo lịch không đăng nhập bằng người dùng thử nghiệm của bạn, nên không kiểm thử được gì sau đăng nhập (xem Thêm người dùng thử nghiệm). Mỗi lần khởi chạy và dừng đều được ghi lại trong Audit logs thuộc danh mục Cyber, để bạn biết ai đã bắt đầu một lượt chạy phá hủy.

​

Cách giới hạn credit hoạt động

Giới hạn credit là điểm dừng mềm cho một lượt chạy Deep dive thủ công, không phải mức trần chi tiêu cứng. Giá trị hợp lệ là số nguyên từ 1 đến 1.000.000.000. Trong khi lượt chạy diễn ra, bảng Credit usage hiển thị mức dùng theo phần trăm giới hạn của bạn, và chuyển sang Writing your report khi kiểm thử dừng.

​

Điều gì xảy ra trong lượt chạy

1. CloudThinker lập bản đồ ứng dụng và kiểm thử giống như ở mức Full, trong phạm vi bạn đã đặt.
2. Cuối mỗi lượt kiểm tra, CloudThinker xem xét các phát hiện đã lưu, mức bao phủ và thông tin đăng nhập, rồi chọn câu hỏi tiếp theo đáng kiểm thử, chẳng hạn “người dùng ở tenant A có mở được hóa đơn của tenant B không?”
3. Mỗi lượt kiểm tra mới giữ lại bằng chứng và ghi chú từ các lượt trước.
4. Lượt chạy kết thúc khi CloudThinker không còn tìm thấy việc hữu ích hoặc đạt đến một giới hạn. Sau đó CloudThinker viết báo cáo liệt kê những gì không kiểm thử được.

Thời gian dài không có phát hiện mới là chuyện bình thường. Lượt kiểm tra có thể loại trừ một lỗ hổng nghi ngờ mà không tạo ra phát hiện nào.

​

Đọc kết quả

Mở lượt chạy từ tab Runs của ứng dụng để xem dòng thời gian, phát hiện và báo cáo. Hãy đọc kết hợp ba phần sau:

• Phát hiện: mỗi phát hiện có Proof flow, bằng chứng yêu cầu và phản hồi, tác động và cách khắc phục. Phân loại chúng trong Phát hiện.
• Đăng nhập: báo cáo nêu tên các khu vực nằm sau một lần đăng nhập thất bại. Những khu vực đó chưa được kiểm thử.
• Giới hạn trong báo cáo: các đường dẫn bị chặn, quyền truy cập còn thiếu và các bước kiểm tra chưa hoàn tất.

Lượt chạy không có phát hiện nào không có nghĩa là ứng dụng an toàn. Kết quả đó chỉ có nghĩa là CloudThinker không tìm thấy gì có thể chứng minh trong phạm vi và quyền truy cập bạn đã cấp.

​

Khắc phục sự cố

Để xem mọi vấn đề Cyber ở một nơi, xem Khắc phục sự cố Cyber.

​

Bước tiếp theo