Blog 👨‍💻

🔏Business logic vulnerabilities

Server Side Vul

Lỗ hổng Business(kinh doanh) logic là gì?

Lỗ hổng Business logic là những lỗ hổng trong thiết kế và triển khai một ứng dụng cho phép kẻ tấn công gây ra hành vi ngoài ý muốn. Điều này có khả năng cho phép những kẻ tấn công thao túng chức năng hợp pháp để đạt được mục đích xấu. Những sai sót này nói chung là kết quả của việc không lường trước được các trạng thái ứng dụng bất thường có thể xảy ra và do đó, không xử lý chúng một cách an toàn.

Trong một vài ngữ cảnh, thuật ngữ "logic kinh doanh" chỉ đơn giản là đề cập đến tập hợp các quy tắc xác định cách ứng dụng hoạt động. Vì các quy tắc này không phải lúc nào cũng liên quan trực tiếp đến một doanh nghiệp, các lỗ hổng liên quan còn được gọi là "lỗ hổng logic ứng dụng" hoặc đơn giản là "lỗ hổng logic".

Các quy tắc logic có thể cho phép những kẻ tấn công phá vỡ các quy tắc này. Ví dụ: họ có thể hoàn thành một giao dịch mà không cần thông qua quy trình mua hàng dự kiến.

Các lỗ hổng Business logic phát sinh như nào

Các lỗ hổng logic nghiệp vụ thường phát sinh do nhóm thiết kế và phát triển đưa ra các giả định sai lầm về cách người dùng sẽ tương tác với ứng dụng. Những giả định không tốt này có thể dẫn đến việc xác nhận không đầy đủ thông tin đầu vào của người dùng. Ví dụ: nếu các nhà phát triển giả định rằng người dùng sẽ truyền dữ liệu độc quyền qua trình duyệt web, thì ứng dụng có thể dựa hoàn toàn vào các điều khiển phía máy khách yếu để xác thực đầu vào. Những thứ này dễ dàng bị kẻ tấn công bỏ qua bằng cách sử dụng proxy chặn.

Cuối cùng, điều này có nghĩa là khi kẻ tấn công đi chệch khỏi hành vi người dùng mong đợi, ứng dụng không thực hiện các bước thích hợp để ngăn chặn điều này và sau đó, không xử lý tình huống một cách an toàn.

Ảnh hưởng của lỗ hổng Business logic này như nào

Về cơ bản, ảnh hưởng của bất kỳ lỗ hổng logic nào phụ thuộc vào chức năng mà nó liên quan đến nhưng nó nghiêm trọng. Ví dụ: nếu lỗ hổng nằm trong cơ chế xác thực, thì điều này có thể ảnh hưởng nghiêm trọng đến bảo mật tổng thể của bạn. Những kẻ tấn công có thể khai thác điều này để leo thang đặc quyền hoặc bỏ qua hoàn toàn xác thực, giành quyền truy cập vào dữ liệu và chức năng nhạy cảm. Điều này cũng cho thấy bề mặt tấn công gia tăng cho các hoạt động khai thác khác.

Logic sai lầm trong các giao dịch tài chính rõ ràng có thể dẫn đến tổn thất lớn cho doanh nghiệp thông qua các quỹ bị đánh cắp, gian lận...

Một số ví dụ về lỗ hổng Business logic

Các lỗ hổng Bussiness logic tương đối cụ thể đối với bối cảnh mà chúng xảy ra. Tuy nhiên, mặc dù các trường hợp lỗi logic riêng lẻ rất khác nhau, nhưng chúng có thể chia sẻ nhiều chủ đề chung. Đặc biệt, chúng có thể được nhóm lại một cách lỏng lẻo dựa trên những sai lầm ban đầu đã tạo ra lỗ hổng bảo mật ngay từ đầu.

Excessive trust in client-side controls

Cơ bản nhất là là tin rằng người dùng sẽ chỉ tương tác với ứng dụng thông qua giao diện web được cũng cấp. Tuy nhiên, kẻ tấn công có thể chỉ cần sử dụng các công cụ như Burp Proxy để giả mạo dữ liệu sau khi dữ liệu được gửi bởi trình duyệt nhưng trước khi nó được chuyển vào logic phía máy chủ. Điều này có hiệu quả làm cho các điều khiển phía máy khách trở nên vô dụng.

Việc chấp nhận dữ liệu theo mệnh giá, mà không thực hiện kiểm tra tính toàn vẹn thích hợp và xác thực phía máy chủ, có thể cho phép kẻ tấn công thực hiện tất cả các loại thiệt hại với nỗ lực tương đối nhỏ. Chính xác những gì họ có thể đạt được phụ thuộc vào chức năng và những gì nó đang làm với dữ liệu có thể kiểm soát. Trong bối cảnh phù hợp, loại lỗ hổng này có thể gây ra hậu quả nghiêm trọng cho cả chức năng liên quan đến kinh doanh và bảo mật của chính trang web.

Failing to handle unconventional input

Không xử lý được thông tin đầu vào khác thường là những cái mà kẻ tấn công có thể thay ddooori dữ liệu trong input. Ví dụ, ứng dụng có thể được thiết kế để chấp nhận các giá trị tùy ý của một kiểu dữ liệu nhất định, nhưng logic xác định liệu giá trị này có được chấp nhận hay không theo quan điểm của doanh nghiệp. Nhiều ứng dụng kết hợp các giới hạn số vào logic của chúng. Điều này có thể bao gồm các giới hạn được thiết kế để quản lý hàng tồn kho, áp dụng các hạn chế về ngân sách, các giai đoạn kích hoạt của chuỗi cung ứng, v.v.

Hãy lấy ví dụ đơn giản về một cửa hàng trực tuyến. Khi đặt mua sản phẩm, người dùng thường chỉ định số lượng mà họ muốn đặt. Mặc dù về mặt lý thuyết, bất kỳ số nguyên nào cũng là đầu vào hợp lệ, ví dụ như logic nghiệp vụ có thể ngăn người dùng đặt hàng nhiều đơn vị hơn số lượng hiện có trong kho.

Hoặc ví dụ: kiểu dữ liệu số có thể chấp nhận các giá trị âm. Tùy thuộc vào chức năng liên quan, logic nghiệp vụ có thể không cho phép điều này. Tuy nhiên, nếu ứng dụng không thực hiện xác thực đầy đủ phía máy chủ và từ chối đầu vào này, kẻ tấn công có thể chuyển giá trị âm và gây ra hành vi không mong muốn.

Cân nhắc chuyển tiền giữa hai tài khoản ngân hàng. Chức năng này gần như chắc chắn sẽ kiểm tra xem người gửi có đủ tiền hay không trước khi hoàn tất chuyển tiền:

$transferAmount = $_POST['amount'];
$currentBalance = $user->getBalance();

if ($transferAmount <= $currentBalance) {
    // hoan thanh chuyen tien
} else {
    // Block chuyen tien: khong du tien
}

Nhưng nếu logic không đủ ngăn người dùng cung cấp giá trị âm trong amount tham số, thì điều này có thể bị kẻ tấn công lợi dụng để bỏ qua việc kiểm tra số dư và chuyển tiền theo hướng "sai". Nếu kẻ tấn công gửi - $ 1000 vào tài khoản của nạn nhân, điều này có thể dẫn đến việc chúng nhận được $ 1000 từ nạn nhân. Logic sẽ luôn đánh giá rằng -1000 nhỏ hơn số dư hiện tại và chấp thuận chuyển khoản.

Khi kiểm tra một ứng dụng, bạn nên sử dụng các công cụ như Burp Proxy và Repeater để thử gửi các giá trị khác thường. Đặc biệt, hãy thử đầu vào trong các phạm vi mà người dùng hợp pháp khó có thể nhập. Điều này bao gồm các đầu vào số đặc biệt cao hoặc đặc biệt thấp và các chuỗi dài bất thường cho các trường dựa trên văn bản. Bạn thậm chí có thể thử các kiểu dữ liệu không mong muốn. Bằng cách quan sát phản hồi của ứng dụng, bạn nên thử và trả lời các câu hỏi sau:

  • Có bất kỳ giới hạn nào được áp đặt cho dữ liệu không?

  • Điều gì xảy ra khi bạn đạt đến những giới hạn đó?

  • Có bất kỳ chuyển đổi hoặc chuẩn hóa nào đang được thực hiện trên đầu vào của bạn không?

Note: Tràn giá trị số nguyên

Note: vì giới hạn độ dài 255 ký tự nên khi đọc hộp thư người ta sẽ nhầm tưởng là người dùng có đặc quyền cao đang đăng ký nên người dùng được cấp đặc quyền cao.

Making flawed assumptions about user behavior

Một trong những nguyên nhân gốc rễ phổ biến nhất của các lỗ hổng logic là đưa ra các giả định sai lầm về hành vi của người dùng. Điều này có thể dẫn đến một loạt các vấn đề mà các nhà phát triển đã không xem xét các tình huống nguy hiểm tiềm ẩn vi phạm các giả định này. Trong phần này, chúng tôi sẽ cung cấp một số ví dụ cảnh báo về các giả định phổ biến cần tránh và chứng minh cách chúng có thể dẫn đến các sai sót logic nguy hiểm.

Trusted users won't always remain trustworthy

Các ứng dụng có thể tỏ ra an toàn vì chúng thực hiện các biện pháp có vẻ mạnh mẽ để thực thi các quy tắc kinh doanh. Thật không may, một số ứng dụng mắc sai lầm khi cho rằng ban đầu đã vượt qua các kiểm soát nghiêm ngặt này, người dùng và dữ liệu của họ có thể được tin cậy vô thời hạn. Điều này có thể dẫn đến việc thực thi tương đối lỏng lẻo các kiểm soát tương tự kể từ thời điểm đó.

Nếu các quy tắc kinh doanh và các biện pháp bảo mật không được áp dụng nhất quán trong suốt ứng dụng, điều này có thể dẫn đến các lỗ hổng nguy hiểm tiềm ẩn có thể bị kẻ tấn công lợi dụng.

Users won't always supply mandatory input

Một quan niệm sai lầm là người dùng sẽ luôn cung cấp giá trị cho các trường đầu vào bắt buộc. Các trình duyệt có thể ngăn người dùng thông thường gửi biểu mẫu mà không cần đầu vào bắt buộc, nhưng như chúng tôi biết, những kẻ tấn công có thể giả mạo các tham số khi chuyển tiếp. Điều này thậm chí còn mở rộng đến việc loại bỏ các thông số hoàn toàn.

Khi thăm dò lỗi logic, bạn nên thử loại bỏ lần lượt từng tham số và quan sát xem điều này có ảnh hưởng gì đến phản hồi và nên đảm bảo:

  • Chỉ xóa một tham số tại một thời điểm để đảm bảo đạt được tất cả các đường dẫn mã có liên quan.

  • Thử xóa tên của tham số cũng như giá trị. Máy chủ thường sẽ xử lý cả hai trường hợp khác nhau.

  • Thực hiện theo quy trình nhiều giai đoạn cho đến khi hoàn thành. Đôi khi việc giả mạo tham số trong một bước sẽ ảnh hưởng đến một bước khác trong quy trình làm việc.

Điều này áp dụng cho cả URL và POST parameters, nhưng đừng quên kiểm tra cookie. Quá trình đơn giản này có thể tiết lộ một số hành vi ứng dụng kỳ lạ có thể khai thác được.

Users won't always follow the intended sequence

Nhiều giao dịch dựa trên quy trình công việc được xác định trước bao gồm một chuỗi các bước. Giao diện web thường sẽ hướng dẫn người dùng qua quy trình này, đưa họ đến bước tiếp theo của quy trình làm việc mỗi khi họ hoàn thành quy trình hiện tại. Tuy nhiên, những kẻ tấn công sẽ không nhất thiết phải tuân theo trình tự dự kiến ​​này. Không tính đến khả năng này có thể dẫn đến các sai sót nguy hiểm có thể tương đối đơn giản để khai thác.

Ví dụ: nhiều trang web triển khai xác thực hai yếu tố (2FA) yêu cầu người dùng đăng nhập trên một trang trước khi nhập mã xác minh trên một trang riêng biệt. Giả sử rằng người dùng sẽ luôn làm theo quy trình này cho đến khi hoàn thành và do đó, việc không xác minh rằng họ làm vậy, có thể cho phép những kẻ tấn công bỏ qua hoàn toàn bước 2FA.

Domain-specific flaws

Nhiều sai sót logic liên quan đến lĩnh vực kinh doanh cụ thể hoặc chủ đề của một ứng dụng cụ thể. Một ví dụ là tính năng giảm giá trong trang web Thương mại điện tử. Đây là một bề mặt tấn công đáng kể, bởi vì nó cho phép những kẻ tấn công khám phá các lỗ hổng logic cơ bản trong cách áp dụng chiết khấu.

Nói chung, bất kỳ chức năng ứng dụng nào có thể điều chỉnh giá, thanh toán hoặc sửa đổi bất kỳ giá trị dữ liệu nhạy cảm nào dựa trên tương tác của người dùng đều phải được xem xét cẩn thận. Điều quan trọng là phải hiểu các thuật toán mà ứng dụng sử dụng để thực hiện các điều chỉnh này và chúng xảy ra trong trường hợp nào. Một cách tốt để kiểm tra điều này là thao tác các loại chức năng này, cố gắng nhập liệu của người dùng sẽ dẫn đến kết quả không mong muốn.

Providing an encryption oracle

Các tình huống nguy hiểm có thể xảy ra khi đầu vào do người dùng kiểm soát được mã hóa và bản mã kết quả sau đó được cung cấp cho người dùng theo một cách nào đó. Loại đầu vào này đôi khi được gọi là "encryption oracle". Kẻ tấn công có thể sử dụng đầu vào này để mã hóa dữ liệu tùy ý bằng cách sử dụng thuật toán chính xác và khóa không đối xứng.

Điều này trở nên nguy hiểm khi có các đầu vào khác do người dùng kiểm soát trong ứng dụng mong đợi dữ liệu được mã hóa bằng cùng một thuật toán. Trong trường hợp này, kẻ tấn công có thể sử dụng tiên tri mã hóa để tạo đầu vào hợp lệ, được mã hóa và sau đó chuyển nó vào các chức năng nhạy cảm khác.

Cách ngăn chặn lỗ hổng business logic

Tóm lại, chìa khóa để ngăn chặn các lỗ hổng logic nghiệp vụ là:

  • Đảm bảo nhà phát triển và người kiểm tra hiểu miền mà ứng dụng phân phát

  • Tránh đưa ra các giả định ngầm về hành vi của người dùng hoặc hành vi của các phần khác của ứng dụng

Điều quan trọng nữa là đảm bảo rằng cả nhà phát triển và người kiểm tra đều có thể hiểu đầy đủ các giả định này và cách ứng dụng phải phản ứng trong các tình huống khác nhau. Điều này có thể giúp nhóm phát hiện ra các sai sót logic càng sớm càng tốt. Để tạo điều kiện thuận lợi cho việc này, nhóm phát triển nên tuân thủ các phương pháp hay nhất sau đây khi có thể:

  • Duy trì các tài liệu thiết kế và luồng dữ liệu rõ ràng cho tất cả các giao dịch và quy trình làm việc, lưu ý bất kỳ giả định nào được thực hiện ở mỗi giai đoạn.

  • Viết mã càng rõ ràng càng tốt. Nếu khó hiểu điều gì sẽ xảy ra, sẽ khó phát hiện ra bất kỳ sai sót logic nào. Tốt nhất, mã được viết tốt không cần tài liệu để hiểu nó. Trong những trường hợp phức tạp không thể tránh khỏi, việc tạo ra tài liệu rõ ràng là rất quan trọng để đảm bảo rằng các nhà phát triển và người thử nghiệm khác biết những giả định đang được thực hiện và chính xác hành vi mong đợi là gì.

  • Lưu ý bất kỳ tham chiếu nào đến mã khác sử dụng từng thành phần. Hãy suy nghĩ về bất kỳ tác dụng phụ nào của những phụ thuộc này nếu một bên độc hại thao túng chúng theo cách bất thường.

Tổng kết

Cảm ơn các bạn đã đọc bài viết! Bài viết dựa trên tổng quan mình học từ PortSwigger và từ các nguồn khác nên có gì thiếu sốt mong các bạn thông cảm...

PreviousAccess control vulnerabilities and privilege escalationNextOS Command injection

Last updated