diff options
Diffstat (limited to 'files/ru/learn/server-side/first_steps/website_security/index.html')
| -rw-r--r-- | files/ru/learn/server-side/first_steps/website_security/index.html | 54 |
1 files changed, 27 insertions, 27 deletions
diff --git a/files/ru/learn/server-side/first_steps/website_security/index.html b/files/ru/learn/server-side/first_steps/website_security/index.html index 514d7490a5..1f976dd741 100644 --- a/files/ru/learn/server-side/first_steps/website_security/index.html +++ b/files/ru/learn/server-side/first_steps/website_security/index.html @@ -8,7 +8,7 @@ original_slug: Learn/Server-side/First_steps/Веб_Безопасность <div>{{PreviousMenu("Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</div> -<p class="summary">Безопасность сайта требует бдительности во всех аспектах дизайна и использования сайта. Эта вводная статья не сделает из вас гуру безопасности веб-сайта, но она поможет вам понять, откуда приходят угрозы, и что вы можете сделать, чтобы укрепить свое веб-приложение против наиболее распространенных атак.</p> +<p class="summary">Безопасность сайта требует бдительности во всех аспектах дизайна и использования сайта. Эта вводная статья не сделает из вас гуру безопасности веб-сайта, но она поможет вам понять, откуда приходят угрозы, и что вы можете сделать, чтобы укрепить своё веб-приложение против наиболее распространённых атак.</p> <table class="learn-box standard-table"> <tbody> @@ -18,20 +18,20 @@ original_slug: Learn/Server-side/First_steps/Веб_Безопасность </tr> <tr> <th scope="row">Цель:</th> - <td>Понять самые распространенные угрозы безопасности веб-приложений. И что вы можете сделать, чтобы уменьшить риск взлома вашего сайта.</td> + <td>Понять самые распространённые угрозы безопасности веб-приложений. И что вы можете сделать, чтобы уменьшить риск взлома вашего сайта.</td> </tr> </tbody> </table> <h2 id="Что_такое_безопасность_сайта">Что такое безопасность сайта?</h2> -<p>Интернет опасное место! Мы регулярно слышим о том, что веб-сайты становятся недоступными из-за атак типа отказано в обслуживании, или отображение измененной (и часто поврежденной) информации на их страницах. В других случаях миллионы паролей, адресов электронной почты и данные кредитных карт становились общедоступными, подвергая пользователей веб-сайта личному смущению или к финансовым рискам.</p> +<p>Интернет опасное место! Мы регулярно слышим о том, что веб-сайты становятся недоступными из-за атак типа отказано в обслуживании, или отображение изменённой (и часто повреждённой) информации на их страницах. В других случаях миллионы паролей, адресов электронной почты и данные кредитных карт становились общедоступными, подвергая пользователей веб-сайта личному смущению или к финансовым рискам.</p> <p>Цель веб-безопасности заключается в предотвращении этих (или других) видов атак. Более формальным определением веб-безопасности является: <em>способы защиты веб-сайтов от несанкционированного доступа, использования, изменения, уничтожения или нарушения работы.</em></p> -<p>Для эффективной безопасности веб-сайта необходимо уделять особое внимание к разработке всего веб-сайта: к вашему веб-приложению, конфигурации веб-сервера, при написании политик создания и обновления паролей, а так же кода на стороне клиента. Хотя все это звучит очень зловеще, хорошая новость заключается в том, что если вы используете веб-фреймворк для серверной части, то он почти наверняка обеспечит «по умолчанию» надежные и продуманные механизмы защиты от ряда наиболее распространенных атак. Другие атаки можно смягчить с помощью конфигурации вашего веб-сервера, например, включив HTTPS. Наконец, есть общедоступные инструменты для сканирования уязвимостей, которые могут помочь вам определить, если вы допустили какие-либо очевидные ошибки.</p> +<p>Для эффективной безопасности веб-сайта необходимо уделять особое внимание к разработке всего веб-сайта: к вашему веб-приложению, конфигурации веб-сервера, при написании политик создания и обновления паролей, а так же кода на стороне клиента. Хотя все это звучит очень зловеще, хорошая новость заключается в том, что если вы используете веб-фреймворк для серверной части, то он почти наверняка обеспечит «по умолчанию» надёжные и продуманные механизмы защиты от ряда наиболее распространённых атак. Другие атаки можно смягчить с помощью конфигурации вашего веб-сервера, например, включив HTTPS. Наконец, есть общедоступные инструменты для сканирования уязвимостей, которые могут помочь вам определить, если вы допустили какие-либо очевидные ошибки.</p> -<p>В оставшейся части этой статьи мы рассмотрим более подробную информацию о некоторых самых распространенных угрозах и о простых шагах, которые вы можете предпринять, чтобы защитить свой сайт.</p> +<p>В оставшейся части этой статьи мы рассмотрим более подробную информацию о некоторых самых распространённых угрозах и о простых шагах, которые вы можете предпринять, чтобы защитить свой сайт.</p> <div class="note"> <p><strong>Примечание: </strong>Это вводная статья, призванная помочь вам задуматься о безопасности веб-сайта, но она не является исчерпывающей.</p> @@ -39,25 +39,25 @@ original_slug: Learn/Server-side/First_steps/Веб_Безопасность <h2 id="Угрозы_безопасности_сайта">Угрозы безопасности сайта</h2> -<p>В этом разделе перечислены лишь некоторые из наиболее распространенных угроз веб-сайта и способы их устранения. Читая, обратите внимание на то, насколько успешны угрозы, когда веб-приложение доверяет, либо <em>недостаточно параноидально</em> относится к данным, поступающим из браузера.</p> +<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> +<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> +<p>Уязвимости XSS делятся на <em>отражённые</em> и <em>хранимые</em>, в зависимости от того, как сайт возвращает внедрённый код в браузер.</p> <ul> - <li><em>Отраженная </em>XSS-уязвимость возникает, когда пользовательский контент, который передается на сервер, <em>немедленно</em> и <em>без изменений</em> возвращается для отображения в браузере. Любой скрипт в исходном пользовательском контенте запустится при загрузке новой страницы. Например, рассмотрим строку поиска по сайту, в которой поисковые слова закодированы как параметры URL, и эти слова отображаются вместе с результатами. Злоумышленник может создать поисковую ссылку, которая будет содержать вредоносный скрипт в качестве параметра (например: <code>http://mysite.com?q=beer<script%20src="http://evilsite.com/tricky.js"></script></code>) и переслать его другому пользователю по электронной почте. Если целевой пользователь кликнет по этой «интересной ссылке», то скрипт выполнится при отображении результатов поиска. Как мы уже говорили, злоумышленник таким образом получает всю информацию, необходимую ему для входа на сайт в качестве целевого пользователя, потенциального совершения покупок от имени пользователя или получения его контактной информации.</li> + <li><em>Отражённая </em>XSS-уязвимость возникает, когда пользовательский контент, который передаётся на сервер, <em>немедленно</em> и <em>без изменений</em> возвращается для отображения в браузере. Любой скрипт в исходном пользовательском контенте запустится при загрузке новой страницы. Например, рассмотрим строку поиска по сайту, в которой поисковые слова закодированы как параметры URL, и эти слова отображаются вместе с результатами. Злоумышленник может создать поисковую ссылку, которая будет содержать вредоносный скрипт в качестве параметра (например: <code>http://mysite.com?q=beer<script%20src="http://evilsite.com/tricky.js"></script></code>) и переслать его другому пользователю по электронной почте. Если целевой пользователь кликнет по этой «интересной ссылке», то скрипт выполнится при отображении результатов поиска. Как мы уже говорили, злоумышленник таким образом получает всю информацию, необходимую ему для входа на сайт в качестве целевого пользователя, потенциального совершения покупок от имени пользователя или получения его контактной информации.</li> <li> <p><span class="tlid-translation translation" lang="ru">Постоянная уязвимость XSS возникает, когда вредоносный скрипт хранится на веб-сайте, а затем снова отображается без изменений, чтобы другие пользователи могли выполнять его невольно.<br> - Например, доска обсуждений, которая принимает комментарии, содержащие неизмененный HTML, может хранить вредоносный скрипт от злоумышленника. Когда комментарии отображаются, скрипт выполняется и может отправить злоумышленнику информацию, необходимую для доступа к учетной записи пользователя. Атака такого рода чрезвычайно популярна и мощна, потому что злоумышленник может даже не иметь прямого отношения к жертвам.<br> + Например, доска обсуждений, которая принимает комментарии, содержащие неизмененный HTML, может хранить вредоносный скрипт от злоумышленника. Когда комментарии отображаются, скрипт выполняется и может отправить злоумышленнику информацию, необходимую для доступа к учётной записи пользователя. Атака такого рода чрезвычайно популярна и мощна, потому что злоумышленник может даже не иметь прямого отношения к жертвам.<br> <br> - Хотя данные из запросов POST или GET являются наиболее распространенным источником уязвимостей XSS, любые данные из браузера потенциально уязвимы, такие как данные cookie, отображаемые браузером, или пользовательские файлы, которые загружаются и отображаются.<br> + Хотя данные из запросов POST или GET являются наиболее распространённым источником уязвимостей XSS, любые данные из браузера потенциально уязвимы, такие как данные cookie, отображаемые браузером, или пользовательские файлы, которые загружаются и отображаются.<br> <br> Наилучшей защитой от уязвимостей XSS является удаление или отключение любой разметки, которая потенциально может содержать инструкции по запуску кода. Для HTML это включает такие элементы, как <script>, <object>, <embed> и <link>.<br> <br> @@ -71,7 +71,7 @@ original_slug: Learn/Server-side/First_steps/Веб_Безопасность <br> <span title="">Типы внедрения SQL включают внедрение SQL на основе ошибок, внедрение SQL на основе логических ошибок и внедрение SQL на основе времени.</span><br> <br> - <span title="">Эта уязвимость присутствует, если пользовательский ввод, который передается в базовый оператор SQL, может изменить смысл оператора.</span> <span title="">Например, следующий код предназначен для перечисления всех пользователей с определенным именем (userName), которое было предоставлено из формы HTML:</span></span></p> + <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> @@ -80,7 +80,7 @@ original_slug: Learn/Server-side/First_steps/Веб_Безопасность <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> +<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> @@ -102,16 +102,16 @@ original_slug: Learn/Server-side/First_steps/Веб_Безопасность <h3 id="Подделка_межсайтовых_запросов_CSRF">Подделка межсайтовых запросов (CSRF)</h3> -<p>CSRF-атаки позволяют злоумышленнику выполнять действия, используя учетные данные другого пользователя, без его ведома или согласия.</p> +<p>CSRF-атаки позволяют злоумышленнику выполнять действия, используя учётные данные другого пользователя, без его ведома или согласия.</p> -<p>Этот тип атаки лучше всего пояснить на примере. Джон - злоумышленник, который знает, что определенный сайт позволяет пользователям, вошедшим в систему, отправлять деньги на указанную учетную запись, используя HTTP-запрос <code>POST</code>, который включает имя учетной записи и сумму денег. Джон создает форму, которая включает в себя его банковские реквизиты и сумму денег в виде скрытых полей, и отправляет ее по электронной почте другим пользователям сайта (с кнопкой «Отправить», замаскированной под ссылку на сайт «быстрого обогащения»).</p> +<p>Этот тип атаки лучше всего пояснить на примере. Джон - злоумышленник, который знает, что определённый сайт позволяет пользователям, вошедшим в систему, отправлять деньги на указанную учётную запись, используя HTTP-запрос <code>POST</code>, который включает имя учётной записи и сумму денег. Джон создаёт форму, которая включает в себя его банковские реквизиты и сумму денег в виде скрытых полей, и отправляет её по электронной почте другим пользователям сайта (с кнопкой «Отправить», замаскированной под ссылку на сайт «быстрого обогащения»).</p> -<p>Если пользователь нажимает кнопку отправки, на сервер будет отправлен HTTP-запрос <code>POST</code>, содержащий сведения о транзакции и любые файлы cookie на стороне клиента, которые браузер связал с сайтом (добавление связанных файлов cookie сайта в запросы является нормальным поведением браузера). Сервер проверит файлы cookie и использует их, чтобы определить, вошел ли пользователь в систему и имеет ли разрешение на совершение транзакции.</p> +<p>Если пользователь нажимает кнопку отправки, на сервер будет отправлен HTTP-запрос <code>POST</code>, содержащий сведения о транзакции и любые файлы cookie на стороне клиента, которые браузер связал с сайтом (добавление связанных файлов cookie сайта в запросы является нормальным поведением браузера). Сервер проверит файлы cookie и использует их, чтобы определить, вошёл ли пользователь в систему и имеет ли разрешение на совершение транзакции.</p> <p>В результате любой пользователь, который нажимает кнопку <em>Отправить</em> во время входа на торговый сайт, совершает транзакцию. Джон становится богатым.</p> <div class="note"> -<p><strong>Примечание: </strong>Уловка здесь в том, что Джону не нужен доступ к файлам cookie пользователя (или учетным данным). Браузер пользователя сохраняет эту информацию и автоматически включает ее во все запросы к соответствующему серверу.</p> +<p><strong>Примечание: </strong>Уловка здесь в том, что Джону не нужен доступ к файлам cookie пользователя (или учётным данным). Браузер пользователя сохраняет эту информацию и автоматически включает её во все запросы к соответствующему серверу.</p> </div> <p>Один из способов предотвратить этот тип атаки - запросить сервером запросы <code>POST</code>, содержащие секрет, созданный пользователем для конкретного сайта. Секрет будет предоставлен сервером при отправке веб-формы, используемой для переводов. Такой подход не позволяет Джону создать свою собственную форму, потому что он должен знать секрет, который сервер предоставляет пользователю. Даже если он узнает секрет и создаст форму для конкретного пользователя, он больше не сможет использовать ту же форму для атаки на каждого пользователя.</p> @@ -120,11 +120,11 @@ original_slug: Learn/Server-side/First_steps/Веб_Безопасность <h3 id="Прочие_угрозы">Прочие угрозы</h3> -<p>Другие распространенные атаки / уязвимости включают:</p> +<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://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> @@ -143,20 +143,20 @@ original_slug: Learn/Server-side/First_steps/Веб_Безопасность <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>Используйте более эффективное управление паролями. Поощряйте регулярную смену надёжных паролей. Рассмотрите возможность двухфакторной аутентификации для вашего сайта, чтобы в дополнение к паролю пользователь должен был ввести другой код аутентификации (обычно тот, который доставляется через какое-то физическое оборудование, которое будет иметь только пользователь, например, код в 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> + <li>Храните и отображайте только те данные, которые вам нужны. Например, если ваши пользователи должны хранить конфиденциальную информацию, такую как данные кредитной карты, отображайте часть номера карты только для того, чтобы он мог быть идентифицирован пользователем, и недостаточно, чтобы его мог скопировать злоумышленник и использовать на другом сайте. Самый распространённый шаблон в настоящее время - отображение только последних 4 цифр номера кредитной карты.</li> </ul> -<p>Веб-фреймворки могут помочь смягчить многие из наиболее распространенных уязвимостей.</p> +<p>Веб-фреймворки могут помочь смягчить многие из наиболее распространённых уязвимостей.</p> <h2 id="Резюме">Резюме</h2> -<p>В этой статье объясняется концепция веб-безопасности и некоторые из наиболее распространенных угроз, от которых ваш веб-сайт должен пытаться защититься. Самое главное, вы должны понимать, что веб-приложение не может доверять никаким данным из веб-браузера. Все пользовательские данные должны быть очищены перед отображением или использованием в SQL-запросах и вызовах файловой системы.</p> +<p>В этой статье объясняется концепция веб-безопасности и некоторые из наиболее распространённых угроз, от которых ваш веб-сайт должен пытаться защититься. Самое главное, вы должны понимать, что веб-приложение не может доверять никаким данным из веб-браузера. Все пользовательские данные должны быть очищены перед отображением или использованием в SQL-запросах и вызовах файловой системы.</p> -<p>Этой статьей вы подошли к концу <a href="/en-US/docs/Learn/Server-side/First_steps">этого модуля</a>, охватывающего ваши первые шаги в программировании на стороне сервера. Мы надеемся, что вам понравилось изучать эти фундаментальные концепции, и теперь вы готовы выбрать веб-платформу и начать программировать.</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> |