API 해킹의 모든 것
https://blog.naver.com/jeipubmarketer/223165717873
웹 트래픽의 80% 이상을 차지하는 API가 위협받고 있다고? API 해킹의 모든 것! (f. 개발자 서평 이벤
안녕하세요, 여러분! 오늘도 특별한 신간을 가져왔어요. 현재 웹에서 돌아가는 거의 모든 애플리케이션이 ...
blog.naver.com
제이펍 공식 블로그의 서평 이벤트에 당첨되어 쓰는 리뷰입니다.
들어가기 전에 서평 작성에 늦은 점 정말 죄송합니다. 😓
REST API
작년 4월에 회사에 입사하고 나서 신규 사업의 백엔드 서버 개발 파트에 참여했다.
영양제 관련 서비스로 나의 역할을 DB 설계와 서버쪽 비즈니스 로직을 구현하는 것.
서버 쪽에서는 웹 클라이언트(SPA로 Vue.js 프레임워크 사용)를 도맡아서 개발했고, 주 클라이언트는 모바일이 대부분이었다.
앱이 디바이스에 설치되어 앱에서 데이터를 요청하는 게 대부분의 애플리케이션 개발 테크인 시대라서
백엔드 개발자는 REST API라는 개념을 자주 접하게 된다.
나도 작년 프로젝트에서 REST API로 개발을 했다.
이 책의 앞 부분은 REST API에 대한 소개를 진득하게 해 준다.
왜 REST API가 현재 드팩토(De-facto) 표준으로 자리를 잡았는지 말이다.
한 번도 보안의 관점에서 REST API를 접근해 본 적이 없었기 때문에,
제이펍 블로그에 댓글을 달아 서평 이벤트 참여 희망 댓글을 남겼고 운이 좋게 당첨되었다.
REST API 해킹 - 불필요한 정보를 내려주는 것.
내가 책을 통해 얻은 인상 깊은 내용은
REST API의 취약점을 발견하는 것과 REST API가 불필요하게 많은 정보를 전달해 주는 것으로 2가지다.
불필요하게 많은 정보를 전달해주는 부분은 모바일 클라이언트 개발자와 주로 얘기하던 내용이었다.
서버에서는 클라이언트로 내려줄 데이터를 DTO로 관리하는데 개별 API별로 DTO를 두기보다는 거대한
DTO를 두어서 불필요한 정보를 같이 전달하도록 만드는 편이었다.
서비스가 가지는 기능이 많으면 많을수록 불필요한 내용을 포함하는 큰 규모의 DTO로 퉁치는 편이었다.
거기다가 DTO로 전달할 엔티티의 내용을 하나하나 DTO의 데이터로 넣어주는 게 아니라 DTO의 헬퍼 메서드를 둬서
엔티티를 넘기는 방식으로 DTO를 생성하다 보니 불필요한 정보인지 아닌지를 체크하지 않는 경우가 많았다.
REST API가 불필요하게 많은 정보를 주는 게 어때서?라는 생각이 들 수 있는데,
REST API의 취약점의 재료가 될 수 있기 때문에 이는 보안적인 측면에서 바람직하지 않다.
책에서는 그래프 QL이라는 기술로 원하는 데이터 정보만 요청하는 방법을 짦게 소개해주는데, 작년에 이 기술을 클라이언트 개발자와 의논했으면 1차적인 보안이 장착된 REST API를 개발하는 게 아니었을까 한다.
REST API - REST API 취약점
내가 참여한 서버 로직에서는 엔티티의 위치를 찾아내기가 상대적으로 쉽다.
API뒤에 GET 파라미터로 넘기는 사용자 번호가 PK순으로 처리되기 때문이다.
웬만한 REST API 응답에는 PK번호가 할당되어 있다.
PK번호는 auto increment(증량) 정책으로 1씩 증가하는데, 이 방식으로 사용자 정보를 받아오려고 하거나
특정 정보에 접근하기 수월하다.
만약 DELETE 메서드가 열려있었다면 누군가 호기심 삼아 번호를 하나하나 넘기는 방식으로 서버에 정상적인 API를 보내
우리가 의도하지 않은 결과를 만들어냈을지도 모르겠다.
회사에서는 의도가 명확할 수 있는 HTTP METHOD를 사단에 차단하는 방식 (DELETE, PUT 사용 금지)을 정책으로 뒀고
서버 쪽에서는 삭제 로직에 있어서 DB에서 실제로 삭제하는 게 아니라 toggle 방식으로 Delete 칼럼에 true를 기입하는 식으로
처리하기에 그나마 안전할 수 있다.
하나 PK를 유출하는 방식으로 REST API를 다루는 것은 썩 좋지 않다.
초기 개발에 투여되는 시점에 UUID를 검토해야 하는 게 아닌가 팀 내 의견을 냈지만, 시작부터 그렇게 무겁게 가고 싶지 않다는 게
주류 의견이었고, 실제로 PK방식으로 개발했을 때 검수하거나 Swagger로 테스트할 때 편리함이 많았다.
알 수 없는 무작위 32글자를 바라보는 것보다 쉽게 DB에서 대조하면서 바라볼 수 있는 PK가 편하기 때문...
지금도 PK를 통해 REST API에 요청하는 것은 변함없다.
개인적인 생각으로는 아직까지 PK 방식으로 크게 데어본 적이 없기 때문이 아닐까 한다...
그 외의 도움 받았던 내용들...
api 해킹 툴과 관련된 내용은 개인적으로 크게 관심 있는 내용이 아니라 읽기만 하고 넘어갔다.
해킹 툴 중에서 http 요청 클라이언트로 사용하는 post man에 대한 내용이 재밌었는데,
내가 알지 못했던 편리한 기능들이 많았기 때문이다. [테스트 API 요청, API 경로에 사용할 수 있는 환경 변수 등등..]
개인적인 소감.
개발하면서 보안은 방학숙제랑 비슷하다.
출시하기 전에 후다닥 몰아서 해결하는 과제와 비슷하게 처리된다.
내가 현재 머무르고 있는 회사에서는 보안 프로세스를 정리하고 운영하는 부서가 있어서, 서비스 개발이 끝난 뒤 검수과정과 함께 보안 정책을 잘 지켰는지 확인하는 과정을 거치게 된다.
특정 매뉴얼이 따로 있다 보니 (케케묵은... 매뉴얼).. 나를 포함한 많은 개발자들에게 보안은 그리 큰 관심사는 아니다.
그래도 틈틈이 보안을 공부하는 편인데, 보안을 공부하는 이유는 방어적인 시각을 갖추기 위해서기 때문이다.
개발자의 시각이 아니라 공격자의 시각으로 무언가를 바라본다면 여러 취약점들이 쉽게 드러나곤 하며,
패턴적인 모습을 보일 때가 있다.
개인적인 소유물에서 개발하면 공격당해도 나만 쓰라리면 그만이지만
회사의 상품이 공격에 노출되었고 그로 인해 소비자(사용자)가 피해를 받았다는 소식을 듣는다면
직업적인 윤리의식에서 큰 타격을 받게 된다.
그래서 귀찮더라도 공격자의 시각을 보면서 방어적인 관점을 갖출 필요가 있다.
거의 80%가 REST API 방식으로 개발되는 시대에 이 책은 꽤나 재밌는 주제를 던져주는 게 아닐까 한다.
REST API가 무엇인지
어디에서 REST API 취약점들이 드러나는지
REST API 공격자들은 어떤 도구를 쓰고 어떤 방법을 쓰는지
를 보면서 이제까지 개발한 내용 중에 내가 노출시켰던 취약점은 없었는지 고민해 보는 시간을 가져보기를....
좋은 책을 번역해 주는 제이펍에 늘 감사하며
좋은 책을 써준 코리 볼 저자와 한성용 옮김이에게 감사를 표합니다.
