세번 째, 주니어 개발 일기🙂

💡오늘의 이슈💡

✅ PG사 데이터 위/변조 테스트 진행

3차 검수인 위/변조 테스트로 수정 사항 없이 검수가 완료되었다.

하지만, 어떤 식으로 검수를 하였고 위/변조 테스트에 대해 직접 테스트해본 경험이 없었던 것 같아 로그롤 통해 분석해보았다.

큰 프로세스로 보면 3가지였다.

• 가격 변조 
  • 결제창 호출시 파라미터 변조
    • 위/변조 테스트를 하며 느낀 것은 클라이언트가 임의적으로 값이 변경 될 수 있다는 점이고, 해당 테스트를 잘 넘어갈 수 있었던 것은 파라미터로 가격을 받아 결제 요청을 보내지 않고 최초로 주문서 진입 시 docdb에 넣은 결제 금액으로 결제 요청을 보냈기에 아무리 클라이언트에서 위/변조를 진행해도 변조된 가격으로 요청되지 않았다.
      • 위의 테스트를 하며 느낀점은 결제와 같이 위/변조에 중요한 프로세스들은 파라미터 방식이 아닌 서버측에서 끝내는게 맞다는 생각이 든다. 
  • 결제창에서 파라미터 변조
    • 해당 경우 결제 요청 시, 제대로 된 파라미터를 던지더라도 pg사 검수에서 결제 창에서 임의로 가격의 값을 바꾼 경우이다.  위의 검수를 잘 통과 할 수 있었던 이유는 결제 승인 후 데이터에 대한 정합성 validation 로직이었다.
    • 최초에 요청한 데이터와 결제 승인 후의 가격 데이터가 일치한지 확인하여 일치하지 않으면 내부적으로 주문 데이터를 생성하지 않고 결제 취소 API 요청으로 보내도록 하였다.
      • 이러한 경우가 자주 발생하지는 않지만 모든 예외 케이스들은 오버 스펙이 되지 않는 선에서 생각하고 체크해야 된다고 생각했다.
• 주문 번호 변조
  • 두번째는 가맹점(글쓴이의 회사)의 주문번호 변조 이다. 결제 요청 시의 주문번호와 결제 승인 시의 주문번호가 일치하지 않도록 검수자가 변조하였고, 결제 승인 시 a의 주문번호로 요청되었지만 b의 주문번호로 반환되었고 가격 validation 체크 로직에서 a의 가격과 b의 가격이 달라서 a의 주문번호는 다시 결제 취소 처리 되었고 b의 주문번호는 정상 처리 되었다.
• 중복 호출
  • 중복 호출은 비교적 간단했다. 결제 승인 중복 호출을 시도하더라도 먼저 요청된 a의 요청이 먼저 승인 처리 될 것이고 이후 요청 b는 동일한 id에 대해 이미 결제 승인 내역 이력이 있으므로 중복 호출이라는 문구를 반환해준다. 
  • 결제 취소 요청에서는 pg사의 주문정보를 조회하여 취소 요청 전 취소된 내역이 있는지 확인해주는 로직으로 검수에 통과하였다.

 

✅ 앱 버전 분기를 위한 os-type 

앱에 confirm 창 노출 이슈가 있어 이번 결제수단에서 부터 앱버전 분기가 들어가게 되었다.

디바이스 정보에 따라 앱버전이 다르므로 디바이스 정보가 중요했다. 

jwt Token에 디바이스 정보가 담기지만 token 이슈가 있어 위 정보를 100% 신뢰하기는 어려웠다. 

그래서 api 요청시 header에도 디바이스 정보가 담겨 이를 통해 분기하려 했지만 주문서 페이지가 모웹 환경이였는데 이번에 신규 웹 전환을 하면서 각 유저의 디바이스 정보가 아닌 웹으로 담겨 나오는 이슈가 있었다. 

오픈은 당장 다음주 화요일 !!! 

어떻게 하면 100% 확신성으로 버전 분기를 할 수 있을까 생각했다.

현재 강제 업데이트 버전은

IOS = 4. xx
AOS = 7. xx

appVersion에 대한 값은 헤더로 꺼내오고 있으며 정합성 또한 100% 이기 때문에 이를 활용하여

첫번째 글자로 디바이스 구분을 하는 것으로 결정했고 

오픈 이후, 위의 문제를 해결하기로 했다.