Hacker News 의견

• CORS는 서버가 브라우저에게 어떤 크로스 오리진 요청이 응답을 읽을 수 있는지를 명시적으로 알려주는 메커니즘임

  • 기본적으로 브라우저는 크로스 오리진 스크립트가 응답을 읽는 것을 차단함
  • 명시적으로 허용되지 않으면 요청 도메인은 응답을 읽을 수 없음
  • 예를 들어, evil.com의 스크립트가 bank.com/transactions에 요청을 보내 피해자의 거래 내역을 읽으려 할 수 있음
  • 브라우저는 요청이 bank.com에 도달하도록 허용하지만 evil.com이 응답을 읽는 것은 차단함

• CSRF 보호는 인증된 사용자를 대신하여 악의적인 크로스 오리진 요청이 무단으로 행동을 수행하는 것을 방지함

  • 예를 들어, evil.com의 스크립트가 bank.com에서 행동을 수행하도록 요청을 보낼 수 있음 (예: bank.com/transfer?from=victim&to=hacker로 돈을 이체)
  • bank.com의 서버 측 CSRF 보호가 이를 거부함 (아마도 요청에 비밀 CSRF 토큰이 포함되어 있지 않기 때문임)

• CSRF 보호는 쓰기 보호에 관한 것이고, CORS는 읽기 보호에 관한 것임

• JS로 시작된 요청은 기본적으로 크로스 사이트가 허용되지 않음

  • fetch()를 사용하여 허용된 헤더만 사용하면 크로스 사이트 요청을 시작할 수 있음

• 이 주제에 대한 더 나은 설명이 있다고 생각함

  • 관련 블로그 링크 제공

• 블로그 게시물의 질문에 대한 응답

  • HTML 4.0의 <form> 요소는 어떤 오리진으로도 간단한 요청을 제출할 수 있음
  • 이와 관련하여 SameSite 이니셔티브와 어떻게 일치하는지에 대한 질문이 있었음

• 2022년에 MDN CORS 기사에 "간단한 요청" 용어의 출처를 명확히 하기 위해 단락을 추가했음

  • 이전에는 fetch 사양에 언급되지 않았다고만 나와 있었음
  • 2019년 브라우저의 CSRF 방지 기능이 SameSite=Lax를 지원하거나 기본값으로 설정된 경우에 대한 언급이 없었음

• SameSite가 CORS 사전 요청과 독립적으로 추가된 것이 혼란스러움

  • 브라우저 제작자들이 모든 크로스 오리진 POST 요청에 사전 요청을 요구하지 않은 이유가 궁금함

• csrf를 사용하지 않아도 안전하다고 생각할 수 있지만, 일부 라이브러리(예: django rest framework)는 콘텐츠 타입 헤더가 설정되면 HTML 폼을 처리할 수 있음

  • 이는 사용자의 사이트에 폼을 게시하여 사용자를 대신하여 요청을 보낼 수 있게 함

• CSRF 토큰이 회전되는 이유에 대한 질문

  • OWASP는 이것이 더 안전하다고 하지만 이유를 잘 모르겠음

• 복잡한 주제에 대한 흐름도를 요청함

  • 새로운 애플리케이션 플랫폼과 표준 세트를 원함

• 이러한 것들이 쉬운 진단 추적을 지원하지 않음

  • 적절히 구성되지 않은 합법적인 사용 사례에 대한 불투명한 오류를 여러 번 경험했음

• CORS가 등장하기 전에는 페이지 오리진이 아닌 임의의 엔드포인트에 요청을 보낼 수 있었지만 응답을 볼 수 없었던 이유를 이해하지 못함

  • 이것이 사양에 우연히 포함된 것인지, XSS를 예상하고 의도적으로 한 것인지, 아니면 주도적인 브라우저가 그렇게 했고 다른 브라우저들이 따라한 것인지 궁금함

• CSRF 보호에 대한 혼란

  • 공격자가 goodsite.com에서 CSRF 토큰을 얻어 badsite.com에 넣고 Alice를 속여 badsite.com에서 goodsite.com으로 요청을 제출하게 하는 것을 막을 방법이 무엇인지 궁금함