1. 브라우저에 ‘naver.com’을 입력하면 내부적으로 어떤 일이 일어나는지 설명해주세요.

①② 사용자가 웹 브라우저를 통해 'naver.com' 주소를 입력함.

③ 사용자가 입력한 URL 주소 중에서 도메인 네임(domain name) 부분을 DNS 서버에서 검색함.

④ DNS 서버에서 해당 도메인 네임에 해당하는 IP 주소를 찾아 사용자가 입력한 URL 정보와 함께 전달함.

⑤⑥ 웹 페이지 URL 정보와 전달받은 IP 주소는 HTTP 프로토콜을 사용하여 HTTP 요청 메시지를 생성함.

이렇게 생성된 HTTP 요청 메시지는 TCP 프로토콜을 사용하여 인터넷을 거쳐 해당 IP 주소의 컴퓨터로 전송됨.

⑦ 이렇게 도착한 HTTP 요청 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 URL 정보로 변환됨.

⑧ 웹 서버는 도착한 웹 페이지 URL 정보에 해당하는 데이터를 검색함.

⑨⑩ 검색된 웹 페이지 데이터는 또 다시 HTTP 프로토콜을 사용하여 HTTP 응답 메시지를 생성함.

이렇게 생성된 HTTP 응답 메시지는 TCP 프로토콜을 사용하여 인터넷을 거쳐 원래 컴퓨터로 전송됨.

⑪ 도착한 HTTP 응답 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 데이터로 변환됨.

⑫ 변환된 웹 페이지 데이터는 웹 브라우저에 의해 출력되어 사용자가 볼 수 있게 됨.

출처

2. 웹 브라우저 공격을 아는대로 설명해주세요.

• SQL Injection

  • 서버에서 실행되는 SQL을 악의적으로 이용하는 공격
  • 이름처럼 기존 SQL에 악의적인 SQL 구문을 삽입하여 데이터 탈취, 삭제 등을 할 수 있다.
  • 방어법
    • SQL에서 특별한 의미를 가지는 문자를 이스케이프한다.
      ex) \n, \t, |, /, &, #, ...
    • 준비된 선언을 사용한다.

• XSS(Cross-Site Scription)

  • 웹 페이지에 악성 자바스크립트를 삽입하는 공격
  • 이 공격을 이용하면 사이트 이용자의 정보를 손쉽게 탈취할 수 있다.
  • 방어법
    • 서버에 데이터를 저장할 때 HTML 필터링을 한 후 데이터베이스에 저장한다.ex) <, >, script, style, &, /, ...
    • 후술할 Reflected XSS나 DOM Based XSS 공격 방어를 위해 서버에서 파라미터 검증을 한다.
    • 혹시나 모를 상황에 대비하여 프론트엔드에서도 필터링이 필요하다.

• CSRF Attack

  • Cross-Site Request Forgery라고 부른다. 공격자가 서비스 사용자를 이용하여 요청을 보내는 공격을 말한다.
    예를 들어 네이버 로그인과 똑같은 화면을 제공하는 피싱 사이트가 있다고 가정해보자. 여기서 사용자가 피싱 사이트인 것을 모르고 아이디와 비밀번호를 입력하고 로그인 버튼을 누른다면 피싱 사이트는 진짜 네이버 로그인 URL에 요청할 수 있다. 만약 CSRF 취약점이 있다면 성공/실패 Response가 내려올 것이다. 이를 이용하여 해커는 계정 정보를 저장하고 진짜 사이트로 이동시킨 후 모른척 할 수 있다. 이러면 사용자는 해킹당했다는 사실조차 모를 수 있다.

  • 방어법

    • Referer Check
      • HTTP Referer를 확인하여 허용된 Referer의 요청만 허락하도록 설정하는 방어 방법이다. 단, HTTP 변조를 통해 쉽게 뚫을 수 있으므로 추천하지 않는다.
    • CSRF Token
      • 모든 요청에 토큰을 발급하여 서버에서 검증하는 방어 방법이다. 발급된 토큰을 서버로 전달하지 않으면 요청이 허락되지 않기 때문에 효과적이다.
    • CAPTCHA
      • 캡챠는 사람이 요청한 것이 맞는지 검증하는 방법이지만 CSRF 공격에도 효과적이다. 사실상 CSRF Token이 하는 것과 똑같고 겸사겸사 로봇 여부 확인도 가능하다.

• Command Injection

  • Command Injection은 쉘을 실행시키는 로직을 이용한 공격이다. 시스템 권한이 탈취되는 것이나 마찬가지기 때문에 매우 치명적이다.

• File Upload Attack

  • 공격 스크립트가 담긴 파일을 서버로 업로드하는 공격이다. WebShell이 가능한 코드가 담긴 파일을 업로드하고 해커가 URL을 통해 접근 가능해지면 Command Injection과 같은 효과를 볼 수 있다.

• JavaScript Injection

  • 브라우저에서 자바스크립트를 삽입시키는 공격이다. 브라우저에서 제공하는 Console을 통해 조작 가능하다. 만약 Client-Side에 민감한 데이터를 넣어놨다면 해당 공격을 통해 탈취가 가능하다.

• DDoS

  • Distributed Denial of Service(분산 서비스 거부 공격)라고 부른다.

  • 분산된 시스템을 이용하여 서버에 비정상적으로 많은 트래픽을 보내 마비시키는 공격이다.
    공격자는 수 많은 PC를 이용하여 서버에 트래픽을 보낸다. 이때 몰래 심어놓은 좀비 PC를 이용할 수도 있고 본인이 사용할 수 있는 PC를 이용할 수도 있다. 많은 트래픽이 발생하면 서비스에 부하가 생겨 느려지거나 서버가 죽을 수 있다.

  • DDoS는 제일 단순한데 제일 막기 힘든 공격이다. 그나마 예방하기 위해선 다음과 같은 것들을 고려할 수 있다.

    • 당장 서버가 죽지 않도록 확장 가능한 분산 시스템을 설계한다.
    • 공격 IP를 필터링한다.
    • 서비스 지역 외의 IP를 막는다.
    • DDoS를 막아주는 전문 업체의 솔루션을 구매한다.

• Dictionary Attack

  • 미리 데이터베이스에 등록해놓은 수많은 문자열을 암호로 대입하는 공격이다. Brute Force의 일종이다.
  • 하나만 걸려라 공격이라고도 볼 수 있다. 많은 웹 사이트에서 간단한 단어로 비밀번호를 등록하지 못하게 하는 이유기도 하다.

• Rainbow Table

  • 평문을 해시 함수로 만든 문자열을 모두 저장시켜 놓은 표를 말한다. 주로 계정 데이터 탈취 후 암호 원문을 알아내기 위해 사용한다.
  • 방어법
    • Salt 사용
    • Key Stretching
    • PBKDF2, BCrypt 등의 암호화 알고리즘 사용 (위 두 가지가 포함된다)

출처

3. RESTful하다는 것은 어떤 의미인지 설명해주세요.

• REST의 정의
  REST(Representational State Transfer)의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미합니다.

  • HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
  • HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
  • 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.

• REST 구성 요소

  • 자원(Resource) : HTTP URI
  • 자원에 대한 행위(Verb) : HTTP Method
  • 자원에 대한 행위의 내용 (Representations) : HTTP Message Pay Load

• REST의 특징

  • Server-Client(서버-클라이언트 구조)
  • Stateless(무상태)
  • Cacheable(캐시 처리 가능)
  • Layered System(계층화)
  • Uniform Interface(인터페이스 일관성)

• REST의 장단점

  • 장점

    • HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
    • HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다.
    • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
    • Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
    • REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
    • 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
    • 서버와 클라이언트의 역할을 명확하게 분리한다.

  • 단점

    • 표준이 자체가 존재하지 않아 정의가 필요하다.
    • HTTP Method 형태가 제한적이다.
    • 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.
    • 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(익스폴로어)

• RESTful이란?

  RESTful이란 REST의 원리를 따르는 시스템을 의미합니다. 하지만 REST를 사용했다 하여 모두가 RESTful 한 것은 아닙니다.

  REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있으며,

  모든 CRUD 기능을 POST로 처리 하는 API 또는,
  URI 규칙을 올바르게 지키지 않은 API 등,

  REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있습니다.

출처

4. 쿠키와 세션의 차이를 설명해주세요.

• 쿠키(Cookie)
  HTTP의 일종으로 사용자가 어떠한 웹 사이트를 방문할 경우,그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일이다.HTTP에서 클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가필요시 정보를 참조하거나 재사용할 수 있다.

  • 특징

    • 이름, 값, 만료일(저장기간), 경로 정보로 구성되어 있다.
    • 클라이언트에 총 300개의 쿠키를 저장할 수 있다.
    • 하나의 도메인 당 20개의 쿠키를 가질 수 있다.
    • 하나의 쿠키는 4KB(=4096byte)까지 저장 가능하다.

  • 동작 순서

    • 클라이언트가 페이지를 요청한다. (사용자가 웹사이트에 접근)
    • 웹 서버는 쿠키를 생성한다.
    • 생성한 쿠키에 정보를 담아 HTTP 화면을 돌려줄 때, 같이 클라이언트에게 돌려준다.
    • 넘겨받은 쿠키는 클라이언트가 가지고 있다가(로컬 PC에 저장) 다시 서버에 요청할 때 요청과 함께 쿠키를 전송한다.
    • 동일 사이트 재방문 시 클라이언트의 PC에 해당 쿠키가 있는 경우, 요청 페이지와 함께 쿠키를 전송한다.

• 세션(Session)
  일정 시간동안 같은 사용자(브라우저)로부터 들어오는일련의 요구를 하나의 상태로 보고, 그 상태를 일정하게 유지시키는 기술이다.여기서 일정 시간은 방문자가 웹 브라우저를 통해웹 서버에 접속한 시점으로부터 웹 브라우저를 종료하여 연결을 끝내는 시점을 말한다.즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 한다.

  • 특징

    • 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장한다.
    • 웹 서버의 저장되는 쿠키(=세션 쿠키)3. 브라우저를 닫거나, 서버에서 세션을 삭제했을때만 삭제가 되므로, 쿠키보다 비교적 보안이 좋다.
    • 저장 데이터에 제한이 없다.(서버 용량이 허용하는 한...)
    • 각 클라이언트 고유 Session ID를 부여한다.
    • Session ID로 클라이언트를 구분하여 각 클라이언트 요구에 맞는 서비스 제공

  • 동작 순서

    • 클라이언트가 페이지를 요청한다. (사용자가 웹사이트 접근)
    • 서버는 접근한 클라이언트의 Request-Header 필드인 Cookie를 확인하여, 클라이언트가 해당 session-id를 보냈는지 확인한다.
    • session-id가 존재하지 않는다면, 서버는 session-id를 생성해 클라이언트에게 돌려준다.
    • 서버에서 클라이언트로 돌려준 session-id를 쿠키를 사용해 서버에 저장한다.
    • 클라이언트는 재접속 시, 이 쿠키(JSESSIONID)를 이용하여 session-id 값을 서버에 전달

• 쿠키와 세션의 차이

  	쿠키(Cookie)	세션(Session)
  저장 위치	클라이언트(=접속자 PC)	웹 서버
  저장 형식	text	Object
  만료 시점	쿠키 저장시 설정 (브라우저가 종료되도, 만료시점이 지나지 않으면 자동삭제되지 않음)	브라우저 종료시 삭제 (기간 지정 가능)
  사용하는 자원(리소스)	클라이언트 리소스	웹 서버 리소스
  용량 제한	총 300개 하나의 도메인 당 20개 하나의 쿠키 당 4KB(=4096byte)	서버가 허용하는 한 용량제한 없음.
  속도	세션보다 빠름	쿠키보다 느림
  보안	세션보다 안좋음	쿠키보다 좋음

출처

5. HTTP와 HTTPS의 차이를 설명해주세요.

• HTTP(Hypertext Transfer Protocol)

  • 서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜
  • HTTP는 인터넷에서 하이퍼텍스트를 교환하기 위한 통신 규약으로, 80번 포트를 사용

• HTTPS(Hyper Text Transfer Protocol Secure)

  • HyperText Transfer Protocol over Secure Socket Layer, HTTP over TLS, HTTP over SSL, HTTP Secure 등으로 불리는 HTTPS는 HTTP에 데이터 암호화가 추가된 프로토콜
  • TTPS는 HTTP와 다르게 443번 포트를 사용하며, 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 암호화를 지원

출처

6. 서버사이드 렌더링이 무엇인가요?

• 서버 사이드 렌더링이란 서버에서 페이지를 그려 클라이언트(브라우저)로 보낸 후 화면에 표시하는 기법을 의미
• 서버 사이드 렌더링을 쓰는 목적은 크게 "검색 엔진 최적화"와 "빠른 페이지 렌더링"
• 서버 사이드 렌더링은 서버쪽 환경 구성과 함께 클라이언트, 서버 빌드에 대한 이해가 필요

출처

7. 진행했던 프로젝트에서 어려웠던 부분을 해결한 경험을 설명해주세요.

8. SQL과 noSQL의 차이를 설명해주세요.

• SQL

  • 장점

    • 명확하게 정의된 스키마, 데이터 무결성 보장
    • 관계는 각 데이터를 중복없이 한번만 저장

  • 단점

    • 덜 유연함. 데이터 스키마를 사전에 계획하고 알려야 함. (나중에 수정하기 힘듬)
    • 관계를 맺고 있어서 조인문이 많은 복잡한 쿼리가 만들어질 수 있음
    • 대체로 수직적 확장만 가능함

  • SQL 사용이 적합한 상황

    • 관계를 맺고 있는 데이터가 자주 변경되는 애플리케이션의 경우
    • 변경될 여지가 없고, 명확한 스키마가 사용자와 데이터에게 중요한 경우

• noSQL

  • 장점

    • 스키마가 없어서 유연함. 언제든지 저장된 데이터를 조정하고 새로운 필드 추가 가능
    • 데이터는 애플리케이션이 필요로 하는 형식으로 저장됨. 데이터 읽어오는 속도 빨라짐
    • 수직 및 수평 확장이 가능해서 애플리케이션이 발생시키는 모든 읽기/쓰기 요청 처리 가능

  • 단점

    • 유연성으로 인해 데이터 구조 결정을 미루게 될 수 있음
    • 데이터 중복을 계속 업데이트 해야 함
    • 데이터가 여러 컬렉션에 중복되어 있기 때문에 수정 시 모든 컬렉션에서 수행해야 함 (SQL에서는 중복 데이터가 없으므로 한번만 수행이 가능)

  • noSQL 사용이 적합한 상황

    • 정확한 데이터 구조를 알 수 없거나 변경/확장 될 수 있는 경우
    • 읽기를 자주 하지만, 데이터 변경은 자주 없는 경우
    • 데이터베이스를 수평으로 확장해야 하는 경우 (막대한 양의 데이터를 다뤄야 하는 경우)

출처

9. 각 언어별 Iterator에 대해 설명해주세요.

10. Git에서 써본 명령어와 사용한 Git flow전략에 대해 설명해주세요.

• Git 기본 명령어
  • git init
    • 새로운 저장소 생성
  • git add
    • 커밋에 단일 파일의 변경 사항을 포함(인덱스에 추가된 상태)
  • git commit -m
    • 커밋 생성(실제 변경사항 확정)
  • git checkout -b
    • 브랜치 생성&이동
  • git push
    • 브랜치를 원격 저장소에 전송
  • git pull
    • 원격 저장소의 변경 내용이 현재 디렉토리에 가져와지고(fetch) 병합(merge)됨
  • git clone
    • 기존 소스 코드 다운로드/복제
• Git flow 전략