영향
공격자는 취약한 애플리케이션 [S2] 사용자로부터 민감하고 인증된 데이터를 훔칠 수 있습니다. 사용자가 취약한 앱에 로그인한 상태에서 악성 웹사이트를 방문하는 경우, 악성 사이트는 앱의 API에 교차 출처 요청을 보내고 [S1][S2] 응답을 읽을 수 있습니다. 이로 인해 사용자 프로필, CSRF 토큰 또는 개인 메시지 [S2]를 포함한 개인 정보가 도난당할 수 있습니다.
근본 원인
CORS는 서버가 리소스 [S1]를 로드하도록 허용되는 원본(도메인, 구성표 또는 포트)을 지정할 수 있도록 하는 HTTP 헤더 기반 메커니즘입니다. 취약점은 일반적으로 서버의 CORS 정책이 너무 유연하거나 [S2]가 제대로 구현되지 않은 경우에 발생합니다.
- 반영된 원본 헤더: 일부 서버는 클라이언트 요청에서
Origin헤더를 읽고 이를Access-Control-Allow-Origin(ACAO) 응답 헤더 [S2]에 다시 표시합니다. 이를 통해 모든 웹사이트에서 [S2] 리소스에 효과적으로 액세스할 수 있습니다. - 잘못 구성된 와일드카드:
*와일드카드를 사용하면 모든 원본이 리소스에 액세스할 수 있지만 자격 증명(예: 쿠키 또는 인증 헤더) [S3]가 필요한 요청에는 사용할 수 없습니다. 개발자는 [S2] 요청을 기반으로 ACAO 헤더를 동적으로 생성하여 이를 우회하려고 시도하는 경우가 많습니다. - 'null' 화이트리스트 지정: 일부 애플리케이션은 리디렉션된 요청이나 로컬 파일에 의해 트리거될 수 있는
null원본을 화이트리스트에 추가하여 악성 사이트가null원본으로 가장하여 [S2][S3]에 액세스할 수 있도록 합니다. - 파싱 오류:
Origin헤더 유효성을 검사할 때 정규식 또는 문자열 일치 오류로 인해 공격자가trusted-domain.com.attacker.com[S2]와 같은 도메인을 사용할 수 있습니다.
CORS는 CSRF(교차 사이트 요청 위조) [S2]에 대한 보호 기능이 아니라는 점에 유의하는 것이 중요합니다.
구체적인 수정
- 정적 화이트리스트 사용: 요청의
Origin헤더 [S2]에서Access-Control-Allow-Origin헤더를 동적으로 생성하지 마세요. 대신 요청의 출처를 하드코딩된 신뢰할 수 있는 도메인 목록 [S3]와 비교하세요. - 'null' 원본을 피하세요: 허용된 원본 [S2]의 화이트리스트에
null를 포함하지 마세요. - 자격 증명 제한: 특정 원본 간 상호 작용 [S3]에 절대적으로 필요한 경우에만
Access-Control-Allow-Credentials: true를 설정하세요. - 적절한 유효성 검사 사용: 여러 원본을 지원해야 하는 경우
Origin헤더에 대한 유효성 검사 논리가 강력하고 하위 도메인이나 유사한 도메인 [S2]가 우회할 수 없는지 확인하세요.
FixVibe가 이를 테스트하는 방법
FixVibe는 이제 이를 게이트 활성 검사로 포함합니다. 도메인 확인 후 active.cors는 합성 공격자 원본이 포함된 동일한 원본 API 요청을 보내고 CORS 응답 헤더를 검토합니다. 공개 자산 노이즈를 피하면서 반영된 임의 출처, 와일드카드 자격 증명 CORS 및 비공개 API 엔드포인트의 개방형 CORS를 보고합니다.