추가 적립 안내

지금이라도 알아두면 쓸데 있는 취약성 관리 대책 프런트엔드 분야의 발전으로 다양한 기능과 UI를 개발할 수 있게 됐지만, 그만큼 프런트엔드와 관련된 보안 문제도 많아졌다. 이 책은 보안 관련 경험이 적은 프런트엔드 개발자를 대상으로 하며, 프런트엔드 보안 이슈, 취약성을 갖는 구조와 대책을 그림과 코드로 쉽게 이해할 수 있도록 구성했다. 보안 관련 경험이 있는 독자라면 실습을 통해 취약성 대책을 복습하고 최신 보안 정보도 얻을 수 있을 것이다. 보안 사고를 방지하고 취약성을 최소화하는 데 필요한 실무 지식을 빠르게 습득해보자.

빈틈없는 프런트엔드 개발자로 만들어주는 실용적인 보안 책

프런트엔드를 노리는 사이버 공격이 늘어나면서, 파이낸셜IT에서는 2019년 전체 사이버 공격의 40%가 XSS 공격이라고 밝혔다. 해커원에 따르면 XSS 취약점은 버그 현상금 프로그램에서 가장 일반적인 취약점 유형이다. 프런트엔드를 제대로 구현한다면 이러한 XSS 공격뿐만 아니라 여러 사이버 공격을 막을 수 있다. 이 책을 통해 취약성을 조사하고, 근본 원인을 이해하고, 자신의 애플리케이션을 사이버 공격으로부터 보호해보자.

책의 1장에서는 보안의 필요성과 최근 트렌드를 설명하고, 2장에서는 실습을 위한 개발 환경과 HTTP 서버를 구축한다. 3장에서는 HTTP 기본 지식과 HTTPS의 구조, 필요성 등을 살펴보고, 4장에서는 웹 보안의 기본 개념인 동일 출처 정책과 교차 출처 리소스 공유를 알아본다. 5장에서는 XSS, 6장에서는 CSRF, 클릭재킹, 오픈 리다이렉트를 설명한다.

7장에서는 로그인 기능을 중심으로 인증, 인가에 대해 알아본다. 8장에서는 자바스크립트 라이브러리를 사용할 때 발생하는 리스크와 이를 감소시키는 방법을 설명한다. 책을 읽고 난 뒤의 학습 방법과 웹 애플리케이션을 HTTPS로 사용할 수 있는 구조를 알아본다. 또한 한국어판 부록으로 웹 애플리케이션을 만들 때 참고할 수 있는 보안 체크리스트를 제공한다.

저자는 통신 기술이나 암호 기술 등 기초 원리나 기술 스펙 등의 설명은 과감히 생략하고 실무에서 사용하는 지식과 실습 위주로 설명한다. 프런트엔드 개발 실무에서 자신이 안전하게 개발하고 있는지 점검할 수 있는 보안 입문서로, 취약성 대책을 알아보고 최신 보안 정보도 얻을 수 있어 웹 보안을 알아보고 싶은 프런트엔드 개발자에게 좋은 지침서가 될 것이다.

주요 내용

• 보안의 필요성과 최신 보안 트렌드
• HTTP 기본 지식과 HTTPS의 구조 및 필요성
• 동일 출처 정책과 교차 출처 리소스 공유
• XSS, CSRF, 클릭재킹, 오픈 리다이렉트
• 로그인 기능 중심으로 인증 및 인가 알아보기
• 라이브러리 사용 시 보안 리스크 줄이는 방법

옮긴이 머리말 ix

베타리더 후기 xi

머리말 xiii

감사의 말 xvi

CHAPTER 1 웹 보안의 개요 1

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

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

__1.1.2 비기능 요건의 중요성 2

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

__1.2.1 보안 지침에서 확인하는 취약성의 종류와 동향 4

__1.2.2 보안 관련 정보 수집 6

COLUMN 기업이 취약성에 대처하는 방법 6

마무리 7

CHAPTER 2 실습 준비 9

2.1 준비 전 9

__2.1.1 실습 추천 환경 9

__2.1.2 실습에서 사용하는 소프트웨어 9

2.2 Node.js 설정하기 11

__2.2.1 Node.js 설치하기 11

__2.2.2 Node.js 설치 확인하기 12

__2.2.3 npm 설치 확인하기 12

2.3 Node.js + Express를 사용한 HTTP 서버 구축하기 13

__2.3.1 실습 준비와 Express 설치하기 13

__2.3.2 Node.js + Express로 HTTP 서버 구축하기 14

__2.3.3 정적 파일 전달하기 17

__2.3.4 호스트명을 임의로 설정해 로컬 HTTP 서버에 접속하기 18

COLUMN CommonJS와 ECMAScript Modules 19

마무리 19

CHAPTER 3 HTTP 21

3.1 HTTP 기초 21

__3.1.1 URL 22

__3.1.2 DNS 23

__3.1.3 TCP/IP 24

__3.1.4 HTTP 메시지 26

__3.1.5 HTTP 메서드 28

__3.1.6 상태 코드 29

__3.1.7 HTTP 헤더 30

__3.1.8 쿠키를 사용한 상태 관리 32

3.2 HTTP 실습하기 33

__3.2.1 GET과 POST로 데이터 전송하기 33

__3.2.2 상태 코드 확인 및 변경하기 38

__3.2.3 임의로 HTTP 헤더 추가하기 42

3.3 안전한 통신을 위한 HTTPS 45

__3.3.1 HTTP의 약점 45

__3.3.2 HTTP 약점을 해결하는 TLS 47

__3.3.3 HTTPS 도입 권장 49

__3.3.4 안전한 콘텍스트만 이용 가능한 API 50

__3.3.5 Mixed Content의 위험성 51

__3.3.6 HSTS를 사용해 HTTPS 통신 강제하기 53

마무리 56

CHAPTER 4 Origin에 의한 애플리케이션 간 접근 제한 57

4.1 애플리케이션 간 접근 제한의 필요성 57

4.2 동일 출처 정책에 의한 보호 59

__4.2.1 출처 60

__4.2.2 동일 출처 정책 60

__4.2.3 동일 출처에 의해 접근 제한되지 않는 사례 65

4.3 동일 출처 정책에 따른 제한 실습 66

__4.3.1 교차 출처에 요청 전송 제한 확인하기 66

__4.3.2 iframe 내부 교차 출처 페이지에 접근 제한 확인하기 67

4.4 CORS 71

__4.4.1 CORS 방식 72

__4.4.2 단순 요청 73

__4.4.3 Preflight Request 74

__4.4.4 쿠키를 포함하는 요청 전송 80

__4.4.5 CORS 요청 모드 81

__4.4.6 crossorigin 속성을 사용하는 CORS 요청 82

4.5 CORS 실습 84

__4.5.1 교차 출처의 요청을 허가하는 방법 84

__4.5.2 접근 허가 출처를 제한하는 방법 87

4.6 postMessage를 사용해 iframe으로 데이터 전송하기 89

4.7 프로세스 분리에 따른 사이드 채널 공격 대책 91

__4.7.1 사이드 채널 공격을 방어하는 Site Isolation 91

__4.7.2 출처마다 프로세스를 분리하는 구조 93

__4.7.3 Cross-Origin Isolation이 유효한 페이지에서 SharedArrayBuffer 사용하기 95

마무리 96

CHAPTER 5 XSS 97

5.1 능동적 공격과 수동적 공격 97

__5.1.1 능동적 공격 97

__5.1.2 수동적 공격 98

5.2 XSS 99

__5.2.1 XSS 구조 100

__5.2.2 XSS 위협 101

__5.2.3 세 가지 XSS 102

__5.2.4 DOM 기반 XSS 104

__5.2.5 XSS 대책 109

5.3 XSS 방지 실습 121

__5.3.1 적절한 DOM API를 사용하는 방법 121

__5.3.2 URL 스키마를 http/https로 한정하기 125

__5.3.3 XSS 문제를 줄이는 DOMPurify 라이브러리 사용하기 127

5.4 Content Security Policy를 사용한 XSS 대처하기 129

__5.4.1 CSP 개요 129

__5.4.2 Strict CSP 134

__5.4.3 문자열을 안전한 타입으로 사용하는 Trusted Types 138

__5.4.4 Report-Only 모드를 사용한 policy 테스트 143

5.5 CSP 설정 실습하기 146

__5.5.1 nonce-source를 사용한 CSP 설정하기 146

__5.5.2 strict-dynamic을 사용해 동적으로 〈script〉 요소 생성하기 150

__5.5.3 Trusted Types 설정 방법 153

마무리 155

CHAPTER 6 기타 수동적인 공격: CSRF, 클릭재킹, 오픈 리다이렉트 157

6.1 CSRF 157

__6.1.1 CSRF의 구조 157

__6.1.2 토큰을 사용하는 CSRF 대책 159

__6.1.3 Double Submit 쿠키를 사용하는 CSRF 대책 161

__6.1.4 SameSite 쿠키를 사용하는 CSRF 대책 163

__6.1.5 Origin 헤더를 사용하는 CSRF 대책 164

__6.1.6 CORS를 사용하는 CSRF 대책 165

6.2 CSRF 대책 실습 166

__6.2.1 간단한 확인용 로그인 화면 생성 166

__6.2.2 폼 전송 화면 생성하기 170

__6.2.3 피싱 사이트에서 CSRF 공격하기 173

__6.2.4 Double Submit 쿠키를 사용하는 CSRF 대책 174

6.3 클릭재킹 178

__6.3.1 클릭재킹의 구조 178

__6.3.2 클릭재킹 대책 181

6.4 클릭재킹 대책 실습 182

__6.4.1 클릭재킹 공격 재현하기 183

__6.4.2 X-Frame-Options에 의한 클릭재킹 대책 186

6.5 오픈 리다이렉트 187

__6.5.1 오픈 리다이렉트의 구조 187

__6.5.2 URL 검사를 통한 오픈 리다이렉트 대책 189

6.6 오픈 리다이렉트 대책 실습 190

__6.6.1 오픈 리다이렉트 공격 재현하기 190

__6.6.2 URL 검사에 의한 대책 191

마무리 192

CHAPTER 7 인증 ？ 인가 193

7.1 인증과 인가의 차이 193

__7.1.1 인증 193

__7.1.2 인증의 3요소 193

__7.1.3 인가 194

7.2 인증 기능의 보안 리스크 195

__7.2.1 인증 방식의 종류 195

__7.2.2 비밀번호 인증에 대한 공격 196

__7.2.3 비밀번호 인증 공격에 대한 대책 197

7.3 계정 생성 폼 구현 실습 198

__7.3.1 계정 생성 페이지 준비 198

__7.3.2 입력 내용에 따른 type 속성 변경 201

__7.3.3 입력 내용 유효성 검사 204

COLUMN 비밀번호 패턴 조합의 경우의 수 210

__7.3.4 비밀번호 입력 보조하기 211

7.4 로그인 정보 유출에 주의하기 217

마무리 219

CHAPTER 8 라이브러리를 노린 보안 리스크 221

8.1 라이브러리의 사용 221

__8.1.1 오픈소스 소프트웨어의 사용 221

__8.1.2 프런트엔드 라이브러리 상황 222

8.2 라이브러리에 숨어 있는 보안 리스크 223

__8.2.1 서드파티 라이브러리를 경유하는 공격 223

__8.2.2 리뷰가 충분하지 않은 코드에 의한 취약성 223

__8.2.3 계정 탈취에 의한 취약성 224

__8.2.4 의존 관계 상속에 의한 취약성 224

__8.2.5 CDN에서 콘텐츠 변조 225

__8.2.6 CDN에서 취약성을 갖는 버전의 라이브러리 가져오기 226

8.3 라이브러리 사용의 보안 대책 226

__8.3.1 취약성을 확인하는 툴과 서비스 사용 226

__8.3.2 유지보수가 꾸준히 이루어지는 라이브러리 사용하기 230

__8.3.3 최신 버전의 라이브러리 사용하기 230

__8.3.4 하위 자원 무결성을 통한 변조 확인하기 231

__8.3.5 CDN에서 불러오는 라이브러리의 버전 지정하기 232

마무리 233

APPENDIX A 앞에서 다루지 않은 주제 235

A.1 보안 관련 보충학습 235

__A.1.1 책에서 다루지 않은 주제 학습 236

__A.1.2 보안 관련 정보를 얻는 필자의 방법 237

A.2 HTTPS 실습 240

__A.2.1 HTTPS 서버 구현하기 240

__A.2.2 HSTS를 사용해 HTTPS로 통신 강제하기 246

APPENDIX B 한국어판 부록 251

B.1 보안 체크리스트 251

참고문헌 255

찾아보기 260

인터넷에 리소스를 공개할 때는 다른 웹 애플리케이션에서 접속을 반드시 제한해야 한다. 동일 출처 정책은 브라우저에 내장된 접근 제한 방식을 말한다. 브라우저는 웹 애플리케이션 사이에 출처라는 경계를 설정해 서로의 접근을 제한한다. 출처와 같은 기능을 통해 개발자는 특별한 대책을 세우지 않아도 다른 웹 애플리케이션에서의 접근을 제한할 수 있다. (59쪽)

CORS는 교차 출처로 요청을 전송할 수 있는 방식이다. / XML과 fetch 함수를 사용해 교차 출처로 요청을 전송하는 것은 동일 출처 정책에 따라 금지되어 있다. 구체적으로는 교차 출처에서 받은 응답의 리소스에 대한 접근이 금지되어 있다. / 그러나 응답에 포함된 HTTP 헤더에 접속해도 좋다는 허가가 주어진 리소스는 접근이 가능하다. 이때 HTTP 헤더를 CORS 헤더라고 한다. CORS 헤더에는 접근을 허락하는 요청의 조건이 기재되어 있으며, 조건을 만족하는 요청이면 브라우저는 자바스크립트를 사용한 접근을 허가한다. 조건과 일치하지 않으면 자바스크립트로 접근할 수 없고 응답을 파기한다. (72쪽)

저장형 XSS는 데이터베이스에 등록된 데이터가 반영되는 페이지를 보는 모든 사용자에게 영향을 미친다. 반사형 XSS와 달리 공격은 한 번으로 끝나는 것이 아니라 정상적인 요청을 하는 사용자에게도 피해를 줄 수 있다. 서버에 저장된 악성 스크립트를 포함하는 데이터를 삭제하거나 애플리케이션의 코드를 수정하지 않으면 저장형 XSS의 피해는 멈추지 않는다. 이와 같이 지속적으로 XSS 공격이 이뤄지므로 지속형 XSS(persistent XSS)라고도 한다. (104쪽)

토큰을 사용하는 CSRF 대책 중에는 Double Submit 쿠키(이중 전송 쿠키) 방법도 있다. 6.1.2에서 설명한 방식은 요청마다 발행하는 랜덤 토큰을 서버에서 유지해야 한다. 그러나 서버에 토큰을 유지하지 않고 브라우저의 쿠키에 유지하는 방법도 있다. / Double Submit 쿠키는 세션용 쿠키와는 달리 랜덤 토큰 값을 가진 쿠키를 발행하고 이 토큰을 사용해 정상적인 요청인지를 확인하는 CSRF 대책이다(그림 6-3). 정상적인 페이지에서 로그인할 때 세션용 쿠키와 CSRF를 위한 HttpOnly 속성이 부여되지 않은 토큰 값을 갖는 쿠키도 발행한다. (161쪽)

HTTPS 연결을 사용할 때만 쿠키를 보내는 Secure 속성과 자바스크립트에서 접근할 수 없는 HttpOnly 속성도 있다. 통신이 도청됐을 때나 XSS 공격에 의해 로그인 정보나 액세스 토큰이 유출될 우려가 있으므로 로그인 정보나 액세스 토큰을 쿠키에 저장할 때는 반드시 이러한 속성을 설정해야 한다. (218쪽)