token
토큰의 종류
JWT에는 Access Token, Refresh Token 두 가지 종류의 토큰이 있다.
Access Token을 통해서 민감한 정보에 접근할 수 있으며
두 가지 토큰 중에서 실제 권한에 접근하는 토큰이다.
짧은 유효기간을 가지며 Refresh Token을 통해서 만료된 Access Token을 발급받을 수 있다.
Access Token보다 긴 유효기간을 가지며 이때, 유저는 다시 로그인하지 않아도 된다.
Refresh Token이 탈취당하면 위험하기 때문에 정보에 민감한 사이트는 Refresh Token을 사용하지 않을 수도 있다.
토큰 기반 인증의 절차
클라이언트가 서버에 아이디와 비밀번호를 담아 로그인 요청을 보낸다.
아이디와 비밀번호가 일치하는지 확인한 뒤에
클라이언트에 보낼 access와 refresh 두 가지 토큰을 만든다.
이 두 토큰에 담길 정보(payload)는 같을 필요는 없다.
토큰을 클라이언트에 보내고, 클라이언트는 토큰을 저장한다.
저장위치: 쿠키, state, local Storage 등
클라이언트가 민감한 정보에 대한 요청을 보낼 때, HTTP의
req.headers.authorization에 토큰을 담아 보낸다.
서버가 토큰을 해독하여 유효한 토큰이라면 클라이언트의 요청을 처리한 뒤에 응답을 보낸다.
유효하지 않은 토큰이라면 에러가 발생한다.
Statelessness & Scalability (무상태성 & 확장성)
서버는 클라이언트의 정보를 저장하지 않아도 된다.
클라이언트는 새로운 요청을 보낼 때마다 헤더에 토큰을 담아 보내면 된다.
만약, 여러 개의 서버를 가진 서비스라면 클라이언트가 가진 하나의 토큰으로 여러 개의 서버에 인증을 할 수 있기 때문에 편리하다. 또한 암호화한 토큰을 사용하고, 암호화 키를 노출할 필요가 없어서 안전하다.
토큰을 확인하는 서버가 토큰을 만들 필요는 없기에 어디에서나 토큰을 만들 수 있다.
토큰용 서버를 만들 수 있고, 다른 회사에 토큰과 관련된 작업을 맡길 수도 있다.
권한을 부여하는데 용이하다.
토큰의 payload 안에 어떤 정보에 접근할 수 있는지 정할 수 있다.
node.js의 환경에서 jsonwebtoken 라이브러리를 사용하여 토큰을 생성할 수 있다.
XSS
크로스 사이트 스크립팅은 웹 어플리케이션에서 어플리케이션 관리자가 아닌 악성 유저가 일부러 심어놓은 악성 코드를 실행하게 함으로써 발생하는 취약점이다. 악의적인 사용자는 공격하려는 사이트에 다른 유저로 하여금 악의적인 스크립트를 실행하도록 유도하여 정보를 편취하거나 의도치 않은 행동을 유발하게 한다.
Reflected XSS
해커가 사용자로 하여금 악성 링크를 클릭하도록 유도하여 정보를 탈취하는 방법이다.
일반적으로 메일 또는 문자 등에 악성 URL을 전송한 후, 사용자가 해당 링크를 클릭하면
악성 스크립트가 실행된다.
일반적으로 사용자가 해당 URL을 읽고 잘못된 URL이라고 판단할 수 있기 때문에
해당 URL을 난독화하여 알아보지 못하도록 만든 후, 접근하도록 유도한다.
Stored XSS
게시판, 쪽지함과 같이 저장된 형태의 거시글에 많이 사용되며, 게시글을 작성할 때
악성 스크립트를 심어서 올려서 해당 스크립트 링크를 클릭하거나 혹은 이미지 태그를 클랙하도록 유도해서 악성 스크립트를 실행시킨다.
이를 통해 지속적인 (Persistent) 공격을 할 수 있는 방식으로,
일반적으로 stored XSS가 막혀있는 페이지의 경우, 스크립트 코드가 포함된 게시글은
단순히 텍스트로 인식해서 출력한다.
DOM based XSS
사용자 브라우저에서 서버로 요청하는 과정이 아니라, 브라우저 상에서 DOM을 구축하는 과정에서 해커가 해당 DOM 환경을 악의적으로 수정해서 이를 통해 예상치 못한 코드를 실행하도록 만드는 공격 방식이다.
CSRF
Cross-site request forgery, 사이트 간 요청 위조
사이트 간 요청 위조는 웹사이트 취약점 공격의 하나로, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위를 특정 웹사이트에 요청하게 하는 공격을 말한다.
