2022-01-03 17:47 작성

object에서 iframe까지 - 다른 임베딩(끼워넣기) 기술들

Table of contents
  1. 임베딩의 짧은 역사
  2. iframes에 대해 자세히 알아보기
    1. 보안 관련
    2. 필요한 경우에만 임베드하라
    3. HTTPS를 사용하라
    4. 항상 sandbox 속성을 이용하라
    5. CSP 명령 설정하기
  3. <embed> 그리고 <object> elements
  4. 저작권

임베딩의 짧은 역사

오래 전 웹에서는 웹사이트를 생성하는데 있어 frames를 사용하는 것이 인기 있었다 - 이 frames는 개별 HTML 페이지에 저장된 웹사이트의 작은 부분이었다. 이 frames는 각각의 frame이 채워진 스크린에서 영역을 구체화하도록 허용된 frameset이라고 불리우는 master document에 임베드 되었다. 마치 표(table)의 행과 열을 sizing하는 것처럼. 90년대에 차분하고 합리적인 대표적인 예시들이 고려되었다, 그리고 웹페이지를 작은 덩어리들(chunks)로 나누는게 다운로드 속도를 개선한다는 것을 알아내었다 - 이 방법은 네트워크 연결 환경이 느릴 때 뚜렷한 효과를 보였다. 그래서 이 방법을 사용했으나 곧 많은 문제들에 직면하게 되었는데, 이 방법을 통해 얻게 되는 이익을 뛰어넘는 네트워크 속도의 개선으로 인해 더이상 사용되지 않게 되었다.

90년대 후반, 2000년대 초, 플러그인 기술(Java Applets, Flash)이 유명해지면서 웹 개발자들은 HTML로는 이용할 수 없는 풍부한 콘텐츠(비디오, 애니메이션)를 임베드 할 수 있게 되었다. 이러한 기술들은 <object>와 같은 elements를 통해 구현할 수 있었고, <embed>는 덜 사용되었으며 당시에는 모두 유용했다. 그러나 접근성, 보안, 파일 크기 등의 많은 문제에 직면하게 되면서 인기가 시들게 되었다.

그리고 마침내 <iframe> element가 나타난다(콘텐츠를 임베딩하는 다른 방식들과 함께, 예를 들어 <canvas>, <video> 등). 이것은 모든 web document를 다른 web document 안에 임베드 하는 방법을 제공했다.

iframes에 대해 자세히 알아보기

<iframe>을 사용하는데 있어서 몇 가지 중요한 보안 문제를 고려해야 한다. 그렇다고 해서 웹사이트에 <iframe>을 사용해서는 안 된다는 의미는 아니다. 단지 조심스럽게 생각하도록 하고 몇 가지 지식을 가지고 있으면 된다. 예시를 보며 좀 더 알아보도록 하자. MDN 용어사전을 웹 페이지에 포함시키고 싶다고 가정하면 다음과 같이 시도해볼 수 있을 것이다:

<head>
  <style> iframe { border: none } </style>
</head>
<body>
  <iframe src="https://developer.mozilla.org/en-US/docs/Glossary"
          width="100%" height="500" allowfullscreen sandbox>
    <p>
      <a href="/en-US/docs/Glossary">
         Fallback link for browsers that don't support iframes
      </a>
    </p>
  </iframe>
</body>
  • border: none:
    만약 사용되면, <iframe>은 경계면 없이 보여진다. 그렇지 않을 경우, 일반적으로 원치 않는 형태의 경계면이 포함된 <iframe>을 보게 된다.

  • allowfullscreen:
    설정 될 경우, Fullscreen API을 이용해 <iframe>을 전체 화면 모드로 전환할 수 있다.

  • src:
    <video>/<img>와 같이 이 속성은 임베드 될 도큐먼트의 URL을 지정한다.

  • width 와 height:
    iframe의 width와 height을 명시하는 속성이다.

  • Fallback content:
    <video>와 비슷한 방식으로 <iframe>/<iframe>` 안에 브라우저가 iframe을 지원하지 않을 경우 나타날 fallback content를 포함시킨다. 위의 예시에서는 페이지로 연결시키는 링크를 포함했다. 최신 브라우저를 사용하는 경우 지원하지 않는 경우가 거의 없으므로 거의 마주칠 일 없는 옵션이다.

  • sandbox:
    이 속성은 iframe의 다른 features보다 좀 더 최신 브라우저에서 작동한다(e.g. IE 10 그리고 그 이상). 이 속성을 통해 보안 설정을 증가시킬 수 있다.

Note: 속도를 개선하기 위해서 메인 콘텐츠의 로딩이 끝난 뒤에 JavaScript와 함께 iframe의 src 속성을 설정하는 것이 좋다. 이 방법은 페이지를 바로 사용할 수 있게 하고 공식 페이지의 로드 타임을 감소시킨다. (SEO 측정(metric)에 있어서 중요)

보안 관련

보안에 대한 염려를 위에서 언급했듯 - 조금 더 자세하게 이 부분에 대해서 알아보자. 이 부분에 대한 염려를 인식하고 더 경험하고 이 부분을 고려할 정도의 지식을 쌓게 되면 참고해 시작할 수 있을 것이다.

브라우저를 만든 사람들과 웹 개발자들은 iframe이 악의적으로 웹페이지를 수정하거나 이용자들이 원하지 않는 행동(id, passowrd와 같은 민감한 정보를 노출하는 등)을 하게 하는 나쁜 사람들(해커: hackers 좀 더 정확하게 말하면, 크래커: crackers)의 흔한 타겟(공식용어-공격 벡터: attack verctor)이 된다는 것을 알게 되었다. 이 때문에 <iframe>의 보안 수준을 높이기 위해 기술 엔지니어들과 브라우저 개발자들은 다양한 보안 메커니즘을 개발했고, 다음에서 가장 실용적인 것들을 다룰 것이다.

Note: Clickjacking(숨겨진 하이퍼링크를 사용해 인터넷 사용자를 속이는 기술)은 iframe를 공격하는 흔한 기술 중 하나다. 개발자의 Web document 내에 보이지 않는 iframe을 임베드 하는 형태로 공격하거나 개발자의 document를 악의적 웹사이트에 임베드 하는 형태로 공격한다. 그리고 그 과정에서 일어나는 상호과정을 붙잡는데(capture) 사용한다. 이 과정에서 사용자들은 민감한 정보를 잃게 된다.

깃허브에서 live 찾아보기를 클릭해 파이어폭스 브라우저에서 열어보면 “Firefox가 이 페이지를 열 수 없음”이라는 경고 표시가 나온다. “X-Frame-Options” 명령이 “DENY” 로 설정되어 있기 때문에 프레임이 거부되는 것이다. 그리고 이것은 MDN을 개발하는 개발자들이 서버에서 웹사이트 페이지가 <iframe>에 포함되는 것을 허용하지 않도록 설정해놨기 때문에 발생한다(아래에 기술될 CSP 명령 설정하기를 참고하라). 이것은 타당하다. 그러나 하나의 전체 MDN 페이지가 다른 페이지들에 임베드 되는 것은 개발자가 자신의 사이트에 임베드 하고 그것을 자신의 것이라고 주장하지 않는 이상 타당하지 않다고 할 수 있다. 또는 clickjacking을 통해 데이터를 훔치려는 시도일 것이다. 뿐만 아니라 모든 사람들이 이렇게 한다면, 추가적 대역폭에 대한 비용은 모두 Mozilla 사에 부과될 것이다.

필요한 경우에만 임베드하라

가끔 youtube 그리고 maps와 같은 third-party content를 임베드 하는 것은 납득 가능하다. 그러나 이 때에도 완전히 필요하다고 느낄 경우에만 third-party content를 임베드하는 것이 두통을 감소시켜 줄 것이다. 웹 보안에 있어 엄지를 추켜 세울만한 규칙은 다음과 같다. “너무 경계하지 말라. 만약 만들었다면 두 번 체크하도록 하라. 만약 다른 사람이 만들었따면, 안정성이 보장되기 전까지 위험하다고 가정하라.”

보안 외에도 지식 재산 문제에도 유의해야 한다. 대부분의 콘텐츠는 저작권이 있기 때문에 스스로의 것이 아니거나 작성자가 본인에게 준 것이 아닌 경우, 그리고 명백한 허락이 있지 않은 한 절대 전시해서는 안 된다.

만약 콘텐츠가 라이센스가 있을 경우에는 라이센스 조건을 지켜야만 한다. 예를 들어 MDN은 CC-BY-SA 라이센스를 가지고 있다. 즉, MDN에 공이 있다는 것을 명시해야 한다. 콘텐츠에 상당한 변화가 있는 경우에도 이는 동일하게 적용된다.

HTTPS를 사용하라

HTTPSHTTP의 암호화 된 버전을 뜻한다. 가능하면 HTTPS를 사용해서 웹사이트들을 받아오는 것이 좋다:

  1. HTTPS는 멀리 있는 콘텐츠가 수송되는 동안 간섭 당할 수 있는 기회를 줄인다.
  2. HTTPS는 부모 document의 콘텐츠에서 임베드 된 콘텐츠로 접근하는 것을 예방하고 그 반대의 경우 또한 예방한다.

HTTPS를 사이트에 적용하기 위해서는 특별한 보안 증명서를 설치해야 한다. 많은 호스팅 제공 업체들은 증명서를 넣는 설치 과정을 거치지 않고도 HTTPS가 적용된 호스팅을 제공한다. 그러나 만약 HTTPS를 지원하는 사이트를 스스로 만들어야 할 경우, Let’s Encrypt의 도움을 받을 수 있다. 이 사이트에서는 자동으로 필요한 증명서를 생성하고 설치할 수 있는 도구와 설명을 제공한다(세계적으로 널리 쓰이는 Apache 웹 서버, Nginx등의 웹 서버를 built-in으로 지원함). Let’s Encrypt의 암호화 도구는 그 과정을 가능한 쉽게 할 수 있도록 디자인 되었고, 그렇기에 HTTPS를 사용하는 사이트를 만드는 것을 기피할 이유가 없다.

Note: GitHub pages는 HTTPS를 기본으로 지원한다. 다른 호스팅 업체를 이용할 경우, 미리 알아보는 것이 좋다.

항상 sandbox 속성을 이용하라

공격자들(attackers)이 웹사이트에 나쁜 영향을 최대한 덜 끼치도록 하고 싶다면, 콘텐츠에 작업 수행에 있어 허가(permission)이 필요함 이 적용되도록 해야 한다. 물론, 이것은 자신이 만든 콘텐츠에도 해당 된다. 테스트를 위한 목적의 혹은 적절하게 사용되어야 하는 코드의 container 그러나 다른 codebase에 해를 끼칠 수 없게 하는 것(사고로 혹은 악의적으로)을 sandbox라고 부른다.

샌드박스화 되지 않은 콘텐츠는 너무 많은 것들을(JavaScript를 실행하고, forms를 제출하고, windows를 팝업하는 등) 할 수 있다. 기본적으로, sandbox 속성에 아무런 파라미터도 주지 않고 가능한 모든 제한을 부과해야 한다.

만약 절대적으로 요구 된다면, 하나씩 허가를 내줄 수 있다(sandbox="" 안에 속성 값을 넣음). sandbox 참조를 통해 모든 가능한 options를 확인할 수 있다. 가중 주의할 점 중 하나는 절대 allow-scripts 그리고 allow-same-origin을 동시에 적용하지 말아야 한 다는 점이다. 만약 그렇게 할 경우 사이트의 스크립트가 실행되는 것을 중지 시키는 Same-origin policy를 우회할 수 있게 되고 JavaScript를 이용해 샌드박스를 무력화할 수 있게 된다.

Note: 샌드박스화 한다고 해도 공격자들이 이용자들을 속여 악의적 콘텐츠를 <iframe> 바깥에서 직접적으로 방문하게 할 경우, 이용자를 보호할 수 없다. 만약 악의적일 수 있는 특정 콘텐츠가 존재할 경우(e.g. 사용자 생성 콘텐츠), 메인 사이트가 아닌 다른 도메인 사이트에서 받도록 해야 한다.

CSP 명령 설정하기

CSPcontent security policy를 의미하고 HTML document의 보안을 향상시키는 일련의 HTTP Headers(웹 페이지가 웹 서버에서 받아질 때 함께 보내지는 메타데이터)를 제공한다. <iframe>의 보안화 하는 것에 관한 한 적절한 X-Frame-Options header를 보내 서버 설정하기 를 참고한다. 이것은 다른 웹사이트에서 본인의 콘텐츠를 임베드 하는 것을 방지한다(clickjacking이나 다른 종류의 공격을 하는 무리).

Note: Frederik Barun의 X-Frame-Options Security Header 포스트에서 더 자세한 정보를 확인할 수 있다.

<embed> 그리고 <object> elements

<embed><object> elements는 <iframe>과는 다른 function을 받는다. 이 elements들은 PDFs와 같은 외부 콘텐츠를 임베드 하기 위한 목적으로 사용된다.

그러나 이 elements를 사용할 가능성은 낮다. 만약 PDFs를 보여줘야 한다면 페이지에 임베드 하는 것 보다 링크해 보여주는 것이 더 낫다.

역사적으로 이러한 elements들은 Adobe Flash와 같은 브라우저 plugin에 의해 관리되는 콘텐츠를 임베드 하는 용도로 사용되었는데 하지만 최신 브라우저에서는 지원하지 않기도 하고 구식이 되었다.

사용 방법이 필요하다면 사이트에서 확인하도록 하자.

<!-- 예시 -->
<object data="mypdf.pdf" type="application/pdf"
        width="800" height="1200">
  <p>You don't have a PDF plugin, but you can
    <a href="mypdf.pdf">download the PDF file.
    </a>
  </p>
</object>

저작권


Mozilla 기여자가 작성한 MDN에 대해는 CC-BY-SA 2.5 라이선스에 따라 사용할 수 있습니다.


크리에이티브 커먼즈 라이선스
이 저작물은 크리에이티브 커먼즈 저작자표시-동일조건변경허락 4.0 국제 라이선스에 따라 이용할 수 있습니다.