From 1154864d2a3a3f44637931613bf6d8a90f994b3f Mon Sep 17 00:00:00 2001 From: User0k Date: Mon, 21 Oct 2024 20:30:25 +0300 Subject: [PATCH 01/13] [ru] update 'Web/Security' translation --- files/ru/web/security/index.md | 178 ++++++++++++++++++++++++++++++++- 1 file changed, 175 insertions(+), 3 deletions(-) diff --git a/files/ru/web/security/index.md b/files/ru/web/security/index.md index 856b4c8532e598..f530b34fa93c34 100644 --- a/files/ru/web/security/index.md +++ b/files/ru/web/security/index.md @@ -1,10 +1,182 @@ --- title: Веб-безопасность slug: Web/Security +l10n: + sourceCommit: f75b2c86ae4168e59416aed4c7121f222afc201d --- -Обеспечение того, чтобы ваш веб-сайт или открытое веб-приложение было безопасным является критически важным. Даже простые ошибки в коде могут привести к утечке частной информации, завладеть которой хотят не добросовестные пользователи, с целью кражи данных. Эти статьи предоставляют информацию, которая может помочь вам обеспечить безопасность вашего кода. +Веб-сайты содержат различную информацию. Какая-то её часть является общедоступной (например, статья на общедоступном ресурсе), а какая-то -- конфиденциальной. Например, имя пользователя, пароль и банковские данные или внутренние алгоритмы и частная информация о продукте. -{{LandingPageListSubpages}} +Конфиденциальная информация должна быть защищена и это -- главная цель веб-безопасности. Если эта информация попадёт в руки злоумышленников, они смогут: -{{QuickLinksWithSubpages}} +- Поставить компанию в невыгодное конкурентное положение, распространяя её информацию среди конкурентов. +- Отключить или получить доступ к её сервисам, что приведёт к серьезным проблемам с её работой. +- Поставить под угрозу [конфиденциальность](/ru/docs/Web/Privacy) клиентов компании, сделав их уязвимыми для показа таргетированной рекламы, потери данных, кражи личной информации или даже финансовых потерь. + +Современные браузеры уже оснащены рядом инструментов для обеспечения безопасности пользователей в Интернете, однако разработчикам также следует использовать лучшие практики и тщательно программировать, чтобы гарантировать безопасность своих веб-сайтов. Даже простые ошибки в коде могут привести к появлению уязвимостей, которые злоумышленники могут использовать для кражи данных и получения несанкционированного контроля над сервисами. + +В этой статье рассматривается введение в веб-безопасность, включая концептуальную информацию которая поможет вам понять уязвимости веб-сайтов, а также практические руководства по их защите. + +## Связь между безопасностью и конфиденциальностью + +Безопасность и конфиденциальность -- разные, но тесно связанные темы. Стоит знать различия между ними и то, как они связаны. + +- **Безопасность** -- это действие направленное на защиту частных данных и систем от несанкционированного доступа. Сюда входят как данные компании (внутренние), так и данные пользователей и партнёров (внешние). + +- **Конфиденциальность** означает действие направленное на предоставление пользователям контроля над тем, как собираются, хранятся и используются их данные, гарантируя при этом, что эти данные не будут использованы безответственно. Например, вам следует сообщить вашим пользователям, какие данные вы собираете, кому они могут быть переданы и как эти данные будут использоваться. Пользователи должны иметь возможность согласиться с вашей политикой конфиденциальности, получить доступ к своим данным и удалить их, если они этого захотят. + +Хорошая безопасность необходима для хорошей конфиденциальности. Вы можете следовать всем советам, перечисленным в нашем руководстве [Конфиденциальность в Интернете](/ru/docs/Web/Privacy), однако действовать добросовестно и иметь надёжную политику конфиденциальности бесполезно, если ваш сайт небезопасен и злоумышленники могут просто украсть данные. + +## Инструменты безопасности, предоставляемые браузерами + +Веб-браузеры следуют строгой модели безопасности, которая гарантирует защиту содержимого, соединения между браузером и сервером, и передачи данных. В этом разделе рассматриваются особенности, лежащие в основе этой модели. + +### Политика одинакового источника и CORS + +[Политика одинакового источника](/ru/docs/Web/Security/Same-origin_policy) -- это фундаментальный механизм безопасности в Интернете, который ограничивает то как документ или скрипт, загружаемые из одного [источника](/ru/docs/Glossary/Origin), может взаимодействовать с ресурсом из другого источника. Это помогает изолировать потенциально вредоносные документы, снижая количество возможных векторов атак. + +Обычно документы из одного источника не могут отправлять запросы другим источникам. Это разумно, поскольку вы не хотите, чтобы сайты мешали друг другу и получали несанкционированный доступ к данным. + +Однако в некоторых случаях может возникнуть необходимость ослабить это ограничение. Например, если у вас есть несколько веб-сайтов, взаимодействующих друг с другом, вы можете разрешить им запрашивать ресурсы друг у друга, используя [`fetch()`](/ru/docs/Web/API/Window/fetch). Это возможно благодаря механизму [Cross-Origin Resource Sharing (CORS)](ru/docs/Web/HTTP/CORS) использующему дополнительные HTTP-заголовки для указания любого другого источника, из которого браузер должен разрешить загрузку ресурсов (источник может отличаться доменом, схемой или портом). + +### Протокол HTTP + +Протокол [HTTP](/ru/docs/Web/HTTP) используется для связи между веб-браузерами и серверами. Он позволяет отправлять запросы, получать ответы (например предоставление запрошенных данных или уточнение причин неудачного запроса) и обеспечивает безопасность этого взаимодействия. + +Transport Layer Security (TLS) обеспечивает безопасность и конфиденциальность путём шифрования данных во время передачи по сети и является технологией, лежащей в основе протокола [HTTPS](/ru/docs/Glossary/HTTPS). TLS хорош для обеспечения конфиденциальности, поскольку не позволяет третьим лицам перехватывать передаваемые данные и использовать их злонамеренно. + +Все браузеры переходят на использование HTTPS по умолчанию. Фактически это уже произошло, поскольку без этого протокола вы мало что сможете сделать в сети. + +Связанные темы: + +- [Transport layer security](/ru/docs/Web/Security/Transport_Layer_Security) (TLS) + - : Протокол TLS является стандартом, позволяющим двум приложениям или устройствам работающим по сети обмениваться информацией конфиденциально и надёжно. Приложения, использующие TLS, имеют возможность настраивать параметры безопасности, что может оказать существенное влияние на безопасность и надёжность данных. +- [HTTP Strict-Transport-Security](/ru/docs/Web/HTTP/Headers/Strict-Transport-Security) + - : Заголовок [HTTP](/ru/docs/Web/HTTP) `Strict-Transport-Security` позволяет веб-сайту указать, что доступ к нему возможен только через HTTPS. +- [Прозрачность сертификатов](/ru/docs/Web/Security/Certificate_Transparency) + - : Прозрачность сертификатов (ПС) -- это открытый фреймворк, который предназначен для защиты и отслеживания ошибок выдачи сертификатов. Вновь выданные сертификаты размещаются в открытом доступе, часто в независимых журналах ПС. Это позволяет добавлять криптографически защищённые записи о выданных TLS сертификатах без возможности их изменения. +- [Смешанное содержимое](/ru/docs/Web/Security/Mixed_content) + - : Страница, доступная по HTTPS и содержащая данные, полученные с использованием [открытого текста](/ru/docs/Glossary/Plaintext) HTTP, называется страницей со **смешанным содержимым**. Подобные страницы зашифрованы лишь частично, что делает незашифрованную часть уязвимой для программ-перехватчиков и атак типа [man-in-the-middle](ru/docs/Glossary/MitM). +- [Ненадёжные алгоритмы создания подписей](/ru/docs/Web/Security/Weak_Signature_Algorithm) + - : Надёжность алгоритма хеширования, используемого для {{Glossary("Signature/Security", "signing")}} в {{Glossary("digital certificate")}} является критически важным элементом безопасности сертификата. Некоторые алгоритмы создания подписи недостаточно надёжны и их, по возможности, следует избегать. + +### Разрешение на выполнение функций в контексте безопасности + +Браузеры контролируют использование определённых функций по-разному. К таким функциям относятся: генерация системных уведомлений на веб-сайте, использование веб-камеры пользователя для получения доступа к медиапотоку, управление графическим процессором (GPU) и проведение веб-платежей. Если бы сайт мог свободно использовать API, управляющий этими функциями, злоумышленники могли бы предпринять следующие действия: + +- Надоедать пользователям ненужными уведомлениями и другими функциями пользовательского интерфейса. +- Включать веб-камеру без предупреждения, чтобы следить за пользователями. +- Засорять их браузер или систему для {{glossary("denial of service", "Denial of Service")}} (DoS) атак. +- Украсть данные или деньги. + +Все эти функции контролируются следующим образом: + +- Их использование разрешено лишь в [безопасных контекстах](/ru/docs/Web/Security/Secure_Contexts). Безопасный контекст -- это {{domxref("Window", "window")}} или {{domxref("WorkerGlobalScope", "worker")}}, для которых существует разумная уверенность в том, что содержимое было доставлено безопасно (через HTTPS/TLS). В безопасном контексте возможности взаимодействия с **небезопасными** контекстами ограничены. Такие контексты также помогают предотвратить атаки типа [man-in-the-middle](https://ru.wikipedia.org/wiki/Атака_посредника). + + О списке функций веб-платформы, доступных только в безопасном контексте, можно прочесть в статье [Функции, доступные только в безопасном контексте](/ru/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts). + +- Использование этих функций ограничено системой разрешения пользователей: для предоставления доступа необходимо явное согласие пользователя, что исключает автоматическую активацию такой функции. Запросы на разрешение пользователем выполняются автоматически и вы можете контролировать этот процесс с помощью [API для разрешений пользователя](/ru/docs/Web/API/Permissions_API). + +- Некоторые другие функции браузера доступны только в ответ на действие пользователя (например нажатие кнопки) и должны вызываться из соответствующих обработчиков событий. Это называется **временной активацией**. Дополнительную информацию об этом читайте в статье [Функции, доступные по активации пользователя](/ru/docs/Web/Security/User_activation). + +## Высокоуровневые аспекты безопасности + +Существует множество аспектов веб-безопасности, которые нужно учитывать как на стороне сервера, так и на стороне клиента. В этом разделе основное внимание уделяется соображениям безопасности на стороне клиента. Сводную информацию о безопасности на стороне сервера, включая описание распространённых атак, можно найти в статье [Веб-безопасность](/ru/docs/Learn/Server-side/First_steps/Website_security) (часть нашего учебного модуля [Программирование веб-сайтов на стороне сервера](/ru/docs/Learn/Server-side)). + +### Ответственное хранение данных на стороне клиента + +Ответственное управление данными предполагает преимущественно сокращение использования [сторонних файлов куки](/ru/docs/Web/Privacy/Third-party_cookies) и осторожность при работе с данными, которые вы храните и передаёте с их помощью. Традиционно веб-разработчики использовали куки для хранения всех видов данных, и злоумышленники легко воспользовались этой тенденцией. В результате браузеры начали ограничивать возможности использования межсайтовых куки, чтобы полностью предотвратить к ним доступ в будущем. + +Вам следует подготовиться к удалению межсайтовых куки, ограничив количество действий по отслеживанию, на которые вы полагаетесь, и/или сохраняя нужную информацию другими способами. Для получения более детальной информации читайте [Уход от сторонних файлов куки](/ru/docs/Web/Privacy/Third-party_cookies#transitioning_from_third-party_cookies) и [Замена сторонних файлов куки](/ru/docs/Web/Privacy/Third-party_cookies#replacing_third-party_cookies). + +### Защита личности пользователя и управление входами в систему + +Разрабатывая безопасное решение, включающее в себя сбор данных, особенно если речь идёт о конфиденциальных данных, таких как учётные данные пользователей, рекомендуется использовать надёжные инструменты. К примеру, у любого известного серверного фреймворка будут встроенные функции для защиты от распространённых уязвимостей. Вы также можете рассмотреть возможность применения специализированных продуктов, например, решения для идентификации пользователей или онлайн-опросов. + +Если вы хотите развернуть собственное решение для сбора данных пользователей, убедитесь,что вы знакомы со всеми нюансами и требованиями. Наймите опытного серверного разработчика и/или инженера по безопасности для разработки системы и убедитесь, что она тщательно протестирована. Используйте многофакторную аутентификацию (MFA) для усиления защиты. Рассмотрите возможность использования специализированного API, такого как [веб-аутентификация](/ru/docs/Web/API/Web_Authentication_API) или [федеративное управление учётными данными](/ru/docs/Web/API/FedCM_API), чтобы оптимизировать клиентскую часть приложения. + +Вот ещё несколько советов по обеспечению безопасного входа в систему: + +- При сборе данных для входа в систему используйте надежные пароли, чтобы данные учетной записи вашего пользователя нельзя было легко угадать. Слабые пароли являются одной из основных причин нарушений безопасности. Кроме того, предложите своим пользователям использовать менеджер паролей, чтобы они могли использовать более сложные пароли, не беспокоились о их запоминании и не создавали угрозу безопасности, записывая их. Можете также прочесть нашу статью о [небезопасных паролях](/ru/docs/Web/Security/Insecure_passwords). + +- Вам также следует информировать своих пользователей о **фишинге**. Фишинг -- это отправка пользователю сообщения (например, email или смс), содержащего ссылку на сайт, который выглядит как тот, который он использует каждый день, но таковым не является. Ссылка сопровождается сообщением, призванным вынудить пользователя ввести своё имя и пароль, чтобы их можно было украсть и затем использовать в своих целях. + + > [!NOTE] + > Некоторые фишинговые сайты могут быть очень сложными, и их трудно отличить от настоящих. Поэтому вам следует обучить пользователей не доверять ссылкам в подозрительных email и смс. Если они получат сообщение с текстом «Срочно! Войдите в систему, чтобы решить проблему», им следует перейти на сайт в новой вкладке и попытаться войти напрямую вместо нажатия на ссылку в сообщении. Или же они могут позвонить вам или написать email, чтобы обсудить полученное сообщение. + +- Защищайте вход пользователей от атак методом подбора паролей, используя {{glossary("rate limit", "rate limiting")}}, блокировку учётной записи после определённого числа неудачных попыток и [капчи](https://ru.wikipedia.org/wiki/Капча). +- Управляйте сеансами входа пользователей с помощью уникальных [id сессии](https://en.wikipedia.org/wiki/Session_ID). + +### Не включайте в URL запрос конфиденциальные данные + +Как правило, не рекомендуется [помещать конфиденциальные данные в параметры URL](https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url), поскольку если третья сторона перехватит URL (например через HTTP заголовок {{httpheader("Referer")}}), она сможет украсть эти данные. Ещё более серьёзным является тот факт, что эти URL-адреса могут быть проиндексированы поисковыми роботами, HTTP-прокси и инструментами архивирования, такими как [интернет-архив](https://web.archive.org/). А это означает, что ваши конфиденциальные данные могут стать общедоступными. + +Чтобы избежать этого, отдавайте предпочтение `POST`-запросам вместо `GET`-запросов. Статья [Политика заголовка Referer: проблемы конфиденциальности и безопасности](/ru/docs/Web/Security/Referer_header:_privacy_and_security_concerns) подробно описывает риски конфиденциальности и безопасности, связанные с заголовком `Referer`, и предлагает советы по их снижению. + +> [!NOTE] +> Отказ от передачи конфиденциальных данных через URL-адреса с использованием `GET`-запросов также может помочь защититься от {{glossary("CSRF", "cross-site request forgery")}} и [атаки повторного воспроизведения](https://ru.wikipedia.org/wiki/Атака_повторного_воспроизведения). + +### Принудительное использование политик + +Рассмотрите возможность использования [Content Security Policy](/ru/docs/Web/HTTP/CSP) (CSP) и [политики разрешений](/ru/docs/Web/HTTP/Permissions_Policy) для соблюдения правил использования функций и ресурсов на вашем веб-сайте, что усложнит внедрение уязвимостей. + +CSP позволяет вам добавить уровень безопасности, например, позволяя загружать изображения или сценарии только из доверенных источников. Это помогает обнаруживать и смягчать определенные типы атак, включая межсайтовый скриптинг ({{Glossary("Cross-site_scripting", "XSS")}}) и атаки инъекцией данных. Эти атаки включают в себя целый ряд вредоносных действий, включая кражу данных, порчу сайта и распространение вредоносного ПО. + +Политика разрешений работает аналогичным образом, за исключением того, что она фокусируется на разрешении или блокировке доступа к [определённым функциям](#разрешение_на_выполнение_функций_в_контексте_безопасности). + +> [!NOTE] +> Такие политики очень полезны для обеспечения безопасности сайтов, особенно если вы используете много стороннего кода. Однако имейте в виду, что блокировка использования функций, необходимых для работы сторонних скриптов, может в конечном итоге нарушить функциональность вашего сайта. + +### Поддержание целостности данных + +В соответствии с предыдущим разделом, когда вы разрешаете использование функций и ресурсов на своём сайте, постарайтесь удостовериться, что эти ресурсы не были подделаны. + +Связанные темы: + +- [Целостность субресурсов](/ru/docs/Web/Security/Subresource_Integrity) + - : **Целостность субресурсов** (SRI) — это механизм безопасности, который позволяет браузерам удостовериться в том, что загружаемые ими ресурсы (например из {{Glossary("CDN")}}) не были изменены без предупреждения. Это достигается путём предоставления криптографического хеша, которому должен соответствовать полученный ресурс. +- [HTTP Access-Control-Allow-Origin](/ru/docs/Web/HTTP/Headers/Access-Control-Allow-Origin) + - : Заголовок ответа **`Access-Control-Allow-Origin`** показывает, может ли ответ сервера быть доступен коду, отправляющему запрос с данного источника {{glossary("origin")}}. +- [HTTP X-Content-Type-Options](/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options) + - : Заголовок ответа **`X-Content-Type-Options`** является маркером, используемым сервером для указания того, что [типы MIME](/ru/docs/Web/HTTP/MIME_types), объявленные в заголовках {{HTTPHeader("Content-Type")}}, должны соблюдаться и не изменяться. Это позволяет отказаться от [перехвата MIME](/ru/docs/Web/HTTP/MIME_types#mime_sniffing), другими словами, указать, что типы MIME намеренно были настроены. + +### Очистка поля ввода + +Основное правило -- не доверять ничему, что пользователи вводят в формы. Пользователи могут случайно или намеренно ввести некорректные данные. Кроме того, злоумышленники научились внедрять в поля форм исполняемый код, такой как SQL или JavaScript. Если не соблюдать осторожность, это может привести к выполнению вредоносного кода на вашем сайте или удалению ваших баз данных. Читайте секцию [SQL инъекция](/ru/docs/Learn/Server-side/First_steps/Website_security#sql_injection) для примера того, как это может произойти. + +Чтобы защититься от этого, необходимо тщательно очищать данные, вводимые в формы: + +- Вам следует реализовать валидацию на стороне клиента, чтобы информировать пользователей о некорректном формате ввода. Вы можете сделать это, используя встроенный механизм валидации HTML-форм или написать собственную утилиту для проверки данных. Для более подробной информации читайте статью [Валидация форм на стороне клиента](/ru/docs/Learn/Forms/Form_validation). +- При отображении пользовательского ввода используйте кодировку вывода, чтобы отобразить данные точно в том виде, в котором их ввёл пользователь, и избежать их выполнения в виде кода. Для более подробной информации читайте статью [Кодирование выходных данных](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#output-encoding). + +В целях безопасности нельзя полагаться только на валидацию на стороне клиента: её следует сочетать с валидацией на стороне сервера. Проверка на стороне клиента повышает удобство работы пользователя, предоставляя мгновенную обратную связь без необходимости ждать ответа от сервера. Однако злоумышленнику легко обойти валидацию на стороне клиента, например, отключив JavaScript в браузере, чтобы обойти проверку, основанную на его использовании. + +Любой уважаемый серверный фреймворк предоставит функциональные возможности для валидации отправки форм. Кроме того, общепринятой практикой является экранирование любых специальных символов, которые являются частью исполняемого синтаксиса, благодаря чему введённый код перестаёт быть исполняемым и рассматривается как обычный текст. + +### Защита от атак типа clickjacking + +При атаке типа [clickjacking](/ru/docs/Glossary/Clickjacking) пользователя обманом вынуждают кликнуть на элементе, выполняющем действие, отличное от ожидаемого пользователем, что часто приводит к утечке конфиденциальной информации. Этот риск присущ стороннему контенту, поэтому убедитесь в надёжности того, что внедряете на ваш сайт. Также стоит учесть, что clickjacking может сочетаться вместе техниками фишинга. Читайте о фишинге в разделе [Защита личности пользователя и управление входами в систему](#защита_личности_пользователя_и_управление_входами_в_систему). + +Следующие действия помогут защититься от атак типа clickjacking: + +- [HTTP X-Frame-Options](/ru/docs/Web/HTTP/Headers/X-Frame-Options) + - : Заголовок **`X-Frame-Options`** [HTTP](/ru/docs/Web/HTTP) позволяет указать, разрешено ли браузеру отображать страницу в [``](/ru/docs/Web/HTML/Element/frame), [`