답변:
로 응답 Access-Control-Allow-Origin: *하면 요청 된 리소스가 모든 출처와 공유 할 수 있습니다. 이것은 기본적으로 모든 사이트가 사이트에 XHR 요청을 보내고이 CORS 응답을 구현하지 않았다면 서버의 응답에 액세스 할 수 있음을 의미합니다.
따라서 모든 사이트는 방문자를 대신하여 사이트에 요청하고 응답을 처리 할 수 있습니다. 브라우저에서 자동으로 제공하는 항목 (쿠키, 쿠키 기반 세션 등)을 기반으로하는 인증 또는 권한 부여 체계와 같은 구현이있는 경우 제 3 자 사이트에서 트리거 한 요청도이를 사용합니다.
이것은 실제로 보안 위험을 초래합니다. 특히 선택한 리소스뿐만 아니라 모든 리소스에 대해 리소스 공유를 허용하는 경우 더욱 그렇습니다. 이 맥락에서 CORS를 활성화하는 것이 안전한 경우를 살펴 봐야합니다 . .
Access-Control-Allow-Origin: *이들을 설정할 때 보안 문제가 있습니까? nogin 등이 없으며 모든 사람에게 공개됩니까?
Access-Control-Allow-Origin: *리소스에 표준 자격 증명 (쿠키, 기본 인증, TLS 클라이언트 인증서)이 아닌 다른 것으로 보호되는 개인 데이터가 포함되어 있지 않는 한 모든 리소스에 추가해도 안전합니다 .
https://example.com/users-private-data사용자의 로그인 상태에 따라 개인 데이터를 노출 할 수있는을 상상해보십시오 . 이 상태는 세션 쿠키를 사용합니다. 그것은의 안전한 추가 Access-Control-Allow-Origin: *요청이 쿠키없이하면이 헤더는 응답에 액세스 할 수 있습니다,이 자원, 및 쿠키는 개인 데이터를 얻기 위해 필요합니다. 결과적으로 개인 데이터가 유출되지 않습니다.
상상 https://intranet.example.com/company-private-data민간 기업 데이터를 노출하는,하지만 당신은 회사의 와이파이 네트워크에있어 경우에만 액세스 할 수 있습니다. 그건 안전하지 추가하는 Access-Control-Allow-Origin: *것이 표준 자격 증명이 아닌 다른 뭔가를 사용하여 보호있어,이 자원. 그렇지 않으면 잘못된 스크립트가 사용자를 인트라넷에 대한 터널로 사용할 수 있습니다.
사용자가 시크릿 창에서 리소스에 액세스하면 무엇을 보게 될지 상상해보십시오. 이 콘텐츠 (브라우저가받은 소스 코드 포함)를 보는 모든 사람이 만족한다면 Access-Control-Allow-Origin: *.
Access-Control-Allow-Origin: *가 없는 요청 만 허용합니다 . 나는 약간을 명확히하기 위해 대답을 편집했습니다.
AFAIK, Access-Control-Allow-Origin은 서버에서 브라우저로 보내는 http 헤더입니다. 특정 주소로 제한 (또는 비활성화)해도 로봇과 같은 사이트가 더 안전 해지지는 않습니다. 로봇이 원하는 경우 헤더를 무시할 수 있습니다. 일반 브라우저 (Explorer, Chrome 등)는 기본적으로 헤더를 따릅니다. 그러나 Postman 과 같은 응용 프로그램은 단순히이를 무시합니다.
서버 측은 응답을 반환 할 때 요청의 '원점'이 무엇인지 실제로 확인하지 않습니다. http 헤더 만 추가합니다. 액세스 제어 헤더를 읽고 이에 따라 조치를 취하기로 결정하는 요청을 보낸 것은 브라우저 (클라이언트 측)입니다. XHR의 경우 특별한 'OPTIONS'요청을 사용하여 먼저 헤더를 요청할 수 있습니다.
따라서 창의적인 스크립팅 능력을 가진 사람은 그 안에 설정된 모든 헤더를 쉽게 무시할 수 있습니다.
Access-Control-Allow-Origin 설정의 가능한 보안 문제를 참조하십시오 .
이제 실제로 질문에 답하기 위해
나는 내 환경을 보안 위험에 빠뜨리고 있다고 생각하지만 어쩔 수 없다.
누군가가 당신을 공격하고 싶다면 Access-Control-Allow-Origin을 쉽게 우회 할 수 있습니다. 그러나 '*'를 활성화하면 공격자에게 HTTP 헤더를 존중하는 일반 웹 브라우저를 사용하는 것과 같이 몇 가지 더 많은 '공격 벡터'를 제공 할 수 있습니다.
Access-Control-Allow-Origin *암호를 훔치는 스크립트를 호스팅하는 악성 웹 사이트에 설정 하는 것은 권장하지 않습니다. :-)
192.168.1.1공격을 허용하도록 라우터를 재구성 할 수 있습니다. 라우터를 DDoS 노드로 직접 사용할 수도 있습니다. (대부분의 라우터에는 핑 또는 간단한 HTTP 서버 검사를 허용하는 테스트 페이지가 있습니다. 이들은 대량으로 악용 될 수 있습니다.)
다음은 와일드 카드가 실제로 문제가 될 때 주석으로 게시 된 두 가지 예입니다.
은행 웹 사이트에 로그인했다고 가정 해 보겠습니다. 다른 페이지로 이동 한 다음 은행으로 돌아 가면 쿠키 때문에 여전히 로그인되어 있습니다. 인터넷의 다른 사용자는 저와 같은 은행에서 동일한 URL에 접속할 수 있지만 쿠키 없이는 제 계정에 액세스 할 수 없습니다. 교차 출처 요청이 허용되면 악성 웹 사이트가 효과적으로 사용자를 가장 할 수 있습니다.
– 브래드
Linksys WRT54g와 같은 일반적인 홈 라우터가 있다고 가정합니다. 라우터가 교차 출처 요청을 허용한다고 가정합니다. 내 웹 페이지의 스크립트는 공통 라우터 IP 주소 (예 : 192.168.1.1)에 HTTP 요청을 만들고 공격을 허용하도록 라우터를 재구성 할 수 있습니다. 라우터를 DDoS 노드로 직접 사용할 수도 있습니다. (대부분의 라우터에는 ping 또는 간단한 HTTP 서버 검사를 허용하는 테스트 페이지가 있습니다. 이들은 대량으로 악용 될 수 있습니다.)
– 브래드
실제 사례로 문제를 설명하기 때문에 이러한 의견이 답이되어야한다고 생각합니다.
서버가 헤더 아래에 설정하여 CORS를 완전히 비활성화하려는 시나리오에서.
Access-Control-Allow-Origin : * (서버가 모든 ORIGIN의 교차 사이트 요청을 수락 함을 브라우저에 알립니다.)
Access-Control-Allow-Credentials : true (브라우저에 사이트 간 요청이 쿠키를 보낼 수 있음을 알립니다)
아래 오류가 발생하는 브라우저에 구현 된 안전 장치가 있습니다.
"Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’"따라서 대부분의 시나리오에서 'Access-Control-Allow-Origin'을 설정 *하는 것은 문제가되지 않습니다. 그러나 공격으로부터 보안을 유지하기 위해 서버는 허용 된 원본 목록을 유지할 수 있으며 서버가 원본 간 요청을받을 때마다 허용 된 원본 목록에 대해 ORIGIN 헤더의 유효성을 검사 한 다음 Access-Control-Allow-Origin에서 동일하게 에코 백 할 수 있습니다. 헤더.
ORIGIN 헤더는 브라우저에서 실행되는 자바 스크립트로 변경할 수 없기 때문에 악성 사이트가 스푸핑 할 수 없습니다.