1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/wizardforcel-web-hacking-101-zh

Клонировать/Скачать
8.md 15 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
gitlife-traslator Отправлено 29.11.2024 03:04 a1c380c

Переведённый текст:

8. Подделка межсайтовых запросов (CSRF)

Автор: Peter Yaworski Переводчик: Летающий дракон Протокол: CC BY-NC-SA 4.0

Описание

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

Влияние CSRF-атаки зависит от сайта, на который отправляется запрос. Вот пример:

  1. Боб заходит в свой банковский аккаунт и выполняет некоторые операции, но не выходит из него.
  2. Боб проверяет свою электронную почту и нажимает на ссылку на незнакомом сайте.
  3. Незнакомый сайт отправляет запрос на перевод денег в банк Боба, передавая сохранённый в браузере Cookie с сессией Боба.
  4. Банк Боба получает запрос от незнакомого (вредоносного) сайта и обрабатывает перевод без использования CSRF Token.

Более интересно то, что вредоносный сайт может содержать действительный HTML, например, <img src="www.malicious_site.com">, и пользователю не нужно нажимать на ссылку. Если устройство Боба (например, браузер) отображает изображение, оно отправит запрос на malicious_site.com для проведения CSRF-атаки.

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

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

Сейчас, похоже, CSRF и CSRF Tokens становятся всё более распространёнными. Или, по крайней мере, я заметил это. По сути, CORS ограничивает доступ к ресурсам, включая ответы JSON, из внешних доменов. Другими словами, если CORS используется для защиты сайта, вы не можете написать JavaScript для вызова целевого приложения, чтения ответа или выполнения другого вызова, если только целевой сайт не разрешает это.

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

Наконец, важно помнить (спасибо Jobert Abma за дополнение), что не каждый запрос без CSRF Token обязательно содержит проблему CSRF. Некоторые сайты могут выполнять дополнительные проверки, такие как сравнение заголовка Referer протокола (хотя это может привести к ошибкам и есть случаи, когда его можно обойти). Это поле указывает на адрес страницы, с которой был сделан запрос к получаемому ресурсу. Иными словами, если заголовок Referer в POST-вызове не исходит от того же сайта, который получил HTTP-запрос, сайт может запретить вызов и, таким образом, выполнить ту же операцию, что и проверка CSRF Token. Кроме того, не все сайты используют термин «csrf» при создании или определении токенов. Например, в Badoo используется параметр «rt», который мы обсудим позже.

Ссылки

Ознакомьтесь с OWASP Testing Guide.

Примеры

1. Экспорт установленных пользователей Shopify

Сложность: низкая

URL: https://app.shopify.com/services/partners/api_clients/XXXX/export_installed_users

Ссылка на отчёт: https://hackerone.com/reports/96470

Дата отчёта: 2015.10.29

Награда: $500

Описание:

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

<html> 
    <head><title>csrf</title></head> 
    <body onLoad="document.forms[0].submit()"> 
        <form action="https://app.shopify.com/services/partners/api_clients/1105664/\ export_installed_users" method="GET"> 
        </form>
    </body> 
</html>

Здесь JavaScript отправит форму, которая фактически содержит GET-запрос к API Shopify, используя браузер пострадавшего и предоставляя Cookie Shopify.

Важный вывод

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

2. Отключение Twitter-соединения Shopify

Сложность: низкая

URL: https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect

Ссылка на отчёт: https://hackerone.com/reports/111216

Дата отчёта: 2016.1.17

Награда: $500

Описание:

Shopify предлагает интеграцию с Twitter, позволяя владельцам магазинов продвигать свои товары. Аналогично, предоставляется функция для отключения соединения между учётной записью Twitter и подключённым магазином.

Отключаемый URL-адрес соединения Twitter не загружен выше. Когда выполняется вызов, Shopify не проверяет CSRF Token, что может позволить злоумышленнику представлять пострадавшего и выполнять GET-вызов для отключения соединения магазина с учётной записью Twitter.

При предоставлении этого отчёта WeSecureApp предоставил пример запроса на уязвимость — обратите внимание на использование тега img для вызова уязвимого URL:

GET /auth/twitter/disconnect HTTP/1.1 
Host: twitter-commerce.shopifyapps.com 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/2010010\ 1 Firefox/43.0 
Accept: text/html, application/xhtml+xml, application/xml 
Accept-Language: en-US,en;q=0.5 
Accept-Encoding: gzip, deflate 
Referer: https://twitter-commerce.shopifyapps.com/account 
Cookie: _twitter-commerce_session=REDACTED 
Connection: keep-alive

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

<html> 
    <body> 
        <img src="https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect"> 
    </body> 
</html>

Важный вывод

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

3. Полный контроль над аккаунтом Badoo

Сложность: средняя

URL: https://badoo.com

Ссылка на отчёт: https://hackerone.com/reports/127703

Дата отчёта: 2016.4.1

Награда: $852

Описание:

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

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

В конечном итоге файл https://eu1.badoo.com/worker-scope/chrome-service-worker.js содержит значение «rt». Что ещё лучше, этот файл может быть прочитан злоумышленником без каких-либо действий со стороны пострадавшего, кроме просмотра вредоносной страницы. Вот предоставленный код:

<html> 
<head> 
<title>Полный контроль над аккаунтом Badoo</title> 
<script
``` По сути, когда жертва загружает эту страницу, она вызывает скрипт Badoo, чтобы получить параметр `rt` для пользователя, после чего представляет жертву в вызове. Здесь её аккаунт связывается с аккаунтом злоумышленника, и таким образом осуществляется контроль над учётной записью.

**Важный вывод**

Нет дыма без огня. Злоумышленник заметил, что параметр `rt` возвращается в разных местах, особенно в JSON-ответе, поэтому он правильно предположил, что он может появиться в некоторых местах, которые можно использовать, и здесь это файл JS.

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

## Резюме

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

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

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/wizardforcel-web-hacking-101-zh.git
git@api.gitlife.ru:oschina-mirror/wizardforcel-web-hacking-101-zh.git
oschina-mirror
wizardforcel-web-hacking-101-zh
wizardforcel-web-hacking-101-zh
master