<인증/보안>

윤장원·2022년 6월 18일
http네트워크보안인증
0

인증보안

목록 보기
1/1

HTTPS

Hyper Text Transfer Protocol Secure Socket layer.
HTTP 요청을 SSL 혹은 TLS라는 알고리즘을 이용해, HTTP 통신을하는 과정에서 내용을 암호화하여 데이터를 전송하는 방법.
HTTP보다 상대적으로 안전한 방법이고, 데이터 제공자의 신원을 보장받을 수 있다.
브라우저가 응답과 함께 전달된 인증서 정보를 확인할 수 있다.

Hashing

어떠한 문자열에 임의의 연산을 적용하여 다른 문자열로 변환하는 것
1. 모든 값에 대해서 해시 값을 계산하는데 오래걸리지 않아야 한다.
2. 최대한 해시 값을 피해야 하며, 모든 값은 고유한 해시 값을 가진다.
3. 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 한다.

Salt

암호화해야 하는 값에 어떤 별도의 값을 추가하여 결과를 변형하는 것
1. 암호화만 해놓는다면 결과가 늘 동일
2. 원본값에 임의로 약속된 별도의 문자열을 추가하여 해시를 진행한다면 기존 해시값과 전혀 다른 해시값이 변반환되어 알고리즘이 노출되더라도 원본값을 보호할 수 있도록 하는 안전 장치
3. (암호화 하려는 값) + (Salt 값) => (hash 값)

쿠키는 서버에서 클라이언트에 데이터를 저장하는 방법의 하나이다.
쿠키 옵션
1. Domain
서버에 접속할 수 있는 이름. 포트 및 서브 도메인 정보, 세부 경로를 포함하지 않는다.
쿠키 옵션에서 도메인 정보가 존재한다면 클라이언트에서는 쿠키의 도메인 옵션과 서버의 도메인이 일치해야만 쿠키를 전송할 수 있다.
2. Path
서버가 라우팅할 때 사용하는 경로.
명시하지 않으면 기본으로 / 으로 설정되어 있다.
설정된 path를 전부 만족하는 경우 요청하는 Path가 추가로 더 존재하더라도 쿠키를 서버에 전송할 수 있다.
3. MaxAge of Expires
쿠키가 유효한 기간을 정하는 옵션.
MaxAge는 앞으로 몇 초 동안 쿠키가 유효한지 설정하는 옵션.
Expires는 언제까지 유효한지 Date를 지정.(클라이언트의 시간을 기준)
두 옵션이 모두 지정되지 않는 경우에는 브라우저의 탭을 닫아야만 쿠키가 제거될 수 있다.
4. Secure
쿠키를 전송해야 할 때 사용하는 프로토콜에 따른 쿠키 전송 여부를 결정한다.
만약 해당 옵션이 true 로 설정된 경우, 'HTTPS'프로토콜을 이용하여 통신하는 경우에만 쿠키를 전송할 수 있다.
5. HttpOnly
자바스크립트에서 브라우저의 쿠키에 접근 여부를 결정한다.
만약 해당 옵션이 true 로 설정된 경우, 자바스크립트에서는 쿠키에 접근이 불가한다.
만약 이 옵션이 false인 경우 자바스크립트에서 쿠키에 접근이 가능하므로 'XSS'공격에 취약하다.
6. Same Site
Cross-Origin 요청을 받은 경우 요청에서 사용한 메소드와 해당 옵션의 조합으로 서버의 쿠키 전송 여부를 결정하게 된다.

  • Lax : Cross-Origin 요청이면 'GET' 메소드에 대해서만 쿠키를 전송할 수 있다.
  • Strict : Cross-Origin이 아닌 same-site 인 경우에만 쿠키를 전송 할 수 있다.
  • None: 항상 쿠키를 보내줄 수 있습니다. 다만 쿠키 옵션 중 Secure 옵션이 필요하다.

이러한 옵션들을 지정한 다음 서버에서 클라이언트로 쿠키를 처음 전송하게 된다면 헤더에 Set-Cookie 라는 프로퍼티에 쿠키를 담아 쿠키를 전송하게 된다.

이후 클라이언트 혹은 서버에서 쿠키를 전송해야 한다면 클라이언트는 헤더에 Cookie 라는 프로퍼티에 쿠키를 담아 서버에 쿠키를 전송하게 된다.

Session

사용자가 인증에 성공한 상태는 세션이라고 부른다.

  • 서버는 일종의 저장소에 세션을 저장한다. 주로 in-memory, 또는 세션 스토어에 저장한다.

세션이 만들어지면, 각 세션을 구분할 수 있는 세션 아이디도 만들어지는데, 보통 클라이언트에 세션 성공을 증명할 수단으로써 세션 아이디를 전달한다.
이때 웹사이트에서 로그인을 유지하기 위한 수단으로 쿠키를 사용한다. 쿠키에는 서버에서 발급한 세션 아이디를 저장한다.

로그아웃

  • 서버의 세션 정보를 삭제한다.
  • 클라이언트의 쿠키를 갱신한다.

CSRF

Corss Site Request Forgery
다른 사이트에서 유저가 보내는 요청을 조작하는 것. 해커가 직접 데이터에 접근할 수 없다.

CSRF 공격을 하기 위한 조건

  • 쿠키를 사용한 로그인 : 유저가 로그인 했을 때, 쿠키로 어떤 유저인지 알 수 있어야 한다.
  • 예측할 수 있는 요청/parameter를 가지고 있어야 한다. : request에 해커가 모를 수 있는 정보가 담겨있으면 안된다.

CSRF 막는 방법

  • CSRF 토큰 사용하기 : 서버측에서 CSRF 공격에 보호하기 위한 문자열을 유저의 브라우저와 웹 앱에만 제공
  • Same-site cookie 사용하기 : 같은 도메인에서만 세션/쿠키를 사용할 수 있다.

Token

세션 기반 인증은 서버에 유저 정보를 담는 인증 방식이다. 서버에서는 유저가 민감하거나 제한된 정보를 요청할 때마다 "지금 요청을 보낸 유저에게 우리가 정보를 줘도 괜찮은가?" 를 확인하기 위해 가지고 있는 세션 값과 일치하는지 확인한다. 매 요청마다 데이터베이스를 살펴보는 것이 불편하고 이 부담을 덜어내기 위해 토큰을 사용한다.

JWT

JSON Web Token
토큰기반 인증 중 하나.

JWT의 종류

  1. Access Token : 보호된 정보들에 접근할 수 있는 권한부여에 사용한다. 권한을 부여 받는데엔 access token 만 있으면 되지만, 악의적인 유저가 이 토큰을 얻어냈다면 마치 본인인 것 마냥 서버에 여러가지 요청을 보낼 수 있을 것이다. 그래서 acceess token은 비교적 짧은 유효기간을 줘서 탈취 되더라도 오랫동안 사용할 수 없도록 한다.
  2. Refresh Token : access token을 발급받기 위한 token. access token 유효기간이 만료되면 refresh token을 사용해서 새로운 access token을 발급받아서 다시 로그인 할 필요가 없게 된다.

JWT 구조

  1. Header : 이것이 어떤 종류의 토큰인지, 어떤 알고리즘으로 sign(암호화) 할지가 적혀있다. JSON 형태
  2. Payload : 어떤 정보에 접근 가능한지에 대한 권한, 사용자의 유저 이름 등 필요한 데이터는 이곳에 담아 암호화 시킨다. 민감한 정보는 되도록 담지 않는 것이 좋다.
  3. Signature : base64로 인코딩된 첫번째, 그리고 두번째 부분이 완성 되었다면, 원하는 비밀 키(암호화에 추가할 salt)를 사용하여 암호화한다.

토큰기반 인증 절차

  1. 클라이언트가 서버에 아이디/비밀번호를 담아 로그인 요청을 보낸다.
  2. 아이디/비밀번호가 일치하는지 확인하고, 클라이언트에게 보낼 암호화된 토큰을 생성한다.
    access/refresh 토큰을 모두 생성한다.
    토큰에 담길 정보(payload)는 유저를 식별할 정보, 권한이 부여된 카테고리(사진, 연락처, 기타등등)이 될 수 있다.
    두 종류의 토큰이 같은 정보를 담을 필요는 없다.
  3. 토큰을 클라이언트에 보내주면, 클라이언트는 토큰을 저장한다.
    저장하는 위치는 local storage, cookie, react의 state 등 다양하다.
  4. 클라이언트가 HTTP 헤더(authorization 헤더)에 토큰을 담아 보낸다.
    bearer authentication을 이용한다.
  5. 서버는 토큰을 해독하여 "아 우리가 발급해준 토큰이 맞네!" 라는 판단이 될 경우, 클라이언트의 요청을 처리한 후 응답을 보내준다.

토큰기반 인증의 장점

  1. Statelessness & Scalability(무상태성 & 확장성)
  • 서버는 클라이언트에 대한 정보를 저장할 필요 없다.
  • 클라이언트는 새로운 요청을 보낼때마다 토큰을 헤더에 포함시키면 된다.
  1. 안전하다.
  2. 어디서나 생성 가능하다.
  3. 권한 부여에 용잏다.
  • 토큰의 payload 안에 어떤 정보에 접근 가능한지 정할 수 있다.

OAuth

OAuth2.0은 인증을 위한 표준 프로토콜의 한 종류.
보안 된 리소스에 엑세스하기 위해 클라이언트에게 권한을 제공(Authorization)하는 프로세스를 단순화하는 프로토콜 중 한 방법.
OAuth를 활용한다면 자주 사용하고 중요한 서비스들의 ID와 Password만 기억해 놓고 해당 서비스들을 통해서 소셜 로그인을 할 수 있다.
검증되지 않은 App에서 OAuth를 사용하여 로그인한다면, 직접 유저의 민감한 정보가 App에 노출될 일이 없고 인증 권한에 대한 허가를 미리 유저에게 구해야 하기 때문에 더 안전하게 사용할 수 있다.

OAuth 용어

  • Resource Owner : 액세스 중인 리소스의 유저이다. 김코딩의 구글 계정을 이용하여 App에 로그인할 경우, 이때 Resource owner은 김코딩이 된다.
  • Client : Resource owner를 대신하여 보호된 리소스에 액세스하는 응용프로그램이다. 클라이언트는 서버, 데스크탑, 모바일 또는 기타 장치에서 호스팅할 수 있다.
  • Resource server : client의 요청을 수락하고 응답할 수 있는 서버이다.
  • Authorization server : Resource server가 액세스 토큰을 발급받는 서버이다. 즉 클라이언트 및 리소스 소유자를 성공적으로 인증한 후 액세스 토큰을 발급하는 서버를 말한다.
  • Authorization grant : 클라이언트가 액세스 토큰을 얻을 때 사용하는 자격 증명의 유형이다.
  • Authorization code : access token을 발급받기 전에 필요한 code 이다. client ID로 이 code를 받아온 후, client secret과 code를 이용해 Access token 을 받아온다.
  • Access token : 보호된 리소스에 액세스하는 데 사용되는 credentials이다. Authorization code와 client secret을 이용해 받아온 이 Access token으로 이제 resource server에 접근을 할 수 있다.
  • Scope : scope는 토큰의 권한을 정의한다. 주어진 액세스 토큰을 사용하여 액세스할 수 있는 리소스의 범위이다.

소셜 로그인 로직 플로우

profile
윤장원

0개의 댓글