Giải thích về Tấn công Logic Nghiệp vụ

Kẻ tấn công không phải lúc nào cũng phá vỡ mã nguồn của bạn để lấy tiền.

Nhiều nhà phát triển dành hàng tháng trời để bảo mật API và mã hóa. Họ tập trung vào việc ngăn chặn SQL injection hoặc XSS. Sau đó, một kẻ tấn công có thể lấy trộm tiền mà không cần phá vỡ bất kỳ biện pháp kiểm soát an ninh nào.

Đây chính là một cuộc tấn công logic nghiệp vụ.

Ứng dụng hoạt động chính xác như thiết kế. Kẻ tấn công chỉ đơn giản là sử dụng chính các quy tắc của bạn để chống lại bạn.

Hãy nghĩ về một két sắt ngân hàng. Hầu hết các bài kiểm tra bảo mật đều kiểm tra xem cánh cửa có chắc chắn hay không. Kiểm thử logic nghiệp vụ lại đặt ra một câu hỏi khác: Chuyện gì sẽ xảy ra nếu ai đó thuyết phục được bảo vệ mở cửa cho họ?

Két sắt vẫn hoạt động. Quy trình đã thất bại.

Dưới đây là ba cách kẻ tấn công lạm dụng logic ngân hàng:

  1. Vượt qua thời gian chờ Các ngân hàng thường yêu cầu chờ 24 giờ sau khi thêm người nhận mới. Điều này nhằm ngăn chặn việc trộm tiền nhanh chóng. Một kẻ tấn công có thể tìm thấy một endpoint API bỏ qua bước kiểm tra này. Chúng vượt qua các hạn chế trên UI và chuyển tiền ngay lập tức.

  2. Phá vỡ hạn mức giao dịch Một ngân hàng có thể đặt hạn mức hàng ngày là 50.000. Nếu mã nguồn chỉ kiểm tra từng giao dịch riêng lẻ, kẻ tấn công có thể thực hiện năm lần chuyển khoản, mỗi lần 49.000. Mỗi giao dịch đều trông có vẻ hợp lệ. Tổng số tiền vượt quá hạn mức, nhưng hệ thống lại bỏ sót điều đó.

  3. Lạm dụng phần thưởng Nhiều ứng dụng tặng tiền hoàn lại (cashback) khi thanh toán hóa đơn. Kẻ tấn công có thể thanh toán một hóa đơn rồi hủy ngay lập tức. Nếu hệ thống không thu hồi phần thưởng, kẻ tấn công sẽ tạo ra một vòng lặp để thu thập tiền hoàn lại vô tận.

Tại sao các trình quét tự động lại bỏ lỡ điều này?

Các trình quét tìm kiếm các lỗ hổng kỹ thuật như mã độc hoặc injection. Một trình quét thấy một giao dịch chuyển tiền thành công và trả về trạng thái 200 OK. Nó nghĩ rằng mọi thứ đều ổn.

Một kiểm thử viên con người sẽ hỏi: Liệu giao dịch này có nên được thực hiện hay không?

Để tìm ra những lỗ hổng này, đừng hỏi liệu một tính năng có thể bị hack hay không. Hãy bắt đầu hỏi liệu một tính năng có thể bị lạm dụng hay không.

Hãy kiểm tra các khu vực sau:

  • Người dùng có thể bỏ qua các bước xác minh không?
  • Người dùng có thể thay đổi quyền sở hữu của một ID không?
  • Các khoảng thời gian chờ có thể bị vượt qua thông qua API không?
  • Các hạn mức được áp dụng trên tổng số tiền hay chỉ trên mỗi lần nhấp chuột?
  • Phần thưởng có thể được kích hoạt nhiều lần không?

Các đội ngũ bảo mật tinh nhuệ không chỉ tạo ra các use case. Họ tạo ra các abuse case.

Thay vì kiểm thử "Người dùng chuyển tiền", hãy kiểm thử "Kẻ tấn công thực hiện 500 lần chuyển khoản nhỏ để vượt qua hạn mức".

Câu hỏi thứ hai mới tìm ra rủi ro thực sự.

Nguồn: https://dev.to/arashad_dodhiya_0e4bdba5a/business-logic-attacks-explained-using-a-banking-app-27hj