diff --git a/files/ru/web/security/index.md b/files/ru/web/security/index.md index 856b4c8532e598..de1f77912b80e1 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). Это возможно благодаря основанному на HTTP-заголовках механизму [Cross-Origin Resource Sharing (CORS)](/ru/docs/Web/HTTP/CORS), который позволяет серверу указывать любые источники (домен, схему и порт), отличные от его собственного, из которых браузер должен разрешать загрузку ресурсов. + +### Протокол 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. +- [Certificate Transparency](/ru/docs/Web/Security/Certificate_Transparency) (CT) + - : Certificate Transparency — это открытая система мониторинга и защиты от ошибок при выдаче сертификатов. Вновь выданные сертификаты «регистрируются» в общедоступных, часто независимых журналах. Это позволяет добавлять криптографически защищённые записи о выданных TLS сертификатах без возможности их изменения. +- [Смешанное содержимое](/ru/docs/Web/Security/Mixed_content) + - : Страница, доступная по HTTPS и содержащая данные, полученные по HTTP с использованием [открытого текста](/ru/docs/Glossary/Plaintext), называется страницей со **смешанным содержимым**. Такие страницы зашифрованы лишь частично, что делает незашифрованную часть уязвимой для программ-перехватчиков и атак типа «[человек посередине](/ru/docs/Glossary/MitM)». +- [Ненадёжные алгоритмы создания подписей](/ru/docs/Web/Security/Weak_Signature_Algorithm) + - : Надёжность алгоритма хеширования, используемого для {{Glossary("Signature/Security", "подписания")}} {{Glossary("digital certificate", "цифрового сертификата")}} является критически важным элементом безопасности сертификата. Некоторые алгоритмы создания подписи недостаточно надёжны и их, по возможности, следует избегать. + +### Разрешение на выполнение функций в контексте безопасности + +Браузеры контролируют использование потенциально опасных функций по-разному. К таким функциям относятся: генерация системных уведомлений на веб-сайте, использование веб-камеры пользователя для получения доступа к медиапотоку, управление графическим процессором (GPU) и проведение веб-платежей. Если бы сайт мог свободно использовать API, управляющий этими функциями, злоумышленники могли бы предпринять следующие действия: + +- Надоедать пользователям ненужными уведомлениями и другими функциями пользовательского интерфейса. +- Включать веб-камеру без предупреждения, чтобы следить за пользователями. +- Засорять их браузер или систему для атак типа «{{glossary("denial of service", "Отказ в обслуживании")}}» (DoS). +- Украсть данные или деньги. + +Такие потенциально опасные функции контролируются следующим образом: + +- Их использование разрешено лишь в [безопасных контекстах](/ru/docs/Web/Security/Secure_Contexts). Безопасный контекст — это {{domxref("Window", "window")}} или {{domxref("WorkerGlobalScope", "worker")}}, для которых существует разумная уверенность в том, что содержимое было доставлено безопасно (через HTTPS/TLS). В безопасном контексте возможности взаимодействия с **небезопасными** контекстами ограничены. Такие контексты также помогают предотвратить атаки типа «[человек посередине](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). + +- Также следует информировать своих пользователей о **фишинге**. Фишинг — это отправка пользователю сообщения (например, по электронной почте или SMS), содержащего ссылку на сайт, который выглядит как тот, который он использует каждый день, но таковым не является. Ссылка сопровождается сообщением, призванным вынудить пользователя ввести своё имя и пароль, в результате чего злоумышленник может их украсть и использовать в своих целях. + + > [!NOTE] + > Некоторые фишинговые сайты очень трудно отличить от настоящих. Поэтому следует обучить пользователей не доверять ссылкам в подозрительных письмах и SMS. Если они получат сообщение с текстом «Срочно! Войдите в систему, чтобы решить проблему», им следует перейти на сайт в новой вкладке и попытаться войти напрямую вместо нажатия на ссылку в сообщении. Или же они могут позвонить или написать письмо владельцу сайта, чтобы обсудить полученное сообщение. + +- Необходимо защищать вход пользователей от атак методом подбора паролей, используя {{glossary("rate limit", "ограничение скорости")}}, блокировку учётной записи после определённого числа неудачных попыток и [капчи](https://ru.wikipedia.org/wiki/Капча). +- Для управления сеансами входа пользователей следует использовать уникальные [идентификаторы сессии](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", "межсайтовой подделки запроса")}} и [атаки повторного воспроизведения](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](/ru/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 в браузере, чтобы обойти проверку, основанную на его использовании. + +Все распространённые серверные фреймворки предоставляют возможность валидации данных. Кроме того, общепринятой практикой является экранирование любых специальных символов, которые могут быть частью исполняемого синтаксиса, благодаря чему введённый код перестаёт быть исполняемым и рассматривается как обычный текст. + +### Защита от кликджекинга + +При атаке типа [кликджекинг](/ru/docs/Glossary/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), [`