CSRF — вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP.
Атака CSRFs довольно распространена и очень проста в использовании. Сайты чаще всего используют хоть какую, да защиту от CSRF. Иногда это может быть проверка CSRF или проверка реферера (Referrer) или подобные методы.
Но в итоге все, что было сделано для предотвращения (защиты) от этой атаки, - это не полная защита с множеством уязвимостей. Сегодня мы поговорим о некоторых аспектах, которые должны использовать, чтобы защититься от CSRF.
(То же самое относится и к защите от SSRF. Тот факт, что реализованы защитные механизмы какой-либо уязвимости, не означает, что эти методы так хороши. Подробнее об обходе защиты SSRF читайте здесь. (https://medium.com/@vickieli/bypassing-ssrf-protection-e111ae70727b))
Независимо от типа развернутой защиты CSRF, вы всегда можете сначала попробовать две вещи: кликджекинг и изменение метода запроса.
Кликджекинг (ClickJacking)
(Если вы не знакомы с атаками кликджекинга, дополнительную информацию можно найти здесь (https://www.owasp.org/index.php/Clickjacking) или узнать краткую информацию ниже.)
Clickjacking, также известный как «атака с восстановлением пользовательского интерфейса», - это когда злоумышленник использует несколько прозрачных или непрозрачных слоев, чтобы заставить пользователя нажать на кнопку или ссылку на другой странице, когда он намеревался щелкнуть на странице верхнего уровня. Таким образом, злоумышленник «перехватывает» клики, предназначенные для их страницы, и направляет их на другую страницу, которая, скорее всего, принадлежит другому приложению, домену или обоим.
Эксплуатация кликджекинга на одной и той же конечной точке обходит всю защиту CSRF. Потому что технически запрос действительно исходит от законного сайта. Если страница, на которой расположена уязвимая конечная точка, уязвима для перехвата кликов, вся защита CSRF будет неактуальной.
Подмена метода запроса
Также стоит попробовать изменить метод запроса. Если секретный запрос, который вы хотите подделать, отправляется методом POST, попробуйте преобразовать запрос в метод GET. И если действие выполняется с помощью GET, попробуйте преобразовать его в POST. Приложение может все еще выполнить действие, и тот же самый механизм защиты часто не работает.
Например, этот запрос:
Может быть переписан как:
Защита CSRF с помощью токена
Тот факт, что сайт использует токены CSRF, не означает, что он правильно их проверяет. Вот несколько вещей, которые вы можете попытаться обойти с защитой CSRF с помощью токенов.
Удалить параметр токена или отправить пустой токен
Не отправка токена работает довольно часто из-за распространенной логической ошибки приложения: приложения иногда проверяют действительность токена только в том случае, если токен существует или параметр токена не пуст. В этом случае отправка запроса без токена или пустого значения в качестве токена может быть достаточной для обхода защиты.
Например, если обычный запрос выглядит так:
Попробуйте это (пустой токен):
Или это:
Использовать токен CSRF другого сеанса
Приложение может только проверять, является ли токен действительным или нет, и проверять, принадлежит ли он текущему пользователю. Если это так, вы можете просто жестко закодировать свой собственный токен CSRF в полезную нагрузку!
Допустим, токен жертвы - 871caef0757a4ac9691aceb9aad8b65b, а ваш - YOUR_TOKEN. Вы можете легко получить свой собственный токен CSRF, но не токен жертвы. Попробуйте обойти защиту CSRF, предоставив свой собственный токен вместо легального (Настоящего) токена.
Другими словами, вместо отправки этого:
Отправьте это:
Фиксация сессии
Иногда сайты используют так называемый файл cookie с двойной передачей для защиты от CSRF. Это означает, что отправленный запрос будет содержать один и тот же случайный токен как в виде файла cookie, так и в качестве параметра запроса, и сервер проверяет, равны ли эти два значения. Если значения равны, запрос считается верным. Эта защита довольно часто встречается повсеместно.
Если в качестве механизма защиты используется cookie с двойной передачей, приложение, вероятно, не сохраняет действительный токен на стороне сервера. У него нет способа узнать, является ли какой-либо токен, который он получает, действительно легитимным, и он просто проверяет, совпадает ли токен в cookie и токен в теле запроса. Это означает, что если вы также можете отправить поддельный файл cookie, вы все равно сможете выполнить CSRF.
Затем атака будет состоять из двух этапов: во-первых, вы используете метод фиксации сеанса, чтобы браузер жертвы сохранял любое значение, выбранное вами в качестве файла cookie CSRF-токена. Затем выполните CSRF с тем же маркером CSRF, который вы выбрали в качестве файла cookie.
1. Сессия фиксации. Это атака, которая позволит вам контролировать хранилище файлов cookie жертвы. Подробнее об этом здесь (https://www.owasp.org/index.php/Session_fixation).
2. Выполните CSRF со следующим запросом:
CSRF Защита через Реферер
Допустим, attacker.com - это ваш домен. И bank.com - это сайт, на который вы нападаете. Сайт не использует токены CSRF, но проверяет заголовок реферера. Что ты можешь сделать сейчас?
Удалить заголовок реферера
Подобно отправке пустого токена, иногда все, что вам нужно сделать, чтобы обойти проверку реферера, это просто не отправлять реферера. Для этого вы можете добавить следующий метатег на страницу с вашей полезной нагрузкой:
Приложение может проверять реферера только в том случае, если оно отправлено, в этом случае вы успешно обошли его защиту CSRF!
Обойти регулярное выражение (regex)
Если проверка реферера основана на белом списке, вы можете попробовать обойти регулярное выражение, используемое для проверки URL. Например, вы можете попробовать поместить доменное имя жертвы в URL-адрес реферера в качестве субдомена (Поддомен(Поддомен — домен, являющийся частью домена более высокого уровня.)) или в качестве каталога.
Если сайт ищет «bank.com» в URL реферера, возможно, сработают «bank.com.attacker.com» или «attacker.com/bank.com».
. . .
Оригинальная статья: https://medium.com/swlh/bypassing-csrf-protection-c9b217175ee
Приветик и спасибо за чтение. Пожалуйста, помогите сделать этот ресурс лучше для новичков: не стесняйтесь указывать на любые ошибки или дайте мне знать о интересующих вас темах. С вами был neopaket, пока
Отдельное спасибо tabac
Атака CSRFs довольно распространена и очень проста в использовании. Сайты чаще всего используют хоть какую, да защиту от CSRF. Иногда это может быть проверка CSRF или проверка реферера (Referrer) или подобные методы.
Но в итоге все, что было сделано для предотвращения (защиты) от этой атаки, - это не полная защита с множеством уязвимостей. Сегодня мы поговорим о некоторых аспектах, которые должны использовать, чтобы защититься от CSRF.
(То же самое относится и к защите от SSRF. Тот факт, что реализованы защитные механизмы какой-либо уязвимости, не означает, что эти методы так хороши. Подробнее об обходе защиты SSRF читайте здесь. (https://medium.com/@vickieli/bypassing-ssrf-protection-e111ae70727b))
Независимо от типа развернутой защиты CSRF, вы всегда можете сначала попробовать две вещи: кликджекинг и изменение метода запроса.
Кликджекинг (ClickJacking)
(Если вы не знакомы с атаками кликджекинга, дополнительную информацию можно найти здесь (https://www.owasp.org/index.php/Clickjacking) или узнать краткую информацию ниже.)
Clickjacking, также известный как «атака с восстановлением пользовательского интерфейса», - это когда злоумышленник использует несколько прозрачных или непрозрачных слоев, чтобы заставить пользователя нажать на кнопку или ссылку на другой странице, когда он намеревался щелкнуть на странице верхнего уровня. Таким образом, злоумышленник «перехватывает» клики, предназначенные для их страницы, и направляет их на другую страницу, которая, скорее всего, принадлежит другому приложению, домену или обоим.
Эксплуатация кликджекинга на одной и той же конечной точке обходит всю защиту CSRF. Потому что технически запрос действительно исходит от законного сайта. Если страница, на которой расположена уязвимая конечная точка, уязвима для перехвата кликов, вся защита CSRF будет неактуальной.
Подмена метода запроса
Также стоит попробовать изменить метод запроса. Если секретный запрос, который вы хотите подделать, отправляется методом POST, попробуйте преобразовать запрос в метод GET. И если действие выполняется с помощью GET, попробуйте преобразовать его в POST. Приложение может все еще выполнить действие, и тот же самый механизм защиты часто не работает.
Например, этот запрос:
Код:
POST /change_passwordPOST body:new_password=qwertyМожет быть переписан как:
Код:
GET /change_password?new_password=qwertyЗащита CSRF с помощью токена
Тот факт, что сайт использует токены CSRF, не означает, что он правильно их проверяет. Вот несколько вещей, которые вы можете попытаться обойти с защитой CSRF с помощью токенов.
Удалить параметр токена или отправить пустой токен
Не отправка токена работает довольно часто из-за распространенной логической ошибки приложения: приложения иногда проверяют действительность токена только в том случае, если токен существует или параметр токена не пуст. В этом случае отправка запроса без токена или пустого значения в качестве токена может быть достаточной для обхода защиты.
Например, если обычный запрос выглядит так:
Код:
POST /change_password
POST body:
new_password=qwerty &csrf_tok=871caef0757a4ac9691aceb9aad8b65bПопробуйте это (пустой токен):
Код:
POST /change_password
POST body:
new_password=qwertyИли это:
Код:
POST /change_passwordPOST body:new_password=qwerty &csrf_tok=Использовать токен CSRF другого сеанса
Приложение может только проверять, является ли токен действительным или нет, и проверять, принадлежит ли он текущему пользователю. Если это так, вы можете просто жестко закодировать свой собственный токен CSRF в полезную нагрузку!
Допустим, токен жертвы - 871caef0757a4ac9691aceb9aad8b65b, а ваш - YOUR_TOKEN. Вы можете легко получить свой собственный токен CSRF, но не токен жертвы. Попробуйте обойти защиту CSRF, предоставив свой собственный токен вместо легального (Настоящего) токена.
Другими словами, вместо отправки этого:
Код:
POST /change_password
POST body:
new_password=qwerty &csrf_tok=871caef0757a4ac9691aceb9aad8b65bОтправьте это:
Код:
POST /change_password
POST body:
new_password=qwerty &csrf_tok=YOUR_TOKENФиксация сессии
Иногда сайты используют так называемый файл cookie с двойной передачей для защиты от CSRF. Это означает, что отправленный запрос будет содержать один и тот же случайный токен как в виде файла cookie, так и в качестве параметра запроса, и сервер проверяет, равны ли эти два значения. Если значения равны, запрос считается верным. Эта защита довольно часто встречается повсеместно.
Если в качестве механизма защиты используется cookie с двойной передачей, приложение, вероятно, не сохраняет действительный токен на стороне сервера. У него нет способа узнать, является ли какой-либо токен, который он получает, действительно легитимным, и он просто проверяет, совпадает ли токен в cookie и токен в теле запроса. Это означает, что если вы также можете отправить поддельный файл cookie, вы все равно сможете выполнить CSRF.
Затем атака будет состоять из двух этапов: во-первых, вы используете метод фиксации сеанса, чтобы браузер жертвы сохранял любое значение, выбранное вами в качестве файла cookie CSRF-токена. Затем выполните CSRF с тем же маркером CSRF, который вы выбрали в качестве файла cookie.
1. Сессия фиксации. Это атака, которая позволит вам контролировать хранилище файлов cookie жертвы. Подробнее об этом здесь (https://www.owasp.org/index.php/Session_fixation).
2. Выполните CSRF со следующим запросом:
Код:
POST /change_password
Cookie: CSRF_TOK=FAKE_TOKEN;
POST body:
new_password=qwerty &csrf_tok=FAKE_TOKENCSRF Защита через Реферер
Допустим, attacker.com - это ваш домен. И bank.com - это сайт, на который вы нападаете. Сайт не использует токены CSRF, но проверяет заголовок реферера. Что ты можешь сделать сейчас?
Удалить заголовок реферера
Подобно отправке пустого токена, иногда все, что вам нужно сделать, чтобы обойти проверку реферера, это просто не отправлять реферера. Для этого вы можете добавить следующий метатег на страницу с вашей полезной нагрузкой:
Код:
<meta name=”referrer” content=”no-referrer”>Приложение может проверять реферера только в том случае, если оно отправлено, в этом случае вы успешно обошли его защиту CSRF!
Обойти регулярное выражение (regex)
Если проверка реферера основана на белом списке, вы можете попробовать обойти регулярное выражение, используемое для проверки URL. Например, вы можете попробовать поместить доменное имя жертвы в URL-адрес реферера в качестве субдомена (Поддомен(Поддомен — домен, являющийся частью домена более высокого уровня.)) или в качестве каталога.
Если сайт ищет «bank.com» в URL реферера, возможно, сработают «bank.com.attacker.com» или «attacker.com/bank.com».
. . .
Оригинальная статья: https://medium.com/swlh/bypassing-csrf-protection-c9b217175ee
Приветик и спасибо за чтение. Пожалуйста, помогите сделать этот ресурс лучше для новичков: не стесняйтесь указывать на любые ошибки или дайте мне знать о интересующих вас темах. С вами был neopaket, пока
Отдельное спасибо tabac
Последнее редактирование:
