Get vs Post 보안상의 고찰

고민지점 

회원가입시에 이미 본인이 쓰고 싶은 아이디가 사용중임을 확인하는 아이디 중복확인이나

회원가입시에 유저의 정보 중에서 이미 본인의 이메일이나 휴대전화번호가 이미 가입된 정보라는 것을 바로 알려주는 기능의 api등을 개발하는 중이었다. 

애초에 회원가입 요청과 다르게 어떤 리소스를 생성하려는 요청이 아니기 때문에, Get 방식이 이용하여 처리했었다. 

https://example.com/usernameduplicatecheck?username= minjun
https://example.com/emailduplicatecheck?email= tistory@gmail.com

 

하지만, 보안적으로 회원가입 이후에 회원 정보로 저장이 될 수 있는 정보이거나, 휴대폰, 이메일과 같이 개인 고유 정보이기 때문에 url에 그대로 노출되는 GET 방식이 적절한지 고민이 되었다. 

 

GET방식의 보안상 문제점 

 1. URL 자체가 보안되지 않았다.

 2. URL에 저장된 데이터가 접근 로그에 남는다.

 3. Referrer을 통해 외부 유출될 수 있다. 

 4. 브라우저에 의해 캐시되어(cached) 저장된다. 

 

그래서 중요한 정보를 전달할 때는 GET보다 POST를 사용하는 것이 더 적합하다고 한다. 

 

그렇다면, POST 방식은 안전할까? 

 

POST로 전달되는 데이터도 URL에 노출만 안될 뿐 똑같이 쉽게 확인 가능하다. 개발자 도구만 켜서 Network 탭에서 request body를 바로 볼 수 있다. 

나도 다른 사이트에선 어떻게 구현되어있는지 궁금해서 찾아보았지만, 회원가입시 중복확인까지도 아닌, 이미 회원가입이 되고 나서의 아이디, 비밀번호를 입력하고 로그인하는 경우조차도 비밀번호가 암호화되지 않아 있는 경우를 확인할 수 있었다.

 

다만, GET, POST 모두 둘 다 훔쳐볼 수 있고 위변조 가능하지만, 시스템의 입장에선 로깅이 된다는 것이 가장 큰 차이점이자, GET 방식에서의 보안상 문제점이라고 볼 수 있다고 한다. 파라미터 자체가 URL에 노출이 되어있다보니, 보통 access logging 할때는 POST의 body를 저장하지 않지만 GET의 parameter는 저장이 되는 경우가 많다고 한다. 

https://okky.kr/questions/437467

 

개선책은?

요청을 보내기 전에 클라이언트에서 입력한 값(Request Body)을 암호화 한 상태로 요청하는 것이다. 

타 사이트에서 개발자 도구를 통해 확인한 내용인데, 해당 사이트에선 브라우저에 입력된 비밀번호를 이미 클라이언트에서 암호화를 진행하고 요청한다. 

[1]

[2] 

 

결론 및 프로젝트 적용 상황 

1. 처음엔 GET vs POST 방식중에서 POST 방식이 URL에 노출이 안되기 때문에 보안적으로 더 나을 것이다 라는 정도만 생각하여 API를 설계했었고, 유저 정보가 들어가는 GET 방식의 중복확인 API를 POST로 바꿔야하나 정도만 생각하고 있었다. 하지만, GET 방식의 문제점 뿐만 아니라 이미 구현된 POST 방식에서의 보안적인 문제점도 확인할 수 있었고, 개선점도 확인해볼 수 있었다. 

 

2. 로그인할때 비밀번호는 특히 POST + Request Body 암호화를 통해 요청을 보내는 것이 필요하다고 생각이 들었다. 현재는 클라이언트에서 암호화하지 않으며, 서버에서 비밀번호 값을 요청으로 받은 후에 암호화하여 DB에 저장하고 있는데, 클라이언트에서 암호화하여 요청 값을 받는 것이 낫다고 생각했다. 

 

3. 다만, 처음 고민한 중복확인 API 같은 경우에는, 어떻게 보느냐에 따라 다르겠지만, 회원가입시 중복확인을 하는 아이디 정도는 POST 방식에서의 암호화를 굳이 하지 않아도 될 것 같았지만, GET방식에서 URL로 노출이 되는 경우는 피하는 것이 좋다고 생각했다. 

 

4. 전화번호, 이메일과 같은 유저 정보는 개인정보이다보니 GET 방식보다는 POST 방식이 더 나아 보이긴 하지만, 비밀번호가 아닌 위와 같은 정보들을 암호화까지 해서 요청하는 경우는 아직 찾지 못했다. 이는 3번 내용과 함께 , 정답은 없는 것 같고, 다만 암호화흘 할 필요까지는 없다고 판단을 했다거나, 아니면 암호화를 해서 얻는 장점보다, 암호화를 통해 따라오는 단점이 더 크다고 판단한 거 같다. 우선 보안적인 요소만 보면 암호화를 하는 것이 좋으나, 그로 인해 나타날 수 있는 단점을 생각해봐야할 것 같다. 

 

4. 보안적인 부분을 고려하다보니 api가 Restful해지진 않는다는 느낌이 많이 들었다. 중복확인 api같은 경우엔특정 리소스를 생성하는 것이 아닌 단순조회인 api들인데, 위에서 언급한 보안적인 부분을 고려한다면, GET대신 POST를 쓰는 경우가 많아질 것이기 때문에 이 부분은 또 다시 개선점을 찾아나갈 필요가 있어보였다. 

 

 

https://okky.kr/questions/437467

OKKY - 전송방식 get과 post중 굳이 post를 쓰라는데 이유가 보안문제라는데요..

https://brunch.co.kr/@skykamja24/322

GET과 POST 구분하기

https://velog.io/@lky9303/GET-POST-%EB%B0%A9%EC%8B%9D%EC%9D%98-%EC%B0%A8%EC%9D%B4

GET / POST 방식의 차이