FrontEnd Security Week 1

March 22, 2025

1주차

chapter 1. 웹 보안의 개요

1.1 보안 대책이 필요한 이유

1.1.1 취약성은 왜 발생할까?

  • 취약성은 상처입기 쉬운 상태를 말한다.

  • 컴퓨터에서 취약성이란 부정한 방법으로 접근하거나 정보를 훔칠 수 있는 상태가 되는 보안상의 버그를 의미한다.

    1.1.2 비기능 요건의 중요성

  • 기능 요건 : 시스템에서 반드시 구현되어야 하는 요건

  • 비기능 요건 : 시스템 사용의 주목적이 되지 않는 요건

1.2 웹 취약성의 종류와 동향

1.2.1 보안 지침에서 확인하는 취약성의 종류와 동향

  1. 안전한 웹사이트를 만드는 법 - 정보처리추진기구
  2. OWASP Top 10 - OWASP

1.2.2 보안 관련 정보 수집

chapter 2. 실습 준비

chapter 3. HTTP

3.1 HTTP 기초

  • 웹 애플리케이션은 서버가 보낸 HTML, CSS, 이미지 등의 리소스 데이터를 사용해 구성된다.

  • 브라우저는 HTTP라고 하는 통신 프로토콜에 따라 서버와 통신해 리소스를 가져오거나 데이터를 생성하고 업데이트 하며 삭제한다.

    3.1.1 URL

  • 인터넷에서 리소스가 위치하는 장소를 나타내는 문자열을 URL이라고 한다.

    image.png

    • 스키마명(프로토콜)
      • 통신 프로토콜을 표시한다.
    • 호스트명
      • 서버의 위치를 표시한다.
    • 포트 번호
      • 서버에서 서비스를 식별하는 번호.
    • 경로
      • 서버에서 리소스의 위치를 표시한다.

    3.1.2 DNS

  • 사용자가 웹 애플리케이션에 접속할 때 브라우저는 먼저 DNS 서버에서 해당 URL의 서버 주소를 확인해야 한다.

  • 브라우저는 URL의 호스트명을 IP 주소로 변환해 서버에 접속한다. 그러나 브라우저는 호스트명의 IP 주소를 알지 못하기 때문에 DNS를 사용해 주소를 확인한다.

    3.1.3 TCP/IP

  • 컴퓨터는 양쪽 모두 정해진 규약에 따라 데이터를 주고 받아야 하는데 이 규약을 통신 프로토콜이라고 한다.

  • TCP와 IP를 포함하는 통신 프로토콜을 총칭해 TCP/IP라고 하며 4계층으로 구성된다.

    3.1.4 HTTP 메시지

  • HTTP는 브라우저와 서버 사이에서 HTTP 메시지라는 정해진 형식에 따라 데이터를 주고 받는다.

  • HTTP 요청

    • HTTP를 사용해 브라우저에서 서버로 요청을 보내는 것을 HTTP 요청이라고 한다.
    • HTTP 요청 메시지는 요청 라인, 헤더, 바디로 구성된다.

  • HTTP 응답 - 브라우저의 요청에 따라 서버가 보내주는 데이터를 HTTP 응답이라고 한다. - HTTP 응답 메시지는 상태 라인, 헤더, 바디로 구성된다.

    3.1.5 HTTP 메서드

  • GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE

    3.1.6 상태코드

  • 1xx

    • 현재 처리 중인 정보를 전달한다.

  • 2xx

    • 정상 처리된 정보를 전달한다.

  • 3xx

    • 이동(리다이렉트)과 관련된 정보를 전달한다.

  • 4xx

    • 브라우저의 요청에 문제가 있는 상태를 전달한다.

  • 5xx - 서버에 문제가 발생한 상태를 전달한다.

    3.1.7 HTTP 헤더

  • HTTP 헤더는 바디의 부수적인 정보와 데이터 송수신에 필요한 정보다.

  • HTTP 헤더는 Request, Response 양쪽 모두에서 사용한다.

  • 대표적인 Request 헤더

    • Host
    • User-Agent
    • Referer

  • 대표적인 Response 헤더

    • Server
    • Location

  • 대표적인 엔티티 헤더

    • Content-Length
    • Content-Type

3.3 안전한 통신을 위한 HTTPS

3.3.1 HTTP의 약점

  • HTTP 통신은 보안과 관련해 크게 세 가지 약점이 있다.
  1. 통신 데이터 도청이 가능한 점
    1. HTTP는 통신 데이터를 암호화하는 시스템은 없다. 따라서 공격자가 통신 경로의 도청이 가능하다면 사용자가 주고 받는 데이터를 훔쳐볼 수 있다.
  2. 통신 상대의 진위 여부 확인이 어려운 점
    1. HTTP는 통신 대상 서버가 실제 서버인지 진위 여부를 확인하는 시스템이 없어서 암호화되지 않은 HTTP 통신 경로는 공격자가 요청 URL로 서버인 척할 수 있다.
  3. 통신 과정에서 데이터 수정 여부가 확인이 안 되는 점
    1. 통신 경로에서는 통신 내용이 올바른지 검증하는 구조가 없다.

3.3.2 HTTP 약점을 해결하는 TLS

  • HTTP의 세 가지 약점을 해결하려면 HTTPS를 사용해 통신해야 한다.
  • HTTPS는 TLS라고 하는 통신 프로토콜을 사용해 HTTP 데이터를 암호화해서 통신하는 구조다.
  • HTTP 데이터 통신을 하기 전에 TLS 핸드셰이크라고 하는 일련의 암호 통신 과정을 진행한다.
  1. 통신 데이터 암호화
    1. TLS는 데이터를 암호화하는 기능과 데이터의 변조를 막는 기능을 제공한다.
    2. 평문 데이터를 암호화하여 전송하면 상대는 암호문을 복호화하여 데이터의 내용을 볼 수 있다.
  2. 통신 상대 검증
    1. TLS는 전자 인증서로 통신 상대를 확인하며, 전자 인증서는 신뢰 가능한 기관인 CA에서 발행한다.
    2. 서버에서 전송된 인증서는 브라우저가 검증하고 다시 브라우저와 OS에 있는 인증서와 대조한다.
  3. 통신 데이터 변경 체크
    1. TLS는 데이터 변조를 체크하는 기능도 제공한다.
    2. TLS는 인증태그 라는 검증용 데이터를 사용하는데 인증 태그는 데이터의 암호화와 동시에 작성되어 상대에게 전송되며, 수신자는 복호화와 동시에 인증 태그를 사용해 암호문의 변조를 체크한다.

3.3.3 HTTPS 도입 권장

  • 웹 애플리케이션 개발자는 사용자 데이터의 보안을 유지하기 위해 모든 페이지에 HTTPS를 도입해야 한다.

    3.3.4 안전한 콘텍스트만 이용 가능한 API

    3.3.5 Mixed Content의 위험성

  • HTTPS를 사용한 웹 애플리케이션에서 HTTP 통신을 사용하는 리소스가 혼재되어 있는 상태를 Mixed Content라고 한다. 웹 애플리케이션이 HTTPS를 도입했다고 하더라도 사용하는 자바스크립트와 이미지 등의 하부 리소스가 HTTP 통신을 사용하면 안전하다고 말할 수 없다.

    3.3.6 HSTS를 사용해 HTTPS 통신 강제하기

  • HSTS 구조를 적용하면 사용자가 HTTPS 통신을 사용하도록 강제할 수 있다. HSTS를 유효화하려면 응답 헤더에 Strict-Transport-Security 헤더를 추가한다. 브라우저는 Strict-Transport-Security 헤더를 받으면 이후의 웹 애플리케이션 요청은 HTTPS를 사용한다.