리팩토링 2 - 결제 검증과, XSS 등에 대한 방어 테스트
개인적으로 생각했던, 결제의 핵심은 검증과 검사였다.
여러가지 경우에 대해 방어 테스트를 진행했었지만, 리팩토링 과정에서 추가하고자 했던 검증 과정등을 정리하여보겠다.
현재 결제 과정은
1. member에 결제 요청 -> 2. 사용자 포인트가 결제 금액보다 작은지 검증 -> 3. 작다면, 그만큼 다시 front end로 전달
-> 4. front end에선, 그 부족한 금액만큼 결제 진행 -> 5. 그 결제 금액을 검증받고, 저장, 승인 -> 6. purchase 부에서 다시
member 부로 전달(product의 상태 변경, 사용자 포인트 변경 등 수행)
1. 1000원을 결제하고, 100000포인트를 넣어달라는 악의적인 요청
이러한 경우는 JSON BODY로 악의적인 DATA를 전송하였거나,
혹은 코드가 다 분석되어 사용자가 임의의 데이터를 전송하였을때 발생할 수 있는 문제라고 보았다.
또한 XSS처럼 스크립트를 삽입하여, POINT를 본인이 원하는 부로 전송할때 문제가 발생할 것이라 생각하였고, 이를 막기 위한 검증 로직을 짰다.
사용자가 몇포인트를 충전했는지를 다시한번 PORTONE과의 통신을 통해 받아와서,
이를 검증하는 로직을 테스트했고, 정상적으로 동작함을 확인했다.
2. 결제는 잘 했고, 그 금액 또한 잘 보냈지만 PRODUCT 금액을 속였다.
이러한 예시이다. 천원을 결제하고, 해당 금액은 잘 맞추어 보냈지만,
상품이 사실 1원이라고 얘기해 상품을 싸게 사려는 형태이다.
현재 구조가, 본인이 소유한 포인트 - 요청 받은 구매 포인트 만큼만 결제하는 로직으로 짜져있다.
그러므로, 결제한 금액과. 상품의 총 금액이 다를 수 있다.
(이러한 방식으로 구축한 이유는, 공격자가 악의적으로 이익을 남기지 못하게 하기 위해서였다.
이러한 구축을 통해 확실히 구매자는 portone으로 결제를 하게 되면 무조건 0포인트가. 그렇지 않고
이미 있는 포인트로 결제하게되면 남는 포인트를 얻게 되었다.)
하지만 여전히, 상품을 싸게 사서 판매자의 손해를 유발할 수는 있다.
이러한 문제를 해결해야 된다는 생각을, 리팩토링 도중 하게 되었다.
1. 보유 금액이 부족하고
2. 결제를 완료하고 해당 결제 금액을 잘 보냈고
3. 그렇지만, 상품 내부의 금액을 거짓말로 보냈다면
문제를 잡아낸다.
또 다시 마주한 , MSA 구조의 불편함
1. 결제부는 , 해당 상품 가격이 진짜인지 아닌지 모른다.
결제부는 PRODUCT DB를 가지고 있지 않다.
그렇기 때문에 해당 금액을 확인하려면 PRODUCT에 대한 요청을 보내야 한다.
2. 각 분야 과정에서 많은 통신이 일어난다.
만약 온프레미스라면, 문제가 발생한다면 그건 서버 개발자가 악의적인 사람이거나,
서버에 침입하여 발생한 공격이다.
하지만 , MSA 과정은 계속해서 통신한다.
그 과정에서 사용자가 들어올 수 있다.
그래서, 결제를 서버에서 진행하고 검증했음에도 불구하고 문제가 발생할 수 있었다.
3. 개발과정이 어렵다.
왜 하지만 잘 검증해놓고 로그로 찍었을까?
그 이유는 해당 PRODUCT,MEMBER의 책임자가 내가 아니기 때문이다.
해당 변경을 위해선 PRODUCT MEMBER부의 책임자가 승인을 해야한다.
"개발과 보안이 싸우면, 보통 현실적으로 개발이 이긴다." 라는 말에 따라 바로 반영하지 않았고,
책임자가 확인하기 위해 로그 형태로만 구현하였다.
이렇게 구현하고, 생각했지만. 해당 내용이 우리 팀장과 팀원들이 느끼기에
반영할만한 가치가 있는지는 미지수이다.
내가 이를 문서로 잘 작성해서 설득해보아야 겠다.