Server - side Vulnerability ③ Business Logic

Business Logic 

:: 규칙에 따라 데이터를 생성. 표시. 저장. 변경하는 로직, 알고리즘

ex) 게시판 서비스는 회원 가입/로그인, 게시물 작성/수정/삭제 등 다양한 로직이 모여 하나의 서비스가 완성됨

 

ⓐ Business Logic Vulnerability

- 비즈니스 로직 취약점은 정상적인 비즈니스 로직을 악용하는 것

- 서비스의 기능에서 적용되어야 할 로직이 없거나 잘못 설계된 경우 발생

 

ex) 상품 후기를 작성시 포인트를 주는 이벤트가 있다. 

후기를 작성한 후, 100 포인트를 받았는데

글을 삭제한 후 다시 후기를 작성하니 100 포인트를 또 받을 수 있었다..

 

※ 비즈니스 로직 취약점을 방어하기 위해선?

- 비즈니스 로직을 확실하게 이해하고, 설계 및 개발 단계에서 어떤 위협이 발생할 수 있는지 위협을 파악하고 방어하는 것이 중요하다.

 

 

ⓑ IDOR (Insecure Direct Object Reference) Vulnerability

:: 안전하지 않은 객체 참조

:: 발생하는 주된 원인 : 사용자의 입력 데이터에 의해 참조하는 객체가 변하는 기능에서 사용자가 참조하고자 하는 객체에 대한 권한 검증이 올바르지 않아서

 

ex) 금액을 조회하고 송금할 수 있는 페이지에서 

사용자가 자신의 계좌번호를 다른 사용자의 것으로 바꿀 때 서버가 이를 검증하지 않는다면 조회, 송금이 가능하다.

 

※ IDOR 취약점을 방어하기 위해선?

- 사용자의 권한을 검증하는게 가장 중요

즉, 사용자가 의도한 권한을 벗어나서 행동할 수 없도록 권한 등을 분리해서 관리해야 한다.

 

- 사용자 인증을 거친 후 사용하는 서비스에서는 사용자가 요청 시 전달하는 세션을 통해 서버 내에서 처리하는 것이 안전

 

- 객체 참조 키를 단순한 숫자가 아닌 무작위 문자 생성 등을 통해 악의적 공격자가 이를 추측하기 어렵게 하는 방법도 있다.

 

 

 

ⓒ Race Condition

:: 공유 자원 처리 과정에서 해당 자원에 대한 동시 다발적인 접근으로 인해 발생하는 취약점

 

- 데이터베이스 또는 파일 시스템과 같이 웹 어플리케이션에서 공유하는 자원들에 대한 접근 과정에서 데이터를 참조하는 타이밍의 차이로 인해 취약점이 발생한다.

- 주로 검증 과정에서의 데이터와 수정 과정의 데이터의 차이로 인해 웹 어플리케이션에서 의도하지 않은 흐름으로 진행한다.

- 비즈니스 로직의 잘못된 순서로 인해 발생하기도 한다.

 

ex) 사용자의 잔액 확인 과정과 차감하는 과정 사이, 재고 확인 과정에서 시간 지연이 발생하며, 

잔액 확인 과정 이후에 잔액이 차감된다는 점을 이용하여 현재 잔액보다 더 많은 금액의 상품을 구매할 수 있다.

 

※ 레이스 컨디션 취약점을 방어하기 위해선?

- 하나의 접근이 끝난 후 다음 접근을 처리하도록 하는 쓰레드 락 등을 통해 동시 다발적 접근을 방지해야 한다.

- CSRF 토큰, 캡차 등을 통해 다량의 접근을 방지하는 방법도 있다.