출처
이해하기 쉬운 웹 보안 모델 이야기 1 (SOP, CORS) :: Stay hungry, Stay foolish. (zairo.kr)
[WEB] 동일 출처 정책(SOP)과 교차 출처 리소스 공유(CORS)란? (tistory.com)
CORS와 쿠키(Same-Site, Secure, httpOnly) (velog.io)
[WEB] 📚 악명 높은 CORS 개념 & 해결법 - 정리 끝판왕 👏 (tistory.com)
[Web] CORS (Cross Origin Resource Sharing) 이해하기 (tistory.com)
[Web] XSS와 CSRF (Cross Site Scripting and Cross Site Request Forgery) (tistory.com)
01. 시큐리티 - HTTP Only 와 Secure Cookie (tistory.com)
[WEB] 🌐 세션 / 쿠키 🍪 차이 정리 (tistory.com)
CORS
[에러]
| 🚨 Access to fetch at ‘https://myhompage.com’ from origin ‘http://localhost:3000’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled. 💬 'https://myhomepage.com'에서 'https://localhost:3000' 출처로 가져올 수 있는 액세스가 CORS 정책에 의해 차단되었습니다. 요청된 리소스에 'Access-Control-Allow-Origin' 헤더가 없습니다. 불투명한 응답이 필요에 적합한 경우, 요청 모드를 'no-cors'로 설정하여 CORS가 비활성화된 리소스를 가져오십시오. |
CORS(Cross Origin Resource Sharing)
CORS(Cross Origin Resource Sharing)는 다른 Origin으로 요청을 보내기 위해 지켜야 하는 정책으로, 원래대로라면 SOP에 의해 막히게 될 요청을 풀어주는 정책이라고 볼 수 있다.
"Cross-Origin Resource Sharing" 문장을 직역하면 "교차 출처 리소스 공유 정책"이라고 해석할 수 있는데, 여기서 교차 출처라고 하는 것은 (엇갈린) 다른 출처를 의미하는 것으로 보면 된다.
- Origin : Protocol + Host + Port
cross-origin에 해당하는 경우 ( 다른 사이트로 보는 경우 )
- http, https 각각 다른 통신 프로토콜을 사용하는경우
- 도메인이 다른 경우
- 포트번호가 다른 경우
[참고]
브라우저가 검사하는 것이기 때문에 서버 간 통신에서는 이러한 정책이 적용되지 않는다.
참고로 서버간의 요청에서는 해당 응답을 JavaScript 단에서 읽을 수 없도록 하기 위해 요청 시 Sec-Fetch-Mode 헤더의 값을 no-cors로 설정한다.
SOP(Same-Origin Policy) - 동일 출처 정책
SOP(Same Origin Policy)는 ORIGIN으로부터 요청 받은 자원을 가지고 다른 Origin으로 요청을 보낼 수 없도록 금지하는 브라우저의 기본적인 보안 정책이다.
📜 SOP (동일 출처 정책)이 필요한 이유
CSRF(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting) 등의 방법을 이용해서 우리가 만든 어플리케이션에서 해커가 심어놓은 코드가 실행하여 개인 정보를 가로챌 수 있다.
CSRF는 공격 대상이 server이고 XSS는 공격대상이 client라는 차이점이 있습니다.
CSRF(Cross-Site Request Forgery)
인증된(권한을 가진) 사용자가 자신의 의도와 무관하게 공격자가 의도한 어떤 행위(수정, 삭제)를 하도록 유도하는 해킹 기법
1. 해커가 자신의 헤킹용 웹사이트를 구축하여 해킹용 웹사이트를 가리키는 링크를 담은 메일을 보낸다.
2. 특정 웹사이트에 로그인 되어있는 사용자가 그 링크를 클릭한다.
3. 링크를 누른 사용자가 웹사이트에 접속하면 해커가 심어둔 JavaScript 코드가 실행된다.
이 코드는 특정 웹사이트로 개인 정보를 조회하는 API 요청을 보내는 코드다.
사용자가 로그인을 했기 때문에 브라우저 단에 인증정보가 존재하고
이것을 담아서 요청하면 서버는 인증된 요청이기 때문에 개인정보를 응답한다.1. 사용자가 해커의 사이트를 방문한다.
2. 방문과 동시에 사용자의 블로그 사이트에 비밀번호 변경요청을 보낸다.
3. 쿠키가 같이 붙어서 요청이 되므로 사용자의 패스워드가 변경되었다.어째서 이러한 공격이 가능했을까를 생각해보면 다음과 같다.
- Cross-Origin 간에는 read는 불가능해도 write는 가능하다.
- 쿠키는 항상 요청에 붙어서 전송된다.
XSS(Cross-Site Scripting)
웹사이트에 악의적 스크립트를 삽입하여 쿠키, 개인정보 등을 빼돌리는 해킹 기법
쿠키나 개인정보 등을 빼돌릴 수도 있고, 특정 웹사이트로 이동하도록 할 수도 있다. 주로 중요한 데이터를 다른 사이트로 빼돌리기 위해 사용하기 때문에 'Cross Site'라는 이름이 붙게 되었다.
사용 예시
1) 공격자는 홈페이지를 통해 웹서버에 악성 스크립트가 포함된 게시물을 등록합니다
2) 사용자는 공격자가 올린 악성스크립트를 포함한 게시글을 읽습니다
4) 이때 악성스크립트가 User PC에서 실행이되면서 각종 정보등이 공격자에게로 넘어갑니다
쿠키와 세션이 필요한 이유
HTTP 프로토콜에는 비연결성(Connectionless)과 비상태성(Stateless)이라는 특징이 있습니다.
이는 서버의 자원을 절약하기 위해 모든 사용자의 요청마다 연결과 해제의 과정을 거치기 때문에 연결 상태가 유지되지 않고, 연결 해제 후에 상태 정보가 저장되지 않는다는 것입니다. HTTP의 비연결성과 비상태성을 보완하여 서버가 클라이언트를 식별하게 해주는 것이 쿠키와 세션입니다.
세션 쿠키 차이점
| 분류 | 쿠키 | 세션 |
| 저장 위치 | 부라우저 | 서버 |
| 보안성 | 취약 | 서버에 저장해서 안전 |
| 속도 | 빠름 | 느림 |
| 저장 형식 | Text | Object |
| 만료 시점 | 쿠키 저장시 설정 설정 안하면 브루우져 종료시 만료 |
브루우져 종료시 만료(기간 설정 가능) |
세션
서버에서 클라이언트들 각각의 상태를 저장하는 기술
세션 특징
- 각 클라이언트마다 고유한 session ID를 부여한다.
- 서버에 저장하기 때문에 로컬에 저장하는 쿠키보다 보안성이 좋다.
- 서버에 저장하기 때문에 서버 부하가 발생한다.
- HTTP는 비연결성이라 매 요청마다 새로운 네트워크 연결이 이뤄지는데, 세션 덕분에 연결 유지가 가능하다.
쿠키
쿠키는 웹 사이트에 접속할 때 생성되는 정보를 담은 임시 파일
브라우저가 서버에 요청을 보냈는데, 응답에 Set-Cookie 헤더가 있는 경우, 브라우저는 Set-Cookie에 있는 데이터를 저장하고 이것을 쿠키라고 합니다.
쿠키의 사용목적
쿠키는 주로 아래의 세 가지 목적을 위해 사용됩니다.
- 세션 관리(Session Management) : 로그인, 사용자 닉네임, 접속 시간, 장바구니 등의 서버가 알아야할 정보들을 저장합니다.
- 개인화(Personalization) : 사용자마다 다르게 그 사람에 적절한 페이지를 보여줄 수 있습니다.
- 트래킹(Tracking) : 사용자의 행동과 패턴을 분석하고 기록합니다.
쿠키가 사용되는 예시
- ID 저장, 로그인 상태 유지
- 일주일간 다시 보지 않기.
- 최근 검색한 상품들을 광고에서 추천
- 쇼핑몰 장바구니 기능
쿠키가 있기 때문에 여러 페이지를 이동할 때마다 로그인을 하지 않고 사용자 정보를 유지할 수 있는 것입니다.
쿠키가 없다면 다음 페이지로 정보를 파라미터로 넘겨줘야 합니다.
CSRF 문제
CSRF(Cross Site Request Forgery)는 쿠키에 별도의 설정이 없으면 모든 HTTP 요청에 대해 쿠키를 전송하게 됩니다. 이것은 큰 문제가 될 수 있습니다.
1. 사용자가 해커의 사이트를 방문한다.
2. 방문과 동시에 사용자의 블로그 사이트에 비밀번호 변경요청을 보낸다.
3. 쿠키가 같이 붙어서 요청이 되므로 사용자의 패스워드가 변경되었다.SameSite
CSRF 공격 방지 옵션
Cross Site로 전송되는 요청의 경우 쿠키 전송에 제한을 둡니다. None, Lax, Strict 3가지의 제한 방식이 존재합니다.
- None : 기존의 쿠키와 동작하는 방식이 같습니다.
- Strict: 가장 보수적인 방식입니다. Cross Site로는 쿠키가 전송되지 않습니다. 즉, 퍼스트 파티 쿠키만 전송됩니다.
- Lax : Strict에 비해 자유롭습니다. Lax로 설정된 경우, 대체적으로 서드파티 쿠키는 전송되지 않지만 예외적인 요청에는 전송할 수 있습니다. 크롬의 쿠키 기본 설정은 Lax로 되어있습니다.
Secure
쿠키는 HTTP,HTTPS를 구분하지 않고 전송가능한데, Secure설정이 된 쿠키는 HTTPS가 적용된 요청에만 전송되는 쿠키입니다.
httpOnly
쿠키가 브라우저 내 자바스크립트로 위 변조 되는 것을 막기 위한 옵션입니다.
1. document.cookie와 같은 자바스크립트로 쿠키를 조회하는 것을 막습니다.
2. 브라우저에서 해당 옵션이 활성화 되어 있는 쿠키를 조회할 수 없습니다.
3. 서버로 HTTP Request 요청을 보낼 때만 쿠키를 전송합니다.
4. XSS(Cross Site Scripting) 공격을 차단할 수 있습니다. (1번의 이유 때문에)
요약
같은 사이트에만 쿠키를 포함한 요청 가능하도록 samesite를 strict 설정
자바스크립트로 쿠키 조회가 안되게 httponly 설정
https요청에서만 쿠키 포함할 수 있게 secure 설정
XSS filter가 동작하도록 헤더에 X-XSS-Protection을 1로 설정
클릭재킹을 못 하도록 같은 사이트의 frame만 호출 가능하게 하기 위해 헤더에 X-Frame-Options을 sameorigin으로 설정
설정해놓은 mime type이외 것은 해석하지 않도록 헤더에 Content-type을 설정해주고 Content-Type-Options를 nosniff로 설정