Chapter 1~3.1

1. 웹 보안의 개요

보안의 필요성과 최근 트렌드를 설명

1.1. 보안 대책이 필요한 이유

취약성의 의미와 보안이 중요한 이유

1.1. 1) 취약성은 왜 발생할까?

요구 사항 규정 및 설계 과정에서 보안에 대한 고려가 충분하지 않으면 예상치 못한 입력과 조작이 발생하는 상황에서 웹 어플리케이션을 공격할 수 있는 버그가 생기기도 한다. 안전한 소프트웨어를 개발하려면 설계와 코딩 단계에서 반드시 보안을 의식해야 한다. 또한, 발견하지 못한 취약성을 찾기 위한 테스트도 중요하다.

1.1 2) 비기능 요건의 중요성

소프트웨어의 특성과 관련해 기능 요건과 비기능 요건에 관해 정리

• 기능 요건 (ex. 신용카드 또는 계좌이체 결제 기능)
  • 시스템 사용의 주목적이 되는 기능
  • 사용자의 요구를 만족시킴
  • 구체적으로 이미지화하기 쉬움
• 비기능 요건 (ex. 접속자가 증가하더라도 서버가 다운되지 않을 것)
  • 시스템 사용의 주목적은 아님
  • 사용자의 요구를 직접적으로 만족시키는 것은 아님
  • 직접적이지 않고 이미지화가 어려움

비기능 요건 등급

• 가용성
• 성능 및 확장성
• 운용 및 보수성
• 이행성
• 보안 - 사회적, 경제적 손실을 가져올 수 있는 위협에 대한 대책이 적절히 세워져 있다.
• 시스템 환경 및 생태계

이 책에서는 비기능 요건 중에서도 소프트웨어 개발과 관련된 보안에 관해 설명

1.2. 웹 취약성의 종류와 동향

신뢰성 있는 곳에서 공개하는 보안 지침을 참고

1.2. 1) 안전한 웹사이트를 만드는 법 - 정보처리추진기구

• SQL 인젝션
• OS 커맨드 및 인젝션
• path 파라미터 미체크 / 디렉털 트래버설
• 취약한 세션 관리
• XSS
• CSRF
• HTTP 헤더 인젝션
• 메일 헤더 인젝션
• 클릭재킹
• 버퍼 오버플로
• 접근 제어, 권한 제어 누락

1.2. 2) OWASP Top10 - OWASP

Open Web Application Security Project가 공개한 OWASP Top10 (2021년 버전)

• A01 - 취약성 접근 통제 // 4단계 up
• A02 - 암호화 실패
• A03 - 인젝션 // 4단계 up (XSS)
• A04 - 안전성이 확인되지 않은 설계
• A05 - 보안 설정 실수
• A06 - 취약하고 오래된 컴포넌트
• A07 - 식별과 인증의 실패
• A08 - 소프트웨어와 데이터 무결성 문제
• A09 - 보안 관련 로그와 모니터링 실패
• A10 - SSRF (Server side request forgery) // 새로 추가된 항목

웹 보안 분야에서 중요한 요소는 단순히 입력 값에 대한 미검증보다는 비정상적인 접근의 통제 가능 여부로 변화되었다는 것을 알 수 있다. 이러한 보안의 관점을 반영한 항목이 A10:Server-Side Request Forgery라고 할 수 있다. 2019년 고객 이름, 주소, 사회보장번호, 신용점수 등이 포함된 1억 6천만 명의 사용자 데이터가 유출된 사건이나 Microsoft Exchange Server(CVE-2021-26855) 등 대규모 보안 사건의 원인이 SSRF와 연관됨에 따라 SSRF를 활용한 보안 사고 사례를 분석하여 근복적인 공격의 매커니즘을 이해하는 것이 중요하다.

ℹ️ CVE-2021-26855 공격 시나리오
중국 APT그룹 ‘HAFNIUM’이 미국 내 산업시설을 공격하기 위한 목적으로 사용한 CVE-2021-26855은 Microsoft Exchange Server의 SSRF 취약점을 활용한 대표적인 공격 사례

SSRF 취약점을 통해 HTTP 연결을 생성하고 별도의 인증 과정 없이 사용자 권한으로 exchange server에 접근하여 exchange 주소록 등 exchange server에 저장된 데이터 접근 및 탈취가 가능해지게 된다.

공격 과정을 보다 자세히 살펴보면 SSRF를 하기 위해서는 HTTP request header의 프로퍼티 중 cookie에 value 값으로 X-BEResource가 필요하다. 스크립트나 이미지와 같은 정적 리소스에 별도의 인증 없이 접근하기 위해서는 입력 값 검증기능이 미흡한 X-BEResource를 통해 접근이 가능해진다.

X-BEResource=내부서버호스트/target.xml#~/ecp/15.1.2106.2/scripts/flurry.js

1. HTTP Request Header의 Cookie 프로퍼티에 autodiscover를 요청하는 SSRF 공격 구문을 삽입하여 내부 서버에 자동 검색 요청을 보내 사용자의 LegacyDN을 탈취
   

2. 그 후 탈취한 LegacyDN을 이용해 사용자의 SID를 검색하기 위해 MAPI 자원에 요청을 전송
   

3. 마지막으로 취득한 SID를 이용 /ecp/proxyLogon.ecp엔드 포인트에 요청을 보내 공격자와 내부 서버에 유효한 세션을 활성화
   

CVE-2021-26855 취약점 자체만으로는 내부 서버와 연결하는 수준으로 진입 점을 생성할 뿐인 취약점이지만 해당 취약점은 다른 Exchange Server 취약점과 연계되면 심각한 서버 손상이 발생할 수 있어 높은 CVSS 위험도 점수를 받았다.

2. 실습 준비

Node.js + Express를 사용한 HTTP 서버를 구축하는 예시로 책에 더 자세히 나와있으므로 이 문서에서는 생략하겠습니다.

3. HTTP

HTTP 기본 지식과 HTTPS 구조, 필요성 등

3.1 HTTP 기초

브라우저는 인터넷에서 웹 어플리케이션의 서버를 특정하기 위해 URL과 DNS 방식을 사용한다. DNS와 HTTP는 TCP/IP 방식을 사용한다.

ℹ️ 사용자가 서버와 통신하기 위해 사용하는 소프트웨어와 컴퓨터 기기를 클라이언트라고 한다. 보통 웹 프런트엔드에서는 클라이언트를 브라우저로 한정짓기도 한다.

3.1. 1) URL

호스트명: host name은 각 네트워크 디바이스(컴퓨터)에 할당되는 이름이고 domain은 네트워크에 부여되는 이름

포트 번호: http: 80, https: 443

3.1 2) DNS

• 인터넷에 접속한 모든 기기는 IP 주소가 할당된다. IP 주소는 192.0.2.0/24와 같이 사람이 기억하기 어려운 숫자의 나열이기 때문에 기억 하기 쉬운 호스트명으로 변환해서 사용한다. DNS는 호스트명을 통해 IP 주소를 알 수 있게 해준다.
• IP 주소 검색은 DNS 서버에서 이뤄지므로 브라우저는 DNS 서버에 호스트명을 전송해 IP 주소를 가져온다.
• 브라우저는 DNS 서버에서 받은 IP 주소로 서버에 접속하고 리소스를 요청한다.

3.1 3) TCP/IP

• 데이터 전송 측 컴퓨터는 각 계층에서 헤더(제어 정보)를 생성해 하위 계층으로 데이터를 전달
• 데이터 수신 측 컴퓨터는 각 계층에서 헤더를 꺼내 상위 계층으로 데이터를 전달

상위 프로토콜은 하위 프로토콜로부터 데이터를 받아서 작업을 수행하며 다양한 애플리케이션 계층의 프로토콜은 TCP를 통해서 작동한다. HTTP/1.1과 HTTP/1.2는 TCP 방식으로 작동하지만 HTTP/3는 UDP 방식으로 작동한다. TCP와 UDP는 IP를 통해서 작동한다.

3.1 4) 상태 코드

• 1xx: 현재 처리 중인 정보를 전달
  • 100 Continue: 서버의 처리가 완료되지 않고 현재 요청이 진행 중인 상태를 전달
• 2xx: 정상 처리된 정보를 전달
  • 200 OK: 요청이 정상적으로 완료된 상태를 전달
  • 201 Created: 리소스 생성이 정상적으로 완료된 상태를 전달
• 3xx: 이동(리다이렉트)과 관련된 정보를 전달
  • 301 Moved Permanently: 지정한 리소스가 다른 장소로 이동된 상태를 전달
  • 302 Found: 지정한 리소르가 일시적으로 이동한 상태를 전달하며, 서버의 일시적인 점검 등의 상태에 사용
• 4xx: 브라우저 요청에 문제가 있는 상태를 전달
  • 400 Bad Request: 요청한 데이터의 오류 상태를 전달
  • 404 Not Found: 지정한 리소스가 존재하지 않는 상태를 전달
• 5xx: 서버에 문제가 발생한 상태를 전달
  • 500 Internal Server Error: 서버 내부의 에러 발생 상태를 전달
  • 503 Service Unavailable: 서버가 다운되거나 점검 등의 상태로 일시적으로 처리할 수 없는 상태를 전달

3.1 5) HTTP 헤더

대표적인 Request 헤더

• Host: 서버의 호스트명과 포트 번호를 지정하며 디폴트 포트 번호는 생략
• User-Agent: 요청을 보내는 쪽의 정보를 전달 (ex. 브라우저 버전, OS 버전)
• Referer: 접속을 요청하는 웹 애플리케이션의 URL을 서버에 전달 (ex. Namecheap Parking Page 페이지의 내부 링크를 통해 site-b.com - This website is for sale! - Site Resources and Information. 으로 이동했을 때 https://site-b.com의 Request header에는 Referer: https://site-a.com이 추가된다

대표적인 Response 헤더

• Server: Response에 사용된 서버의 소프트웨어 정보를 브라우저에 전달
• Location: 리다이렉트 URL을 지정

Request와 Response 양쪽 모두에서 사용되는 헤더가 있는데 이를 엔티티 헤더라고 한다

대표적인 엔티티 헤더

• Content-Length: 리소스의 크기를 바이트 단위로 표시
• Content-Type: 리소스의 미디어 종류를 표시 (ex. Content-type: multipart/form-data)

3.1 6) 쿠키를 사용한 상태 관리

• 서버와 통신한 정보를 브라우저 안의 쿠키라는 파일에 보관하는 방식
• 사용자가 페이지를 이동하거나 브라우저를 닫아도 로그인 정보를 유지하기 위해 로그인 정보를 쿠키에 보관한다.

쿠키는 다음과 같은 키: 값의 형식으로 데이터를 보관한다.

SESSION_ID: 1234abcdef

서버에서 쿠키를 브라우저에 저장하기 위해 Response에 Set-Cookie헤더를 전달한다.

Set-Cookie: SESSION_ID = 1234abcdef

페이지를 이동할 때, 폼을 전송하거나 요청이 발생할 때 브라우저는 쿠키를 자동으로 서버에 전송한다.