보안/인증
1. CORS에 대해 설명해주세요. 레퍼런스
: 많은 웹 어플리케이션들이 리소스들을 각각의 출처로부터 읽어온다. 웹 어플리케이션이 자기 자신이 속하지 않은 다른 도메인, 다른 프로토콜, 다른 포트에 있는 리소스를 요청하면 웹 어플리케이션은 cross-origin HTTP 요청을 실행한다.
이 때 브라우저는 보안상의 이유로 스크립트 안에서 시작되는 cross-origin HTTP 요청들을 제한한다. 예를 들어 XMLHttpRequest와 Fetch API는 동일 출처 원칙이 적용된다. 이는 웹 어플리케이션이 자기가 로드되었던 그 origin과 동일한 origin으로 리소스를 요청하는 것만 허용한다는 뜻이다. 다른 origin으로부터의 응답이 올바른 CORS header를 포함하지 않는다면 말이다.
다른 도메인의 img파일이나 css파일을 가져오는 것은 모두 가능하다. 그러나 스크립트 태그 안의 스크립트에서 생성된 Cross-site HTTP Request는 Same-origin policy를 적용받아 Cross-site HTTP Request가 제한된다.
동일 출처로 요청을 보내는 것(Same-origin requests)은 항상 허용되지만 다른 출처로의 요청(Cross-origin requests)은 보안상의 이유로 제한된다는 뜻이다. 그러나 AJAX가 널리 퍼지면서 스크립트 태그 안의 스크립트에서 생겨난 XMLHTTPRequest에서도 Cross-site HTTP Requests의 필요성이 매우 커졌다. 그래서 W3C(월드 와이드 웹을 위한 표준을 개발하고 장려하는 조직)에서 CORS라는 이름으로 새로운 표준을 내놓게되었다.
즉, 기존에는 보안상의 이유로 XMLHttpRequest가 자신과 동일한 도메인으로만 HTTP 요청을 보내도록 제한하였으나 웹 개발에서 다른 도메인으로의 요청이 꼭 필요하게 되었다. 그래서 XMLHttpRequest가 cross-domain을 요청할 수 있도록 CORS라는 것이 만들어졌다.
W3C 명세에 의하면 브라우저는 먼저 서버에 Preflight request(예비 요청)를 전송하여 실제 요청을 보내는 것이 안전한지 OPTIONS method로 확인한다. 그리고 서버로부터 유효하다는 응답을 받으면 그 다음 HTTP request 메소드와 함께 Actual request(본 요청)을 보낸다. 만약 유효하지 않다면 에러를 발생시키고 실제 요청은 서버로 전송하지 않는다.
2. SSL 인증서 암호화 기법인 대칭키 암호화 기법, 공개키 암호화 기법에 대해 설명해주세요. 레퍼런스
: SSL 인증서는 클라이언트와 서버 간의 통신을 제3자가 보증해주는 전자화된 문서이다. 클라이언트가 서버에 접속한 직후 서버는 클라이언트에게 SSL 인증서 정보를 전달하고, 클라이언트는 이 인증서 정보가 신뢰할 수 있는 것인지를 검증 한 후에 절차를 수행하게 된다.
모두에게 알려져있는 공개키(비대칭키)로 전송할 데이터를 암호하하여 전송하면, 데이터를 수신하는 쪽에서 비공개키로 이를 복호화 한다. 클라이언트, 서버 모두 각자의 공개키/비밀키를 가지고 있으며 데이터를 전송 할 때는 상대에게 공개키를 요청하여 암호화하여 전송하고 데이터를 복호화할 때는 자신의 비밀키를 사용한다. 속도가 느리다는 단점이 있다.
공유한 대칭키로 데이터를 암호화하여 전송하면, 데이터를 수신하는 쪽에서 공유한 대칭키로 이를 복호화 한다. 최초 통신시 암호화, 복호화에 사용할 키를 주고 받으므로 통신속도가 빠르다는 장점이 있지만, 처음 키를 공유할 때는 해당 키를 암호화 하지 않고 평문으로 키를 전송하기 때문에 보안상 취약점이 생기는데 이를 키분배의 문제라고 한다.
공개키 방식은 암/복호화 과정에서 컴퓨팅 파워를 많이 사용하기 때문에, 성능상의 많은 단점이 생긴다. 따라서, SSL은 공개키와 대칭키를 혼합해서 사용한다.
- 대칭키를 공유할 때 사용하는 암호화 기법 = 공개키방식
- 실 데이터를 공유할 때 사용하는 암호화 기법 = 대칭키 방식
클라이언트와 서버가 주고 받는 실제 정보는 대칭키 방식을 사용하고, 대칭키를 공유할 때는 공개키 방식을 이용하여 대칭키를 주고 받는다.
3. OAuth에 대해서 간단히 설명해주세요.
: OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다. 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용한다.
4. Session과 Cookie 그리고 Token의 차이에 대해 설명해주세요. 레퍼런스 레퍼런스2
(얄코 쿠키: 사이트를 방문하고 이용할 때 브라우저(내가 갖고 있는 정보)에 저장되는 내용, 사용자가 임의로 고치거나 지울 수 있고, 남이 훔처보거나 도둑질하기 쉬움 --> 민감하거나 중요한 정보 X, 로그인창의 아이디 자동완성, 공지 메세지 하루 안보기, 쇼핑몰에서 로그인 안 한 상태로 장바구니에 물건 담기등 사용자의 편의를 위하되 지워지거나 조작되거나 가로채이더라도 큰 일 없을 수준의 정보들을 브라우저에 저장되는데 사용
세션: 쿠키에 저장하기 곤란한 정보들을 관리, 세션을 사용하는 사이트에 접속하면 서버에서 사용자를 구분하기 위한 기한이 짧은 임시 키 하나를 브라우저에 보내서 쿠키로 저장, 사용자가 페이지를 돌아다닐 때, 사용자의 중요 정보들은 서버의 메모리나 DB에 저장됨, 브라우저가 사이트의 페이지에 접속할 때마다 HTTP요청에 이 키가 담긴 쿠키를 실어서 전송하고 서버는 그 키를 보고 사용자를 인식해서 사용자의 정보를 가공해서 응답으로 보내줌, 사용자나 다른 누군가에게 노출되어서는 안 되는 서비스 제공자가 직접 관리해야 할 정보들은 세션으로 서버 안에서 다뤄짐, 세션을 남발하면 접속자가 많을 때 서버에 부하가 걸림
캐시: 웹뿐만 아니라 메모리 부분이나 안드로이드 등 다양한 곳에서 쓰임, 가져오는데 비용이 드는 데이터를 한 번 가져온 뒤에는 임시로 저장해두는 것, 웹캐시는 정보를 불러올 때 데이터 사용량도 발생하고 시간도 들기 때문에 사용자가 여러번 방문할 법한 사이트에서는 한 번 받아온 데이터를 사용자 컴퓨터 또는 중간 역할을 하는 서버에 저장해둠)
토큰: 인증받은 사용자들에게 토큰을 발급하고, 서버에 요청을 할 때 헤더에 토큰을 함께 보내도록 하여 유효성 검사를 한다. 이러한 시스템에서는 더이상 사용자의 인증 정보를 서버나 세션에 유지하지 않고 클라이언트 측에서 들어오는 요청만으로 작업을 처리한다. 즉, 서버 기반의 인증 시스템과 달리 상태를 유지하지 않으므로 Stateless한 구조를 갖는다. 토큰 기반의 인증 방식은 사용자가 로그인이 되어있는지 안되어있는지 신경쓰지 않고 손쉽게 시스템을 확장할 수 있다.
