[T0M4TO] 개발과 보안의 괴리 1탄 (Authentication)

---

오늘 알아볼 것은, 늘 고민하고 있는 개발과 보안의 괴리에 관련한 것이다.

모두 알겠지만, 개발 기술은 정말 빠르게 진화하고 변화하고 있다.
대표적으로 몇년전에만 해도 쓰던 인증 방식인 쿠키 + 세션 조합을 이제는 잘 사용하지 않고, 토큰 + Storage를 쓴다던가...

 

tistory는 TSSESSION이라는 쿠키에 세션을 저장하여 사용하는 전형적인 쿠키 + 세션 조합의 인증 방식을 선택하고 있다.

물론 WAS에서 직접 제공해주는 Session같은 경우에는 AutoScaling되는 환경에서는 세션이 공유가 안된다는 치명적인 문제도 발생할 수 있고, 세션이라는 방법 특성상 서버에서 인증에 걸리는 부하가 있을수 밖에 없다. 
하지만 확실히 보안면에서는 안전한 편이라고 말할 수 있다.

먼저 쿠키에 저장되지만, Secure 옵션과 HTTP Only 옵션을 추가함으로써 HTTPS 통신이 아닌경우를 차단할 수 있고, 자바스크립트로 쿠키 데이터에 접근하지 못하게 함으로써 XSS 피해로 인한 세션 탈취를 예방할 수 있다.

그렇다면 아까 위에서 말한 요즘 방법을 한번 알아보자.

 

요즘 방식인 토큰 값을 Response Body를 통해 받아오는 형태인데, HTTP Response를 보면 access token을 Json 형태로 body를 통해 전달받고 있다.
여기서 중요한건 어떤 형태인지가 아닌, body값으로 받았다는 것이다.

body로 받았을 경우, 이에 대한 처리를 자바스크립트에서 진행하게 되는데 여기서부터 문제다.
자바스크립트로 받아왔기때문에, 프론트엔드에서 해당 값에 대해 접근이 가능해진다. 즉 XSS공격을 당할 경우 토큰값을 탈취당할 수 있다는 것이다. 

그런데 여기서 끝이 아니다.

Response body를 통해 받은 데이터를 사용할 경우 주로 변수에 저장하게 되는데, 이 변수는 다른 창 또는 탭과는 공유가 되지 않는다는 단점이 있다.  즉 A라는 사이트에 로그인 한 뒤에, 다른 창 또는 다른 탭으로 A라는 사이트에 다시 접속하면, 로그인을 다시해야하는 불편함이 생긴다는 것이다.

과연 서비스를 제공하는 기업들이 이 부분을 그대로 둘까..? 그럴리가 없다. 가용성이 확연히 떨어지기 때문이다.
그렇다면 어떻게 대응했을까?

세상에 맙소사!! 바로 Storage를 이용한다.

Storage에는 크게 LocalStorage와 SessionStorage가 있다.
두 Storage의 차이는 세션 종료 이후 삭제가 되는지 안되는지에 차이가 있다. 다만 여기서 말하고자 하는 부분은 어떤 Storage냐에 구애받지 않는다. 

우선 Storage를 사용하는 이유는 너무나 단순하다. 어딘가에 저장을 해두어야 인증토큰이 사라지지 않는데, 저장할 곳이 Storage가 아니라면 마땅히 없기 때문이다.
이렇게 Storage에 토큰을 저장한뒤, API를 호출할때 Request Header에 넣는다던가, 최근엔 프론트엔드에 많은 기능을 포함시키는 추세이기에, Storage에 토큰이 있는지 그 유무를 통해 프론트엔드 디자인을 동적으로 변경하게 하는 등에 활용하는 경우가 많아지고 있다.

하지만 Storage는 보안입장에서는 정말 쓰지않았으면 하는 저장공간이다.
Cookie처럼 보안옵션을 넣을수있는것도 아니고... Javascript로 너무 쉽게 접근이 가능하기때문에 XSS를 활용한 인증토큰 탈취가 가능하기 때문이다.

그렇다면 어떻게 해야할까?

보안을 하는 사람 입장에서는 세션의 단점을 상쇄시킬수 있는 통합형태의 인증 토큰을 구현한 뒤, 쿠키를 통해 이를 관리하는것이 가장 이상적이라고 생각한다.
하지만 프론트엔드에 많은 기능을 주는게 유행인 지금, 대부분의 서비스들은 Storage를 활용하고 있다는 점에서 개발과 보안의 괴리를 크게 느끼고 있다.

2탄을 언제쓸지는 모르겠지만 2탄은 내가 정말 혐오하는 Stateless Token으로 인한 개발과 보안의 괴리에 대해 작성해보도록 하겠다.

---