[04-02] JS 기반 WB의 취약성 - CSRF와 CORS

0. 시작

: WB의 엔진은 JS를 동작시키기 때문에 높은 자율성을 얻을 수 있게 되었지만, 트레이드오프로 많은 취약성을 가짐

0.1 Origin과 Site

• Origin
  : Scheme + Host Name (Domain Name) + Port 으로 구성
  : Ex) https://api.KK.com:8080
  
  
• Site
  : Domain Name 중 SLD (Second-Level Domain) + TLD (Top-Level Domain)
  : Ex) api.kk.com or admin.kk.com
  • 다른 말로 정의하자면 TLD + 1 혹은 eTLD + 1 영역
    : TLD (Top-Level Domain) 에는 eTLD (유효 TLD) 개념이 존재
    

    

    -  api.kk.com  : .com 은 TLD ❘  .kk.com  은 TLD + 1

    

    -  admin.kk.com.kr  : .co.kr 은 eTLD ❘  .kk.co. kr 은 eTLD + 1

Domain	kk.com
Origin	https:// + kk.com + :8080
Site	api.kk.com or admin.kk.com or api.kk.co.kr

---

1. CSRF(Cross-Site Request Forgery)

: 사이트 간 위조 요청
: 사용자가 인증된 상태에서 진행
: 사용자가 의도치 않은 행위(수정, 삭제 등)를 특정 웹 사이트에 요청하게 하는 공격

: 주로, form 태그나 AJAX 요청을 통해 발생 가능

1.1 SOP(Same-Origin Policy)

: 동일 출처 정책, W3C에서 도입한 정책 표준

: 같은 Origin(프로토콜, 호스트, 포트)의 서버의 리소스 처리만 가능

: WB가 주관한다.

1. 적용 범위
   : WB에서는 HTTP Req는 기본적으로 SOP을 따름
   : But, Cross-Site HTTP Request(교차 출처 요청)이 가능하므로 부분적인 Cross-Origin 요청 허용
   
   • 적용 X인 Cross-Origin "요청/가져오기" // Embedded cross origin
     1) 가져오기의 경우(대체로 허락됨)
         - <img> 태그를 통한 "이미지 파일" 
         - <link> 태그를 통한 "CSS 파일"
     
     2) 의도된 "제출"의 경우
         - <form> 태그를 통한 개발자의 의도된 제출(서버 변경의 경우)
     
     
   • 적용 O인 Cross-Origin "요청"
     - Ajax(XMLHttpRequest, XHR)- POST, DELETE와 같이 서버의 상태를 바꾸는 것들..
     - WB의 비동기 지원 Ajax
     1) FORM(Synchronous) =>제출 후 끝(페이지 반환 및 리렌더링)
     2) AJAX(ASynchronous JavaScript and XML) => XHR(XML 객체 반환, 페이지 리렌더링 X)  

=> API 사용에 대한 제한이 너무 까다로움(POST 못보내면 내가 뭘 할 수 있는데)
==> "CORS" 등장(AJAX-서버상태를 바꾸는 호출에 대한 예외적 허용 정책)

---

2. CORS(Cross Origin Resource Sharing)

2.1 CORS

: AJAX를 통한 타 웹 서버에 대한 비의도적인 요청 방어를 위한 WB정책

: WB의 HTTP 요청의 출처(origin)을 확인 - 서버는 특정 출처(origin)에서만 오는 요청만 허용하게 설정

: 서버측에 설정된 헤더를 통해 요청을 보낸 출처와 메소드, 헤더 등을 비교하여 유효성 확인

• WB에서 XSS, JS-AJAX를 통한 CSRF 방지
  - 네이티브 앱에서는 XSRF Token사용(난수와 세션의 조합)
• <form>태그에 대한 방어는 ....X

- Cross Origin에 대한 조건부 허용을 위한 정책

- CORS또한 WB에 판단하기에 서버-서버 통신에는 CORS 이슈 X(React-Proxy or Next.js)

---

2.2 서버측 적용 방법: Header설정

나의 귀여운 손글씨...

1. 허용된 Origin
   - WB: Origin를 송신
   - WS: Access-Control-Allow-Origin를 송신
       => 위 두개의 값을 WB에서 비교 및 유효성 검사
   
   
2. 허용된 Method
   : 해당 Origin에 허용된 Method를 명시
   - WB: Access-Control-Request-Method 를 송신
   - WS: Access-Control-Allow-Method를 송신
       => 위 두개의 값을 WB에서 비교 및 유효성 검사
   
   
3. 허용된 Header
   - WB: Access-Control-Request-Header 를 송신
   - WS: Access-Control-Allow-Header를 송신
       => 위 두개의 값을 WB에서 비교 및 유효성 검사

---

• WB의 요청 시, 자격증명 Header 전달 허용
  
  • 자격증명: Cookie, Authorization Header 도는 TLS Client 인증을 위한 정보들
    - WB: allowCredentials = true or credentials: "include" 설정
    - 요청에 자격증명(인증)과 관련된 정보를 담을 수 있게 해주는 옵션
        1) credentials: "include": 최신 JS fetch()를 활용한 API 호출 시
        2) allowCredentials = true: 구버전 js XMLHttpRequest를 활용한 API 호출 시
    - WS: Access-Control-Allow-Credentials = true 설정
    - 이를 통해 WS측에서는 자격증명이 담긴 요청을 받을 수 있음
    - Access-Control-Allow-Credentials 사용시 Access-Controll-Allow-Origin 헤더 제약 존재
        - Spring Security 에서 Access-Controll-Allow-Origin 이 * 이면 X
        - Spring Security 에서 allowOriginPatterns(*) 를 사용 권고
         => 위 두개의 값을 WB에서 비교 및 유효성 검사

---

2.3 CORS 검증 요청

: 서버에서 설정한 Origin, Method, Header를 알아내기 위한 방법

: Simple/Non-Preflight Request or Preflight Request

출처: ASAC 수업자료

	Simple/Non-Preflight Request	Preflight Request
설명	서버 상태 조회	서버 상태 변경
서버 상태 변경를 위한 Methods	- GET, HEAD, POST    (몇몇 간단한 Header 에 대해서만)	- GET, HEAD, POST - DELETE, PATCH, PUT    (그 외 모든 종류의 커스텀 Header)
체크 절차	허용된 Origin 체크 절차	허용된 Origin 체크 + 허용된 Method 체크 + 허용된 Header 체크 절차
1) WB	서버에게 원 요청	서버에게 임시 요청(Preflight, OPTIONS)
2) WS	“결과” +  “CORS 헤더” 응답	"CORS 헤더” 응답
3) WB:	“CORS 헤더” 가 요청과 부합 X ⇒ 반환 결과 폐기	“CORS 헤더” 가 요청과 부합 X ⇒ 원 요청을 보내지 않는다.

---

2.4 결론

1) CSRF로 인한 피해를 막고자 WB 정책으로 SOP 설정 -> 불편함

2) 부분적 해소를 위해 WB에 CORS 적용 => AJAX에 대한 문제만 해소 FORM 태그의 경우 해결 X

3) 그럼 다른걸 추가해 볼까? == HTTPS

 

 

---

출처:

ASAC 7기 수업 자료

https://velog.io/@ppou/SOP

SOP(Same-Origin Policy)