HTTPS:
인증서를 기반으로 데이터 제공자의 신원을 보장받을 수 있다.
기존 HTTP 방식보다 더 안전한 통신 프로토콜이다.
공개 키 암호화 (Public-key cryptography) 방식을 사용한다.
최신 프로토콜의 기반이다.
기존의 HTTP를 사용한 통신은 제3자가 중간에 요청을 가로 채갈 경우 데이터를 쉽게 빼낼 수 있었지만, HTTPS를 사용한 통신은 암호화가 되어 있기 때문에 제3자가 중간에 요청을 가로채도 쉽게 복호화 할 수 없습니다.
비대칭 암호화란?
1. 암호화와 복호화에 서로 다른 키를 사용하는 방식이다.
2. public key는 누구에게나 공개해도 되는 키다.
3. public key로 암호화한 데이터는 그에 맞는 private key로만이 복호화가 가능하다.
private key와 public key는 한 쌍이다. public key 소유자 (누구나 소유 가능)는 private key로 암호화된 서버에서 받은 데이터를 복호화가 가능하며, private key 소유자(서버)는 public key로 암호화한 데이터를 복호화가 가능하다. public key는 누구나 가지고 있을 수 있음에도 이런 방식을 사용하는 이유는 공개키가 데이터 제공자의 신원을 보장해 주기 때문이다.
해시 함수에 대한 설명으로 올바른 것은?
해시 함수는 시간이 들지만 해독이 가능하다.
SHA-256 알고리즘을 사용했을 경우 입력값의 길이와 관계없이 출력값의 길이는 언제나 동일하다.
해시 알고리즘은 특정 입력값에 대해 항상 같은 해시값을 리턴한다.
극히 드물게 다른 입력값인데 해시된 값이 같은 경우가 발생할 수 있다.
쿠키에 대한 설명으로 올바른 답을 고르세요.
쿠키가 삭제되는 경우: MaxAge 또는 Expires 옵션이 설정되는 쿠키의 경우 설정된 시간이 지난 이후 자동으로 제거합니다. 해당 옵션이 없는 경우, 대부분의 브라우저에서는 쿠키를 지우지 않으므로, 쿠키는 보존됩니다. 현재의 브라우저는 쿠키를 지우지 않는 것이 기본 옵션입니다.
httpOnly 옵션을 사용하면 자바스크립트를 이용해서 쿠키에 접근할 수 없습니다.
sameSite=none은 모든 요청에 대해 쿠키를 주고받을 수 있지만 Secure 옵션, 즉 HTTPS 프로토콜을 사용하는 것이 필수적입니다.
요청하는 서버의 도메인, 경로, sameSite 등의 조건이 맞아떨어질 경우 같이 전송된다.
쿠키를 사용할 수 있는 옵션
domain - 서버와 요청의 도메인이 일치하는 경우 쿠키 전송
path - 서버의 요청의 세부 경로가 일치하는 경우 쿠키 전송
maxage/expires - 쿠키의 유효기간 설정
httpOnly - 스크립트의 쿠키 접근 가능 여부 설정
secure - HTTPS 프로토콜에서만 쿠키 전송 여부 설정
sameSite - 같은 사이트에서만 쿠키를 사용할 수 있게 하는 설정
쿠키의 sameSite 옵션의 설명으로 올바른 것을 모두 고르세요.
Lax: 사이트가 서로 달라도, GET 요청이라면 쿠키 전송이 가능하다.
Strict: 사이트가 서로 다르면, 쿠키 전송을 할 수 없다.
None: 사이트가 달라도, 모든(GET, POST, PUT 등등) 요청에 대해 쿠키 전송이 가능하다.
session 기반 인증 방식이란?
서버에 접속 상태가 저장된다.
세션은 보통 하나의 서버에서만 접속 상태를 저장한다. 여러 개의 서버에서 같은 세션 데이터에 접근하려고 한다면 session clustering 혹은 공통 session store를 사용해야 하는 번거로움이 있다. (고로 불가능한 것은 아니다.) 여러 개의 서버를 가지고 있을 때 유리한 것이 아니다.
신뢰할 수 있는 유저인지 확인이 가능하다.
Cookie에 세션 아이디가 저장된다.
CSRF (cross site request forgery)
CSRF는 사용자가 보내는 요청을 다른 사이트(오리진이 아님)에서 위조하는 것이다. 쿠키 방식의 인증을 사용하는 곳에서 사용이 가능하며 sameSite 옵션을 none이 아닌 것으로 사용하면, 서버는 클라이언트에 따라 신뢰할 수 있는 요청인지 아닌지를 판단할 수 있으므로, CSRF 공격을 방지할 수 있다.
해커는 GET에서 parameter를 바꾸어 변조된 요청을 보내게 할 수 있으며, POST의 경우도 쿼리 문자열(x-www-form-urlencoded)변조가 가능하므로 공격할 수 있다. Cross origin의 경우 CORS 설정은 CSRF를 막는 데 도움을 줄 수 있다.
악성 스크립트가 담긴 사이트를 열거나 링크를 클릭할 때, 변조된 요청을 보내는 공격이다.
기존의 로그인한 기록을 바탕으로 서버가 클라이언트의 요청을 믿기 때문에 발생한다.
sameSite 옵션을 none이 아닌 것으로 바꾸어 CSRF 공격을 막을 수 있다.
GET이나 POST 메소드의 경우 CSRF 공격을 받을 수 있다.
- 세션 기반 인증 대신 토큰 기반 인증의 사용을 고려한다면 그 이유는 무엇인가요?
서버의 부담을 덜어주기 위해서,
여러 개의 서버를 사용하는 서비스를 운영할 때
앱의 확장을 고려하고 있어서
세션 기반 인증은 서버(혹인 DB 통합)에 유저에 대한 정보를 저장하고 있다. 즉, 메모리 공간을 서버 쪽에서 차지하고 있고, 자원을 사용하고 있으므로 유저가 많으면 많을수록 성능이 떨어지기 마련이다. (사용하는 유저가 많으면 토큰 기반 인증이어도 과부하가 될 수 있겠지만, 세션 기반 인증만큼은 아니다.) 어느 한쪽이 더 안전한 인증 방식이라고는 얘기할 수 없지만, 앱의 확장을 고려한다면 (여러 개의 서버를 사용하며 점점 커져가는 앱이라면), 토큰 기반 인증을 사용하는 것을 고려해 봐야 할 것이다.
JWT의 구조에 대한 설명
Header: 어떤 종류의 토큰을 사용하는지 적혀있다. 어떤 알고리즘으로 암호화하는지 적혀있다.
Payload: 권한 정보가 담겨있다. 암호화 되어 있다. 유저의 아이디, 연락처 목록 등의 내용이 담겨있다. 비밀번호 같은 민감한 개인 정보는 담지 않는다.
Signature: Header와 Payload를 인코딩한 값과 salt 값의 조합으로 암호화되어 있다.
