[5주차/엘리] 워크북 제출합니다.

keyword/Chapter_05/CSP.md

@@ -0,0 +1,143 @@
+# 서버에서 HTML 문서를 응답할 때 CSP를 적용하려면 어떤 HTTP 응답 헤더를 설정해야 하나요? 블로그에 나온 Express.js 코드 예시를 기반으로 설명해보세요.
+
+서버에서 HTML 보낼 때 아래 헤더 설정
+
+👉 `Content-Security-Policy`
+
+Express.js 예시
+
+```jsx
+app.use((req,res,next) => {
+res.setHeader(
+"Content-Security-Policy",
+"default-src 'self'"
+  );
+next();
+});
+```
+
+→ 의미:
+
+브라우저한테 “이 페이지에서 어떤 리소스 써도 되는지” 규칙을 내려주는 것
+
+# `default-src 'self'` 설정은 브라우저에게 어떤 보안 정책을 의미하나요? 또한 `'self'` 값은 어떤 출처를 포함하거나 제외하나요?
+
+    기본 규칙으로, “모든 리소스는 같은 출처에서만 가져와라” 라는 뜻
+
+    ### 포함되는 것
+
+    - 같은 도메인
+    - 같은 프로토콜
+    - 같은 포트
+
+    ### 제외되는 것
+
+    - 다른 도메인 (ex. google.com)
+    - 다른 프로토콜 (http vs https)
+    - 서브도메인도 기본적으로 다름
+
+    즉 완전히 동일한 origin만 허용됨
+
+# 블로그에 나온 악성 스크립트(`<script>fetch(...)</script>`)를 주입했을 때 CSP가 어떻게 동작하는지 네트워크 탭과 콘솔 메시지 측면에서 설명해보세요.
+
+    예시
+
+    ```html
+    <script>fetch("https://evil.com")</script>
+    ```
+
+    ### 네트워크 탭
+
+    - 요청 자체가 안 나감
+    - 아예 차단됨
+
+    ### 콘솔
+
+    - 아래와 같은 에러가 뜸
+
+    ```
+    Refused to connect because it violates CSP
+    ```
+
+    👉 정리
+
+    코드 실행 자체를 막아버림 + 외부 요청도 안 나감
+
+# 기본 CSP 설정에서 인라인 스타일이 차단된다고 했습니다. 블로그 예시 중 `width:600px`이 적용되지 않는 이유를 설명하세요.
+
+    기본 CSP는 인라인 코드를 차단함
+
+    이유:
+
+    - 인라인 스타일/스크립트가 XSS 공격 경로라서 기본적으로 막아둔 것
+# 구글 애널리틱스, 카카오맵, 외부 API 등이 CSP 때문에 차단될 수 있다고 했습니다. 이러한 현상을 "건물 보안을 강화한다"는 비유와 연결해 설명해보세요.
+
+    CSP를 건물 보안으로 보면
+
+    - `default-src 'self'`
+    → “우리 건물 직원만 출입 가능”
+
+    근데
+
+    - 구글 애널리틱스
+    - 카카오맵
+    - 외부 API
+
+    다 외부 사람으로 취급되기 때문에 전부 출입 금지됨
+
+    해결:
+
+    → “이 사람은 들어와도 됨” 이렇게 허용 추가해야 함
+
+# Report-Only 모드에서는 실제 리소스 실행이 차단되지 않습니다. 그 대신 브라우저와 서버에서 각각 어떤 동작을 수행하나요?
+
+    헤더:
+
+    `Content-Security-Policy-Report-Only`
+
+    ### 브라우저
+
+    - 차단 안 함
+    - 그냥 실행은 시켜줌
+
+    대신
+
+    - “이거 원래 차단해야 하는데?” 로그 남김
+
+    ### 서버
+
+    - 위반 내용 받아서 기록함
+
+    막는 게 아니라 테스트 + 모니터링용
+
+# CSP만으로는 CSRF를 막을 수 없다고 했습니다. 블로그에 정리된 다른 보안 조치들(SameSite 쿠키, X-Frame-Options 등) 중 2가지를 설명하세요.
+
+    CSP는 “어디서 리소스 가져오냐”만 막는 것
+
+    CSRF는 “사용자 인증된 요청을 다른 사이트에서 보내는 공격”
+
+    → 성격이 달라서 CSP로 못 막음
+
+    ---
+
+    ### 1. SameSite 쿠키
+
+    ```
+    Set-Cookie: SameSite=Strict
+    ```
+
+    → 다른 사이트에서 요청 보내면 쿠키 안 붙음
+
+    그래서 로그인 정보 못 씀 = CSRF 방지됨
+
+    ---
+
+    ### 2. X-Frame-Options
+
+    ```
+    X-Frame-Options: DENY
+    ```
+
+    → 다른 사이트에서 iframe으로 못 띄움
+
+    클릭 유도 공격 (클릭재킹) 막음

keyword/Chapter_05/abac.md

@@ -0,0 +1,80 @@
+# **RBAC**의 한계에 대해 설명해주세요.
+
+    RBAC는 역할(Role) 기반으로 권한 주는 방식임
+
+    ### 문제점
+
+    1. 역할이 너무 많아짐
+        - 상황마다 역할 계속 추가됨
+        - 관리 복잡해짐 (role explosion)
+    2. 상황 반영이 어려움
+        - 시간, 위치, 상태 같은 조건 반영 못 함
+        - 예: “근무 시간에만 접근” 이런 거 표현 힘듦
+    3. 유연성 부족
+        - 단순히 “누구냐”만 보고 판단함
+        - “지금 어떤 상황이냐”는 고려 못 함
+
+    정리
+
+    정적이고 단순해서 현실적인 접근 제어에는 한계 있음
+
+# **ABAC**으로의 전환, 어떤 '기준'이 적절할까요?
+
+    ABAC는 속성(Attribute) 기반임
+
+    전환 기준은 “상황 기반 제어가 필요한지”임
+
+    ### 적절한 기준
+
+    1. 사용자 속성
+        - 부서, 직급, 고용 형태
+    2. 리소스 속성
+        - 데이터 민감도, 문서 종류
+    3. 환경 조건
+        - 시간, 위치, IP, 디바이스
+    4. 행위 조건
+        - 조회인지 수정인지
+
+    정리
+
+    “누가 + 무엇을 + 언제 + 어떤 상황에서”까지 필요하면 ABAC 가야 함
+
+# 어떤 서비스 영역에 **RBAC**을 남겨두고, **ABAC**을 도입하시겠어요?
+
+    ### RBAC 유지하는 영역
+
+    - 관리자 / 일반 사용자 구분
+    - 기본 메뉴 접근 권한
+    - 단순한 권한 구조
+
+    → 이유: 단순하고 관리 쉬움
+
+    ---
+
+    ### ABAC 도입하는 영역
+
+    - 개인정보, 금융 데이터
+    - 내부 문서 접근
+    - API 접근 제어
+
+    → 이유: 조건 기반 제어 필요
+
+    예
+
+    - “재무팀 + 근무시간 + 사내망일 때만 접근 가능”
+# 여러분들은 다른 부서에서 요청을 받았을 때 어떤식으로 행동하실껀가요?
+
+    권한 요청 들어왔을 때 무조건 주면 안 됨
+
+    ### 처리 방식
+
+    1. 요청 목적 확인
+        - 왜 필요한지 먼저 확인
+    2. 최소 권한 원칙 적용
+        - 필요한 만큼만 권한 부여
+    3. 기간 제한 설정
+        - 영구 권한 말고 기간 제한
+    4. 로그 남기기
+        - 누가 언제 요청했는지 기록
+    5. 가능하면 ABAC 조건으로 처리
+        - 상황 기반으로 제한 걸기

keyword/Chapter_05/same-origin-policy.md

@@ -0,0 +1,136 @@
+# 출처(Origin)는 어떤 세 요소의 조합으로 결정되나요?
+    - 프로토콜 (http / https)
+    - 도메인 (example.com)
+    - 포트 (80, 443 등)
+
+    이 3개가 모두 같아야 같은 출처
+
+# 출처의 요소가 다른 경우(예: 프로토콜만, 포트만 다른 경우)에 같은 출처인지 아닌지를 예시 3개(같은 출처 1개, 다른 출처 2개)로 설명하세요.
+
+    ### 같은 출처 (1개)
+
+    ```
+    https://example.com:443
+    https://example.com
+    ```
+
+    → https 기본 포트가 443이라서 같은 출처로 봄
+
+    ---
+
+    ### 다른 출처 (2개)
+
+    1. 프로토콜 다른 경우
+
+    ```
+    http://example.com
+    https://example.com
+    ```
+
+    → 프로토콜 다름 → 다른 출처
+
+    1. 포트 다른 경우
+
+    ```
+    https://example.com:3000
+    https://example.com:8080
+    ```
+
+    → 포트 다름 → 다른 출처
+
+# 블로그에 나온 `fetch` 기반 악성 스크립트를 다른 출처로 실행했을 때 브라우저에서 어떤 일이 발생하나요? 네트워크 전송 여부, 응답 사용 가능성, 브라우저 콘솔 메시지 측면에서 서술하세요.
+
+    예시
+
+    ```html
+    <script>
+    fetch("https://victim.com/api")
+    </script>
+    ```
+
+    ### 네트워크
+
+    - 요청 자체는 나감
+
+    ### 응답 사용 가능 여부
+
+    - 응답 데이터 접근 불가
+    - JS에서 response 읽을 수 없음
+
+    ### 콘솔
+
+    - SOP/CORS 관련 에러 출력됨
+
+    정리
+
+    요청은 보내지지만 결과를 읽을 수 없어서 공격이 막힘
+
+# SOP가 어떻게 Session Hijacking(세션 하이재킹) 시도를 방지하는지 구체적으로 설명하세요. SOP가 차단하는 것과 허용되는 것(예: 네트워크 요청은 나가지만 응답 데이터에 접근 불가)을 포함하세요.
+
+    세션 하이재킹은
+
+    다른 사이트에서 사용자 인증 정보를 이용해 데이터를 훔치는 공격임
+
+    SOP는 이렇게 막음
+
+    ### 차단하는 것
+
+    - 다른 출처의 쿠키, DOM, 응답 데이터 접근 금지
+
+    ### 허용되는 것
+
+    - 네트워크 요청 자체는 가능함
+
+    ### 핵심 동작
+
+    - 요청은 나갈 수 있음
+    - 하지만 응답 내용을 JS가 못 읽음
+
+    → 그래서 공격자가 사용자 데이터 못 가져감
+
+# 블로그에서 명시한 대로 SOP가 반드시 동일 출처에서만 접근하도록 하는 주요 브라우저 API/리소스 3가지를 쓰고, 각각에 대해 간단한 설명(왜 제한되는지)을 덧붙이세요.
+
+    ### 1. DOM 접근
+
+    - 다른 사이트의 HTML 구조 접근 불가
+    - 이유: 사용자 정보 노출 방지
+
+    ---
+
+    ### 2. XMLHttpRequest / fetch 응답
+
+    - 다른 출처 응답 데이터 읽기 불가
+    - 이유: API 데이터 탈취 방지
+
+    ---
+
+    ### 3. 쿠키 / localStorage
+
+    - 다른 출처 데이터 접근 불가
+    - 이유: 인증 정보 보호
+# SOP와 CSP의 차이를 블로그 내용에 따라 요점 4개(각 항목 1문장)로 정리하세요. (예: 누가 적용하는가, 제어 주체, 설정 가능 여부 등)
+    1. SOP는 브라우저 기본 정책이고 CSP는 서버가 설정하는 정책임
+    2. SOP는 변경 불가능하고 CSP는 개발자가 설정 가능함
+    3. SOP는 데이터 접근 제한이고 CSP는 리소스 로딩 제한임
+    4. SOP는 출처 기반 보호고 CSP는 허용 목록 기반 보호임
+
+
+# 브라우저에서 SOP 관련 차단 오류를 발견했을 때(예: 콘솔에 “동일 출처 정책으로 인해 ... 차단했습니다” 메시지) 문제 원인 파악을 위한 체크리스트(최소 3항목)를 작성하고, 임시·영구 대응 방안(각 1~2줄)도 제시하세요.
+
+    ### 체크리스트
+
+    1. 요청 URL의 프로토콜 / 도메인 / 포트 확인
+    2. CORS 헤더 설정 여부 확인
+    3. 서버에서 Access-Control-Allow-Origin 설정 확인
+
+    ---
+
+    ### 임시 대응
+
+    브라우저 설정 끄거나 CORS 우회 플러그인 사용
+
+    ---
+
+    ### 영구 대응
+
+    서버에서 CORS 허용 설정 추가 또는 같은 출처 구조로 변경

mission/Chapter03/movie/package.json

@@ -12,6 +12,7 @@
   "dependencies": {
     "@hookform/resolvers": "^5.2.2",
     "@tailwindcss/vite": "^4.2.2",
+    "axios": "^1.15.2",
     "react": "^19.2.4",
     "react-dom": "^19.2.4",
     "react-hook-form": "^7.74.0",