비즈니스 로직 공격 설명
공격자가 돈을 훔치기 위해 항상 코드를 깨뜨리는 것은 아닙니다.
많은 개발자가 API와 암호화를 보호하는 데 수개월을 보냅니다. 그들은 SQL 인젝션이나 XSS를 막는 데 집중합니다. 하지만 공격자는 단 하나의 보안 제어도 무력화하지 않고 자금을 훔쳐갑니다.
이것이 바로 비즈니스 로직 공격입니다.
애플리케이션은 설계된 대로 정확하게 작동합니다. 공격자는 단지 당신이 만든 규칙을 당신에게 불리하게 이용할 뿐입니다.
은행 금고를 생각해 보세요. 대부분의 보안 테스트는 문이 튼튼한지 확인합니다. 비즈니스 로직 테스트는 다른 질문을 던집니다. 만약 누군가 경비원을 설득해 문을 열어주게 만든다면 어떻게 될까요?
금고는 정상 작동합니다. 프로세스가 실패한 것입니다.
공격자가 뱅킹 로직을 악용하는 세 가지 방법은 다음과 같습니다:
대기 기간 우회 은행은 종종 새로운 수취인을 추가한 후 24시간의 대기 시간을 요구합니다. 이는 빠른 도난을 방지하기 위함입니다. 공격자는 이 확인 과정을 건너뛰는 API 엔드포인트를 찾아낼 수 있습니다. 그들은 UI 제한을 우회하여 즉시 돈을 이체합니다.
거래 한도 무력화 은행이 일일 한도를 50,000으로 설정했을 수 있습니다. 만약 코드가 각 거래를 개별적으로만 확인한다면, 공격자는 49,000씩 다섯 번의 이체를 보낼 수 있습니다. 각 거래는 유효해 보입니다. 총합은 한도를 초과하지만, 시스템은 이를 놓칩니다.
보상 악용 많은 앱이 공과금 결제 시 캐시백을 제공합니다. 공격자는 공과금을 결제한 후 즉시 취소할 수 있습니다. 시스템이 보상을 회수하지 않는다면, 공격자는 무한한 캐시백을 받기 위해 이 과정을 반복합니다.
왜 자동화된 스캐너는 이를 놓칠까요?
스캐너는 악성코드나 인젝션 같은 기술적 결함을 찾습니다. 스캐너는 성공적인 이체를 확인하고 200 OK 상태를 반환합니다. 스캐너는 모든 것이 정상이라고 생각합니다.
인간 테스터는 질문합니다: 이 이체가 애초에 일어나서는 안 되는 것이었나?
이러한 결함을 찾으려면, 기능이 해킹될 수 있는지 묻는 것을 멈추고, 기능이 악용될 수 있는지 묻기 시작하십시오.
다음 영역을 확인하십시오:
- 사용자가 인증 단계를 건너뛸 수 있는가?
- 사용자가 ID의 소유권을 변경할 수 있는가?
- API를 통해 대기 기간을 우회할 수 있는가?
- 한도가 총액에 적용되는가, 아니면 클릭당 적용되는가?
- 보상이 여러 번 트리거될 수 있는가?
엘리트 보안 팀은 단순히 유스케이스(use cases)를 만들지 않습니다. 그들은 어뷰즈 케이스(abuse cases)를 만듭니다.
"사용자가 돈을 이체한다"를 테스트하는 대신, "공격자가 한도를 우회하기 위해 500번의 소액 이체를 시도한다"를 테스트하십시오.
두 번째 질문이 진짜 위험을 찾아냅니다.
Source: https://dev.to/arashad_dodhiya_0e4bdba5a/business-logic-attacks-explained-using-a-banking-app-27hj