recursal/MDN huggingface dataset:
SVG In HTML Introduction
========================

### 개요

이 문서와 관련된 예제는 form의 배경 그림을 제공하기 위해서 inline SVG를 어떻게 사용하는지를 보여줍니다. 정규 XHTML을 작성하는 것과 같은 방식으로 그 그림들을 조작하기 위해 JavaScript와 CSS의 사용법도 설명합니다. 예제들은 XHTML(HTML이 아님)과 SVG integration을 지원하는 웹브라우져에서만 동작함을 유의하시기 바랍니다.

### 소스

예제에 대한 소스는 여기:
```

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title>XTech SVG Demo</title>
  <style>
    stop.begin { stop-color:yellow; }
    stop.end { stop-color:green; }
    body.invalid stop.end { stop-color:red; }
    #err { display:none; }
    body.invalid #err { display:inline; }
  </style>
  <script>
    function signalError() {
      document.getElementById('body').setAttribute("class", "invalid");
    }
  </script>
</head>
<body id="body"
   style="position:absolute; z-index:0; border:1px solid black; left:5%; top:5%; width:90%; height:90%;">
  <form>
     <fieldset>
       <legend>HTML Form</legend>
       <p><label>Enter something:</label>
          <input type="text"/>
          <span id="err">Incorrect value!</span></p>
       <p><button onclick="signalError();">Activate!</button></p>
     </fieldset>
  </form>
  <svg xmlns="http://www.w3.org/2000/svg" version="1.1"
    viewBox="0 0 100 100" preserveAspectRatio="xMidYMid slice"
    style="width:100%; height:100%; position:absolute; top:0; left:0; z-index:-1;">
    <linearGradient id="gradient">
      <stop class="begin" offset="0%"/>
      <stop class="end" offset="100%"/>
    </linearGradient>
    <rect x="0" y="0" width="100" height="100" style="fill:url(#gradient)" />
    <circle cx="50" cy="50" r="30" style="fill:url(#gradient)" />
  </svg>
</body>
</html>
```

### Discussion

위 페이지는 주로 정규 XHTML, CSS, JavaScript입니다. 다만 흥미로운 부분은 위 페이지에 포함되어 있는 `<svg>`원소입니다. 이 원소와 그 자식들은 SVG 네임스페이스 상에서 선언되어 있습니다. 이 원소는 하나의 색변화도(그라데이션)와 이 색변화도에 따라 내부가 채워진 두개의 도형을 포함하고 있습니다. 색변화도의 양끝의 색깔은 CSS에서 지정된 색을 가집니다. 만약 사용자가 form에 잘못된 내용을 입력하였다면 스크립트는 `<body>`태그에 `invalid`속성을 설정하고 스타일 규칙은 색변화도의 `end-stop`색을 빨간색으로 변경합니다. (나머지 스타일 규칙에 따라 에러 메시지가 출력됩니다.)

이 방식은 수고면에서 다음과 같은 특징을 가집니다:

* 우리는 기존의 웹사이트들에서 이전부터 사용되어온 정규 XHTML의 form을 사용했으며 여기에 매력적이고 인터랙티브한 배경그림까지도 추가했습니다.
* 이 방식은 SVG를 지원하지 않는 웹브라우져와 하위 호완성을 가집니다; 단순히 이들 웹브라우져에서는 배경그림만 없을 뿐입니다.
* 단순한 방식이며 아주 잘 동작합니다.
* 그림은 동적으로 필요한 크기에 따라 영리하게 스스로 크기를 변경합니다.
* HTML과 SVG 모두에게 적용될 수 있는 선언적 스타일 규칙들을 가질 수 있습니다.
* 같은 스크립트가 HTML과 SVG 모두를 조작할 수 있습니다.
* 문서는 완전히 표준에 기반하고 있습니다.
### Details

`viewBox`속성은 SVG 그림의 좌표계에 상대적인 논리적 좌표계를 생성합니다. 이 경우 그림은 100x100크기의 뷰포트에 놓여집니다.

`preserveAspectRatio`속성은 주어진 크기내에 그림을 넣을때 그림의 높이나 폭을 최대로 해서 주어진 크기에 맞게 그림을 맞추고 넘어가는 부분들을 잘라냄으로써 그림의 비율이 보존되도록 지정합니다.

`style`속성은 SVG 원소를 form의 배경에 고정시킵니다.

### Related Links

* Another SVG in XHTML example: A swarm of motes
* Inline SVG page on SVG wiki
소개
==

* « 이전
* 다음 »

![Mozilla dino logo](/ko/docs/Web/SVG/Tutorial/Introduction/dino.svg)

SVG는 XHTML과 비슷한 XML 언어로 오른쪽에 있는 것과 같은 그래픽을 그리는 데 사용된다. SVG 이미지는 필요한 모든 선과 모양을 직접 일일이 지정하거나, 이미 존재하는 래스터 이미지를 수정하거나, 이 두 가지 방법을 조합해서 만들 수 있다. 이미지와 그 구성요소들은 변형되고, 조합되고, 필터링될 수 있으며, 이를 통해 원래의 형태를 완전히 바꿀 수도 있다.

SVG는 비슷한 경쟁 포맷들이 W3C에 제출되었지만 완전히 승인되지는 않았던 1999년에 등장했다. 명세는 오랫동안 존재해 왔지만 웹 브라우저에서 느리게 받아들여졌기 때문에, 웹 문서에서 바로 SVG를 포함하는 컨텐츠는 2009년까지도 많지 않았다. 사용할 수 있는 구현조차도 경쟁기술인 HTML5 캔버스나 (애플리케이션 인터페이스로서) 어도비 플래시보다 느린 편이다. SVG는 캔버스나 플래시와 비교했을 때 DOM 인터페이스를 사용할 수 있는 점과 서드파티 확장을 필요로 하지 않는 이점을 가지고 있다. SVG를 활용할 지는 사용자의 목적에 달려있다.

Can I Use...에서 확인할 수 있듯이, SVG 지원은 2009년부터 확대되어 왔다.

### 기본적인 요소들

HTML은 헤더, 문단, 표와 같은 요소들을 제공한다. SVG도 마찬가지로 원, 사각형, 간단한 곡선과 복잡한 곡선을 그릴 수 있는 요소들을 제공한다. 간단한 SVG 문서는 `<svg>` (en-US) 루트 요소와 그래픽을 구성하기 위한 몇몇 기본 도형들로 구성된다. 또한 `<g>` (en-US) 요소를 통해 간단한 모양들을 조합할 수 있다.

이를 통해서 SVG 이미지는 아주 복잡해질 수도 있다. SVG는 그라디언트, 회전, 필터 효과, 애니메이션, JavaScript를 통한 조작을 지원한다. 하지만 SVG의 이러한 추가적인 기능들은 그래픽 영역을 정의하는 비교적 작은 요소들의 집합에 의존하고 있다.

### 시작하기 전에

잉크스케이프(Inkscape)를 비롯해 SVG를 네이티브 포맷으로 활용하는 무료 드로잉 애플리케이션들이 있다. 하지만 이 튜토리얼에서는 순수하게 XML과 (독자가 선택한) 텍스트 에디터만을 사용한다. 이는 SVG의 내부 구조에 대한 이해를 돕기 위함이며, 이렇게 하기 위해서는 직접 마크업 언어를 경험해보는 것이 무엇보다 중요하다. SVG를 배우는 이유를 되새겨보자. 모든 SVG 뷰어가 같은 방식으로 구현되어 있지는 않기 때문에, 어떤 애플리케이션에서 잘 보여지도록 작성된 SVG가 다른 애플리케이션에서는 의도한 대로 작동하지 않을 수도 있다. 이는 SVG 명세나 SVG와 함께 사용되는 JavaScript나 CSS를 지원하는 수준이 서로 상이하기 때문에 발생하는 문제이다.

SVG는 모든 모던 웹 브라우저에서 지원하고 있으며, 이전부터 지원해오던 경우도 있다. Can I use에서 SVG 지원 현황을 표로 확인할 수 있다. Firefox는 1.5 버전에서부터 SVG를 지원해오고 있으며, 매 버전이 나올 때마다 SVG 지원 범위도 넓어지고 있다. 바라건대 이 튜토리얼과 MDN 문서가 개발자들이 Gecko와 다른 주요 구현체들의 차이를 이해하는 데 도움이 되길 바란다.

SVG를 시작하기에 앞서, 기초적인 XML 문법이나 HTML 같은 다른 마크업 언어를 이해할 필요가 있다. XML에 익숙하지 않다면 다음 사항들을 유념하기 바란다.

* XML은 (HTML과 달리) 대소문자를 구분하는 언어이므로 SVG 요소와 속성은 반드시 예제에 보이는 대로 입력해야 한다.
* SVG에서 속성 값은 숫자라고 할지라도 반드시 따옴표로 둘러싸야 한다.

SVG의 명세는 아주 길다. 이 튜토리얼에서는 기초적인 부분만을 다룬다. 이미 SVG에 익숙하다면 요소 레퍼런스나 인터페이스 레퍼런스 (en-US)에서 필요한 부분을 찾아보면 된다.

### SVG의 종류

2003년에 권고가 된 후 최신의 완전한(full) SVG 버전은 1.1이다. 1.1은 1.0을 기반으로 작성되었으나 구현을 쉽게 하기 위해 좀 더 모듈화되었다. SVG 1.1 두번째 에디션은 2011년에 권고되었다. 완전한 SVG 1.2가 SVG의 다음 주요 릴리즈였다. 1.2 대신 현재 활발히 개발중인 SVG 2.0으로 넘어갈 것이다. SVG 2.0에서는 CSS 3과 마찬가지로 구성요소들이 느슨히 결합된 명세들로 분리될 것이다.

완전한 SVG 권고와는 별도로 W3C 워킹 그룹에서는 2003년에 SVG Tiny와 SVG Basic을 내놓았다. SVG Tiny와 SVG Basic은 모바일 기기를 위한 것이다. 먼저 SVG Tiny에 따르면 적은 리소스를 가진 작은 기기에서도 그래픽을 생성할 수 있어야 한다. SVG Basic은 완전한 SVG 명세의 많은 부분을 지원하지만 구현하기 어렵거나 애니메이션과 같이 무거운 렌더 작업은 포함하지 않는다. 2008년에는 SVG Tiny 1.2가 W3C 권고가 되었다.

다중 페이지 지원 및 더 나은 색상 관리를 위한 SVG 프린트 명세도 계획되어 있었다. 이 작업은 현재 진행되지 않고 있다.

* « 이전
* 다음 »
위치
==

* « 이전
* 다음 »
그리드
---

![가운데가 파란색 상자로 표시된 X, Y 좌표 격자](/ko/docs/Web/SVG/Tutorial/Positions/canvas_default_grid.png)모든 요소(Element)에 대해 SVG는 캔버스를 포함한 컴퓨터에서 무언가 그리고자 할때 많이 사용되는 것과 유사한 좌표계 또는 그리드 시스템을 사용합니다. 즉, 문서의 왼쪽 위 모서리는 (0,0)으로 간주되며 한 지점의 위치는 왼쪽 상단 모서리에서 픽셀 단위로 표시되고 X축의 양의 방향은 오른쪽, Y축의 양의 방향은 아래쪽으로 향하게됩니다. 어린시절 배웠던 그래프와는 반대라는 점을 기억하세요. 그러나 이것은 HTML의 요소가 배치되는 것과는 같은 방법입니다 (기본적으로 LTR 문서는 X를 오른쪽에서 왼쪽으로 배치하는 RTL 문서가 아닙니다).

#### 예제

아래 요소는
```

<rect x="0" y="0" width="100" height="100" />
```


왼쪽 상단에서 100px의 정사각형을 정의합니다.

### "픽셀"이란?

기본적으로 SVG 문서에서 1픽셀은 출력 장치(화면)의 1픽셀에 매핑됩니다. 하지만 이러한 방식만 가능했다면 SVG의 이름에 "확장성(Scalable)"이란 단어가 들어가 있지는 않았겠죠. CSS의 절대 및 상대 글꼴 크기와 매우 흡사하게 SVG는 절대적인 단위 ( "pt"또는 "cm"와 같은 식별자가있는 것)를 정의하고 이것을 사용자 단위(User Unit)로 명칭하며, 이것은 별도의 식별자 없이 숫자 그대로를 사용합니다.

별도로 명시하지 않았다면, 사용자 단위와 화면 단위는 1:1의 비율로 동작합니다. SVG에는 이 비율을 변경하기 위한 몇가지 방법이 있습니다.
```

<svg width="100" height="100">
```


위 요소는 100x100px 의 SVG 캔버스를 정의합니다. 사용자 단위와 화면 단위는 1:1의 비율로 동작합니다.
```

<svg width="200" height="200" viewBox="0 0 100 100">
```


SVG 캔버스 전체 크기는 200x200 픽셀입니다. 그러나 viewBox속성을 사용하여 (0,0)에서 시작하는 100x100px의 화면을 200x200px의 화면에 출력합니다. 이렇게하면 100x100 단위 영역을 효과적으로 확대하고 이미지를 두 배 크기로 확대 할 수 있습니다.

이러한 요소 혹은 전체 이미지의 사용자 단위와 화면 단위의 매핑을 사용자 좌표계(User coordinate system)이라고 합니다. 스케일링 외에도 회전, 기울이기, 뒤집기가 가능합니다. 기본 사용자 좌표계는 하나의 사용자 픽셀을 하나의 장치 픽셀에 매핑합니다. SVG파일에서 "in"또는 "cm"과 같은 특정 치수는 결과 이미지에서 1:1로 보이도록 계산됩니다.

SVG 1.1 스펙에서는 다음과 같이 인용합니다:

> 
> [...] 사용자 환경에서 "1px"이 "0.2822222mm" 에 대응한다고 가정했을때(90dpi), SVG는 다음과 같이 처리한다: [...] "1cm"는 "35.43307px"과 같다. (그리고 35.43307 사용자 단위와 같다.)
> 
> 
> 

* « 이전
* 다음 »
calcMode
========

« SVG Attribute reference home

이 속성은 애니메이션의 interpolation 모드를 지정합니다. 기본 모드는 linear 이지만 속성이 linear interpolation을 지원하지 않으면(예: 문자열의 경우) calcMode 속성이 무시되고 discrete interpolation이 사용됩니다.

Usage context
-------------

| Categories | Animation value attribute |
| --- | --- |
| Value | discrete | linear | paced | spline |
| Animatable | No |
| Normative document | SVG 1.1 (2nd Edition) |

discrete

이것은 애니메이션 함수가 interpolation 없이 하나의 값에서 다음 값으로 점프하도록 지정합니다.

linear

값 사이의 단순한 linear interpolation은 애니메이션 함수를 계산하는데 사용됩니다. `<animateMotion>` (en-US)의 경우를 제외하고는 이것은 기본 값입니다.

paced

Defines interpolation to produce an even pace of change across the animation. This is only supported for values that define a linear numeric range, and for which some notion of "distance" between points can be calculated (e.g. position, width, height, etc.). If paced is specified, any `keyTimes (en-US)` or `keySplines (en-US)` will be ignored. For `<animateMotion>` (en-US), this is the default value.

spline

cubic Bézier spline에 정의된 시간 함수에 따라 `values (en-US)` 목록의 한 값에서 다음 값으로 interpolation 합니다. spline의 점(point)은 `keyTimes (en-US)` 속성에 정의되고, 각 간격의 제어점은 `keySplines (en-US)` 속성에 정의됩니다.

예제
--

Elements
--------

다음 요소에서 calcMode 속성을 사용할 수 있습니다.

* `<animate>` (en-US)
* `<animateColor>` (en-US)
* `<animateMotion>` (en-US)
* `<animateTransform>` (en-US)
viewBox
=======

« SVG Attribute reference home

`viewBox` 속성은 특수한 container element 에 fit 하기 위한 주어진 graphics stretch 의 set 을 명시한다.

`viewBox` 속성의 값은 whitespace and/or a comma 로 나뉘어진 `min-x`, `min-y`, `width`, `height` 4가지 number list 이다. 이는 주어진 element 에 의해 설정된 viewport 의 bounds 에 맵핑되어야 하는 user space 내의 rectangle 을 명시하며, `preserveAspectRatio (en-US)` 속성과 관계가 있다.

음수로 이루어진 width 또는 height 는 허용되지 않으며 zero 값은 element rendering 이 불가하다.

Usage context
-------------

| Categories | None |
| --- | --- |
| Value | *See above* |
| Animatable | Yes |
| Normative document | SVG 1.1 (2nd Edition) |

Example
-------

Elements
--------

아래 element 들은 `viewBox` 속성을 사용할 수 있다.

* `<svg>` (en-US)
* `<symbol>` (en-US)
* `<image>` (en-US)
* `<marker>` (en-US)
* `<pattern>` (en-US)
* `<view>` (en-US)
See also
--------

* SVG Getting Started: Positions
version
=======

**`version`** 속성은 해당 SVG 문서가 어떤 명세를 따르고 있는지 표시하기 위해 사용됩니다. 이는 오직 <svg> (en-US) 요소 내에서만 사용되며 순전히 사용되는 버전의 알림을 위한 용도로 프로세싱이나 렌더링에는 영향을 미치지 않습니다.

버전을 명시하기 위해 어떤 숫자든지 입력할 수 있지만, 현재로써 유효하게 사용되는 버전은 1.0과 1.1 두 버전만이 유일합니다.

Usage context
-------------

| Categories | None |
| --- | --- |
| Value | <number> |
| Animatable | No |
| Normative document | SVG 1.1 (2nd Edition): version attribute |
cx
==

**`cx`** 속성은 중심점의 x축 좌표를 정의합니다.

다음 SVG 요소와 함께 이 속성을 사용할 수 있습니다:

* `<circle>`
* `<ellipse>`
* `<radialGradient>` (en-US)
Example
-------
```

html,
body,
svg {
  height: 100%;
}
```



```html
<svg viewBox="0 0 300 100" xmlns="http://www.w3.org/2000/svg">
  <radialGradient cx="25%" id="myGradient">
    <stop offset="0" stop-color="white" />
    <stop offset="100%" stop-color="black" />
  </radialGradient>

  <circle cx="50" cy="50" r="45" />
  <ellipse cx="150" cy="50" rx="45" ry="25" />
  <rect x="205" y="5" width="90" height="90" fill="url(#myGradient)" />
</svg>
```

circle
------

`<circle>` 의 경우, `cx`는 모양 중심의 x축 좌표를 정의합니다.

|  |  |
| --- | --- |
| Value | `<length-percentage>` |
| Default value | `0` |
| Animatable | Yes |

> 
> **Note:** SVG2 `cx`로 시작하는 것은 *기하학적 속성* 입니다. 즉, 이 속성은 circle의 CSS 속성으로도 사용할 수 있습니다.
> 
> 
> 

ellipse
-------

`<ellipse>`의 경우, `cx`는 모양 중심의 x축 좌표를 정의합니다.

|  |  |
| --- | --- |
| Value | `<length-percentage>` |
| Default value | `0` |
| Animatable | Yes |

> 
> **Note:** SVG2 `cx`로 시작하는 것은 *기하학적 속성* 입니다. 이는 이 속성이 ellipse의 CSS 속성으로도 사용될 수 있음을 의미합니다.
> 
> 
> 

radialGradient
--------------

`<radialGradient>` (en-US)의 경우 `cx`는 radial Gradient에 대한 끝 원의 x축 좌표를 정의합니다.

|  |  |
| --- | --- |
| Value | `<length>` |
| Default value | `50%` |
| Animatable | Yes |

#### 예제
```

html,
body,
svg {
  height: 100%;
}
```



```html
<svg viewBox="0 0 34 10" xmlns="http://www.w3.org/2000/svg">
  <defs>
    <radialGradient cx="0" id="myGradient000">
      <stop offset="0%" stop-color="gold" />
      <stop offset="50%" stop-color="green" />
      <stop offset="100%" stop-color="white" />
    </radialGradient>

    <radialGradient cx="50%" id="myGradient050">
      <stop offset="0%" stop-color="gold" />
      <stop offset="50%" stop-color="green" />
      <stop offset="100%" stop-color="white" />
    </radialGradient>

    <radialGradient cx="100%" id="myGradient100">
      <stop offset="0%" stop-color="gold" />
      <stop offset="50%" stop-color="green" />
      <stop offset="100%" stop-color="white" />
    </radialGradient>
  </defs>

  <rect
 x="1"
 y="1"
 width="8"
 height="8"
 fill="url(#myGradient000)"
 stroke="black" />
  <rect
 x="13"
 y="1"
 width="8"
 height="8"
 fill="url(#myGradient050)"
 stroke="black" />
  <rect
 x="25"
 y="1"
 width="8"
 height="8"
 fill="url(#myGradient100)"
 stroke="black" />
</svg>
```

명세서
---

| Specification |
| --- |
| Scalable Vector Graphics (SVG) 2 # CX |
| Scalable Vector Graphics (SVG) 2 # RadialGradientElementCXAttribute |

같이 보기
-----

* cy (en-US)
* r (en-US)
약한 서명 알고리즘
==========

디지털 인증서 서명 (en-US)에 사용되는 해시 알고리즘의 강도는 인증서 보안의 중요한 요소입니다. 이 문서에서는 약한 것으로 알려진 서명 알고리즘에 대한 몇 가지 정보를 제공하므로 적절한 때 이 알고리즘을 피할 수 있습니다.

해시 알고리즘의 약점으로 인해 공격자가 사기성 인증서를 생성하거나 획득할 수 있는 상황이 발생할 수 있습니다. 새로운 공격이 발견되고 사용 가능한 기술이 개선됨에 따라 공격이 보다 실현 가능해지면서 이전 알고리즘의 사용은 권장되지 않으며 이에 대한 지원은 결국 제거됩니다.

SHA-1
-----

SHA-1 인증서는 2017년부터 주요 브라우저 제조업체에서 더 이상 안전한 것으로 취급하지 않습니다. 대신 보다 안전한 해시 알고리즘(예: SHA-256 또는 SHA-512)을 사용하는 인증서를 사용해야 합니다.

MD5
---

MD5 기반 서명에 대한 지원은 2012년 초에 제거되었습니다.

같이 보기
-----

* SHA-1 사용 중단에 대한 Mozilla 보안 블로그 게시물
안전하지 않은 비밀번호
============

HTTP를 통한 로그인 양식은 특히 사용자의 비밀번호를 추출하는데 사용할 수 있는 다양한 종류의 공격으로 인해 위험합니다. 네트워크 도청자는 네트워크를 스니핑하거나 전송되는 페이지를 수정하여 사용자의 비밀번호를 훔칠 수 있습니다.

HTTPS 프로토콜은 네트워크에서 도청(기밀성)과 수정(무결성)으로부터 사용자 데이터를 보호하도록 설계되었습니다. 사용자 데이터를 처리하는 웹사이트는 HTTPS를 사용하여 공격자로부터 사용자를 보호해야 합니다. 웹사이트에서 HTTPS 대신 HTTP를 사용하는 경우 사용자 정보(예: 로그인 자격 증명)를 도용하는 것은 간단합니다. 이것은 Firesheep에 의해 유명하게 입증되었습니다.

이 문제를 해결하려면 서버에 SSL/TLS 인증서를 설치하고 구성하세요. 무료 및 유료 인증서를 제공하는 다양한 공급 업체가 있습니다. 클라우드 플랫폼을 사용하는 경우 HTTPS를 사용하는 고유한 방법이 있을 수 있습니다.

비밀번호 재사용에 대한 참고 사항
------------------

가끔 웹사이트는 사용자 이름과 암호를 요구하지만 실제로는 매우 민감한 데이터를 저장하지 않습니다. 예를 들어 뉴스 사이트는 사용자가 다시 읽고 싶은 뉴스 기사가 무엇인지 저장할 수 있겠지만, 사용자에 대한 다른 데이터는 저장하지 않을 수 있습니다. 뉴스 사이트의 웹 개발자는 사이트와 사용자 자격 증명을 보호하려는 의욕이 덜할 수 있습니다.

불행하게도 비밀번호 재사용은 큰 문제입니다. 사용자는 여러 사이트(뉴스 웹사이트, 소셜 네트워크, 이메일 제공업체, 은행)에서 같은 비밀번호를 사용합니다. 따라서 사이트가 사용자의 이름과 암호에 대해 접근하는 것이 큰 위험으로 보이지 않지만, 같은 이름과 암호를 사용하여 은행 계좌에 로그인한 사용자에게는 큰 위험이 됩니다. 공격자는 점점 더 똑똑해지고 있습니다. 한 사이트에서 사용자 이름/암호 쌍을 도용한 다음 더 수익성이 좋은 사이트에서 재사용하려고 합니다.

같이 보기
-----

* No More Passwords over HTTP, Please! — 더 많은 정보가 포함된 자세한 블로그 게시물, 그리고 FAQ.
인증서 투명성
=======

**인증서 투명성**은 잘못된 인증서 발급을 방지하고 모니터링하도록 설계된 개방형 프레임워크로, RFC 9162에 정의되어 있습니다. 인증서 투명성을 통해 새로 발급된 인증서는 공개적으로 실행되고, 종종 독립적인 **CT 로그**에 '로그'됩니다. 이 로그는 발급된 TLS 인증서의 추가 전용 암호화 보증 레코드를 유지합니다.

이러한 방식으로 인증 기관(CA)은 훨씬 더 많은 공개 조사와 감독을 받을 수 있습니다. CA/B 포럼 **기본 요구 사항**을 위반하는 것과 같은 잠재적으로 악의적 사항이 있는 인증서를 훨씬 더 빠르게 감지하고 해지시킬 수 있습니다. 또한 브라우저 벤더와 루트 저장소 관리자는 그들이 불신하기로 결정할 수 있는 문제가 있는 CA에 대해 더 많은 정보에 입각한 결정을 내릴 수 있습니다.

배경
--

CT 로그는 **Merkle 트리** 데이터 구조를 기반으로 구축됩니다. 노드는 하위 노드의 **암호화 해시**로 레이블되고, 리프 노드에는 실제 데이터 조각의 해시가 포함됩니다. 따라서 루트 노드의 레이블은 트리의 다른 모든 노드에 따라 달라집니다.

인증서 투명성의 맥락에서 리프 노드에 의해 해시된 데이터는 오늘날 운영되는 다양한 CA에서 발급된 인증서입니다. 인증서 포함은 O(log n) 시간 복잡도로 효율적으로 생성되고 검증할 수 있는 **감사 증명**을 통해 검증될 수 있습니다.

인증서 투명성은 CA 침해(2011년 DigiNotar 위반), 의심스러운 결정안(2012년 Trustwave 하위 루트 사건) 및 기술적 발급 문제(말레이시아의 Digicert Sdn Bhd에 의한 512비트 취약 인증서 발급)를 배경으로 2013년에 시작되었습니다.

구현
--

인증서가 CT 로그에 제출되면 **서명된 인증서 타임스탬프**(SCT)가 생성되어 반환됩니다. 이는 인증서가 제출되었고 로그에 추가된다는 증거로 사용됩니다.

명세서에는 호환 서버가 연결할 때 **반드시** TLS 클라이언트에 이러한 다수의 SCT를 제공해야 한다고 명시되어 있습니다. 이는 다음과 같은 다양한 메커니즘을 통해 수행될 수 있습니다.

* 서명된 인증서 타임스탬프를 리프 인증서에 직접 포함하는 X.509v3 인증서 확장
* 핸드셰이크 중에 전송된 `signed_certificate_timestamp` 유형의 TLS 확장
* OCSP 스테이플링(즉, `status_request` TLS 확장) 및 하나 이상의 SCT로 `SignedCertificateTimestampList` 제공

X.509 인증서 확장을 사용하면 포함된 SCT가 발급 CA에 의해 결정됩니다. 2021년 6월부터 가장 활발하게 사용되고 공개적으로 신뢰할 수 있는 인증서에는 이 확장에 포함된 투명성 데이터가 포함되어 있습니다. 이 방법은 웹 서버를 수정할 필요가 없는 방법입니다.

후자의 방법을 사용하는 경우 필요한 데이터를 전송하려면 서버를 업데이트해야 합니다. 이 벙법의 장점은 서버 운영자가 TLS 확장/스테이플링된 OCSP 응답을 통해 전송된 SCT를 제공하는 CT 로그 소스를 사용자 정의할 수 있다는 것입니다.

브라우저 요구 사항
----------

Google Chrome은 notBefore 날짜가 2018년 4월 30일 이후인 모든 인증서 대해 CT 로그 포함을 요구합니다. 사용자는 비호환 TLS 인증서를 사용하여 사이트를 방문할 수 없습니다. 이전에 Chrome은 *Extended Validation* (EV)와 Symantec 발급 인증서에 CT 포함을 요구했었습니다.

Apple은 Safari 및 기타 서버가 서버 인증서를 신뢰하기 위해 여러개의 SCT를 요구합니다.

Firefox는 현재 사용자가 방문하는 사이트에 대해 CT 로그 사용을 확인하거나 요구하지 않습니다.
Referer 헤더: 개인 정보 보호 및 보안 문제
============================

Referer HTTP 헤더와 관련된 개인 정보 및 보안 위험이 있습니다. 이 문서는 이런 위험에 대해 설명하고, 이를 완화하는 방법에 대한 조언을 제공합니다.

리퍼러 문제
------

`Referer` (철자 주의) 헤더에는 요청 주소가 들어있습니다(예를 들어, 현재 요청된 페이지의 링크로 이어진 이전 웹 페이지의 주소, 이미지나 기타 리소스를 로드하는 페이지의 주소). 이는 분석, 로깅, 최적화된 캐싱을 포함하여 악의 없는 용도로 많이 사용됩니다. 하지만, 정보를 추적하거나 훔치는 것과 같이 문제가 있는 용도가 더 많이 쓰이고, 실수로 민감한 정보를 유출하는 것과 같은 부작용도 있습니다.

예를 들어, "비밀번호 재설정" 페이지 푸터에 소셜 미디어 링크가 있다고 생각해 보겠습니다. 링크를 따라갔다면, 정보가 어떻게 공유됐는지에 따라 소셜 미디어 사이트는 암호 재설정 URL을 받을 수도 있고, 공유된 정보를 계속 사용할 수 있으므로 잠재적으로 사용자 보안이 침해될 수 있습니다.

같은 논리로, 페이지에 포함된 타사 사이트의 이미지로 인해 민감한 정보가 타사에 유출될 수 있습니다. 보안이 침해되지 않더라도, 이런 정보는 사용자가 공유하길 원하지 않을 수 있습니다.

어떻게 해결할 수 있을까요?
---------------

이러한 위험의 대부분은 애플리케이션의 현명한 설계로 완화할 수 있습니다. 현명한 애플리케이션은 일회용 비밀번호 재설정 URL을 만들거나 이를 고유한 사용자 토큰과 결합하여 위험을 제거합니다. 민감한 데이터를 보다 안전한 방식으로 전송함으로써 위험을 줄일 수도 있습니다.

URL을 통해 민감한 데이터를 다른 위치로 전달하지 않기 위해선 가능한한 `GET` 대신 `POST`를 사용해야 합니다.

항상 HTTPS 사이트를 사용해야 합니다. HTTPS 사이트는 HTTPS가 아닌 사이트에 리퍼러 정보를 전송하지 않는다는 사실을 포함하여 많은 보안 이점이 있습니다. 이 조언은 현재 대부분의 웹이 HTTPS를 사용하고 있기 때문에 관련성이 적지만 여전히 고려할 가치가 있습니다.

또한 비밀번호 재설정 페이지, 결제 양식, 로그인 영역 등과 같은 웹사이트의 보안 영역에서 제3자의 콘텐츠(예: `<iframe>` (en-US)에 포함된 소셜 네트워크 위젯)를 제거하는 것을 고려해야 합니다.

다음을 사용하여 위험을 완화할 수도 있습니다.

* 서버의 `Referrer-Policy` (en-US) 헤더는 `Referer` 헤더를 통해 전송되는 정보를 제어합니다. 예를 들어 `no-referrer` 지시문은 Referer 헤더를 완전히 생략합니다.
* 이러한 정보가 유출될 위험이 있는 HTML 요소(예: `<img>`와 `<a>`)의 `referrerpolicy` 속성입니다. 예를 들어 `Referer` 헤더가 전송되는 것을 중지하도록 `no-referrer`로 설정할 수 있습니다.
* 이러한 정보가 유출될 위험이 있는 HTML 요소(예: `<img>`와 `<a>`)에서 `rel` 속성을 `noreferrer` (en-US)로 설정합니다.
* 전체 문서에 대한 Referer 헤더를 비활성화하기 위해 `referrer`의 name과 콘텐츠가 `no-referrer`으로 설정된 `<meta>` 요소. HTML과 Referrer-Policy 통합 (en-US)을 참조하십시오.
* Exit page 기술.

보안에 민감한 서버 측 프레임워크는 이러한 문제에 대한 완화 기능을 내장하는 경우가 많습니다. 예를 들어 다음과 같습니다.

* Django의 보안(특히 교차 사이트 요청 위조(CSRF) 보호 참조).
* helmetjs referrer-policy — Node.js/Express 앱에서 Referrer-Policy를 설정하기 위한 미들웨어입니다(자세한 보안 규정은 helmetjs 참조).
정책 및 요구 사항
----------

관련 위험을 완화하기 위해 프로젝트 팀에 이러한 기능의 사용을 특정하는 일련의 보안 및 개인 정보 보호 요구 사항을 정하는 것이 좋습니다. 웹 보안 전문가의 도움을 받아 이런 요구 사항을 작성하고, 사용자 요구 사항과 복지는 물론, EU 일반 데이터 보호 규정(GDPR)과 같은 법률에 의해 시행되는 정책과 규정과 같은 기타 문제도 모두 고려해야 합니다.

같이 보기
-----

* Referrer-Policy에 대한 Mozilla 보안 팀 지침
하위 도메인 탈취
=========

하위 도메인 탈취는 공격자가 대상 도메인의 하위 도메인을 제어할 때 일어납니다. 일반적으로 하위 도메인이 도메인 이름 시스템(DNS)에 정식 이름(CNAME)은 있지만 콘텐츠를 제공하는 호스트가 없을 때 발생합니다. 이는 가상 호스트가 아직 게시되지 않았거나 가상 호스트가 제거되었기 때문에 발생할 수 있습니다. 공격자는 그들만의 가상 호스트를 제공하고, 하위 도메인에 그들의 콘텐츠를 호스팅 하여 해당 하위 도메인을 장악할 수 있습니다.

공격자가 이를 수행할 수 있는 경우, 그들은 잠재적으로 기본 도메인에 설정된 쿠키를 읽거나, 교차 사이트 스크립팅을 수행하거나, 콘텐츠 보안 정책을 우회하여 보호된 정보(로그인 포함)를 가져가거나, 의심 없는 사용자에게 악의적인 콘텐츠를 보낼 수 있습니다.

하위 도메인은 전기 콘센트와 같습니다. 자신의 기기(호스트)가 연결되어 있으면 아무 문제 없습니다. 그러나, 콘센트에서 기기를 제거한 경우(또는 아직 꽂지 않은 경우), 누군가 콘센트에 다른 것을 꽂을 수 있습니다. 다른 사람이 콘센트를 사용하지 못하도록 차단기나 퓨즈박스(DNS)에서 전원을 차단해야 합니다.

어떻게 발생하나요?
----------

가상 호스트를 프로비저닝 또는 프로비저닝 해제(제거)하는 과정이 제대로 처리되지 않으면, 공격자가 하위 도메인을 장악할 기회가 있을 수 있습니다.

### 프로비저닝 과정에서

공격자는 여러분보다 먼저 여러분이 호스팅 제공자에게 구입한 하위 도메인에 가상 호스트를 등록합니다.

`example.com` 도메인을 관리한다고 가정해 보겠습니다. 여러분은 `blog.example.com`에 블로그를 추가하고 싶고, 블로그 플랫폼을 유지 관리하는 호스팅 공급자를 사용하기로 결정했습니다. ("블로그"는 "전자상거래 플랫폼", "고객 서비스 플랫폼" 또는 기타 "클라우드 기반" 가상 호스팅 시나리오로 대체할 수 있습니다.) 진행되는 프로세스는 다음과 같습니다.

1. 도메인 등록 기관에 "blog.example.com"이라는 이름을 등록합니다.
2. blog.example.com에 액세스하려는 브라우저가 가상 호스트로 이동하도록 DNS 레코드를 설정합니다.
3. 호스팅 공급자에서 가상 호스트를 생성합니다.

호스팅 공급자가 가상 호스트를 설정하는 주체가 실제 하위 도메인 이름의 소유자인지 매우 신중하게 확인하지 않는 한, 여러분보다 더 빠른 공격자는 여러분의 하위 도메인 이름을 사용하여 동일한 호스팅 공급자에서 가상 호스트를 만들 수 있습니다. 이런 경우, 2단계에서 DNS를 설정하는 즉시 공격자가 하위 도메인에서 콘텐츠를 호스트 할 수 있습니다.

### 프로비저닝 해제 과정에서

가상 호스트를 중단했지만, 공격자는 동일한 이름과 호스팅 공급자를 사용하여 새 가상 호스트를 등록합니다.

여러분(또는 여러분의 회사)은 더 이상 블로그를 유지하지 않기로 결정하여 호스팅 공급자에서 가상 호스트를 제거합니다. 그러나 호스팅 공급자를 가리키는 DNS 항목을 제거하지 않으면, 공격자가 이제 해당 공급자와 함께 자신의 가상 호스트를 만들고, 여러분의 하위 도메인을 할당하여 해당 하위 도메인 아래에서 자신의 콘텐츠를 호스팅 할 수 있습니다.

어떻게 방지하나요?
----------

하위 도메인 탈취 방지는 가상 호스트와 DNS에 대한 수명 주기 관리 작업의 순서 문제입니다. 조직의 규모에 따라 여러 부서 간의 소통과 조정이 필요할 수 있고, 이로 인해 취약한 구성 오류의 가능성만 높아질 수 있습니다.

* 호스트 프로비저닝과 프로비저닝 해제를 위한 표준 과정을 정의하세요. 모든 단계를 가능한 한 밀접하게 수행해야 합니다.
    + 먼저 가상 호스트에 요청하여 프로비저닝을 수행하고, 마지막으로 DNS 레코드를 만드세요.
    + 먼저 DNS 레코드를 제거하고 프로비저닝을 해제하세요.
* 조직의 모든 도메인과 해당 호스팅 제공 업체의 인벤토리를 생성하고, 변경 사항이 있을 때마다 업데이트하여 아무것도 남아 있지 않도록 하세요.
* 공격의 틈을 줄이기 위해 호스팅 공급 업체에 압력을 가하세요. 가상 호스트를 요구하는 누군가가 실제로 도메인 이름에 대한 정당한 권한을 가지고 있는지 어떻게 확인하고 있는지 물어봅니다. 조직 내에서 협력하여 이 부분을 공급업체의 자격 확인 과정의 일부로 만듭니다.
제 하위 도메인이 탈취되었습니다. 어떻게 해야 하나요?
------------------------------

도메인의 하위 도메인이 탈취당한 것을 발견한 경우, 가능하다면 먼저 하위 도메인에 대한 DNS 항목을 제거하여 "전원을 차단"해야 합니다. 사이트에 여러 가상화 계층(예: 가상 호스팅 외에 CDN)이 있다면, 각 계층을 조사하여 공격자가 도메인을 탈취하기 위해 가상 호스트 권한을 주장한 정확한 위치가 어디인지 확인해야 할 수도 있습니다.

더 알아보기
------

* Subdomain Takeover Vulnerabilities의 'Deep Thoughts'
* Subdomain Takeover: Basics
사용자 활성화로 제어되는 기능
================

원하지 않은 동작으로 나쁜 사용자 경험을 제공할 수 있는 API를 애플리케이션이 남용할 수 없도록 하기 위해 일부 API는 사용자가 현재 웹 페이지와 상호 작용 중임을 의미하는 "상호 작용 활성" 상태에 있을 때, 혹은 한 번 이상 페이지와 상호 작용을 한 경우에만 사용할 수 있습니다. 브라우저는 악의적인 스크립트가 이러한 기능을 남용하지 못하도록 팝업, 전체 화면 또는 진동 API와 같은 민감한 API에 대한 액세스를 활성 사용자 상호 작용으로 제한합니다. 이 페이지에는 사용자 활성화 후에만 사용할 수 있는 웹 플랫폼 기능이 나열되어 있습니다.

사용자 활성화는 사용자가 현재 페이지와 상호 작용 중이거나 페이지 로드 이후 상호 작용을 완료했음을 의미합니다. 일반적으로 이것은 버튼 클릭 또는 UI와의 다른 사용자 상호 작용입니다.

보다 정확하게, **활성화 트리거 입력 이벤트**는 다음과 같은 이벤트입니다.

* `isTrusted` 속성이 `true`로 설정되어 있고
* 다음 유형의 이벤트인 경우
    + `keydown` (en-US)(`Esc` 키나 사용자 에이전트가 예약한 바로 가기 키 제외)
    + `mousedown` (en-US)
    + `pointerdown` (en-US) (`pointerType`이 "mouse"인 경우)
    + `pointerup` (en-US) (`pointerType`이 "mouse"가 아닌 경우)
    + `touchend` (en-US)

활성화가 트리거된 경우, 사용자 에이전트는 사용자 활성화 창 상태를 고정과 임시라는 두 가지 유형으로 구분합니다.

임시 활성화
------

임시 활성화는 사용자가 최근에 버튼을 눌렀거나, 마우스를 이동했거나, 메뉴를 사용했거나, 다른 사용자 상호 작용을 수행했음을 나타내는 창 상태입니다. 임시 활성화는 추가 상호 작용으로 갱신되지 않는한 시간 초과 후 만료되며 `Window.open()` (en-US)과 같은 일부 API에서 사용할 수도 있습니다.

임시 활성화가 필요한 예시 API는 다음과 같습니다.

* `beforeunload` 이벤트
* `Clipboard.read()` (en-US)
* `Clipboard.readText()` (en-US)
* `Clipboard.writeText()` (en-US)
* `Document.requestStorageAccess()` (en-US)
* `Element.requestFullScreen()` (en-US)
* `Element.requestPointerLock()` (en-US)
* `GPUAdapter.requestAdapterInfo()`
* `HID.requestDevice()` (en-US)
* `HTMLInputElement.showPicker()` (en-US)
* `HTMLVideoElement.requestPictureInPicture()` (en-US)
* `IdleDetector.requestPermission()` (en-US)
* `MediaDevices.selectAudioOutput()` (en-US)
* `MediaStreamTrack.sendCaptureAction()`
* `MediaDevices.getViewportMedia()`
* `MediaDevices.getDisplayMedia()` (en-US)
* `Navigator.share()`
* `PaymentRequest.show()` (en-US)
* `PresentationRequest.start()` (en-US)
* `RemotePlayback.prompt()` (en-US)
* `USB.requestDevice()` (en-US)
* `Keyboard.lock()` (en-US)
* `Window.open()` (en-US)
* `Window.showOpenFilePicker()` (en-US)
* `Window.showSaveFilePicker()` (en-US)
* `Window.showDirectoryPicker()` (en-US)
* `Window.getScreenDetails()`
* `Window.queryLocalFonts()`
* `XRSystem.requestSession()` (en-US)
고정 활성화
------

고정 활성화는 사용자가 버튼을 눌렀거나, 마우스를 이동했거나, 메뉴를 사용했거나, 다른 사용자 상호 작용을 수행했음을 나타내는 창 상태입니다. 임시 활성화와 달리 처음 설정한 후에는 다시 설정되지 않습니다.

고정 활성화가 필요한 예시 API는 다음과 같습니다.

* `Navigator.vibrate()` (en-US)
* `navigator.getAutoplayPolicy()`
* `navigator.virtualKeyboard.show()`
UserActivation API
------------------

창에 고정 또는 일시적 사용자 활성화가 있는지 프로그래밍적으로 확인하기 위해 `UserActivation` (en-US) API는 `navigator.userActivation` (en-US)을 사용하여 얻을 수 있는 두 가지 속성을 제공합니다.

* `UserActivation.hasBeenActive` (en-US)는 창에 고정 사용자 활성화 여부를 나타냅니다.
* `UserActivation.isActive` (en-US)는 창에 임시 사용자 활성화 여부를 나타냅니다.
같이 보기
-----

* Transient activation
* Sticky activation
* `UserActivation` (en-US) API
* 보안 컨텍스트로 제한된 기능들