programing

CORS를 유효하게 하는 것은 언제가 안전합니까?

padding 2023. 3. 29. 21:16
반응형

CORS를 유효하게 하는 것은 언제가 안전합니까?

저는 JSON/REST Web API를 개발하고 있으며, 특히 서드파티 웹사이트에서 AJAX를 통해 서비스를 호출할 수 있도록 하고 싶습니다.따라서 서비스에서는 유명한 CORS 헤더를 송신하고 있습니다.

Access-Control-Allow-Origin: *

이를 통해 서드파티 사이트에서 AJAX를 통해 서비스를 호출할 수 있습니다.아직까지는 괜찮아.

단, Web API의 서브섹션은 비공개로 인증이 필요합니다(OAuth와 access_token cookie의 매우 표준적인 것).이 사이트에서도 CORS를 유효하게 해도 안전한가요?

한편, 서드 파티의 Web 사이트에는, 제 서비스의 이 부분과 상호 작용하는 Ajax 클라이언트가 있으면 좋겠다고 생각합니다.그러나 처음부터 동일한 오리진 정책이 있는 이유는 이것이 위험할 수 있기 때문입니다.나중에 방문하는 웹 사이트가 개인 컨텐츠에 액세스할 수 없도록 하려는 경우.

제가 두려워하는 시나리오는 사용자가 제 웹 API에 로그인하여 웹 사이트 또는 신뢰할 수 있는 웹 사이트에서 로그아웃하는 것을 잊어버리는 것입니다.이렇게 하면 나중에 그가 운영하는 다른 모든 웹 사이트가 기존 세션을 사용하여 개인 컨텐츠에 액세스할 수 있습니까?

그래서 질문합니다.

  • 비공개 콘텐츠에서 CORS를 활성화해도 안전합니까?
  • CORS 지원 서버가 쿠키를 통해 session_token을 설정한 경우 이 쿠키는 CORS 서버 또는 메인 웹 페이지 서버의 도메인에 저장됩니까?

" " " " " " cookie " " session _ token " " " 。cookie CORS. 웹 가 JS를 수 .document.cookie. 는 . cookie " , cookie " " " " " " 가 .withCredentials되어 있는 가 「이러한 속성」, 「이러한 속성」을 하고 있는 .Access-Control-Allow-Credentials머리글

당신의 첫 번째 질문은 좀 더 자유롭습니다.그것은 꽤 안전하지만, 사물을 우회시킬 수 있는 방법이 있다.예를 들어 공격자는 DNS 포이즈닝 기술을 사용하여 프리플라이트 요구가 실제 서버에 히트하도록 하고 실제 CORS 요구를 부정한 서버에 송신할 수 있습니다.다음은 CORS 보안에 관한 기타 자원입니다.

마지막으로, 고객님의 관심사는 고객님의 CORS 데이터에 대한 웹사이트 접근을 허용하는 것입니다.이 문제를 방지하기 위해Access-Control-Allow-Origin: *header를 클릭합니다.대신 사용자의 오리진 값을 에코백해야 합니다.예를 들어 다음과 같습니다.

Access-Control-Allow-Origin: http://www.example.com

이 헤더에서는http://www.example.com응답 데이터에 액세스합니다.

CORS의 목적은 XHR 요구에 대한 크로스 오리진 요구를 허용하면서 서버에 어떤 오리진이 어떤 리소스에 액세스할 수 있는지 지정할 수 있는 권한을 부여하는 것입니다.특히 CORS에서는 서버가 정기적인 XHR 요구와 가능한 XHR 요구를 구별할 수 있는 Origin 헤더필드가 도입되었습니다.이 헤더 필드는 사용자가 설정하거나 변경할 수 없지만 브라우저에서 XHR 요청에 대해 설정합니다.

따라서 XHR에서만 사용하도록 설계된API가 있는 경우 CORS에 준거하도록 요구를 요구할 수 있습니다.특히 요구가 서버상의 스테이트도 변경할 수 있는 경우는 CSRF에 취약합니다.

CSRF 공격은 다른 방법을 사용하여 GET 및 POST 요구를 위조하는 CORS에 관계없이 발생할 수 있습니다.CORS는 서버가 허용하는 경우에만 JavaScript를 사용하여 XHR 요청에 대한 서버의 응답에 액세스할 수 있습니다.

언급URL : https://stackoverflow.com/questions/9713644/when-is-it-safe-to-enable-cors

반응형