Business logic 취약점은 발생하는 상황에 따라 비교적으로 특정하다. 그러나 logic flaws의 사례는 다 다르지만, 많은 공통적인 테마를 공유할 수 있다. 이런 취약점은 처음에 발생하게 된 초기 실수에 따라 그룹화시킬 수 있다.
Logic flaws의 예는 다음과 같다.

• Excessive trust in client-side controls
• Failing to handle unconventional input
• Making flawed assumptions about user behavior
• Domain-specific flaws
• Providing an encryption oracle

Excessive trust in client-side controls

근본적으로 잘못된 가정은 사용자가 제공된 앱 인터페이스를 통해서만 applicaiton과 상호작용을 할 것이라고 가정하는 것이다. 이는 클라이언트측 유효성 검사가 사용자의 악의적인 입력을 하지 못하도록 막을 것이라는 추가 가정으로 이어지기 때문에 특히 위험하다. 공격자는 Burp 프록시와 같은 도구를 사용하여 데이터가 브라우저에서 전송된 후 서버 측 logic으로 전달되기 전에 데이터를 변조할 수 있다. 이렇게 되면 클라이언트쪽 컨트롤이 쓸모 없게 된다.
적절한 무결성 검사 및 서버 측 유효성 검사를 수행하지 않고 그대로 데이터를 받으면 공격자가 비교적 적은 노력으로 모든 종류의 손상을 줄 수 있다. 적절한 상황에서도 이런 종류의 결함은 business 관련 기능과 웹사이트 자체의 보안에 치명적인 결과를 초래할 수 있다.

Failing to handle unconventional input

application logic의 한 가지 목표는 사용자 입력을 business 규칙을 준수하는 값으로 제한하는 것이다. 예를 들어 application은 특정 데이터 유형의 임의의 값을 받아들이도록 설계할 수 있지만, logic은 business 관점에서 이 값이 허용 가능한지 여부를 결정한다. 많은 application은 숫자 제한을 logic에 통합시켰다. 여기에는 재고 관리, 예산 제한 적용, 공급망 단계 트리거 등을 위해 설계된 제한이 포함시킬 수 있다.
온라인 상점의 간단한 예를 들어 본다. 제품을 주문할 때 사용자는 일반적으로 주문하려는 수량을 지정한다. 이론적으로는 모든 정수가 유효한 입력이지만 business logic은 예를 들어 사용자가 현재 재고보다 더 많은 단위를 주문하지 못하게 할 수 있다.
이와 같은 규칙을 구현하려면 개발자는 모든 시나리오를 예상하고 이를 처리하는 방법을 application logic에 통합해야 한다. 즉 주어진 입력을 허용할지 여부와 다양한 조건에 따라 어떻게 반응해야 하는지 application에 알려야 한다. 이런 사례를 처리하기 위한 명시적 logic이 없는 경우 예상치 못한 악용이 발생할 수 있다.
예를 들어 숫자 데이터 유형은 음수 값을 허용할 수 있다. 관련 기능에 따라 business logic이 이를 허용하지 않을 수 있다. 그러나 application이 적절한 서버 측 유효성 검사없이 이 입력을 거부하는 경우 공격자가 어떻게든 음수값을 전달하고 원치 않는 동작을 유도할 수 있다.
두 은행 계좌 간의 자금 이체를 생각해본다. 이 기능은 전송을 완료하기 전에 발신자에게 충분한 자금이 있는지 거의 확실하게 확인한다.

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

if ($transferAmount <= $currentBalance) {
    // Complete the transfer
} else {
    // Block the transfer: insufficient funds
}

그러나 logic이 사용자가 파라미터에 음수 값을 제공하는 것을 방지하지 못하는 경우 공격자는 amount를 악용해서 잔익 확인을 우회하고 “잘못된”방향으로 자금을 이체할 수 있다. 공격자가 피해자의 계정에 -$1000를 보낸 경우 대신 피해자한테 $1000을 받을 수 있다. logic은 -1000이 현재 잔액보다 작은지 평가했고, 이체를 승인했다.
이와 같은 단순한 logic flaws이 올바른 기능에서 발생하면 치명적일 수 있다. 또한 이러한 입력이 웹 인터페이스의 클라이언트측 컨트롤에 의해 차단될 수 있다는 점을 고려할 때 개발과 테스트 중에 놓치기 쉽다.
application을 감사할 때는 Burp 프록시와 리피터 같은 도구를 사용하여 색다른 값을 제출해야 한다. 특히 합법적인 사용자가 입력할 가능성이 없는 범위의 값을 입력으로 시도해야 한다. 여기에는 예외적으로 높거나 매우 낮은 숫자 입력, 텍스트 기반 필드에 대한 비정상적으로 긴 문자열이 포함된다. 예상치 못한 데이터 유형을 시도할 수도 있다. application의 응답을 보고 다음 질문에 답해본다.

• 데이터에 제한이 있는가?
• 이 제한이 한계에 도달하면 어떻게 되는가?
• 입력값에 대해 변환 또는 정규화가 이루어지고 있는가?

이것으로 비정상적인 방식으로 application을 조작할 수 있는 약한 유효성 검사를 찾을 수 있다. 대상 웹 사이트에서 형식에 얽메이지 않는 입력을 안전하게 처리하지 못하는 양식을 찾으면 다른 양식에도 동일한 문제가 있을 수 있다.

Making flawed assumptions about user behavior

logic 취약점은 가장 일반적이고 근본적인 원인 중 하나는 사용자 행동에 대해 잘못된 가정을 하는 것이다.개발자는 위반된 이런 가정이 있는 잠재적인 위험성이 있는 시라니오를 고려하지 않을 경우 다양한 문제가 발생할 수 있다.

Trusted users won’t always remain trustworthy

application은 business 규칙을 강제하는 것처럼 보이는 강력한 조치들을 구현하여 안전한 것처럼 보일 수 있다. 안타깝게도 이부 application은 처음에 이런 엄격한 제어를 통과하면 사용자와 해당 데이터를 무한정 신뢰할 수 있다고 가정하는 실수를 한다. 이로 인해 해당 시점부터동일한 제어가 상대적으로 느슨하게 시행될 수 있다.
business 규칙과 보안 조치가 application 전체에 일관되게 적용되지 않으면 공격자가 악용할 수 있는 잠재적 위혐성이 있는 허점이 생길 수 있다.

Users won’t always supply mandatory input

한 가지 오해는 사용자가 항상 필수 입력 필드에 값을 제공한다는 것이다. 브라우저는 일반 사용자가 필수 입력 없이 양식을 제출하는 것을 방지할 수 있지만 공격자는 전송 중인 파라미터를 조작할 수 있다. 심지어 완전히 파라미터를 제거하는 것까지 확장된다.
이는 동일하게 서버측 스크립트 내에서 여러 기능이 제공될 때 문제가 된다. 이 경우 특정 파라미터의 유무에 따라 어떤 코드가 실행되는지 결정할 수 있다. 파라미터 값을 제거하면 공격자가 접근할 수 없는 코드 경로에 접근할 수 있다.
logic flaws을 조사할 때 각 파라미터를 차례로 제거하고 이것이 응답에 어떤 영향을 미치는지 관찰한다. 아래, 다음을 확인한다.

• 모든 관련 코드경로에 도달하는 것을 확인하기 위해 한 번에 하나의 파라미터만 제거한다.
• 파라미터의 이름과 값을 삭제한다. 그러면 서버는 일반적으로 두 경우를 다르게 처리한다.
• 다단계 프로세스를 완료할 때까지 따라간다. 그리고 때론 어떤 단계에서 파라미터를 조작하면 작업흐름에 따라 다른 단계에 영향을 미칠 수 있다.

이는 URL과 POST 파라미터에 모두 적용되지만 쿠키도 확인하는 것일 잊지말아야 한다. 이 간단한 과정은 악용될 수 있고, 이상하게 동작하는 application을 확인할 수 있다.

Users won't always follow the intended sequence

많은 작업처리는 일련의 단계로 구성된, 미리 정의된 작업흐름에 의존한다. 웹 인터페이스는 일반적으로 사용자가 이 프로세스를 따라가도록 안내하며, 사용자가 현재 단계를 완료할 때마다 다음단계로 이동시킨다. 그러나 공격자는 의도된 순서를 반드시 따르진 않는다. 이 가능성을 고려하지 않으면 쉽게 악용할 수 있는 위험한 결함이 발생할 수 있다.

예를 들어 이중 인증(2FA)을 구현하는 많은 웹사이트에서는 사용자가 로그인 후에 별도의 페이지의 확인 코드를 입력해야 한다. 사용자가 항상 이 과정을 완료할 것이라고 가정하고 확인하지 않으면 공격자는 2FA단계를 우회할 수 있다.
이런 사건들에 대해 가정하면 같은 작업흐름이나 기능 내에서도 광범위한 문제가 발생할 수 있다. Burp proxy와 repeater와 같은 도구를 사용하면 공격자가 요청을 본 후 마음대로 재생하고, forced browsing을 사용해서 원하는 순서대로 서버와 상호작용을 할 수 있다. 이를 통해 application이 예상치 못한 상태에서 다른 작업을 완료할 수 있다.
이러한 종류의 결함을 식별하려면 forced browsing을 사용하여 의도하지 않은 순서로 요청을 제출해야 한다. 예를 들어 특정 단계를 건너뛰고, 단인 단계에 두 번 이상 접근하고, 이전 단계로 돌아가는 등의 작업을 수행할 수 있다. 다른 단계에 접근하는 방법을 기록해 둔다. 종종 특정 URL에 GET나 POST 요청을 제출하게 되지만, 때로는 동일한 URL에 다른 파라미터 집합을 제출함으로써 단계에 접근할 수 있다. 모든 logic flaws과 마찬가지로 개발자가 어떤 가정을 하고 attack surface이 어디에 있는지 확인한다. 그러면 가정을 위반하는 방법을 찾을 수 있다.
이런 종류의 테스트는 종종 예상되는 변수에 null 또는 초기화되지 않은 값이 있기 때문에 예외를 발생시킨다. 부분적으로 정의되거나 일관성이 없는 상태의 위치에 도달하면 application의 컴플레인 원인이 될 수 있다. 이 경우 발생하는 오류 메시지나 디버그 정보에 주의를 기울여야 한다. 이는 공격을 미세 조정하고 백엔드 동작에 대한 주요 세부 정보를 이해하는 데 도움이 되는 귀중한 information disclosure 소스가 될 수 있다.

Domain-specific flaws

대부분의 경우 business 도메인 또는 사이트 목적에 특정한 logic flaw이 발생한다.
logic flaw을 찾을 때 온라인 상점의 할인 기능은 전형적인 attack surface이다. 이것은 할인이 적용되는 방식에서 발생하는 모든 종류의 기본 logic flaw으로 인해 공격자의 돈벌이수단이 될 수 있다.
예를 들어 $1000 이상 주문 시 10% 할인을 제공하는 온라인 상점을 생각해 본다. 할인이 적용된 후 business logic이 주문이 변경되었는지 여부를 확인하지 못하는 경우 남용에 취약할 수 있다. 이 경우 공격자는 $1000 이상 물건을 장바구니에 넣은 다믕 주문하기 전에 원하지 않은 물건을 제거할 수 있다. 그러면 기준을 충족하지 않더라도 주문에 대한 항인을 받게 된다.
가격 또는 기타 민감한 값이 사용자의 작업에 따라 조정되는 경우에 특히 주의를 기울여야 한다. application이 이러한 조정을 수행하는 데 사용하는 알고리즘과 이러한 조정이 수행되는 시점을 이해한다. 여기에는 적용된 조정이 개발자가 의도한 원래 기준과 일치하지 않는 상태가 되도록 application을 조작하는 것도 포함된다.
이러한 취약점을 식별하려면 공격자가 가질 수 있는 목표에 대해 신중하게 생각하고 제공된 기능을 사용하여 이를 달성하는 다양한 방법을 찾아야 한다. 이것은 주어진 context에서 무엇이 유리할 수 있는지 이해하기 위해 영역별 특정 수준의 지식이 필요할 수 있다. 간단한 예로 소셜 미디어를 이해해야 사용자를 많이 팔로우하게 하는 방법을 이해할 수 있다.
도메인에 대한 이러한 지식이 없으면 잠재적인 연쇄 효과를 인식하지 못하기 때문에 위험한 동작을 무시할 수 있다. 마찬가지로 두가지 기능이 어떻게 유해하게 결합될 수 있는지를 파악하는 데 어려움을 겪을 수 있다.