[Webhacking] business logic vulnerability

Business logic은 규칙에 따라데이터를 생성.표시.저장.변경하는 로직, 알고리즘 등을 말함.

비즈니스 로직 취약점은 서비스의 기능에서 적용되어야 할 로직이 없거나 잘못 설계된 경우 발생.

Injection, File vulnerability는 악의적인 데이터가 서버의 시스템 상에서 악영향을 미치는 공격을 수행.

 

1. 사용자가 게시물 수정을 요청한다.
2. 로그인된 사용자인지 확인한다.
3. 수정을 요청한 사용자가 해당 게시물을 수정 할 수 있는 권한인지 확인한다.
4. 2,3번 과정이 확인되면 데이터베이스에 사용자가 입력한 정보로 수정한다

3번 과정 누락 시에 공격자가 다른 사용자의 게시물 수정 가능.

---

Business Logic Vulnerability 

어플리케이션의 검증 부재 또는 미흡의 이유로 발생.

후기 삭제 후 재작성에도 포인트가 적립되는 취약점 존재.

취약점 패치를 위해 게시물 삭제 시에 포인트도 100 차감하는 로직 필요.

설계 및 개발 단계에서 발생할 수 있는 위협에 대해 파악하고 방어해야 한다.

---

IDOR (Insecure Direct Object Reference)

안전하지 않은 객체 참조라는 의미

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

 

이런 인풋에서 데이터에 자신의 계좌가 아닌 남의 계좌를 입력했을 때도 정보가 출력됨.

이렇게 입력으로 임의의 계좌에 대한 송금을 요청할 수 있다면 남의 계좌에서 돈을빼서 자신의 계좌에 넣을 수 있음

IDOR 취약점을 방어하기 위해서는 객체 참조 시 사용자 권한을 검증하는게 가장 중요.

 

숫자 만을 이용한 해쉬 함수로 객체 참조 키를 사용하면 레인보우 테이블에 의해 바로 해독되어 버림.

솔트를 이용해 해쉬함수를 안전하게 사용할 것.

---

Race Condition

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

 

잔액에 대해서 확인하는 로직과 차감하는 로직이 있을 때, 확인하는 로직이 차감하는 로직보다 먼저 수행된다면 (딜레이 존재)

차감되기 전에 잔액보다 많은 상품 구입 가능.

따라서 특정한 행위에 요청을 할 시에흔 CSRF 토큰, 캡차이 등을 통해 다량의 접근을 방지