От автора: поводом к записи данного урока послужил вопрос на нашем форуме, который звучал следующим образом — как защитить сайт от 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); }
//Отправка сообщения if ($ this -> isGet () && ! empty ($ _GET [ "email" ] ) ) { $ body = . $ this -> user [ "name" ] ; $ body . = " Content - from GET - " . $ _GET [ "content" ] . "From - " . $ _GET [ "email" ] ; 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 = "http://localhost/csrf/[email protected]&content=Hello world" > |
То есть, по сути, мы видим тег img, в атрибуте src которого располагается путь к сайту, предполагаемого для атаки, с набором необходимых параметров, для выполнения конкретного действия. В нашем случае это отправка сообщения, а значит, теперь злоумышленнику достаточно заманить пользователя на текущий сайт и незаметно от него, будет осуществлен запрос к интересующему сайту, так как браузер будет пытаться загрузить изображение, путь к которому указан в атрибуте src. При этом мы помним, что в куках браузера хранятся данные для авторизации и, конечно же, приложение сразу же их использует и соответственно вышеуказанный запрос успешно будет обработан сервером. А это означает, что будет отправлено сообщение от имени пользователя.
Если посмотреть набор заголовков, которые отправляются вместе с запросом, то действительно, мы сможем увидеть и куки, с данными для входа в учетную запись, что само собой означает – как было сказано выше, что запрос будет воспринят как исходящий от аутентифицированного пользователя.
Точно такая же ситуация обстоит и с отправкой запроса методом POST, единственно в этом случае злоумышленник создаст на своем сайте форму, которая будет автоматически отправляться при помощи JavaScript ,как только посетитель зайдет на данный сайт.
Таким образом защищаться от атак подобного рода нужно обязательно и единственный наиболее эффективный способ защиты – это использование специальных токенов.
Защитный токен – это строка, которая генерируется случайным образом под конкретного пользователя и передается в каждом запросе, который предусматривает изменение данных. Помимо этого токен,так же сохраняется и в сессии. Таким образом, суть защиты, сводится к простой проверке соответствия токена, который передается в запросе и токена который хранится в сессии. Если оба токена идентичны, значит, запрос отправил авторизированный пользователь. Если токены не совпадают, или в запросе его вообще нет – с большой уверенностью можно судить, что осуществляется атака, а значит, никакие действия выполнять нельзя.
Заметьте, что защищать нужно абсолютно все запросы, которые направлены на изменение или же выполнение определенных действий.
Собственно на данном этапе текстовая часть урока завершена и продолжим говорить поданной теме мы уже в видео версии. При этом мы рассмотрим способы генерации токенов и практически реализуем алгоритм работы защиты, который описан выше. А сейчас давайте прощаться. Удачного кодирования!!!
Статья эвакуирована с DrupalDance.com
Поводом к написанию этой статьи послужило нахождение мною уязвимости в одном довольно известном модуле. Так как по правилам обнаружения уязвимостей , я пока не вправе распространяться о деталях, то расскажу об уязвимости в общих чертах, а также о методах борьбы с ней.
Итак, подделка межсайтовых запросов (анг. Сross Site Request Forgery, или, сокращенно, CSRF): что это такое и с чем его едят.
CSRF - это вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP. Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на другой сервер (например, на сервер платёжной системы), осуществляющий некую вредоносную операцию (например, перевод денег на счёт злоумышленника). Для осуществления данной атаки, жертва должна быть авторизована на том сервере, на который отправляется запрос, и этот запрос не должен требовать какого-либо подтверждения со стороны пользователя.
Данный тип атак, вопреки распространённому заблуждению, появился достаточно давно: первые теоретические рассуждения появились в 1988 году, а первые уязвимости были обнаружены в 2000 году.
Одно из применений СSRF - эксплуатация пассивных XSS, обнаруженных на другом сервере. Так же возможны отправка спама от лица жертвы и изменение каких-либо настроек учётных записей на других сайтах(например, секретного вопроса для восстановления пароля).
Живой пример
Например, нам нужно сделать небольшой модуль, который должен аяксом удалять ноды. Это можно реализовать служебной ссылкой ноды, при нажатии которой, отправляется аякс запрос на друпаловский путь. К этому пути прицеплен обработчик, который и удаляет ноду. Вот примерно таким модулем все и делается:
node_destroy.module
/** * Реализация hook_menu(). Регистрирует наш коллбек в системе меню. */ function node_destroy_menu() { $menu["node/%node/destroy"] = array("page_callback" => "node_destroy", "page_arguments" => array(1), "access_arguments" => array("administer nodes"), "type" => MENU_CALLBACK,); return $menu; } /** * Реализация коллбека. */ function node_destroy($node) { if ($node->nid) { node_delete($node->nid); print("SUCCESS"); } // в коллбеках для аякса почти всегда надо принудительно завершать скрипт, // чтобы не выводить оформление сайта вместе с вашими данными exit(); } /** * Реализация hook_link(). Добавляем свою ссылку в служебные ссылки ноды. */ function node_destroy_link($type, $node = NULL, $teaser = FALSE) { switch ($type) { case "node": // если эта функция вызывается, значит мы выводим ссылки ноды, // а это значит, что нам и скрипты нужны $path = drupal_get_path("module", "node_destroy"); drupal_add_js($path ."/node_destroy.js"); // собственно, добавление ссылки $links["node_destroy"] = array("title" => t("Destroy node"), "href" => "node/$node->nid/destroy", "attributes" => array("class" => "node_destroy_link"),); break; } return $links; }node_destroy.js
// Таким нехитрым путем правильно инициализировать некие действия // вместо обычного $(document).ready(function() { ... }) Drupal.behaviors.node_destroy = function(context) { // Мы перебираем все наши ссылочки и навешиваем на них аякс запросы. // Заметьте необычный селектор. Он предотвратит двойное навешивание обработчиков. $(".node_destroy_link:not(.processed)", context).addClass("processed").click(function(){ href = $(this).attr("href"); $.ajax({ type: "GET", url: href, success: function(result){ // SUCCESS нам возвращает наш коллбек меню, если все замечательно if (result != "SUCCESS") { alert("Error"); } } }); }); }И все бы хорошо, но в один солнечный день, на сайт приходит злой тролль... Или более жизненная ситуация - озлобленный бывший сотрудник приходит на сайт и пытается его поломать. Помня старый опыт, он пробует зайти по адресу http://site.ru/node/123/destroy , но получает от ворот поворот, так как уже не имеет прав на удаление материалов.
И тут, в порыве деструктивного креатива, он создает ноду с таким контетом:
Что происходит в этот момент? Никакая картинка, естественно, не подгрузится, но браузер тролля выполнит запрос на этот путь с прежним результатом.
Смирившись с неудачей, тролль уходит с сайта. Через день, администратор сайта замечает эту мусорную ноду, заходит в нее и удаляет. А вернувшись в список материалов, не находит в нем ноды с айдишником 123. Атака удалась. Занавес.
Для тех, кто не понял, когда администратор зашел в ноду, его браузер тоже ломанулся по ссылке картинки. Но здесь уже прав доступа хватило, и нода была успешно удалена, а админ даже ничего не заметил.
Как избежать CSRF уязвимостей?
Ответ - использовать уникальные ссылки для действий по изменению данных. Как это возможно? В друпале используется метод токенизации ссылок. Это означает, что к ссылке активного действия, прибавляется уникальный параметр, который проверяется при осуществлении самого действия. В друпале сгенерировать такой параметр можно функцией drupal_get_token() . Проверить -drupal_valid_token() . Токен генерируется на основе подаваемого значения, сессии пользователя, а также приватного ключа сайта, что практически сводит на ноль вероятность генерации вредителем правильного токена.
Внесем изменения в наш модуль. Начнем с выставления правильной ссылки:
Function node_destroy_link($type, $node = NULL, $teaser = FALSE) { switch ($type) { case "node": $path = drupal_get_path("module", "node_destroy"); drupal_add_js($path ."/node_destroy.js"); $links["node_destroy"] = array("title" => t("Destroy node"), "href" => "node/$node->nid/destroy", "attributes" => array("class" => "node_destroy_link"), // query - это все GET параметры, т.е. все что в ссылке находится после знака вопроса // мы добавляем параметр token "query" => "token=". drupal_get_token("node_destroy_". $node->nid)); break; } return $links; }
Как вы помните, мы шлем аякс запрос по адресу, который зашит в ссылке, поэтому в коллбеке нам остается только проверить $_GET стандартным способом.
Function node_destroy($node) { if ($node->nid && isset($_GET["token"]) && drupal_valid_token($_GET["token"], "node_destroy_". $node->nid)) { node_delete($node->nid); print("SUCCESS"); } exit(); }
ASP.NET MVC - не самый хайповый, но довольно популярный стек в среде веб-разработчиков. С точки зрения (анти)хакера, его стандартная функциональность дает тебе кое-какой базовый уровень безопасности, но для предохранения от абсолютного большинства хакерских трюков нужна дополнительная защита. В этой статье мы рассмотрим основы, которые должен знать о безопасности ASP.NET-разработчик (будь то Core, MVC, MVC Razor или Web Forms).
Начнем со всем известных видов атак.
SQL Injection
Как ни странно, но в 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
Типичный пример XSS - добавление скрипта в комментарий или запись в гостевую книгу. Выглядеть он может так:
Как ты понимаешь, в данном примере куки с твоего сайта передаются в качестве параметра на какой-то хакерский ресурс.
В Web Forms можно совершить ошибку с помощью примерно такого кода:
Извините <%= username %>, но пароль ошибочный
Понятно, что вместо username может быть скрипт. Чтобы избежать выполнения скрипта, можно как минимум использовать другое ASP.NET-выражение: , которое энкодит свое содержимое.
Если мы используем Razor, то строки автоматически энкодируются, что сводит возможность реализации XSS к минимуму - хакер сможет ее провернуть, только если ты грубо ошибешься, например используешь @Html.Raw(Model.username) или заюзаешь в своей модели MvcHtmlString вместо string .
Для дополнительной защиты от XSS данные кодируются еще и в коде C#. В.NET Core можно использовать следующие кодеры из пространства имен System.Text.Encodings.Web: HtmlEncoder , JavaScriptEncoder и UrlEncoder .
Следующий пример вернет строку 6 7
8В общем, когда жертва загружала страницу, она делала запрос к скрипту Badoo, забирала параметр rt для этого пользователя и затем делала запрос от имени жертвы. В этом случае, это было связывание аккаунта Махмуда с аккаунтом жертвы, что позволяло полностью захватить аккаунт.
Выводы
Где дым, там и огонь, Здесь Махмуд заметил, что параметр rt возвращался в разных местах, в конкретных json-ответах. Поэтому он правильно предположил, что он может быть показан где-то, где его можно будет использовать в этом случае в js файле.
Итоги
CSRF-атаки представляют другой опасный вектор для атак и могут быть быть выполнены без активных действий со стороны жертвы или вообще без её уведомления. Обнаружение CSRF-уязвимостей требует некоторой изобретательности и, опять же, желания тестировать все подряд.
Как правило, формы стандартно защищены фреймворками вроде Rails если сайт выполняет POST-запрос, но API могут
быть отдельной историей. Например, Shopify написан в основном на основе фреймворка Ruby on Rails, который предоставляет защиту от CSRF-атак для всех форм по умолчанию (хотя её и можно отключить). Однако, очевидно, что это не обязательно так для API, созданных с помощью этого фреймворка. Наконец, обращайте внимание на вызовы, которые изменяют данные на сервере (такие, как действие удаления) и выполняются с помощью GET-запроса.
