Предотвращение атак путем внедрения в ASP.NET [Перевод]

Автор：Eve Cole Время обновления：2009-06-30 16:03:51

Источник: MSDN
Перевод:

Область применения Yunzhongcheng BLOG:

АСП.NET версии 1.1
АСП.NET версии 2.0

Краткое описание:

В этом тексте в основном рассказывается о том, как проверять вводимые пользователем данные для предотвращения атак путем внедрения. Очень важно проверять вводимые пользователем данные. Почти все атаки на уровне программы содержат вредоносные методы ввода.

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

Чтобы проверить входной контент, вы должны определить приемлемые правила ввода для каждого поля ввода. Лучший подход. заключается в создании ограничений на основе длины, диапазона, формата и типа поля ввода. Используйте список ограничений допустимых символов вместо списка недопустимых символов для ограничения ввода. Использование ограничений списка недопустимых символов нехорошо, потому что это почти невозможно. для фильтрации всех вредоносных входных данных.

Если вам необходимо принять ввод символов HTML, лучше всего использовать такой метод, как HtmlEncode, для его безопасного кодирования перед отображением.

Содержание:

Цель

Обзор

Пошаговая лента реализации

Шаг 1. Использование ASP. Проверка запроса NET.

Шаг 2. Используйте ввод ограничения прав.

Шаг 3. Кодируйте небезопасный ввод.

Шаг 4. Используйте параметры команды

для

операторов Sql.

Шаг 5. Убедитесь, что ошибки ASP.NET не возвращаются клиенту.

-------------------------------------------------- ------------------------------

Цель:

Ограничьте длину, диапазон, формат и тип входной строки.
Используйте проверку запросов, чтобы предотвратить атаки путем внедрения при разработке программ ASP.NET.
Используйте элементы управления проверкой ASP.NET для проверки ввода.
Кодировать небезопасный вывод.
Предотвратите атаки путем внедрения, используя шаблон набора параметров команды.
Предотвратите возврат сведений об ошибке клиенту.
Обзор.

Вы должны проверять все ненадежные входные данные в своем приложении. Вы должны предполагать, что все вводимые пользователем данные недействительны. Пользователи могут предоставлять в приложении поля формы, строки запроса, файлы cookie клиента и значения среды браузера, такие как строки прокси-сервера пользователя. IP-адреса и т. д.

Слабая проверка входных данных обычно предоставляет возможности для атак путем внедрения. Ниже приведены распространенные методы атаки с использованием слабой проверки входных данных или без проверки входных данных.

Если вы используете вводимые пользователем значения для динамического построения операторов SQL, база данных может выполнять оскорбительные и вредные операторы SQL.
Межсайтовые сценарии. Атаки с использованием межсайтовых сценариев используют уязвимости проверки веб-страниц для внедрения клиентских сценариев. Эти коды затем отправляются на доверенный клиентский компьютер, интерпретируются и выполняются браузером. Поскольку эти коды поступают с доверенного сайта, браузер не имеет возможности узнать, что код вреден.
Несанкционированный доступ к файлу. Если ваш код принимает входные данные от вызывающей стороны, злоумышленник может увидеть ваши файловые операции и получить доступ к защищенным файлам или использовать ваш код для внедрения незаконных данных.

Примечание. Атаки с внедрением могут осуществляться с использованием соединений HTTP или HTTPS Secure Socket Layer (SSL). Методы транспортного шифрования не могут использоваться для предотвращения атак.

Ниже кратко описаны общие методы проверки входных данных. Проверка должна выполняться везде, где требуется ввод данных по сети. , такие как текстовые поля и другие поля ввода формы, параметры строки запроса, файлы cookie, переменные на стороне сервера и параметры сетевого метода. Обратите внимание, что стратегия фильтрации должна разрешать только правильный ввод и отклонять недопустимый ввод. Это связано с тем, что определение правильной стратегии ввода является необходимостью. лучше, чем фильтровать все. Легче обнаружить незаконный ввод, но обычно сложно включить весь недопустимый ввод.

Проверьте вводимое содержимое по следующим аспектам:

Ограничения Убедитесь, что входные данные имеют правильный тип, длину символов, формат и диапазон. Для ограничения входных данных управления сервером можно использовать элементы управления проверки ASP.NET. Для ограничения входных данных из других источников можно использовать регулярные выражения и пользовательские правила проверки.
Отклонить. Обнаружить известный вредоносный ввод данных и отклонить его.
Фильтрация Иногда вам может потребоваться отфильтровать те части пользовательского ввода, которые представляют угрозу безопасности. Например, если ваше приложение допускает ввод в произвольной форме, например поля-метки, вы разрешите определенные безопасные теги HTML, такие как <b>, <i. > и другие HTML-теги.

Краткое описание шагов

Защитите свое приложение ASP.NET от атак путем внедрения, выполнив следующие действия:

Шаг 1. Используйте проверку запроса ASP.NET.
Шаг 2. Ограничьте ввод.
Шаг 3. Закодируйте небезопасный вывод.
Шаг 4. Используйте параметры команды для операторов запроса SQL.
Шаг 5. Убедитесь, что информация об ошибках ASP.NET не попала клиенту.

В следующих главах эти шаги будут подробно рассмотрены.

Шаг 1. Используйте проверку запроса ASP.NET.

По умолчанию проверка запроса ASP.NET 1.1 и 2.0 проверяет, содержат ли данные, отправляемые на сервер, элементы разметки HTML и зарезервированные символы. от ввода сценариев в программу. Проверка запроса будет сопоставлена со списком потенциально опасных строк, и если будет обнаружено исключение, будет выдано исключение типа HttpRequestValidationException.

Вы можете сделать это в файле web.config с помощью <Add validateRequest=. «false» для элемента «pages>» или установите ValidateRequest = «false» в элементе @Pages отдельной страницы, чтобы отключить эту функцию.

Если вы хотите отключить проверку запроса, вы можете отключить ее только на тех страницах, где она вам нужна. Например, если вы включаете на страницу программы поле, которое принимает входные данные в формате HTML,

убедитесь, что функция проверки запроса включена в файле Machine.config

. Функция проверки запроса включена по умолчанию в ASP.NET. можно сделать это в файле Machine.config.comments. Вы видите следующие настройки по умолчанию:

Убедитесь, что вы не изменили настройки по умолчанию в файле Machine.config вашего сервера и в файле Web. config.

Проверка проверки запроса ASP.NET.

Вы можете проверить эффект проверки запроса. Создайте страницу ASP.NET и отключите проверку запроса, установив ValidateRequest = «fasle» следующим образом:

<%@ Language="C#" ValidateRequest="false" %>
<html>
<script runat="сервер">
void btnSubmit_Click (отправитель объекта, EventArgs e)
{
// Если ValidateRequest имеет значение false, то отображается «привет»
// Если ValidateRequest имеет значение true, то ASP.NET возвращает исключение
Response.Write(txtString.Text);
}
</скрипт>
<тело>
<form id="form1" runat="server">
<asp:TextBox id="txtString" runat="сервер"
Text="<script>alert('привет');</script>" />
<asp:Button id="btnSubmit" runat="server" OnClick="btnSubmit_Click"
Текст="Отправить" />
</форма>
</тело>
</html>

При запуске страницы в окне сообщения отображается «Привет», поскольку сценарий в txtString выполняется и обрабатывается браузером клиента.

Если вы установите ValidateRequest = «true» или удалите атрибут страницы ValidateRequest, проверка запроса ASP .NET. отклонит ввод сценария и выдаст сообщение об ошибке, подобное приведенному ниже.

У клиента обнаружено потенциально опасное значение Request.Form (txtString="<script>alert('hello").

Будьте осторожны и не полагайтесь исключительно на функцию проверки запроса, а используйте ее только в качестве руководства для пользовательской проверки.

Шаг 2. Ограничьте ввод

Чтобы ограничить ввод, используйте следующий метод.

Используйте проверку ввода на стороне сервера. Не полагайтесь на проверку на стороне клиента, поскольку ее можно легко обойти. Используйте проверку на стороне клиента, чтобы уменьшить количество отказов страниц, повысить производительность и улучшить взаимодействие с пользователем.
Проверьте длину, диапазон, формат и тип входных данных. Убедитесь, что входное содержимое правильное и соответствует требованиям.
Используйте строгие типы данных. Укажите тип данных, например Integer или Double, для числового ввода. Укажите тип данных String для ввода символов. Укажите тип DateTime для ввода даты и времени.

Чтобы проверить

поля

ввода элемента управления HTML в форме, выполните проверку в серверном коде. Использование типа регулярного выражения Regex может помочь ограничить ввод символов. В следующем разделе описано, как ограничить переменные общих типов ввода.

Для проверки строковых полей, таких как имя, адрес, факс и номер свидетельства о рождении, используйте регулярные выражения.
Ограничивает допустимый диапазон символов.
Включите правила форматирования. Например, для полей на основе шаблонов, таких как идентификатор налогоплательщика, почтовый индекс и почтовый индекс, требуются определенные шаблоны символов.
Проверьте длину.

Используйте элемент управления проверкой регулярных выражений (RegularExpresionValidator).

Чтобы использовать элемент управления проверкой регулярных выражений, вам необходимо установить имя элемента управления, подлежащего проверке (ControlToValidate), выражение проверки (ValidationExpression) и сообщение об ошибке (ErrorMessage). Настройки соответствующих свойств см. в коде. пример ниже.

В приведенном выше коде регулярное выражение используется для ограничения входного имени буквами (допускаются прописные и строчные буквы), пробелами, эллипсами с одним именем, такими как О'Делл, и точками. Кроме того, длина входного символа ограничена 40 символами. Символы

Обратите внимание, что элемент управления проверкой регулярного выражения (RegularExpressionValidator) автоматически добавит каретку (^) и знак доллара ($) в качестве начального и конечного разделителей. Если вы не добавили их в пользовательское выражение, лучше всего добавить их. Добавление разделителей предназначено только для того, чтобы ваше выражение могло получить ту часть данных, которую вы хотите.

Используйте класс регулярных выражений (класс Regex),

если вы не используете серверные элементы управления (то есть вы не можете использовать элементы управления проверкой) или вам нужны другие. Для источников полей ввода, отличных от полей формы (таких как параметры строки запроса и файлы cookie), вы можете использовать класс регулярных выражений (класс Regex).

Используйте класс регулярных выражений

для импорта пространства имен System.Text.RegularExpressions, добавив оператор с использованием. префикс.
Убедитесь, что регулярное выражение содержит «^» и «$» (в начале строки, в конце строки).
Вызовите метод IsMatch класса Regex. Ниже приведен пример кода.

//Метод экземпляра:
Regex reg = new Regex(@"^[a-zA-Z'.s]{1,40}$");
Response.Write(reg.IsMatch(txtName.Text));

// Статический метод:
if (!Regex.IsMatch(txtName.Text,@"^[a-zA-Z'.s]{1,40}$"))
{
// Имя не соответствует выражению
}

Если вы не можете кэшировать часто используемые регулярные выражения, вам следует использовать статический метод IsMatch, чтобы повысить производительность и предотвратить создание ненужных объектов.

Проверка числовых полей.

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

Чтобы использовать элемент управления RangeValidator, вам необходимо установить имя элемента управления (ControlToValidate), тип (Type) и минимальное значение (MinimumValue). ), максимальное значение (MaximumValue) и сообщение об ошибке (ErrorMessage). Вот пример кода:

<asp:RangeValidator
ID="RangeValidator1"
Рунат="сервер"
ErrorMessage="Неверный диапазон. Число должно быть от 0 до 255."
ControlToValidate="rangeInput"
Максимальное значение="255"
МинимальноеЗначение="0" Тип="Целое число" />

Если вы не используете серверный элемент управления, вы можете выполнить проверку диапазона чисел, преобразовав входное значение в целое число и затем проверив его. Например, чтобы проверить, является ли целое число допустимым, используйте новый метод Int32.TryParse, предоставляемый ASP.NET 2.0, для преобразования входного значения в тип переменной System.Int32. Этот метод вернет false, если преобразование завершится неудачно.

Int32 я;
если (Int32.TryParse(txtInput.Text, out i) == false)
{
//Преобразование не удалось
}

Если вы используете более раннюю версию ASP.NET, вы можете использовать метод Int32.Parse или Convert.ToInt32 в блоке try/catch и обрабатывать исключение FormatException, которое генерируется при сбое преобразования.

В следующем примере кода показано, как проверить. из HTML Тип и диапазон целочисленного типа текстового поля.

<%@ Page Language="C#" %>

void Page_Load(отправитель объекта, EventArgs e)
{
если (Request.RequestType == "POST")
{
интервал я;
if (Int32.TryParse(Request.Form["integerTxt"], out i) == true)
{
// TryParse возвращает true, если преобразование прошло успешно
if ((0 <= i && i <= 255) == true)
{
Response.Write("Входные данные верны.");
}
еще
Response.Write("Входные данные выходят за пределы диапазона");
}
еще
Response.Write("Входные данные не являются целыми числами");
}
}

</script>

<html>
<тело>
<form id="form1" action="NumericInput.aspx" метод="post">
<дел>
Введите целое число от 0 до 255:
<input name="integerTxt" type="text" />
<input name="Отправить" type="отправить" value="отправить" />
</div>
</форма>
</тело>
</html>

Проверка полей даты.

Необходимо убедиться, что поля даты имеют правильный тип. В большинстве случаев вам также потребуется проверить их диапазон, например, проверить, находятся ли они в будущем или в прошлом, если вы используете серверный элемент управления. для захвата входного значения даты, и если вы хотите, чтобы значение находилось в определенном диапазоне, вы можете использовать элемент управления проверкой диапазона (RangeValidator) и установить его разрешенный тип как тип даты. Этот элемент управления позволяет указать специальный период времени. установив начальный момент. Если вам нужно использовать сегодняшнее время в качестве ссылки для проверки, например, чтобы проверить, находится ли время в будущем или в прошлом, вы можете использовать элемент управления проверки CustomValidator.
Использование элемента управления CustomValidator для проверки даты требует установки свойств ControlToValidate и ErrorMessage и указания пользовательского логического метода проверки в событии OnServerValidate. Ниже приведен пример кода.

<%@ Page Language="C#" %>

void ValidateDateInFuture(источник объекта, ServerValidateEventArgs args)
{
DateTime dt

// Проверяем корректность даты и то, что она находится в будущем
if ((DateTime.TryParse(args.Value, out dt) == false) ||
(dt <= DateTime.Today))
{
args.IsValid = ложь;
}
}

</script>

Обратите внимание, что в приведенном выше коде используется метод DateTime.TryParse, который является новым методом, предоставляемым ASP.NET 2.0.

Чтобы фильтровать свободные текстовые поля

для фильтрации входных данных, вам необходимо убедиться, что небезопасный ввод не рассматривается как код. позволяет пользователю Данные в общей базе данных не могут быть прочитаны. Сначала необходимо отфильтровать данные, чтобы они не были опасны при выводе. Используйте метод HttpUtility.HtmlEncode, чтобы сначала закодировать входное значение.

Разрешает ограниченный входной HTML-код.

Добавьте следующие поля в элемент страницы @Page ValidateRequest = «false», чтобы отключить проверку запроса ASP.NET. Используйте метод HtmlEncode для кодирования входной строки. Используйте объект StringBuilder и вызовите его метод replace, чтобы заменить HTML в символах. Следующий код дает пример такого подхода. Эта страница отключает проверку запроса ASP.NET, устанавливая ValidateRequest = "fasle". Ее HTML-кодировка позволяет использовать теги <b> и <i> для отображения простого форматирования текста. .

<%@ Page Language="C#" ValidateRequest="false"%>

void submitBtn_Click(отправитель объекта, EventArgs e)
{
// Кодируем ввод строки
StringBuilder sb = новый StringBuilder(
HttpUtility.HtmlEncode(htmlInputTxt.Text));
// Выборочно разрешаем и <i>
sb.Replace("<b>", "<b>");
sb.Replace("</b>", "");
sb.Replace("<i>", "<i>");
sb.Replace("</i>", "");
Response.Write(sb.ToString());
}
</script>

Проверка значения строки запроса

Проверка длины, диапазона, формата и типа строки запроса. Обычно комбинированное регулярное выражение используется для выполнения следующих задач:

Ограничить входные значения. Установить явные проверки диапазона. Указать тип входных данных и преобразовать его в ASP.NET. платформа Следующий тип обрабатывает любые исключения, вызванные преобразованиями типов. В следующем примере кода показано использование класса Regex для проверки строки имени, переданной в строке запроса.

void Page_Load (отправитель объекта, EventArgs e)
{
если (!System.Text.RegularExpressions.Regex.IsMatch(
Request.QueryString["Имя"], @"^[a-zA-Z'.s]{1,40}$"))
Response.Write("Неверное имя параметра");
еще
Response.Write("Имя: " + Request.QueryString["Имя"]);
}

Проверка значений файлов cookie.

Значения, хранящиеся в файлах cookie, таких как строки запроса, могут быть легко изменены пользователем. Также проверьте длину, диапазон, формат и тип этих значений.

Проверьте

файлы и URL-адреса.

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

Проверьте путь к файлу

чтобы предотвратить использование вашей программой пользователей для доступа к файлам, запретите ей принимать файлы или пути к файлам, введенные пользователем. Например:

если вы принимаете имена входных файлов, используйте Систему. .IO.Path.GetFileName метод для получения полного имени файла. Если необходимо. Принимает входной путь к файлу и использует System.IO.Path.GetFullPath для получения полного пути к файлу. Используйте метод MapPath, чтобы предотвратить сопоставление между приложениями. .

Если вы используете метод MapPath для сопоставления предоставленного виртуального каталога с физическим каталогом на сервере, используйте перегруженную версию метода Request.MapPath с параметром bool, чтобы предотвратить сопоставление между приложениями. Вот пример кода для этого метода:

пытаться
{
строка MappedPath = Request.MapPath( inputPath.Text,
Request.ApplicationPath, ложь);
}
поймать (HttpException)
{
// Попытка сопоставления между приложениями
}

Последний параметр false предотвратит сопоставление между приложениями. Это означает, что пользователям не разрешено использовать синтаксис «...» для указания недопустимого пути, находящегося за пределами указанного вами виртуального каталога.

Если вы используете серверные элементы управления, вы можете использовать метод Control.MapPathSecure для получения фактического адреса каталога, соответствующего виртуальному каталогу.
Метод Control.MapPathSecure создает исключение HttpException при доступе к неавторизованному файлу. Дополнительные сведения см. в описании метода Control.MapPathSecure в документации .NET Framework.

Использование безопасности доступа к коду для ограничения ввода и вывода файлов.

Администраторы могут ограничить возможность программы читать и записывать файлы в виртуальный каталог, в котором она находится, установив для нее значение «средний». Механизм безопасности кода .NET гарантирует, что программа не имеет прав доступа к файлам за пределами виртуального каталога, в котором она находится.

Чтобы установить уровень доверия приложения «средний», вы можете добавить:

Проверка URL-адреса

. Для сопоставления URL-адресов можно использовать регулярные выражения, подобные следующим:

^(?:http|https|ftp)://[a-zA-Z0-9 .-]+(?::d. {1,5})?(?:[A-Za-z0-9.;:@&=+$,? /]|%u[0-9A-Fa- f]{4}|%[0-9A-Fa-f]{2})*$

Это только ограничивает формат ввода и не проверяет, является ли он приемлемым в приложении в рамках вашего приложения. Вы должны это проверить. он действителен в контексте вашего приложения. Например, взаимодействует ли ваше приложение с указанным вами сервером.

Шаг 3. Кодирование небезопасного кода.

Если вы вводите текст на веб-страницу, используйте метод HttpUtility.HtmlEncode для его кодирования. Если текст поступает из пользовательского ввода, базы данных или локального файла, обязательно всегда делайте это.

Аналогично, если вы пишете URL-адрес, содержащий небезопасные символы, поскольку они взяты из содержимого, введенного пользователем, баз данных и т. д., используйте метод HttpUtility.UrlEncode для кодирования.

Чтобы предотвратить кодирование перед сохранением данных, которое может повредить сохраненные данные, обязательно кодируйте их как можно позже при их отображении.

Используйте HtmlEncode. Для небезопасного кодирования вывода

HtmlEncode заменяет HTML-теги. со специальными текстовыми строками для представления этих символов и не позволяет браузеру интерпретировать их как теги HTML. Например, «<» заменяется на < « (двоеточие) заменяется на «Эти теги отображаются как безобидный текст».

<%@ Page Language="C#" ValidateRequest="false" %>

Чтобы увидеть эффект кодирования HTML, создайте виртуальный каталог и поместите в него вышеупомянутые файлы, запустите эту страницу, введите HTML-код в текстовое поле и нажмите кнопку «Отправить». Например, следующий ввод отображается как обычный. text.

Запустите скрипт и поздоровайтесь <script>alert('hello');</script>

Если вы удалите вызов метода HtmlEncode и просто введете текстовое содержимое, браузер выполнит код и выдаст всплывающее окно с подсказкой.

Использование метода UrlEncode небезопасно. Кодирование URL-адреса.

Если вам необходимо получить параметры URL-адреса с помощью пользовательского ввода, что может привести к определенным рискам безопасности, используйте метод HttpUtility.UrlEncode для кодирования строки адреса

HttpUtility.UrlEncode(urlString)

;

Шаг 4. SQL В операторе используется метод параметров команды.

Чтобы избежать атак с использованием параметров SQL, используйте метод параметров SQL. Если вы используете набор параметров, входное содержимое будет рассматриваться как. текстовое значение, а база данных не будет. Содержащийся в нем код будет выполнен. Дополнительным преимуществом использования метода набора параметров является то, что вы можете строго ограничить тип и длину ввода. Если тип ввода выходит за пределы диапазона, возникает ошибка. будет вызвано исключение.

При вызове хранимой процедуры используйте набор параметров,

указанный ниже. Фрагмент кода демонстрирует пример использования наборов параметров при вызове хранимой процедуры.

SqlDataAdapter myCommand = новый SqlDataAdapter("AuthorLogin",
мое соединение);
мояКоманда.ВыбратьКоманду.ТипКоманды = ТипКоманды.СохраненнаяПроцедура;
SqlParameter parm = myCommand.SelectCommand.Parameters.Add(
"@LoginId", SqlDbType.VarChar, 11);
парм.Значение = Логин.Текст;

Используйте наборы параметров при создании собственных операторов SQL.

Если вы не можете использовать хранимые процедуры, вы все равно можете использовать наборы параметров, см. код ниже.

SqlDataAdapter myCommand = новый SqlDataAdapter(
"ВЫБЕРИТЕ au_lname, au_fname ОТ АВТОРОВ ГДЕ au_id = @au_id", myConnection);
SQLParameter parm = myCommand.SelectCommand.Parameters.Add(
"@au_id", SqlDbType.VarChar, 11);
Парм.Значение = Логин.Текст;

Дополнительные сведения о том, как предотвратить атаки с внедрением SQL, см. в разделе Как защититься от внедрения SQL в ASP.NET,

шаг 5. Чтобы убедиться, что сообщения об ошибках ASP.NET не возвращаются клиенту,

вы можете использовать элемент <customErrors>. Для настройки клиента механизм обнаружения ошибок программы должен возвращать клиенту общие сообщения об ошибках.

Убедитесь, что вы изменили атрибут режима в файле web.config на «remoteOnly», ниже приведен пример

<customErrors mode =

«remoteOnly»>

В разделе «После установки программы ASP.NET» вы можете указать страницу сообщения об ошибке клиента следующим образом.

Дополнительные ресурсы см. в связанных темах:

Как использовать регулярные выражения для ограничения ввода в ASP.NET.

Предотвращение атак с использованием SQL-инъекций

и атак с использованием межсайтовых сценариев.

PS: Я наконец дочитал это, я так устал. Мне потребовалось почти три дня. На самом деле, эти предложения очень простые, если вы посмотрите на них. Это мой первый перевод, пожалуйста, простите меня, если перевод не очень хороший, спасибо.