Web 관련 면접 질문 준비

작년 그리고 올해초 펄어비스와 에이블리 코딩 테스트를 겪으면서, 웹 쪽 지식에 대한 부족함을 느껴서 이번에는 Web 쪽과 관련한 공부를 진행했다.

 

Web 관련 면접 질문 준비

 

목차

 

1. 면접 질문 및 대답

추천글

위의 목차를 클릭하면 해당 글로 자동 이동 합니다.

 

면접 질문 및 대답

1. CSRF (Cross-Site Request Forgery)란?

- 공격자가 사용자의 인증된 세션을 이용해 악의적인 요청을 서버로 보내는 공격이다.

- 사용자가 정상 웹 사이트에 로그인한 뒤, 악의적인 사이트를 방문하게 되면, 악성 스크립트를 통해 사용자의 쿠키로 서버에 공격이 전송된다.

- 이것을 방지하기 위해 CSRF 토큰을 사용한다.

- 랜덤 문자열로 서버 쿠키와 함께 저장되며, 모든 요청에 포함되어야 한다.

- 이 토큰은 브라우저에 저장된다. 대부분 HTML 내부 어딘가에 Hidden으로 숨어있으며 사용자의 요청에 같이 포함된다.

- 서버는 세션 발급과 동시에 CSRF 토큰을 발급하며, 요청시 매번 검증한다.

- XSS 공격에 의해 CSRF 토큰도 탈취될 위험이 존재한다.

 

2. XSS (Cross-Site Scripting)란?

- 공격자가 사이트에 악의적인 스크립트를 싣고 사용자를 유도한다. 사용자가 접근 시 스크립트가 동작한다. 이 스크립트는 URL에 심을 수도 있고, 게시글 같은 곳에 삽입할 수 있다. 스크립트가 실행되게 되면 사용자의 쿠키와 같은 정보들을 공격자의 서버로 전송시키는 식으로 탈취한다. 스크립트의 경우 localStorge나 sessionStorge에 접근이 가능하기 때문에 해당 공간에 저장된 정보들을 가져오는 것도 가능하다.

- CSRF가 사이트가 사용자를 신뢰해서 발생하는 것이라면, XSS는 사용자가 사이트를 신뢰해서 발생하는 문제이다.

 

3. 그러면 사용자 정보가 담긴 토큰을 어디에 담는 것이 적절할까?

- 어느 한 곳이 안전하지 않기 때문에, JWT와 같은 토큰 인증 방식에서는 AccessToken과 RefreshToken, 두 개의 토큰을 각각 다른 장소에 저장하는 형태로 사용한다.

- localStorge: CSRF 공격에는 안전하지만, XSS에는 취약하다.

- Cookie: httpOnly 옵션을 설정하면 XSS 공격에는 안전하다. 하지만 CSRF에는 취약하다.

- AccessToken: JS의 Private 변수에 담아둔다. 하지만 이것은 휘발성이기 때문에 매번 받아와야 하는 소요가 존재한다.

- RefreshToken: httpOnly, Secure, Same-site와 같은 보안 설정을 해둔 상태에서 쿠키에 담는다.

- 사용자는 매 요청마다 AccessToken과 RefreshToken을 서버로 보낸다.

- 이때, 중요한 것은 AccessToken의 경우 요청의 바디에 담아 보내고, 새로 받아오는 AccessToken 역시 응답의 바디에 포함되도록 한다.

- 왜냐하면, CSRF 공격을 통해 나의 RefreshToken을 기반으로 새로운 AccessToken을 받는다 하더라도 응답은 사용자에게만 전달되기 때문에 AccessToken을 공격자가 알 수 없다.

- 그러면 이런 질문이 생길 수 있다.

3-1. RefreshToken이 아예 탈취당해 공격자가 AccessToken을 발급 요청한다면?

- 현재의 설계대로 작동한다면, RefreshToken만 가지고 AccessToken을 발급받을 수 없지만, 만약 가능하다고 하더라도 CORS (Cross-Origin Resource Sharing) 정책으로 인해서 같은 서버가 아니면 응답을 제공받을 수 없다. 이런 것을 보면 CORS 정책이 우리를 엄청 괴롭히지만 중요하다는 것을 알 수 있다.

- 근데 이런 상태면 또 다른 꼬리 질문이 들 수 있다.

3-2. CORS 정책이 있으면, CSRF는 소용없는 것 아닌가?

- 당연하게도 아니다. CORS의 경우 응답을 제공하지 않는 것이기 때문에 요청은 서버에 그대로 전달된다.

- 악의적인 공격 내용이 담긴 요청을 보냈을 때, 응답을 받지 못할 뿐 서버는 해당 요청을 처리한 상태이다.

- 그러니 CSRF 토큰은 필요하다고 볼 수 있다.

 

4. HTTPS의 암호화 방식

- 암호화된 데이터 전송 프로토콜로는 SSL과 TLS가 있는데, SSL의 취약성을 해결한 TLS가 주로 쓰인다.

- 현대의 SSL 인증서도 대부분 실제로는 TLS라고 한다.

 

1) 대칭키 암호화:

- 암호화, 복호화에 같은 키를 사용한다. 연산 속도가 빠르지만 키 전달 과정에서 키를 탈취당할 수 있으며, 그러면 문제가 발생한다. 즉, 키 관리가 어렵다.

 

2) 비대칭키 암호화:

- 암호화, 복호화에 서로 다른 키가 사용된다(공개키, 비밀키).

- 데이터를 공개키로 암호화해서 보내면, 서버는 개인키로 복호화한다.

- 주고 받는 키가 공개키이기 때문에 키가 탈취당하더라도 해당 키로 데이터를 복호화하는 것은 불가능하다.

- 즉, 키 교환 문제는 해결할 수 있다. 그러나 대칭키 암호화에 비해 연산 속도가 느리다.

 

3) 하이브리드 방식:

- 현대적인 방식이다.

- 데이터는 대칭키로 암호화하고, 대칭키를 공개키로 암호화해서 서버에 전달한다.

- 키 교환이 안전하며, 연산 속도도 빠르다.

 

5. SSL인증서 동작 원리

1) 서버는 공개키와 비밀키를 생성한다.

2) 서버는 인증서를 받기 위해 서버의 공개키와 서버 정보를 인증 기관(CA: Certificate Authority)에 제공한다.

3) 인증 기관은 서버의 정보를 담은 SSL 인증서를 발급한다.

4) 인증 기관은 해당 인증서에 서명을 위해 인증 기관의 공개키와 비밀키를 생성한다. 인증서는 비밀키에 의해 서명된다.

 

- 서명 과정?

- 인증 기관은 서버의 공개키를 해시해서 해시값을 인증서에 등록한다.

- 이 해시값을 Finger Print (지문)이라고 한다.

- 이 지문을 인증 기관의 비밀키로 암호화해 인증서에 '서명'으로 등록한다.

- 브라우저는 사이트 접속시 인증 기관의 공개키를 받게 되는데, 이 공개키를 이용해 서버의 서명을 복호화하여 인증서의 지문과 대조한다.

- 인증서가 유효하다고 판단되면, 인증서에 있는 서버의 공개키를 추출한다.

 

이해가 잘 되지 않을까봐, 그림으로 대충 인증서를 그려보았다.

 

6. 클라이언트와 서버의 HTTPS 통신 과정

1) 클라이언트가 서버에 연결을 시도하면, SSL 인증서를 받는다.

2) 앞에서 설명한 과정을 통해 클라이언트는 인증서를 검증한다.

3) 데이터를 암호화하기 위해 클라이언트는 대칭키를 생성한다.

4) 인증서에서 추출한 서버의 공개키로 방금 생성한 대칭키를 암호화한다.

5) 서버로 암호화된 대칭키를 전달한다.

6) 서버는 전달받은 것을 비밀키로 복호화해 대칭키를 얻는다.

7) 이제 클라이언트와 서버는 안전한 통신이 가능하다.

 

7. DNS 작동 원리

- 아주 간단하게 설명할 예정이다.

- LocalDNS에 도메인 정보를 요청한다. LocalDNS는 통신사라고 생각하면 된다.

- 만약 여기서 찾을 수 없다면 RootDNS에 요청한다.

- 또 찾을 수 없다면 TLD DNS에 요청한다.

- 또 찾을 수 없다면 AuthoritativeDNS에 요청한다. Sub DNS라고도 하는 것 같다. 이것은 호스팅 업체의 네임서버를 얘기한다.

- 반환받은 IP 주소를 LocalDNS는 캐싱하고, 클라이언트에게 전달한다.

 

다음 시간에는 www.google.com에 에 접속할 때, 어떤 일이 벌어지는 지 이런 것들을 공부해보면 좋을 것 같다.

 

추천글

https://kdeon.tistory.com/m/132

HTTPS 통신 동작 원리 (SSL, TLS)

https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-DNS-%EA%B0%9C%EB%85%90-%EB%8F%99%EC%9E%91-%EC%99%84%EB%B2%BD-%EC%9D%B4%ED%95%B4-%E2%98%85-%EC%95%8C%EA%B8%B0-%EC%89%BD%EA%B2%8C-%EC%A0%95%EB%A6%AC

🌐 DNS 개념 & 동작 ★ 알기 쉽게 정리