Читал про защиту от CSRF - якобы с помощью hidden-поля.
Механизм понятен, типа записываем большую шифрованную хрень в сессию, а затем сравниваем с переданной хренью через форму.
Например, у нас есть a.php, откуда данные из формы отправляются в b.php
Что мешает взломщику глянуть в html-коде страницы a.php значение hidden-поля и передавать его в b.php вместе со всеми своими злорадствами?
Спустя 6 минут, 34 секунды (23.03.2011 - 01:59) Админ написал(а):
да фигня это - вопрос валидации не более
а хидден поля - шляпа
а хидден поля - шляпа
Спустя 2 минуты, 27 секунд (23.03.2011 - 02:01) drasute написал(а):
| Цитата (Админ @ 22.03.2011 - 22:59) |
| да фигня это - вопрос валидации не более а хидден поля - шляпа |
я тебя не понял.
что именно фигня?
и почему хидден-поле - шляпа?
Спустя 7 минут, 51 секунда (23.03.2011 - 02:09) Админ написал(а):
drasute
в данном случае - от хиддена толку мало
да и тема весьма специфическая - эти межсайтовые запросы - там защита то ведь элементарная от этого дела
в данном случае - от хиддена толку мало
да и тема весьма специфическая - эти межсайтовые запросы - там защита то ведь элементарная от этого дела
Спустя 6 минут, 7 секунд (23.03.2011 - 02:15) drasute написал(а):
| Цитата (Админ @ 22.03.2011 - 23:09) |
| защита то ведь элементарная от этого дела |
поделись
Спустя 3 минуты, 32 секунды (23.03.2011 - 02:19) inpost написал(а):
drasute
Капчей защищаются, а не скрытым полем.
Капчей защищаются, а не скрытым полем.
Спустя 8 минут, 16 секунд (23.03.2011 - 02:27) Админ написал(а):
ну ты даёшь - вот мне делать нефиг - это ж не 5 минут тем более - не очень понятно с какой стороны это необходимо отсекать.
на вот хабр почитай - сам подумай - покажи что надумал, а мы направим на путь истинный
http://habrahabr.ru/blogs/webdev/21626/
на вот хабр почитай - сам подумай - покажи что надумал, а мы направим на путь истинный
http://habrahabr.ru/blogs/webdev/21626/
Спустя 4 минуты, 46 секунд (23.03.2011 - 02:32) Guest написал(а):
| Цитата (inpost @ 22.03.2011 - 23:19) |
| Капчей защищаются, а не скрытым полем. |
разве одно мешает другому?
мне кажется, вариантов защиты масса
Спустя 18 минут, 11 секунд (23.03.2011 - 02:50) drasute написал(а):
Админ
Ну на хабре только и обсуждают эти стандартные методы - капча, токен, реф.
Когда ты говорил, что защита элементарная, ты имел в виду что-то другое?
Ну на хабре только и обсуждают эти стандартные методы - капча, токен, реф.
Когда ты говорил, что защита элементарная, ты имел в виду что-то другое?
Спустя 7 минут, 38 секунд (23.03.2011 - 02:58) Админ написал(а):
drasute
как раз это и имел - это ж просто реализовать
как раз это и имел - это ж просто реализовать
Спустя 9 минут, 47 секунд (23.03.2011 - 03:08) drasute написал(а):
Админ
я люблю твороженные булочки, а я о чём говорил в первом посте?
я знаю эти методы, вопрос был в другом.
пожалуйста, перечитай 1-й пост темы.
я люблю твороженные булочки, а я о чём говорил в первом посте?
я знаю эти методы, вопрос был в другом.
пожалуйста, перечитай 1-й пост темы.
| ! |
inpost |
Спустя 4 часа, 27 минут (23.03.2011 - 07:35) Белый Тигр написал(а):
Ребят, вы вообще о чём? 
Вы точно понимаете что такое CSRF?
Приведу простой пример. Есть у вас на одном сайте А форма заполнения профиля. Вы вводите туда свои данные, жмёте "Сохранить" и информация о вас сохраняется. Приходит злоумышленник, ему нужно изменить ваш профиль.
Он регистрирует аккаунт, заходит в свой профиль и копирует код формы. Помещает её на хост Б, делает невидимой (размещая в скрытом iframe например). Добавляет на страницу JavaScript автоматической отправки формы. Затем злоумышленник заполняет поля формы так как надо ему. То есть в итоге получается такая схема. На сайте Б есть невидимая уже заполненная форма, которая отправится на сайт А как только кто-нибудь зайдёт на страницу.
Далее зовут вас. Под любым предлогом просят войти на эту страничку. Вы, попадая на неё, вызываете выполнение кода отправки. Форма уходит на сайт А, ваш профиль изменяется. Если защиты от CSRF нет, то со стороны скриптов сайта А это выглядит так, будто вы сами отправили им форму редактирования профиля. Им без разницы с какого хоста она пришла, главное что она пришла и её нужно обработать.
Теперь о защите. Первое что тут приходит на ум, это, конечно же, проверка реферера. Но тут есть небольшой подводный камень - у небольшого числа интернет-пользователей реферер режется файрволом, корпоративным прокси и пр. То есть существует вероятность (хоть и совсем небольшая) что некоторые пользователи не смогут работать с вашим сайтом если вы опираетесь на данные из реферера.
hidden-поля тут дают 100% гарантию. По крайней мере я ещё не видел возможностей обхода такой защиты. Суть вот в чём. Когда пользователь проходит авторизацию на сайте, ему в сессию генерируется случайный ключ. Пусть это будет какой-нибудь md5-хеш. Далее этот хеш лепится к каждой форме. А на стороне сервера скрипты, принимая формы от посетителя, проверяют что за хеш передан, и он ли лежит в сессии. Если ключи не совпадают - кто-то пытается провести CSRF.
Вы точно понимаете что такое CSRF?
Приведу простой пример. Есть у вас на одном сайте А форма заполнения профиля. Вы вводите туда свои данные, жмёте "Сохранить" и информация о вас сохраняется. Приходит злоумышленник, ему нужно изменить ваш профиль.
Он регистрирует аккаунт, заходит в свой профиль и копирует код формы. Помещает её на хост Б, делает невидимой (размещая в скрытом iframe например). Добавляет на страницу JavaScript автоматической отправки формы. Затем злоумышленник заполняет поля формы так как надо ему. То есть в итоге получается такая схема. На сайте Б есть невидимая уже заполненная форма, которая отправится на сайт А как только кто-нибудь зайдёт на страницу.
Далее зовут вас. Под любым предлогом просят войти на эту страничку. Вы, попадая на неё, вызываете выполнение кода отправки. Форма уходит на сайт А, ваш профиль изменяется. Если защиты от CSRF нет, то со стороны скриптов сайта А это выглядит так, будто вы сами отправили им форму редактирования профиля. Им без разницы с какого хоста она пришла, главное что она пришла и её нужно обработать.
Теперь о защите. Первое что тут приходит на ум, это, конечно же, проверка реферера. Но тут есть небольшой подводный камень - у небольшого числа интернет-пользователей реферер режется файрволом, корпоративным прокси и пр. То есть существует вероятность (хоть и совсем небольшая) что некоторые пользователи не смогут работать с вашим сайтом если вы опираетесь на данные из реферера.
hidden-поля тут дают 100% гарантию. По крайней мере я ещё не видел возможностей обхода такой защиты. Суть вот в чём. Когда пользователь проходит авторизацию на сайте, ему в сессию генерируется случайный ключ. Пусть это будет какой-нибудь md5-хеш. Далее этот хеш лепится к каждой форме. А на стороне сервера скрипты, принимая формы от посетителя, проверяют что за хеш передан, и он ли лежит в сессии. Если ключи не совпадают - кто-то пытается провести CSRF.
| Цитата |
| Что мешает взломщику глянуть в html-коде страницы a.php значение hidden-поля и передавать его в b.php вместе со всеми своими злорадствами? |
То что для каждого пользователя значение этого поля разное и при каждом новом входе оно выдаётся новое. Единственный вариант тут - сесть за компьютер жертвы, непосредственно за ним посмотреть содержимое hidden-поля и пойти злорадствовать
P.S.Капча тоже железный вариант, но зачем лишний раз заставлять что-то делать пользователя?
Спустя 32 минуты, 46 секунд (23.03.2011 - 08:07) Семён написал(а):
Белый Тигр
не совсем верно, hash ключ в hidden inpute должен перегенерироваться, после каждой последующей ре-инициализации формы (для надёжности)
не совсем верно, hash ключ в hidden inpute должен перегенерироваться, после каждой последующей ре-инициализации формы (для надёжности)
Спустя 4 часа, 22 минуты, 21 секунда (23.03.2011 - 12:30) drasute написал(а):
| Цитата (Белый Тигр @ 23.03.2011 - 04:35) |
| То что для каждого пользователя значение этого поля разное и при каждом новом входе оно выдаётся новое. |
После того, как пользователь прошёл авторизацию, он может открыть html-код и глянуть этот хэш, который мы записали ему в сессию и, соответственно, в хидден-поле.
Ты же не генирируешь его каждую секунду? Сгенерировал и поставил в input.
Спустя 56 минут, 26 секунд (23.03.2011 - 13:26) Белый Тигр написал(а):
| Цитата |
| После того, как пользователь прошёл авторизацию, он может открыть html-код и глянуть этот хэш, который мы записали ему в сессию и, соответственно, в хидден-поле. Ты же не генирируешь его каждую секунду? Сгенерировал и поставил в input. |
И что? Пользователь отдаст это значение злоумышленнику? Суть в том что его не знает злоумышленник. Пользователь может хоть что с этим значением делать. Главное что у одного посетителя ключ один, у другого другой и т.д.
| Цитата |
| не совсем верно, hash ключ в hidden inpute должен перегенерироваться, после каждой последующей ре-инициализации формы (для надёжности) |
Зачем лишние сложности? Смысл? Теоретически можно вообще генерировать случайный (главное случайный - чтоб невозможно было просчитать ключи для всех) ключ сразу при регистрации и всегда использовать только его - разницы не будет. Попасть в руки злоумышленнику он сможет только через другие уязвимости типа XSS, но при их наличие о CSRF уже никто не подумает
Спустя 5 часов, 57 минут, 4 секунды (23.03.2011 - 19:23) drasute написал(а):
Белый Тигр
спасибо большое, я всё понял.
спасибо большое, я всё понял.