본문 바로가기
MAKESITE

점검 항목 · 보안

CORS 와일드카드 허용

서버는 멀쩡한데 이용자의 데이터만 새 나갑니다. 로그인한 사람이 공격자의 페이지를 열어 보는 것만으로 성립하고, 우리 로그에는 정상 요청으로 남습니다.

심각도 높음 보안 무료 스캔 판정 항목 /check/cors-policy

01DEFINITION

한 줄로 말하면

다른 도메인에서 우리 서버의 응답을 읽을 수 있게 허용하는 설정입니다. 편하다는 이유로 모든 출처를 허용해 두면, 로그인한 이용자가 공격자의 페이지를 여는 것만으로 그 이용자의 데이터가 그쪽으로 넘어갑니다. 허용할 출처는 필요한 것만 이름으로 적어야 합니다.

02RISK

없으면 무슨 일이 생기나

브라우저에는 원래 벽이 있습니다. A 사이트의 스크립트는 B 사이트에 요청을 보낼 수는 있어도 그 답을 읽지는 못합니다. CORS 헤더는 그 벽을 서버가 스스로 낮추는 장치이고, Access-Control-Allow-Origin 에 별표를 적는 것은 「누구든 읽어도 좋다」는 뜻입니다. 공개 정보만 주는 주소라면 문제가 없지만, 로그인 상태에 따라 다른 내용을 주는 주소라면 이야기가 완전히 달라집니다.

가장 나쁜 조합은 별표가 아니라 요청한 출처를 그대로 되비추면서 자격증명까지 허용하는 것입니다. 요청 헤더의 Origin 값을 받아 그대로 응답에 적어 주는 구현이 흔한데, 이러면 사실상 모든 출처를 허용하면서 쿠키까지 함께 보내집니다. 이용자가 우리 사이트에 로그인한 상태로 공격자 페이지를 열면, 그 페이지의 스크립트가 우리 API 를 호출하고 로그인된 그 사람의 데이터를 받아 갑니다.

이 사고는 우리 쪽에서 보이지 않습니다. 요청은 정상 세션의 정상 요청이고, 응답 코드도 200 입니다. 서버 로그를 아무리 봐도 이상이 없습니다. 피해 사실이 드러나는 것은 대개 유출된 데이터가 다른 곳에서 발견될 때이고, 그때는 언제부터였는지 특정하기 어렵습니다.

03CHECK IT YOURSELF

직접 확인하는 방법

아래는 저희를 거치지 않고 지금 해 보실 수 있는 방법입니다. 결과를 저희에게 보내실 필요도 없습니다.

  1. 01
    아무 출처나 보내 보고 응답을 본다

    보내지 않은 도메인이 응답에 그대로 적혀 돌아오면 되비추는 구현입니다. 별표도 확인 대상이지만, 되비추기가 더 위험합니다.

    $ curl -sI -H "Origin: https://evil.example" https://example.com/api/me \
      | grep -i "access-control-allow"
    access-control-allow-origin: https://evil.example   ← 되비춘다. 위험
    access-control-allow-credentials: true              ← 쿠키까지 간다. 더 위험

나머지 확인 방법 2단계는 셀프수리 가이드에 있습니다.

04HOW TO FIX

고치는 방법

서버 환경에 따라 적을 자리가 다릅니다. 아래는 가장 흔한 구성 기준이고, 적용 전에 현재 설정을 백업하십시오.

허용할 출처를 이름으로 적는다

와일드카드도 되비추기도 쓰지 마십시오. 실제로 필요한 도메인을 목록으로 두고 그 안에 있을 때만 응답에 적습니다. 목록에 없으면 헤더를 아예 안 붙이는 것이 맞습니다 — 빈 값으로 붙이지 않습니다.

공개 데이터라면 자격증명을 끈다
Vary: Origin 을 빠뜨리지 않는다
조치 코드는 셀프수리 가이드에 있습니다. 서버 구성별 설정 원문 3단계와, 귀사 사이트에서 실제로 관찰된 값이 함께 실립니다 — 무엇을 어디에 적어야 하는지가 정해집니다.
가이드 안내 보기 · 먼저 무료로 진단받기
이미 열람권을 구매하셨다면 안내 메일의 가이드 링크로 바로 열립니다 — 링크를 잃으셨다면 문의 주시면 다시 보내 드립니다.
주의. CORS 는 브라우저 안에서만 동작하는 규칙입니다. 서버 대 서버 요청이나 도구로 직접 부르는 요청은 이 헤더와 무관하게 응답을 받습니다. 그래서 CORS 를 접근 제어로 쓰면 안 됩니다 — 인증과 권한 검사는 그것대로 따로 있어야 합니다.

05FAQ

자주 묻는 질문

CORS 를 열어 두면 누가 우리 서버를 공격할 수 있나요

이 항목의 피해자는 우리 서버가 아니라 우리 이용자입니다. 서버는 정상적으로 동작하고 정상적으로 응답합니다. 다만 그 응답을 읽을 자격이 없는 페이지가 읽어 갑니다. 그래서 서버 로그와 모니터링이 깨끗한 것이 안전의 근거가 되지 않습니다.

개발할 때 편해서 열어 뒀는데 그대로 둬도 되나요

가장 흔한 경위가 그것입니다. 로컬에서 막혀서 모든 출처를 허용해 두고 그대로 배포됩니다. 개발용으로 열어야 한다면 개발 환경에서만 켜지게 조건을 두십시오. 운영 설정 파일에 그 줄이 있는지 배포 점검 목록에 한 줄로 넣어 두는 것이 확실합니다.

어떤 주소를 우선 봐야 하나요

로그인 상태에 따라 응답이 달라지는 주소입니다. 내 정보 조회, 장바구니, 주문 내역, 관리자용 조회 API 가 대표적입니다. 반대로 공지사항이나 상품 목록처럼 누가 부르든 같은 내용을 주는 주소는 열려 있어도 잃을 것이 없습니다.

Origin 을 검사하는데도 위험한 경우가 있나요

검사 방식에 따라 있습니다. 앞부분만 맞으면 통과시키는 구현은 우리 도메인으로 시작하는 공격자 도메인을 지나가게 합니다. 부분 문자열로 확인하는 구현도 마찬가지입니다. 정확히 같은지로만 판단하고, 서브도메인을 허용해야 한다면 그것도 목록에 하나씩 적으십시오.
여기까지는 항목 일반론입니다. 무엇이고 왜 문제이며 어떻게 고치는지는 감출 이유가 없어 그대로 적었습니다. 리포트에 들어가는 것은 귀사 사이트에서 실제로 어떤 값이 나왔는지 — 어느 주소의 어느 응답인지, 그 환경에서 어떤 순서로 적용해야 하는지, 예상 공수가 얼마인지입니다. 이 페이지만 보고 직접 고치셔도 되고, 실제로 그러시라고 적어 두었습니다.

GET STARTED

내 사이트는
이 항목을 통과할까요

주소만 넣으시면 이 항목을 포함해 58가지를 판정해 점수와 실패 개수를 보여 드립니다. 로그인도, 소유 확인도 필요 없습니다 — 전부 밖에서 관찰만 하는 항목이기 때문입니다.

무료 스캔 문의하기 로그인