diff options
Diffstat (limited to 'files/ko/web/security')
| -rw-r--r-- | files/ko/web/security/index.html | 24 | ||||
| -rw-r--r-- | files/ko/web/security/insecure_passwords/index.html | 67 | ||||
| -rw-r--r-- | files/ko/web/security/same-origin_policy/index.html | 271 | ||||
| -rw-r--r-- | files/ko/web/security/transport_layer_security/index.html | 110 | ||||
| -rw-r--r-- | files/ko/web/security/정보_보안_기본/index.html | 28 | ||||
| -rw-r--r-- | files/ko/web/security/정보_보안_기본/취약점/index.html | 99 |
6 files changed, 599 insertions, 0 deletions
diff --git a/files/ko/web/security/index.html b/files/ko/web/security/index.html new file mode 100644 index 0000000000..eaebaf999e --- /dev/null +++ b/files/ko/web/security/index.html @@ -0,0 +1,24 @@ +--- +title: 웹 보안 +slug: Web/Security +tags: + - Landing + - NeedsTranslation + - Security + - TopicStub + - Web +translation_of: Web/Security +--- +<p><span class="seoSummary">웹 사이트 및 OWA(open web application)의 보안을 유지하는것은 중요합니다. 심지어 코드의 간단한 버그조차도 개인 정보를 유출시킬 수 있습니다. 또한 나쁜 사람들이 데이터를 훔치는 방법을 연구하고 있습니다. 여기에 나열된 웹 보안 관련 기사는 공격 및 데이터 절도로부터 사이트와 코드를 보호하는데 도움이 되는 정보를 제공합니다.</span></p> + +<p>{{LandingPageListSubpages}}</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li><a href="https://lists.mozilla.org/listinfo/dev-security">Mozilla mailing list</a></li> + <li><a href="https://blog.mozilla.com/security/">Blog</a></li> + <li><a href="https://twitter.com/mozsec">@mozsec on Twitter</a></li> +</ul> + +<p>{{QuickLinksWithSubpages}}</p> diff --git a/files/ko/web/security/insecure_passwords/index.html b/files/ko/web/security/insecure_passwords/index.html new file mode 100644 index 0000000000..ddc9f66fa2 --- /dev/null +++ b/files/ko/web/security/insecure_passwords/index.html @@ -0,0 +1,67 @@ +--- +title: 안전하지 않은 비밀번호 +slug: Web/Security/Insecure_passwords +translation_of: Web/Security/Insecure_passwords +--- +<p>HTTP를 통한 로그인 양식은 특히 사용자의 비밀번호를 추출하는데 사용할 수 있는 다양한 종류의 공격으로 인해 위험합니다. 네트워크 도청자는 네트워크를 스니핑하거나 전송되는 페이지를 수정하여 사용자의 비밀번호를 도용할 수 있습니다. 이 페이지는 안전하지 않은 비밀번호와 비밀번호 도용을 둘러싼 위험을 사용자와 개발자에게 경고하기 위해 Firefox가 마련한 보안 메커니즘에 대해 자세히 설명합니다.</p> + +<p><a href="https://mdn.mozillademos.org/files/5951/insecure_page2_with_arrows_cropped.jpeg" title="https://en.wikipedia.org/wiki/HTTP_Secure">HTTPS</a> 프로토콜은 사용자 데이터를 도청(기밀성)하거나 네트워크에 수정(무결성)을 가하는 것으로부터 보호하도록 설계되었습니다. 사용자 데이터를 처리하는 웹사이트는 HTTPS를 사용하여 공격자로부터 사용자를 보호해야 합니다. 웹사이트에서 HTTP 대신 HTTPS를 사용하는 경우 사용자 정보(예 : 로그인 자격 증명)를 훔치는 일은 쉽지 않습니다. 이것은 <a href="https://codebutler.github.io/firesheep/" title="http://codebutler.com/firesheep/">Firesheep</a>에 의해 유명하게 시연되었습니다.</p> + +<p>이 문제를 해결하려면 서버에 SSL/TLS 인증서를 설치하고 구성하십시오. 무료 및 유료 인증서를 제공하는 다양한 공급 업체가 있습니다. 클라우드 플랫폼을 사용하는 경우 HTTPS를 사용하는 고유한 방법이 있을 수 있습니다.</p> + +<h2 id="Firefox_비밀번호_보안_표시기">Firefox 비밀번호 보안 표시기</h2> + +<p>위에서 설명한 위협을 알리기 위해서, Firefox는 많은 경고 메커니즘을 구현합니다.</p> + +<ol> + <li> + <p>Firefox 51버전부터는 로그인 페이지에 보안 연결이 없는 경우, 아래와 보이는 것과 같은 주소 표시줄에 빨간색으로 취소 표시가 있는 잠금 아이콘을 표시합니다.</p> + + <p style="text-align: center;"><img alt="Lock Icon" src="https://support.cdn.mozilla.net/media/uploads/gallery/images/2015-11-17-12-13-18-2faa61.png" style="height: 25px; width: 25px;"></p> + </li> + <li> + <p>Firefox 52버전부터는 URL 표시줄과 안전하지 않은 양식의 선택된 비밀번호 필드 아래에 명확한 경고를 표시합니다.</p> + + <p style="text-align: center;"><img alt="Warning" src="https://support.cdn.mozilla.net/media/uploads/gallery/images/2017-04-21-23-52-53-ba340d.png" style="height: 133px; width: 328px;"></p> + </li> + <li> + <p>Firefox 52버전부터는 안전하지 않은 로그인 양식에 대한 자동 채우기도 비활성화했습니다. 사용자는 저장된 로그인 정보를 드롭다운 목록에서 수동으로 완료할 수 있습니다.</p> + </li> + <li> + <p>안전하지 않은 로그인 양식에 대한 경고는 다음 섹션에서 설명하는 것처럼 모든 Firefox 릴리스의 개발자 콘솔 보안창에서 찾을 수 있습니다.</p> + </li> +</ol> + +<h2 id="웹_콘솔_메시지"><strong>웹 콘솔 메시지</strong></h2> + +<p>이 섹션에서는 안전하지 않은 비밀번호에 대한 응답으로 Firefox DevTools의 개발자 콘솔에 표시되는 보안 메시지에 대해 설명합니다.</p> + +<h3 id="HTTP를_통한_로그인_양식_제공">HTTP를 통한 로그인 양식 제공</h3> + +<p>Form action이 HTTPS URL 인 경우에도 공격자는 사용자가 받을 페이지에 수정을 가할 수 있으므로 사용자의 로그인 양식이 보호되지 않습니다 (예 : 공격자가 form의 목적지를 변경하여 중요한 데이터를 공격자가 제어하는 서버로 보내거나, 사용자가 비밀번호를 입력할 때 비밀번호를 도용하는 키로깅 스크립트를 삽입할 수 있습니다). 웹 콘솔의 보안 탭은 개발자와 사용자에게 보안 문제에 대해 경고합니다.</p> + +<p style="text-align: center;"><img alt="Insecure login form shown with the Web Console and contextual warning on the password field." src="https://mdn.mozillademos.org/files/14783/Insecure_Password_Console_Contextual_sm.png" style="height: 566px; width: 790px;"></p> + +<div class="note"> +<p><strong>주의</strong> : HTTP 문서에 HTTPS 로그인 페이지를 포함시키는 것도 안전하지 않습니다. 공격자는 악의적인 사이트를 가리키도록 프레임 URL을 변경할 수 있습니다.</p> +</div> + +<h3 id="Form_action_에_HTTP_URL_사용"><strong>Form action 에 HTTP URL 사용</strong></h3> + +<p>이 경우 사용자가 입력하는 모든 데이터는 네트워크를 통해 일반 텍스트로 전송됩니다. 사용자의 비밀번호가 사용자의 컴퓨터를 떠나서 웹사이트의 서버에 도달할 때까지 네트워크를 스니핑하는 누구든 사용자의 비밀번호를 볼 수 있습니다.</p> + +<p style="text-align: center;"><img alt="Insecure login form action shown with the Web Console and contextual warning on the password field." src="https://mdn.mozillademos.org/files/14785/Insecure_Action_Password_Console_Contextual_sm.png" style="height: 566px; width: 790px;"></p> + +<h2 id="비밀번호_재사용에_대한_주의사항">비밀번호 재사용에 대한 주의사항</h2> + +<p>가끔씩 웹사이트는 사용자이름과 비밀번호를 요구하지만 실제로는 매우 민감한 데이터는 저장하지 않습니다. 예를 들어, 뉴스 사이트는 사용자가 돌아가서 읽고 싶어하는 뉴스 기사를 저장할 수 있지만 사용자에 대한 다른 데이터는 저장하지 않을 수 있습니다. 뉴스 사이트의 웹 개발자는 자신의 사이트와 사용자 자격 증명을 확보하려는 동기가 적을 수 있습니다.</p> + +<p>불행하게도 <a href="https://www.lightbluetouchpaper.org/2011/02/09/measuring-password-re-use-empirically/">비밀번호 재사용은 큰 문제입니다.</a> 사용자는 여러 사이트(뉴스 웹사이트, 소셜 네트워크, 이메일 제공 업체, 은행)에서 동일한 비밀번호를 사용합니다. 따라서 사용자이름과 비밀번호로 사이트에 접근하는 것이 큰 위험으로 보이지 않더라도 동일한 사용자이름과 비밀번호를 사용하여 은행 계좌에 로그인한 사용자에게는 큰 위험이 따릅니다. 공격자가 점점 더 똑똑해지고 있습니다. 그들은 한 사이트에서 사용자이름/암호 쌍을 훔친 다음 더 수익성있는 사이트에서 다시 사용하려고 시도합니다.</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li class="entry-title"><a href="https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/">HTTP를 통한 비밀번호는 더 이상 안됩니다, 제발!</a> — 더 자세한 정보와 FAQ를 가진 블로그.</li> +</ul> + +<p class="entry-title">{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}</p> diff --git a/files/ko/web/security/same-origin_policy/index.html b/files/ko/web/security/same-origin_policy/index.html new file mode 100644 index 0000000000..3c43aa1837 --- /dev/null +++ b/files/ko/web/security/same-origin_policy/index.html @@ -0,0 +1,271 @@ +--- +title: 동일 출처 정책 +slug: Web/Security/Same-origin_policy +tags: + - CORS + - JavaScript + - Same-origin policy + - Security + - URL + - 교차 출처 정책 + - 동일 출처 정책 +translation_of: Web/Security/Same-origin_policy +--- +<div>{{QuickLinksWithSubpages("/ko/docs/Web/Security")}}</div> + +<p><strong>동일 출처 정책</strong>(same-origin policy)은 어떤 {{Glossary("origin", "출처")}}에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 중요한 보안 방식입니다. 동일 출처 정책은 잠재적으로 해로울 수 있는 문서를 분리함으로써 공격받을 수 있는 경로를 줄여줍니다.</p> + +<h2 id="출처의_정의">출처의 정의</h2> + +<p>두 URL의 {{glossary("protocol", "프로토콜")}}, {{glossary("port", "포트")}}(명시한 경우), {{glossary("host", "호스트")}}가 모두 같아야 <strong>동일한 출처</strong>라고 말합니다. "스킴/호스트/포트튜플"이나 그냥 "튜플"(2개 이상의 요소가 전체를 구성하는 집합)이라고 하기도 합니다.</p> + +<p>아래 표는 URL <code>http://store.company.com/dir/page.html</code>의 출처를 비교한 예시입니다.</p> + +<table class="standard-table"> + <tbody> + <tr> + <th>URL</th> + <th>결과</th> + <th>이유</th> + </tr> + <tr> + <td><code>http://store.company.com/dir2/other.html</code></td> + <td>성공</td> + <td>경로만 다름</td> + </tr> + <tr> + <td><code>http://store.company.com/dir/inner/another.html</code></td> + <td>성공</td> + <td>경로만 다름</td> + </tr> + <tr> + <td><code>https://store.company.com/secure.html</code></td> + <td>실패</td> + <td>프로토콜 다름</td> + </tr> + <tr> + <td><code>http://store.company.com:81/dir/etc.html</code></td> + <td>실패</td> + <td>포트 다름 (<code>http://</code>는 80이 기본값)</td> + </tr> + <tr> + <td><code>http://news.company.com/dir/other.html</code></td> + <td>실패</td> + <td>호스트 다름</td> + </tr> + </tbody> +</table> + +<h3 id="출처_상속">출처 상속</h3> + +<p><code>about:blank</code>와 <code>javascript:</code> URL은 출처 서버에 대한 정보를 가지고 있지 않습니다. 따라서 이런 URL에서 실행하는 스크립트는 해당 URL을 가지고 있는 문서의 출처를 상속합니다.</p> + +<div class="blockIndicator note"> +<p>예를 들어, <code>about:blank</code>는 부모 창에서 내용을 채워넣을 빈 팝업({{domxref("Window.open()")}} 등의 방식으로 생성)의 URL로 주로 사용됩니다. 만약 이 팝업이 JavaScript도 포함한다면 팝업을 생성한 스크립트의 출처를 따라가게 됩니다.</p> +</div> + +<div class="blockIndicator warning"> +<p><code>data:</code> URL은 비어있는 보안 맥락을 새로 받습니다.</p> +</div> + +<h3 id="Internet_Explorer_예외사항">Internet Explorer 예외사항</h3> + +<p>Internet Explorer는 동일 출처 정책에 두 가지 중요한 예외사항이 있습니다.</p> + +<dl> + <dt>신뢰할 수 있는 사이트</dt> + <dd>양쪽 도메인 모두가 <strong>높음</strong> 단계의 보안 수준을 가지고 있는 경우 동일 출처 제약을 적용하지 않습니다.</dd> + <dt>포트</dt> + <dd>Internet Explorer는 동일 출처 정책 검사에 포트를 포함하지 않습니다. 따라서 <code>http://company.com:81/index.html</code>과 <code>http://company.com/index.html</code>은 동일 출처로 간주하며, 제한을 두지 않습니다.</dd> +</dl> + +<p>두 예외 모두 비표준이며 다른 브라우저에서는 지원하지 않습니다.</p> + +<h2 id="출처_변경">출처 변경</h2> + +<p>일부 제약이 있긴 하지만 페이지의 출처를 변경하는 것도 가능합니다. 스크립트로{{domxref("document.domain")}}의 값을 현재 도메인이나 현재 도메인의 상위 도메인으로 변경할 수 있는데, 상위 도메인으로 설정한 경우 (더 짧은) 상위 도메인을 동일 출처 검사에 사용합니다.</p> + +<p><code>http://store.company.com/dir/other.html</code> 문서의 스크립트가 다음 코드를 실행한 이후를 가정해보겠습니다.</p> + +<pre class="notranslate">document.domain = "company.com"; +</pre> + +<p>해당 페이지는 <code>http://company.com/dir/page.html</code>과의 동일 출처 검사를 통과할 수 있습니다. (단, <code>http://company.com/dir/page.html</code> 역시 자신의 <code>document.domain</code>을 <code>"company.com"</code>으로 설정해 이런 동작을 허용하겠다고 알려줘야 합니다. {{domxref("document.domain")}} 문서에서 더 알아보세요.) 그러나, <code>company.com</code>은 <code>document.domain</code>을 <code>othercompany.com</code>으로 설정할 수 <strong>없습니다</strong>. <code>company.com</code>의 상위 도메인이 아니기 때문입니다.</p> + +<p>포트 번호는 브라우저가 따로 검사합니다. 모든 <code>document.domain</code>의 변화, 심지어 <code>document.domain = document.domain</code>조차 포트 번호를 {{jsxref("null")}}로 덮어씁니다. 따라서 <code>company.com:8080</code>과 <code>company.com</code>을 서로 연결하고자 할때 앞쪽에서 <code>document.domain = "company.com"</code>을 추가하는 것만 가지고는 <strong>불가능</strong>하며, 반드시 양쪽 모두 자신의 포트 숫자를 <code>null</code>로 설정해야 합니다.</p> + +<div class="note"> +<p><strong>참고:</strong> <code>document.domain</code>을 통해 서브도메인이 부모에 안전하게 접근할 수 있도록 허용할 때, 반드시 부모와 자식 모두의 <code>document.domain</code>을 같은 값으로 지정해야 합니다. 부모 도메인을 자기 자신의 값으로 설정하는, 아무 의미도 없어 보이는 경우라도 지정이 필요합니다. 그렇지 않으면 권한 오류가 발생할 수 있습니다.</p> +</div> + +<h2 id="교차_출처_네트워크_접근">교차 출처 네트워크 접근</h2> + +<p>동일 출처 정책은 서로 다른 출처 사이에서 {{domxref("XMLHttpRequest")}} 혹은 {{htmlelement("img")}} 요소를 사용할 때 등의 상호작용을 통제합니다. 상호작용은 보통 다음의 세 가지 범주로 나뉩니다.</p> + +<ul> + <li>교차 출처 쓰기는 보통 허용합니다. 예시로는 링크, 리다이렉트, 양식 제출 등이 있습니다. 일부 HTTP 요청은 <a href="/en-US/docs/Web/HTTP/CORS#Preflighted_requests">프리플라이트</a>를 요구합니다.</li> + <li>교차 출처 삽입은 보통 허용합니다. 예시는 아래에 있습니다.</li> + <li>교차 출처 읽기는 보통 불허하지만, 종종 교차 출처 삽입 과정에서 읽기 권한이 누출됩니다. 가령 삽입한 이미지의 크기나, 삽입한 스크립트의 행동, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=629094">삽입한 리소스의 가용성</a> 등을 읽을 수 있습니다.</li> +</ul> + +<p>다음은 교차 출처로 삽입할 수 있는 리소스의 일부 예제입니다.</p> + +<ul> + <li><code><script src="..."></script></code>로 추가하는 JavaScript. 그러나 구문 오류에 대한 상세 정보는 동일 출처 스크립트에서만 확인 가능합니다.</li> + <li><code><link rel="stylesheet" href="..."></code>로 적용하는 CSS. CSS의 <a href="https://scarybeastsecurity.blogspot.com/2009/12/generic-cross-browser-cross-domain.html">느슨한 구문 규칙</a>으로 인해, 교차 출처 CSS는 올바른 <code>Content-Type</code> 헤더를 필요로 합니다. 브라우저 별 제한은 다릅니다. <a href="https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/gg622939(v=vs.85)?redirectedfrom=MSDN">Internet Explorer</a>, <a href="https://www.mozilla.org/en-US/security/advisories/mfsa2010-46/">Firefox</a>, <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=9877">Chrome</a>, <a href="https://support.apple.com/ko-kr/HT4070">Safari</a>(CVE-2010-0051), <a href="https://security.opera.com/cross-domain-data-theft-with-css-load-opera-security-advisories/">Opera</a></li> + <li>{{htmlelement("img")}}로 표시하는 이미지.</li> + <li>{{htmlelement("video")}}와 {{htmlelement("audio")}}로 재생하는 미디어.</li> + <li>{{htmlelement("object")}}와 {{htmlelement("embed")}}로 삽입하는 외부 리소스.</li> + <li>{{cssxref("@font-face")}}로 적용하는 글씨체. 하지만 일부 브라우저는 동일 출처를 요구할 수도 있습니다.</li> + <li>{{htmlelement("iframe")}}으로 삽입하는 모든 것. {{httpheader("X-Frame-Options")}} 헤더를 사용해 교차 출처 프레임의 대상이 되는 것을 방지할 수 있습니다.</li> +</ul> + +<h3 id="교차_출처_접근_허용하기">교차 출처 접근 허용하기</h3> + +<p><a href="/ko/docs/Web/HTTP/CORS" title="HTTP/Access_control_CORS">CORS</a>를 사용해 교차 출처 접근을 허용하세요. CORS는 {{glossary("HTTP")}}의 일부로, 어떤 호스트에서 자신의 콘텐츠를 불러갈 수 있는지 서버에 지정할 수 있는 방법입니다.</p> + +<h3 id="교차_출처_접근_막기">교차 출처 접근 막기</h3> + +<ul> + <li>교차 출처 쓰기를 방지하려면 추측 불가능한 토큰을 요청에 포함하세요. <a href="https://owasp.org/www-community/attacks/csrf">교차 출처 요청 위조(Cross-Site Request Forgery, CSRF)</a> 토큰이라고 부릅니다. 토큰을 요구하는 페이지의 교차 출처 읽기도 막아야 합니다.</li> + <li>리소스의 교차 출처 읽기를 방지하려면 삽입 불가하도록 설정하세요. 리소스 삽입 과정에서 일부 정보가 새어 나가므로 방지해야 합니다.</li> + <li>교차 출처 삽입을 방지하려면, 리소스가 위에 나열한 삽입 가능 형태로 읽히지 않도록 해야 합니다. 브라우저는 Content-Type 헤더를 준수하지 않을 수도 있습니다. 즉, <code><script></code> 태그가 HTML 문서를 가리키도록 설정하는 경우, 브라우저는 HTML을 JavaScript로 분석하려고 시도합니다. 방지하려는 리소스가 사이트의 진입점이 아닌 경우 CSRF 토큰을 사용하는 것도 삽입 방지의 방법입니다.</li> +</ul> + +<h2 id="교차_출처_스크립트_API_접근">교차 출처 스크립트 API 접근</h2> + +<p>{{domxref("HTMLIFrameElement.contentWindow", "iframe.contentWindow")}}, {{domxref("window.parent")}}, {{domxref("window.open")}}, {{domxref("window.opener")}} 등의 JavaScript API는 문서가 서로를 직접 참조할 수 있도록 합니다. 이때 두 문서의 출처가 같지 않을 경우 참조를 통해 {{domxref("Window")}}와 {{domxref("Location")}} 객체로의 매우 제한된 접근만 가능합니다. 아래의 두 구획에서 접근 가능한 항목을 볼 수 있습니다.</p> + +<p>서로 다른 출처의 문서간 통신을 하려면 {{domxref("window.postMessage()")}}를 사용하세요.</p> + +<p>명세: <a class="external external-icon" href="https://html.spec.whatwg.org/multipage/browsers.html#cross-origin-objects">HTML Living Standard § Cross-origin objects</a></p> + +<h3 id="Window">Window</h3> + +<p>교차 출처에서 <code>Window</code>의 다음 항목에 접근할 수 있습니다.</p> + +<table class="fullwidth-table standard-table"> + <thead> + <tr> + <th scope="col">메서드</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{domxref("window.blur")}}</td> + </tr> + <tr> + <td>{{domxref("window.close")}}</td> + </tr> + <tr> + <td>{{domxref("window.focus")}}</td> + </tr> + <tr> + <td>{{domxref("window.postMessage")}}</td> + </tr> + </tbody> +</table> + +<table class="fullwidth-table standard-table"> + <thead> + <tr> + <th scope="col">속성</th> + <th scope="col"></th> + </tr> + </thead> + <tbody> + <tr> + <td>{{domxref("window.closed")}}</td> + <td>읽기 전용.</td> + </tr> + <tr> + <td>{{domxref("window.frames")}}</td> + <td>읽기 전용.</td> + </tr> + <tr> + <td>{{domxref("window.length")}}</td> + <td>읽기 전용.</td> + </tr> + <tr> + <td>{{domxref("window.location")}}</td> + <td>읽기/쓰기.</td> + </tr> + <tr> + <td>{{domxref("window.opener")}}</td> + <td>읽기 전용.</td> + </tr> + <tr> + <td>{{domxref("window.parent")}}</td> + <td>읽기 전용.</td> + </tr> + <tr> + <td>{{domxref("window.self")}}</td> + <td>읽기 전용.</td> + </tr> + <tr> + <td>{{domxref("window.top")}}</td> + <td>읽기 전용.</td> + </tr> + <tr> + <td>{{domxref("window.window")}}</td> + <td>읽기 전용.</td> + </tr> + </tbody> +</table> + +<p>일부 브라우저는 위의 항목보다 더 많은 접근을 허용할 수도 있습니다.</p> + +<h3 id="Location">Location</h3> + +<p>교차 출처에서 <code>Location</code>의 다음 항목에 접근할 수 있습니다.</p> + +<table class="fullwidth-table standard-table"> + <thead> + <tr> + <th scope="col">메서드</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{domxref("location.replace")}}</td> + </tr> + </tbody> +</table> + +<table class="fullwidth-table standard-table"> + <thead> + <tr> + <th scope="col">속성</th> + <th scope="col"></th> + </tr> + </thead> + <tbody> + <tr> + <td>{{domxref("URLUtils.href")}}</td> + <td>쓰기 전용.</td> + </tr> + </tbody> +</table> + +<p>일부 브라우저는 위의 항목보다 더 많은 접근을 허용할 수도 있습니다.</p> + +<h2 id="교차_출처_데이터_저장소_접근">교차 출처 데이터 저장소 접근</h2> + +<p><a href="/ko/docs/Web/API/Web_Storage_API">Web Storage</a>와 <a href="/ko/docs/Web/API/IndexedDB_API">IndexedDB</a> 등 브라우저에 저장한 데이터로의 접근은 출처별로 제한됩니다. 각각의 출처는 별도의 저장소를 받으며, 한 출처의 JavaScript에서 다른 출처의 저장소를 읽거나 쓰는 것은 불가능합니다.</p> + +<p>{{glossary("Cookie", "쿠키")}}는 출처에 대해 다른 정의를 사용합니다. 어떤 페이지는 자신의 도메인은 물론, 공개 접두사가 아닌 모든 부모 도메인에 대해 쿠키를 설정할 수 있습니다. Firefox와 Chrome은 <a href="https://publicsuffix.org/">Public Suffix List</a>를 사용해 도메인의 공개 접두사 여부를 판별합니다. Internet Explorer는 별도의 내부 방식을 사용합니다. 브라우저는 주어진 도메인 및 하위 도메인에 대한 쿠키 접근을 허용하며, 사용한 {{glossary("protocol", "프로토콜")}}(HTTP/HTTPS)과 {{glossary("port", "포트")}}는 검사하지 않습니다. 쿠키를 설정할 때 <code>Domain</code>, <code>Path</code>, <code>Secure</code>, <code>HttpOnly</code> 플래그를 사용해 쿠키 접근을 제한할 수 있습니다. 쿠키를 읽을 때, 쿠키를 설정한 장소는 볼 수 없습니다. 오로지 안전한 HTTPS 연결만 사용하더라도, 보이는 쿠키 중 어떠한 것이라도 안전하지 않은 연결에서 설정한 것일 수 있습니다.</p> + +<h2 id="같이_보기">같이 보기</h2> + +<ul> + <li><a href="https://www.w3.org/Security/wiki/Same_Origin_Policy" title="http://www.w3.org/Security/wiki/Same_Origin_Policy">W3C의 Same-Origin Policy</a></li> + <li><a href="https://web.dev/secure/same-origin-policy">web.dev의 Same-origin policy</a></li> +</ul> + +<div class="originaldocinfo"> +<h2 id="Original_Document_Information" name="Original_Document_Information">원본 문서 정보</h2> + +<ul> + <li>저자: Jesse Ruderman</li> +</ul> +</div> diff --git a/files/ko/web/security/transport_layer_security/index.html b/files/ko/web/security/transport_layer_security/index.html new file mode 100644 index 0000000000..16ba656e8e --- /dev/null +++ b/files/ko/web/security/transport_layer_security/index.html @@ -0,0 +1,110 @@ +--- +title: Transport Layer Security +slug: Web/Security/Transport_Layer_Security +translation_of: Web/Security/Transport_Layer_Security +--- +<div>{{draft}}</div> + +<p><span class="seoSummary"> TLS(Transport Layer Security)를 사용하는 연결의 보안은 암호 스위트(Ciper Suites)와 선택된 보안 파라메터에 강하게 의존합니다. 이 문서는 클라이언트와 서버 사이의 기밀성과 무결성 통신을 보장하기 위한 결정을 하도록 돕는 것이 목적입니다. 모질라 운영 보안(OpSec) 팀은 서버를 위한 참조용 설정이 있는 <a href="https://wiki.mozilla.org/Security/Server_Side_TLS">위키</a>를 관리합니다..</span></p> + +<p class="summary"> TLS(Transport Layer Security) 프로토콜은 네트워크로 연결된 두 개의 어플리케이션 혹은 디바이스가 비밀스럽고 강건하게 정보를 교환하도록 하는 표준입니다. TLS를 사용하는 어플리케이션은 데이터의 보안과 신뢰성에 상당한 영향을 미칠 수 있는 보안 파라메터를 선택할 수 있습니다. 이 글은 TLS에 대한 개요와 컨텐츠를 보호할 때 결정해야 할 사항에 대해 설명합니다.</p> + +<h2 id="역사">역사</h2> + +<p> HTTPS가 처음 발표 됐을 때는 넷스케이프가 도입한 기술인 SSL(Secure Sockets Layer) 2.0에 기반을 뒀습니다. 얼마되지 않아 SSL이 3.0으로 업데이트 되고 사용처가 확대되면서, 모든 웹 브라우저와 서버 사이에 상호 운영성을 보장하기 위한 공통의 표준 암호화 기술이 지정해야 하는 것이 명확해졌습니다. 국제 인터넷 표준화 기구(IETF)는 1999년 1월, TLS 1.0 {{RFC(2246)}}을 지정했습니다. 현재 TLS의 버전은 1.2 {{RFC(5246)}}입니다. 프로토콜에 대한 주요 개정 작업이 진행중이며, TLS 1.3이 거의 완성됐습니다.</p> + +<div class="note"> +<p>이제 웹이 암호화에 TLS를 사용하고 있음에도 불구하고, 많은 사람들이 아직까지 습관적으로 TLS를 "SSL"이라고 언급합니다. </p> +</div> + +<p> TLS가 모든 저수준의 전송 프로토콜의 위에서 사용될 수 있지만, 이 프로토콜은 원래 HTTP 트래픽을 암호화하는 것이 목적이었습니다. TLS로 암호화된 HTTP는 흔히 HTTPS라고 언급됐습니다. TLS로 암호화된 웹 트래픽은 관습적으로 443 포트를 통해 교환되었으며, 암호화되지 않은 HTTP는 기본적으로 80번 포트를 사용합니다. HTTPS는 중요한 TLS 사용 사례로 남았습니다.</p> + +<h2 id="HTTP보다_TLS">HTTP보다 TLS</h2> + +<p>TLS는 주고받는 데이터의 안전과 보안을 보장하게 하는 세 가지 주요 서비스를 제공합니다. </p> + +<dl> + <dt>인증</dt> + <dd>인증은 커뮤니케이션에 대한 각각의 당사자가 상대방이 주장하는 사람인지 검증하게 합니다.</dd> + <dt>암호화</dt> + <dd>데이터는 사용자 에이전트와 서버 사이에 전송이 되는 동안에 허용되지 않은 쪽에 의해 데이터가 읽혀지고 가로채지는 것을 방지하기 위해서 암호화됩니다.</dd> + <dt>무결성</dt> + <dd>TLS는 데이터를 암호화하고 전송하고 복호화하는 동안에 정보가 없어지거나, 손실되거나, 위변조되지 않는 것을 보장합니다.</dd> +</dl> + +<p>TLS 연결은 클라이언트와 서버가 공유된 암호에 동의하고, 보안 스위트(cipher suite)같은 중요한 파라메터가 협상되는 핸드쉐이크 단계로 시작합니다. Once parameters and a data exchange mode where application data, such HTTP, is exchanged.</p> + +<h3 id="Cipher_suites">Cipher suites</h3> + +<p>TLS 핸드쉐이크가 협상하는 주요 파라메터들은 {{interwiki("wikipedia", "cipher suite")}}입니다.</p> + +<p>In TLS 1.2 and earlier, the negotiated cipher suite includes a set of cryptographic algorithms that together provide the negotiation of the shared secret, the means by which a server is authenticated, and the method that will be used to encrypt data.</p> + +<p>The cipher suite in TLS 1.3 primarily governs the encryption of data, separate negotiation methods are used for key agreement and authentication.</p> + +<p>Different software might use different names for the same cipher suites. For instance, the names used in OpenSSL and GnuTLS differ from those in the TLS standards. The <a href="https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table">cipher names correspondence table</a> on the Mozilla OpSec team's article on TLS configurations lists these names as well as information about compatibility and security levels.</p> + +<h3 id="Configuring_your_server">Configuring your server</h3> + +<p>서버를 올바르게 구성하는 것은 매우 중요합니다. 일반적으로, 사이트에 연결하려는 브라우저와 호환 가능한 최신 암호화 기능으로만 한정적으로 설정하는 것이 좋습니다. 올바른 설정과 관련해서 <a href="https://wiki.mozilla.org/Security/Server_Side_TLS">Mozilla OpSec guide to TLS configurations</a> 에서 추가적인 정보를 얻을 수 있습니다.</p> + +<p>To assist you in configuring your site, Mozilla provides a helpful <a href="https://mozilla.github.io/server-side-tls/ssl-config-generator/">TLS configuration generator</a> that will generate configuration files for the following Web servers:</p> + +<ul> + <li>Apache</li> + <li>Nginx</li> + <li>Lighttpd</li> + <li>HAProxy</li> + <li>Amazon Web Services CloudFormation Elastic Load Balancer</li> +</ul> + +<p>Using the <a href="https://mozilla.github.io/server-side-tls/ssl-config-generator/">configurator</a> is a recommended way to create the configuration to meet your needs; then copy and paste it into the appropriate file on your server and restart the server to pick up the changes. The configuration file may need some adjustments to include custom settings, so be sure to review the generated configuration before using it; installing the configuration file without ensuring any references to domain names and the like are correct will result in a server that just doesn't work.</p> + +<h2 id="TLS_1.3">TLS 1.3</h2> + +<p>{{RFC("8446", "TLS 1.3")}} is a major revision to TLS. TLS 1.3은 보안과 성능을 향상시키는 많은 변화들을 포함하고 있습니다. TLS 1.3의 목표는:</p> + +<ul> + <li>TLS 1.2에서 사용하지 않고 안전하지 않은 요소들을 제거하는 것</li> + <li>디자인에 높은 수준의 보안 분석을 포함시키는 것</li> + <li>더 많은 프로토콜들의 암호화를 통해 프라이버시를 향상시키는 것</li> + <li>핸드쉐이크를 성립시키는데 소요되는 시간을 단축시키는 것</li> +</ul> + +<p>TLS 1.3은 프로토콜의 기본적인 부분들에 변화를 주지만, 이전 버전의 TLS의 기본적인 작업들을 대부분 온전히 수행할 수 있습니다. 웹에서 TLS 1.3은 아주 드문 예외적인 경우들을 제외하면 원활하게 사용될 수 있습니다.(아래 참고).</p> + +<p>TLS 1.3의 주요 변화들은:</p> + +<ul> + <li>TLS 1.3 핸드쉐이크는 대부분의 경우에 한번의 왕복만으로 성립되어, 핸드쉐이크 지연시간을 단축.</li> + <li>서버는 0-RTT(zero round trip time) 핸드쉐이크를 활성화시킬 수 있다. 서버에 재접속하려는 클라이언트들은 요청(request)을 즉시 보낼 수 있으며, 이를 통해 TLS 핸드쉐이크의 지연시간을 완전히 단축시킬 수 있다. 성능적인 측면에서 보면 0-RTT를 통해 얻을 수 있는 이점이 상당하지만, 리플레이 공격(replay attack)의 위험을 감수해야하므로 0-RTT를 활성화하기 전에 주의가 필요.</li> + <li>TLS 1.3 supports forward-secure modes only, unless the connection is resumed or it uses a pre-shared key.</li> + <li>TLS 1.3 defines a new set of cipher suites that are exclusive to TLS 1.3. These cipher suites all use modern Authenticated Encryption with Associated Data (AEAD) algorithms.</li> + <li>The TLS 1.3 handshake is encrypted, except for the messages that are necessary to establish a shared secret. In particular, this means that server and client certificates are encrypted. Note however that the server identity (the server_name or SNI extension) that a client sends to the server is not encrypted.</li> + <li>Numerous mechanisms have been disabled: renegotiation, generic data compression, {{interwiki("wikipedia", "Digital Signature Algorithm")}} (DSA) certificates, static RSA key exchange, and key exchange with custom Diffie-Hellman (DH) groups.</li> +</ul> + +<p>Implementations of draft versions of TLS 1.3 are available. TLS 1.3 is enabled in some browsers, including the 0-RTT mode. Web servers that enable TLS 1.3 might need to adjust configuration to allow TLS 1.3 to operate successfully.</p> + +<p>TLS 1.3 adds just one significant new use case. The 0-RTT handshake can provide significant performance gains for latency sensitive applications, like the web. Enabling 0-RTT requires additional steps, both to ensure successful deployment and to manage the risks of replay attacks.</p> + +<p>TLS 1.3에서 재협상을 제거함으로써, 증명서(certificate)를 이용한 클라이언트 인증에 의존하는 몇몇 웹서버들이 영향을 받을 수 있습니다.어떤 웹서버들은 재협상을 통해 클라이언트 증명서의 암호화를 보장하거나, 특정 리소스가 필요할 때 재협상을 통해 클라이언트 증명서를 요청합니다. 클라이언트 증명서의 프라이버시를 위해, TLS 1.3 핸드쉐이크의 보안은 클라이언트 증명서가 암호화되었다는 것을 보장해줍니다. 그러나 소프트웨어에 변화가 필요할지도 모릅니다. TLS 1.3은 증명서를 사용한 반응형 클라이언트 인증을 지원하지만, 대중적으로 사용되지는 않습니다. HTTP/2를 지원하는 대안책들이 개발중에 있습니다.</p> + +<h2 id="TLS_handshake_timeout_values">TLS handshake timeout values</h2> + +<p>어떤 이유에서든지 간에 TLS 핸드쉐이크가 느려지거나 반응이 없다면 사용자 입장에서는 큰 영향을 받을 수가 있습니다. 이러한 문제들을 완화시키기위해 모던 브라우저들은 핸드쉐이크 시간 만료(handshake timeout)를 도입했습니다:</p> + +<ul> + <li>Firefox는 version 58 이후로 30초를 디폴트 값으로 가지는 TLS handshake timeout을 도입했습니다. Timeout value 값은 about:config에 있는 <code>network.http.tls-handshake-timeout</code> 를 통해 재설정 할 수 있습니다.</li> +</ul> + +<h2 id="See_also">See also</h2> + +<ul> + <li>The <a href="https://mozilla.github.io/server-side-tls/ssl-config-generator/">Mozilla TLS Configurator</a> can help you generate configuration files for your server to secure your site.</li> + <li><a href="https://cipherli.st/">Cipherli.st</a> provides of strong TLS configurations for a variety of software products.</li> + <li>The Mozilla Operations Security (OpSec) team maintains a wiki page with <a href="https://wiki.mozilla.org/Security/Server_Side_TLS">reference TLS configurations</a>.</li> + <li><a href="https://observatory.mozilla.org/">Mozilla Observatory</a>, <a href="https://www.ssllabs.com/ssltest/">SSL Labs</a>, and <a href="https://github.com/mozilla/cipherscan">Cipherscan</a> can help you test a site to see how secure its TLS configuration is.</li> +</ul> + +<p>{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}</p> diff --git a/files/ko/web/security/정보_보안_기본/index.html b/files/ko/web/security/정보_보안_기본/index.html new file mode 100644 index 0000000000..48eeaed961 --- /dev/null +++ b/files/ko/web/security/정보_보안_기본/index.html @@ -0,0 +1,28 @@ +--- +title: Information Security Basics +slug: Web/Security/정보_보안_기본 +translation_of: Web/Security/Information_Security_Basics +--- +<p><span class="seoSummary"> 정보 보안에 대한 기본적인 이해는 불안전하거나 취약점으로 인해 생긴 약점이 악의적인 이유로 악용되지 않게 당신을 도와줄 것입니다. 이 기사는 당신이 알아야 할 것을 배우는데 도움을 줄 것 입니다.</span> 이 정보를 이용하면, 웹 개발주기 및 콘텐츠 배포를 넘어 보안의 역할과 중요성을 알게될 것입니다.</p> + +<dl> + <dt><a href="/en-US/Learn/Confidentiality,_Integrity,_and_Availability">신뢰성, 무결성, 가용성</a></dt> + <dd>보안을 이해하기 위해 필수적이고 기본적인 보안의 목적에 대해 설명합니다. </dd> + <dt><a href="/en-US/Learn/Vulnerabilities">취약점</a></dt> + <dd>취약점의 주요 카테고리를 정의하고, 모든 소프트웨어에 있는 취약점에 대해서 논의합니다. </dd> + <dt><a href="/en-US/Learn/Threats">위협</a></dt> + <dd>주요한 위협의 개념에 대해 간단히 소개합니다.</dd> + <dt><a href="/en-US/Learn/Security_Controls">보안 제어</a></dt> + <dd>보안 제어의 주요 카테고리를 정의하고, 잠재적인 단점에 대해서 논의합니다. </dd> + <dt><a href="/en-US/Learn/TCP_IP_Security">TCP/IP 보안</a></dt> + <dd>SSL에 대한 보안 고려 사항에 초점을 맞춘 TCP / IP 모델의 개요.</dd> +</dl> + +<h2 id="참고">참고</h2> + +<ul> + <li><a href="/en-US/docs/Mozilla/Security">Browser security</a></li> + <li><a href="/en-US/docs/Web/Security">Web security</a></li> + <li><a href="/en-US/docs/Web/Security/Securing_your_site">Securing your site</a></li> + <li><a href="/en-US/docs/Security/Firefox_Security_Basics_For_Developers">Firefox Security Basics for Developers</a></li> +</ul> diff --git a/files/ko/web/security/정보_보안_기본/취약점/index.html b/files/ko/web/security/정보_보안_기본/취약점/index.html new file mode 100644 index 0000000000..8b7543b414 --- /dev/null +++ b/files/ko/web/security/정보_보안_기본/취약점/index.html @@ -0,0 +1,99 @@ +--- +title: 취약점 +slug: Web/Security/정보_보안_기본/취약점 +tags: + - 보안 + - 웹 보안 + - 초보자 + - 취약점 + - 튜토리얼 +translation_of: Archive/Security/Vulnerabilities +--- +<div class="summary"> +<p>이 글은 취약점이 무엇인지, 그리고 모든 시스템에서 어떻게 나타나는 지에 대하여 다룹니다.</p> +</div> + +<p>취약점은 신뢰성, 무결성 및/또는 가용성에 부정적으로 작용할 수 있는 시스템 내의 약점입니다. 취약점을 분류할 수 있는 방법은 여러가지가 있습니다. 이 글은 소프트웨어 결함, 보안 설정 문제, 그리고 소프트웨어 기능 오용의 세가지 상위 취약점 분류를 사용합니다. 이러한 분류는 아래에서 설명하고 있습니다.</p> + +<h2 id="취약점_분류">취약점 분류</h2> + +<p><font><em>소프트웨어 결함 취약점</em>은 소프트웨어 설계 또는 코딩에서의 의도하지 않은 오류로 인해 발생합니다. 사용자가 제공한 입력이 알려진 공격과 관련있는 악의적인 문자열이거나 지나치게 긴 값에 대해 적절하게 평가되지 않는 것과 같은 입력 유효성 검사 오류를 그 예로 들 수 있습니다. 또 다른 예로는, 공격자가 상승된 권한으로 특정 작업을 수행할 수 있는 경합 조건 오류가 있습니다.</font></p> + +<p><font>보안 구성 설정은 소프트웨어 자체를 통해 변경할 수 있는 소프트웨어 보안의 요소입니다. 설정의 예로는 사용자에게 파일에 대한 권한을 설정하는 제어 목록에 대한 액세스를 제공하는 운영 체제와, 응용 프로그램이 저장한 중요한 데이터의 암호화를 활성화 또는 비활성화하는 응용 프로그램입니다.</font></p> + +<p><em>보안 구성 문제 취약점</em>에는 소프트웨어 보안에 부정적인 영향을 주는 보안 구성 설정이 사용됩니다.</p> + +<p><font>소프트웨어 기능은 소프트웨어에서 제공하는 기능입니다. </font><font><em>소프트웨어 기능 오용 취약점</em>은 시스템 보안을 손상시키는 방법도 제공합니다. </font><font>이러한 취약점은 소프트웨어 디자이너가 유익한 기능을 제공하도록 허용하는 신뢰 가정을 만드는 한편, 누군가가 보안 손상에 대한 신뢰 가정을 위반할 가능성을 초래하기 때문입니다.</font></p> + +<p><font>예를 들어, 이메일 클라이언트 소프트웨어는 이메일 메시지에 HTML컨텐츠를 렌더링 하는 기능을 포함할 수 있습니다. </font><font>공격자는 HTML로 렌더링 된 하이퍼링크가 포함된 사기성 전자 메일 메시지를 조작할 수 있습니다. 하이퍼링크는 수신인에게 양호한 것으로 표시되지만 클릭하면 실제로 수신인을 악성 웹 사이트로 가져옵니다. </font><font>HTML콘텐츠 렌더링 기능 설계 시 신뢰할 수 있는 가정 중 하나는 사용자가 악의적인 하이퍼링크를 수신하지 않고 클릭하지 않는다는 것입니다.</font></p> + +<p><font>소프트웨어 기능 오용 취약점은 소프트웨어 또는 소프트웨어 구성 요소의 설계 중에 발생합니다(예:소프트웨어가 구현하는 프로토콜). </font><font>신뢰 가정은 사실일 수 있습니다. 예를 들어, 설계자는 보안 약점을 인식하고 별도의 보안 통제가 이를 보상할 것이라고 판단합니다.</font></p> + +<p><font>그러나, 신뢰가 도입할 위험을 먼저 평가하지 않고 특징을 생성하는 것과 같이, 신뢰 가정은 주로 암묵적입니다. 위협 요소는 소프트웨어 수명 주기 또는 소프트웨어에 사용되는 프로토콜에 따라 변경될 수도 있습니다.</font></p> + +<p><font>예를 들어 주소 결정 프로토콜(ARP)는 ARP 응답이 매체 접근 제어(MAC) 및 인터넷 프로토콜(IP) 주소 간의 올바른 매핑을 포함하고 있다고 신뢰합니다. </font><font>ARP 캐시는 유용한 서비스를 제공하기 위해 이 정보를 사용하여 로컬 네트워크 내의 장치 간에 데이터를 보낼 수 있도록 합니다. </font><font>하지만 공격자는 잘못된 ARP 메시지를 생성하여 시스템의 ARP 테이블을 손상시키고 서비스 거부 또는 메시지 가로채기(man-in-the-middle)공격을 시작합니다.</font></p> + +<p><font>ARP 프로토콜은 25년 전에 표준화되었으며, 그 이후로 위협이 크게 변화하여, 설계에 내재한 신뢰 가정이 현재에도 여전히 타당하지는 않을 것입니다.</font></p> + +<p><font>소프트웨어 기능 오용 취약점을 다른 두 범주와 구별하기 어려울 수도 있습니다. 예를 들어, 소프트웨어 결함 및 오용 취약점은 소프트웨어 설계 프로세스의 결함으로 인해 발생할 수 있습니다. 하지만 소프트웨어 결함은 보안이나 기능에 긍정적인 이점을 제공하지 않으므로 추가 기능 제공의 결과로 소프트웨어 기능 오용 취약점이 발생할 수 있습니다.</font></p> + +<p><font>또한 어떤 면에서 구성된 방식으로 기능을 활성화하거나 비활성화할 수 있는 기능의 오용 취약점과 보안 구성 문제에 대해서도 혼동이 발생할 수 있습니다. 주요 차이점은 오용 취약점의 경우 구성 설정이 전체 기능을 활성화 또는 비활성화하고 전체 기능만 특별히 변경하지 않는다는 것입니다. 보안 구성 문제의 경우 구성 설정은 소프트웨어의 보안만 변경합니다.</font></p> + +<p><font>예를 들어 전자 메일에서 HTML을 모두 사용할 수 없도록 설정하면 보안 및 기능에 큰 영향을 미치므로 이 설정과 관련된 취약성은 오용 취약점이 됩니다. 전자 메일 클라이언트에서 암호화 기능을 사용하지 않도록 설정하면 보안에만 큰 영향을 미치므로 이 설정의 취약점은 보안 구성 문제 취약성으로 간주됩니다.</font></p> + +<h2 id="취약점의_존재">취약점의 존재</h2> + +<p><font>100% 안전한 시스템은 없습니다. 모든 시스템에 취약점이 있습니다. 어</font><font>느 때나 시스템에 알려진 소프트웨어 결함이 없을 수 있지만 보안 구성 문제 및 소프트웨어 기능 오용 취약점은 항상 존재합니다.</font></p> + +<p><font>각 기능은 신뢰성 평가를 기반으로 해야 하기 때문에 소프트웨어 기능에는 남용 취약점이 내재되어 있으며, 이러한 가정은 상당한 비용과 노력이 수반되지만 손상될 수 있습니다. </font><font>보안 구성 문제도 다음의 두가지 이유로 불가피합니다.</font></p> + +<p><font>첫째, 대부분의 구성 설정은 기능을 줄이는 대신 보안을 강화하므로 가장 안전한 설정을 사용하면 소프트웨어를 사용할 수 없거나 사용할 수 없게 될 수 있습니다. </font><font>둘째, 많은 보안 설정은 보안에 긍정적인 영향과 부정적인 영향을 모두 미칩니다.</font></p> + +<p><font>예를 들어, 사용자 계정을 잠그기 전에 허용하려는 연속적인 인증 실패 횟수를 들 수 있습니다. </font><font>이를 1로 설정하면 암호 추측 공격에 대한 가장 안전한 설정이 되지만 합법적인 사용자가 암호를 한번 잘못 해독하면 계정 하나를 더 쉽게 생성할 수 있습니다.</font></p> + +<p><font>보안 구성 설정 및 소프트웨어 기능 오용 가능성에 내재된 취약점의 수와 지정된 시간에 시스템의 소프트웨어 결함 취약점의 수 때문에 단일 시스템에는 수 십 개 또는 수 백 개의 취약점이 있을 수 있습니다.</font></p> + +<p><font>이러한 취약점은 다양한 특성을 가질 수 있습니다. </font><font>어떤 것들은 매우 이용하기 쉬운 반면, 다른 것들은 매우 가능성이 적은 조건들의 조합에 의해서만 설명될 수 있을 것이다.</font></p> + +<p><font>한 취약점은 시스템에 대한 루트 수준 액세스를 제공하는 반면 다른 취약성은 중요하지 않은 파일에 대한 읽기 액세스만 허용할 수 있습니다.</font></p> + +<p><font>궁극적으로 조직은 누군가가 각 취약성을 이용하는 것이 얼마나 어려운지, 그리고 취약점을 이용할 경우 어떤 영향을 미칠 수 있는지 알아야 합니다.</font></p> + +<h2 id="웹사이트의_취약점">웹사이트의 취약점</h2> + +<p><font>OWASP또는 Open Web Security Project는 소프트웨어 및 웹 응용 프로그램의 보안을 향상시키는 데 초점을 맞춘 비영리 자선 단체입니다. Open Web Application Security Project에 따르면, XSS는 2017년에</font> <a href="https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf" rel="noopener">7번째로 흔한 웹 응용 프로그램 취약점</a> <font>이었습니다.</font></p> + +<p><font>이 단체은 다양한 보안 조직의 데이터를 기반으로 상위 웹 보안 취약점 목록을 게시합니다.</font></p> + +<p><a href="https://developer.mozilla.org/en-US/docs/Web/Security">웹 보안</a><font>취약성은 WordPress, Joomla, Magento, Wocommerce등의 CMS가 될 수 있는 배포 가능성, 탐지 가능성 및 소프트웨어 영향에 따라 우선 순위가 지정됩니다.</font></p> + +<p><font>다음은 자신을 보호해야 하는 6가지 가장 일반적인 웹 사이트 취약성입니다.</font></p> + +<p><font><font>1. SQL주입</font></font><br> + 2. <a href="https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scripting">사이트간 스크립팅(XSS)</a><br> + <font><font>3. 망가진 인증 및 세션 관리<a href="https://papago.naver.net/apis/site/proxy?data=lY2EyqzIfo3Oypv5go3ccoTkuYz9lMl9yov1IHl9xo2AmY0SlL2ucqzHiFJEyoaEcqUyALJ5uM2IlVa1IC0RlrlW1pzjvBvWbqUEjpmbi">-</a></font></font><a href="https://developer.mozilla.org/en-US/docs/Archive/IdentityManager"> IdentityManager</a><br> + <font><font>4. 안전하지 않은 직접 객체 참조 <a href="https://papago.naver.net/apis/site/proxy?data=JW1pzjvBvWbqUEjpmbiY2EyqzIfo3Oypv5go3ccoTkuYz9lMl9yov1IHl9xo2AmY0qfo3AmLKW5Y0ECGFW9F3EHrl">- </a></font></font><a href="https://developer.mozilla.org/en-US/docs/Glossary/DOM">DOM (문서 객체 모델)</a><br> + <font><font>5. 보안 오구성</font></font><br> + 6. <a href="https://developer.mozilla.org/en-US/docs/Glossary/CSRF">사이트 간 요청 위조(CSRF)</a></p> + +<h2 id="See_also">See also</h2> + +<ul> + <li><a class="external" href="https://www.owasp.org/">Open Web Application Security Project (OWASP)</a></li> + <li><a href="https://cve.mitre.org/">Common Vulnerabilities and Exposures (CVE)</a></li> + <li><a href="https://secure.wphackedhelp.com/blog/wordpress-vulnerabilities-how-to-fix-guide-tools/">Common WordPress Security Vulnerabilities</a></li> + <li><a href="https://en.wikipedia.org/wiki/Vulnerability_database">Vulnerability database</a></li> +</ul> + +<div class="originaldocinfo"> +<h3 id="Original_Document_Information" name="Original_Document_Information">Original Document Information</h3> + +<ul> + <li>Author(s): Elizabeth LeMay, Karen Scarfone, and Peter Mell</li> + <li>Title: National Institute of Standards and Technology (NIST) Interagency Report 7864, The Common Misuse Scoring System (CMSS): Metrics for Software Feature Misuse Vulnerabilities</li> + <li>Last Updated Date: July 2012</li> + <li>Copyright Information: This document is not subject to copyright.</li> +</ul> +</div> + +<p>{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}</p> |