diff options
author | Florian Merz <me@fiji-flo.de> | 2021-02-11 14:51:05 +0100 |
---|---|---|
committer | Florian Merz <me@fiji-flo.de> | 2021-02-11 14:51:05 +0100 |
commit | c058fa0fb22dc40ef0225b21a97578cddd0aaffa (patch) | |
tree | df20f8b4c724b61cb9c34cdb450a7ac77d690bd0 /files/ru/web/http/authentication | |
parent | 8260a606c143e6b55a467edf017a56bdcd6cba7e (diff) | |
download | translated-content-c058fa0fb22dc40ef0225b21a97578cddd0aaffa.tar.gz translated-content-c058fa0fb22dc40ef0225b21a97578cddd0aaffa.tar.bz2 translated-content-c058fa0fb22dc40ef0225b21a97578cddd0aaffa.zip |
unslug ru: move
Diffstat (limited to 'files/ru/web/http/authentication')
-rw-r--r-- | files/ru/web/http/authentication/index.html | 123 |
1 files changed, 123 insertions, 0 deletions
diff --git a/files/ru/web/http/authentication/index.html b/files/ru/web/http/authentication/index.html new file mode 100644 index 0000000000..99228e7633 --- /dev/null +++ b/files/ru/web/http/authentication/index.html @@ -0,0 +1,123 @@ +--- +title: HTTP авторизация +slug: Web/HTTP/Авторизация +tags: + - Авторизация + - Разграничение доступа + - Руководство +translation_of: Web/HTTP/Authentication +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">HTTP предоставляет набор инструментов для разграничения доступа к ресурсам и авторизацией. Самой распространенной схемой HTTP авторизации является "Basic" (базовая) авторизация. Данное руководство описывает основные возможности HTTP авторизации и показывает способы ограничения доступа к вашему серверу с ее использованием.</p> + +<h2 id="Общий_механизм_HTTP_авторизации">Общий механизм HTTP авторизации</h2> + +<p>{{RFC("7235")}} определяет средства HTTP авторизации, которые может использовать сервер для {{glossary("запроса")}} у клиента аутентификационной информации. Сценарий запрос-ответ подразумевает, что вначале сервер отвечает клиенту со статусом {{HTTPStatus("401")}} (Unauthorized) и предоставляет информацию о порядке авторизации через заголовок {{HTTPHeader("WWW-Authenticate")}}, содержащий хотя бы один метод авторизации. Клиент, который хочет авторизоваться, может сделать это, включив в следующий запрос заголовок {{HTTPHeader("Authorization")}} с требуемыми данными. Обычно, клиент отображает запрос пароля пользователю, и после получения ответа отправляет запрос с пользовательскими данными в заголовке <code>Authorization</code>.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14689/HTTPAuth.png" style="height: 335px; width: 710px;"></p> + +<p>В случае базовой авторизации как на иллюстрации выше, обмен <strong>должен</strong> вестись через HTTPS (TLS) соединение, чтобы обеспечить защищённость.</p> + +<h3 id="Прокси-авторизация">Прокси-авторизация</h3> + +<p>Этот же механизм запроса и ответа может быть использован для <em>прокси-авторизации</em>. В таком случае ответ посылает промежуточный прокси-сервер, который требует авторизации. Поскольку обе формы авторизации могут использоваться одновременно, для них используются разные заголовки и коды статуса ответа. В случае с <em>прокси</em>, статус-код запроса {{HTTPStatus("407")}} (Proxy Authentication Required) и заголовок {{HTTPHeader("Proxy-Authenticate")}}, который содержит хотя бы один запрос, относящийся к прокси-авторизации, а для передачи авторизационных данных прокси-серверу используется заголовок {{HTTPHeader("Proxy-Authorization")}}.</p> + +<h3 id="Доступ_запрещен">Доступ запрещен</h3> + +<p>Если (прокси) сервер получает корректные учетные данные, но они не подходят для доступа к данному ресурсу, сервер должен отправить ответ со статус кодом {{HTTPStatus("403")}} <code>Forbidden</code>. В отличии от статус кода {{HTTPStatus("401")}} <code>Unauthorized</code> или {{HTTPStatus("407")}} <code>Proxy Authentication Required</code>, аутентификация для этого пользователя не возможна.</p> + +<h3 id="Аутентификация_с_помощью_изображений">Аутентификация с помощью изображений</h3> + +<p>Аутентификация с помощью изображений, загружаемых из разных источников, была до недавнего времени потенциальной дырой в безопасности. Начиная с <a href="https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/59">Firefox 59</a>, изображения, загружаемые из разных источников в текущий документ, больше не запускают диалог HTTP-аутентификации, предотвращая тем самым кражу пользовательских данных (если нарушители смогли встроить это изображение в страницу).</p> + +<h3 id="Кодировка_символов_HTTP_аутентификации">Кодировка символов HTTP аутентификации</h3> + +<p>Браузеры используют кодировку <code>utf-8</code> для имени пользователя и пароля. Firefox использовал <code>ISO-8859-1</code>, но она была заменена <code>utf-8</code> с целью уравнения с другими браузерами, а также чтобы избежать потенциальных проблем (таких как {{bug(1419658)}}).</p> + +<h3 id="WWW-Authenticate_and_Proxy-Authenticate_headers"><code>WWW-Authenticate</code> and <code>Proxy-Authenticate</code> headers</h3> + +<p>{{HTTPHeader("WWW-Authenticate")}} и {{HTTPHeader("Proxy-Authenticate")}} заголовки ответа которые определяют методы, что следует использовать для получения доступа к ресурсу. Они должны указывать, какую схему аутентификации использовать, чтобы клиент, желающий авторизоваться, знал, какие данные предоставить. Синтаксис для этих заголовков следующий:</p> + +<pre class="syntaxbox">WWW-Authenticate: <type> realm=<realm> +Proxy-Authenticate: <type> realm=<realm> +</pre> + +<p>Here, <code><type></code> is the authentication scheme ("Basic" is the most common scheme and <a href="/en-US/docs/Web/HTTP/Authentication#Basic_authentication_scheme">introduced below</a>). The <em>realm</em> is used to describe the protected area or to indicate the scope of protection. This could be a message like "Access to the staging site" or similar, so that the user knows to which space they are trying to get access to.</p> + +<h3 id="Authorization_and_Proxy-Authorization_headers"><code>Authorization</code> and <code>Proxy-Authorization</code> headers</h3> + +<p>The {{HTTPHeader("Authorization")}} and {{HTTPHeader("Proxy-Authorization")}} request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the type is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.</p> + +<pre class="syntaxbox">Authorization: <type> <credentials> +Proxy-Authorization: <type> <credentials> +</pre> + +<h3 id="Authentication_schemes">Authentication schemes</h3> + +<p>The general HTTP authentication framework is used by several authentication schemes. Schemes can differ in security strength and in their availability in client or server software.</p> + +<p>The most common authentication scheme is the "Basic" authentication scheme which is introduced in more details below. IANA maintains a <a class="external external-icon" href="http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml">list of authentication schemes</a>, but there are other schemes offered by host services, such as Amazon AWS. Common authentication schemes include:</p> + +<ul> + <li><strong>Basic</strong> (see {{rfc(7617)}}, base64-encoded credentials. See below for more information.),</li> + <li><strong>Bearer</strong> (see {{rfc(6750)}}, bearer tokens to access OAuth 2.0-protected resources),</li> + <li><strong>Digest</strong> (see {{rfc(7616)}}, only md5 hashing is supported in Firefox, see {{bug(472823)}} for SHA encryption support),</li> + <li><strong>HOBA</strong> (see {{rfc(7486)}} (draft), <strong>H</strong>TTP <strong>O</strong>rigin-<strong>B</strong>ound <strong>A</strong>uthentication, digital-signature-based),</li> + <li><strong>Mutual</strong> (see <a href="https://tools.ietf.org/html/draft-ietf-httpauth-mutual-11">draft-ietf-httpauth-mutual</a>),</li> + <li> + <p><strong>AWS4-HMAC-SHA256</strong> (see <a href="http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html">AWS docs</a>).</p> + </li> +</ul> + +<h2 id="Basic_authentication_scheme">Basic authentication scheme</h2> + +<p>The "Basic" HTTP authentication scheme is defined in {{rfc(7617)}}, which transmits credentials as user ID/password pairs, encoded using base64.</p> + +<h3 id="Security_of_basic_authentication">Security of basic authentication</h3> + +<p>As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS / TLS should be used in conjunction with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information.</p> + +<h3 id="Restricting_access_with_Apache_and_basic_authentication">Restricting access with Apache and basic authentication</h3> + +<p>To password-protect a directory on an Apache server, you will need a <code>.htaccess</code> and a <code>.htpasswd</code> file.</p> + +<p>The <code>.htaccess</code> file typically looks like this:</p> + +<pre>AuthType Basic +AuthName "Access to the staging site" +AuthUserFile /path/to/.htpasswd +Require valid-user</pre> + +<p>The <code>.htaccess</code> file references a <code>.htpasswd</code> file in which each line contains of a username and a password separated by a colon (":"). You can not see the actual passwords as they are <a href="https://httpd.apache.org/docs/2.4/misc/password_encryptions.html">encrypted</a> (md5 in this case). Note that you can name your <code>.htpasswd</code> file differently if you like, but keep in mind this file shouldn't be accessible to anyone. (Apache is usually configured to prevent access to <code>.ht*</code> files).</p> + +<pre>aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz. +user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/ +</pre> + +<h3 id="Restricting_access_with_nginx_and_basic_authentication">Restricting access with nginx and basic authentication</h3> + +<p>For nginx, you will need to specify a location that you are going to protect and the <code>auth_basic</code> directive that provides the name to the password-protected area. The <code>auth_basic_user_file</code> directive then points to a .htpasswd file containing the encrypted user credentials, just like in the Apache example above.</p> + +<pre>location /status { + auth_basic "Access to the staging site"; + auth_basic_user_file /etc/apache2/.htpasswd; +}</pre> + +<h3 id="Access_using_credentials_in_the_URL">Access using credentials in the URL</h3> + +<p>Many clients also let you avoid the login prompt by using an encoded URL containing the username and the password like this:</p> + +<pre class="example-bad">https://username:password@www.example.com/</pre> + +<p><strong>The use of these URLs is deprecated</strong>. In Chrome, the <code>username:password@</code> part in URLs is even<a href="https://bugs.chromium.org/p/chromium/issues/detail?id=82250#c7"> stripped out</a> for security reasons. In Firefox, it is checked if the site actually requires authentication and if not, Firefox will warn the user with a prompt "You are about to log in to the site “www.example.com” with the username “username”, but the website does not require authentication. This may be an attempt to trick you.".</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li>{{HTTPHeader("WWW-Authenticate")}}</li> + <li>{{HTTPHeader("Authorization")}}</li> + <li>{{HTTPHeader("Proxy-Authorization")}}</li> + <li>{{HTTPHeader("Proxy-Authenticate")}}</li> + <li>{{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}</li> +</ul> |