Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737
Форумы портала PHP.SU :: Нужно ли сверять токен в БД? [2]

 PHP.SU

Программирование на PHP, MySQL и другие веб-технологии
PHP.SU Портал     На главную страницу форума Главная     Помощь Помощь     Поиск Поиск     Поиск Яндекс Поиск Яндекс     Вакансии  Пользователи Пользователи


 Страниц (6): « 1 [2] 3 4 5 6 »   

> Без описания
teddy
Отправлено: 07 Ноября, 2015 - 10:58:12
Post Id


Участник


Покинул форум
Сообщений всего: 1462
Дата рег-ции: Апр. 2013  


Помог: 91 раз(а)




DeepVarvar пишет:
Не надо нам тут гвозди забивать двуручной пилой.

Не пойму, с каких пор проверка на наличие ключа перед его использованием, стало забиванием гвоздей двуручной пилой?
isset вполне нормальный выбор, если не требуется проверять NULL-ы.
DeepVarvar пишет:
3) Перевести все, требующие защиты от CSRF места, на POST/PUT/DELETE запросы.
После чего не использовать CSRF-токен вообще.

Ха-ха Что то ты какой то наивный сегодня ))

Попробуй ответить на вопрос Мелкого Закатив глазки
 
 Top
DeepVarvar Супермодератор
Отправлено: 07 Ноября, 2015 - 17:46:21
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




teddy пишет:
isset вполне нормальный выбор, если не требуется проверять NULL-ы

teddy пишет:
Лучше проверить например на isset, потому что данного ключа может просто не существовать

Так существование или нуллы?
teddy пишет:
наивный Попробуй ответить на вопрос Мелкого

Мелкий пишет:
какая тебе проблема попросить браузер пользователя сделать не GET-запрос на атакуемую страницу, а тот же POST?

Аяксом, вестимо, только, аяксом (ну ладно, еще форму в ифрейм отправить). Но!!!

1) Если мы говорим о том же самом сайте, то у нас XSS, а это другая проблема, не так ли?

2) Если каким-то образом атакующий узнал о том, что жертва ходит на другой конкретный сайт, то,
даже при условии что, на стороне другого сайта будет XSS, или сторонний сайт принадлежит атакующему:

а) для аякса (1): сработает COP (Cross Origin Policy).
б) для аякса (2): при условии что домен "родственный", ты не подумал про CORS.
в) и для аякса (3) и для ифрейма (1): ты не подумал про COP для POST (проверить реферер).

Бонус: реферер статичен, в отличии от токенов, и не требует соотв. обвязки и пинания туда-сюда-обратно.
И давай не будем говорить что реферер можно подделать -- в этом контексте у нас не MiTM.
 
 Top
Мелкий Супермодератор
Отправлено: 07 Ноября, 2015 - 20:15:50
Post Id



Активный участник


Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 618 раз(а)




DeepVarvar пишет:
ну ладно, еще форму в ифрейм отправить

ну так?

DeepVarvar пишет:
не будем говорить что реферер можно подделать -- в этом контексте у нас не MiTM.

Зачем подделывать? Достаточно просто его убить. Это вполне возможно без вмешательства в настройки браузера. Например, https://en[dot]wikipedia[dot]org/wiki/HT[dot][dot][dot]r#Referer_hiding


-----
PostgreSQL DBA
 
 Top
DeepVarvar Супермодератор
Отправлено: 07 Ноября, 2015 - 22:20:54
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Мелкий пишет:
ну так?
Я расписал что будет и как в случае с формой.
Мелкий пишет:
Достаточно просто его убить
Убить === подделать.
 
 Top
Deonis
Отправлено: 08 Ноября, 2015 - 02:47:31
Post Id



Посетитель


Покинул форум
Сообщений всего: 298
Дата рег-ции: Нояб. 2009  


Помог: 14 раз(а)




DeepVarvar пишет:
может оставить все как есть?
От меня действительно никто не требовал переделывать авторизацию и всё, что с ней связано и за это, я думаю, мне не заплатят, НО я пять лет обходил стороной эту тему, уговаривая себя тем, что мол "если кому-то очень надо будет, то он всё равно взломает". Может оно так и есть, но пусть это уже будет профи, чем какой-то сопляк-школьник... не так обидно будет ))
DeepVarvar пишет:
может лучше взять серьезный фреймворк?
Нет уж, переписывать всю CRM - на это моего энтузиазма не хватит ))
DeepVarvar пишет:
Перенести хранение сессии в БД
Я так понимаю, что тут будет в помощь session_set_save_handler() или есть другие варианты?
Мелкий пишет:
всё-таки надо прочитать и понаписать текста
В общем и целом понял, но иллюзий не строю и понимаю, что тут надо копать гораздо глубже.

Собственно, господа, всем низкий поклон за ответы, очень полезно и моё "белое пятно" по этой теме начало потихоньку закрашиваться Подмигивание
 
 Top
Мелкий Супермодератор
Отправлено: 08 Ноября, 2015 - 10:09:10
Post Id



Активный участник


Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 618 раз(а)




DeepVarvar пишет:
Убить === подделать.

Примем утверждение за true.
DeepVarvar пишет:
И давай не будем говорить что реферер можно подделать -- в этом контексте у нас не MiTM.

Это утверждение становится ложно. Убить реферер можно без использования MitM.

Утверждения противоречат друг другу, следовательно, выбери какое-то одно утверждение либо докажи отсутствие противоречия.

Реферер дополнительно проверять можно, но базовая защита от CSRF - токен в формах. Один токен на сессию использовать вполне можно.
Штука элементарная: при старте сессии генерируется токен, подставляется его в скрытые поля формы, при получении формы проверяется, что токен с формы пришёл и совпадает с записанным в сессии. Всё, ничего лишнего дёргать не надо, просто и надёжно.
Вот если параноить и делать отдельный токен на каждый запрос - тогда да, проблем добавляется.


-----
PostgreSQL DBA
 
 Top
teddy
Отправлено: 08 Ноября, 2015 - 18:21:40
Post Id


Участник


Покинул форум
Сообщений всего: 1462
Дата рег-ции: Апр. 2013  


Помог: 91 раз(а)




DeepVarvar
Цитата:
Так существование или нуллы?

Не придирайся Улыбка Кому-кому уж тебе точно должно быть понятно, почему я подчеркнул нулл.
И да, я в курсе что isset проверяет значения, а не ключи. Почему я так выразился - думаю должно быть понятно

Вернемся к CSRF.
Во первых когда ты говорил про
Цитата:
Перевести все, требующие защиты от CSRF места, на POST/PUT/DELETE запросы.
После чего не использовать CSRF-токен вообще.

О проверке реферера ты ничего не сказал. Ок, пусть так.

Да, браузер при отправке формы так же отправляет реферера, этим или отсутствием реферера можно воспользоваться(палка двух концов) для валидации запроса.
Но, если подгрузить атакуемую страницу на свою(мы злоумышленники) через iframe и пригласить туда жертву - можно осуществить CSRF атаку даже при проверке реферера на сервере жертвы.
Да, нельзя будет сделать это автоматически ввиду ограничений для кроссдоменных запросов, но есть одно НО.
Подгрузив атакуемую страницу через iframe, ты можешь "замазать" её собственной версткой, не скрыв iframe.

Даем ссылку жертве на нашу страничку и говорим, заполни форму по этой ссылке и получишь такие то плюшки.
Инпуты, которые будет заполнять жертва - будут инпутами той зоны, где авторизованна жертва.
Все что нужно злоумышленнику, это сделать качественные декорации вокруг разметки, которая подгружена из атакуемой страницы с помощью iframe.
И при отправке такой формы, реферером будет URL того сервера, с которого был подгружен контент.
И не важно это тот же самый сайт или нет.
CSRF успешно удался.

Но ведь скажешь ты, "в таком случае и токен не спасет, потому что он так же будет загружен через iframe в форму и окажется валидным при проверке на сервере", на что я отвечу:
Если генерировать токен для GET параметра, и сверять этот токен ТОЛЬКО при изменении данных, то атакующий ничего сделать не сможет.
Он может знать адрес атакуемой страницы и запросить её через iframe, но не будет знать токен аутентефицированного пользователя. Поэтому данные не будут сохранены. Желательно что бы токен был одноразовым, ведь утащить токен из GET параметра не составил труда.
Почему сравнивать токен из GET ТОЛЬКО при изменении данных? Что бы люди которые будут ходить например из поисковика могли успешно посетить страницу по этому адресу. С реферером такое не прокатит потому что ты просто убьешь любые переходы со сторонних ресурсов, что конечно же недопустимо, если речь идет не о админке.

Скажешь, можно можно воспользоваться X-Frame-Options? Не все браузеры это поддерживают. Фича относительно новая да и обязывать клиента следить за безопасностью сервера тоже не надежно.
Скажешь, можно написать js, который будет "запрещать" подгрузку через iframe? Sandbox у iframe способен убить js.

Ну, кто что думает?
 
 Top
DeepVarvar Супермодератор
Отправлено: 23 Ноября, 2015 - 03:50:19
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Сорики за долгущщий ответ, были дела, продолжим!

Мелкий пишет:
Утверждения противоречат друг другу, следовательно, выбери какое-то одно утверждение либо докажи отсутствие противоречия.
Наш реферер проверяется именно в контексте CSRF, а не митм. А любая CSRF содержит в себе митм. Поэтому я и сказал "в этом контексте".
Мелкий пишет:
при старте сессии генерируется токен
И даже если он меняется, то:

а) От чужого хоста это спасает, да...

б) На довренном домене/поддомене НЕ спасает, т.к. атакующий может сходить на нужную страницу аяксом и сматчить оттуда токен, затем сфрмировав запрос с токеном -- сделать какашку.
Только проблема тут уже не в CSRF, а в XSS, как я и говорил ранее.

teddy пишет:
бла-бла-бла
Согласен.
teddy пишет:
Если генерировать токен для GET параметра, и сверять этот токен ТОЛЬКО при изменении данных
Ты этот токен будешь передавать в гет-форму или гет-строку для пост-формы, которая и лежит в замазанном подгруженном айфрейме, иначе сравнивать будет не с чем.
teddy пишет:
С реферером такое не прокатит потому что ты просто убьешь любые переходы со сторонних ресурсов, что конечно же недопустимо, если речь идет не о админке
Нет же, изменение данных даже вне админки уже подразумевает точки доступа явно не являющиеся тупым ридонли, в том числе и местом входа с любого внешнего ресурса.
teddy пишет:
Ну, кто что думает?
Я пока остался при своем мнении -- реферер. Ибо реферер проще токена в реализации.
Спойлер (Отобразить)
 
 Top
Мелкий Супермодератор
Отправлено: 23 Ноября, 2015 - 11:49:28
Post Id



Активный участник


Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 618 раз(а)




DeepVarvar пишет:
А любая CSRF содержит в себе митм.

Нет, не содержит. Потому и является отдельным классом атак.

DeepVarvar пишет:
От чужого хоста это спасает, да...

Это и есть CSRF. Сross Site Request Forgery


-----
PostgreSQL DBA
 
 Top
DeepVarvar Супермодератор
Отправлено: 23 Ноября, 2015 - 13:08:39
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Мелкий пишет:
Сross Site Request Forgery
Т.е. если есть bazz.foo.bar и foo.bar то они это одно и то же?
Тогда я ушел проводить НЕцсрф на *.blog.com
 
 Top
Мелкий Супермодератор
Отправлено: 23 Ноября, 2015 - 15:41:55
Post Id



Активный участник


Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 618 раз(а)




Иди, проводи. Кто же мешает?

Для атаки достаточно:
0) выполнения действия по запросу от пользователя без подтверждения
1) заманить пользователя на страницу, к которой у тебя есть доступ (в том числе, скомпрометированную тем же XSS). На любом домене. На этой странице элементарно выполняется отправка запроса на желаемое действие от имени пользователя - запрос-то отправляет браузер и любезно подставляет куки. У самого атакующего доступа к кукам нет, но это и не нужно. Как убить реферер - см. предыдущую страницу.

А если атакуемый сайт делает фееричную глупость и принимает запрос через GET (а таких много и без каких-то мыслей о защите от csrf) - то атаку можно эксплуатировать, просто запостив на форум картинку.


-----
PostgreSQL DBA
 
 Top
DeepVarvar Супермодератор
Отправлено: 23 Ноября, 2015 - 17:16:44
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Мелкий пишет:
Как убить реферер - см. предыдущую страницу
Как убить токен так же см. выше.
Мелкий пишет:
принимает запрос через GET

DeepVarvar пишет:
можешь поковырять мою поделку -- там на реферерах и даже с гетом
 
 Top
Мелкий Супермодератор
Отправлено: 23 Ноября, 2015 - 17:31:36
Post Id



Активный участник


Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 618 раз(а)




При чём тут твоя поделка? На ней весь мир построен?


-----
PostgreSQL DBA
 
 Top
DeepVarvar Супермодератор
Отправлено: 23 Ноября, 2015 - 18:14:19
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Поделка вообще ни при чем. Не надо на ней заострять внимание.
Надо посмотреть и убедиться, что реферер защищает в той же степени, что и токен, только подход немного иной.
 
 Top
teddy
Отправлено: 23 Ноября, 2015 - 20:37:28
Post Id


Участник


Покинул форум
Сообщений всего: 1462
Дата рег-ции: Апр. 2013  


Помог: 91 раз(а)




DeepVarvar пишет:
Ты этот токен будешь передавать в гет-форму или гет-строку для пост-формы, которая и лежит в замазанном подгруженном айфрейме

Нет Улыбка Этого токена не будет в POST форме, в этом то и вся фича Улыбка
Правда в сыром виде такой подход плохо сказывается на юзабельности если токен одноразовый. Придется дополнительно шаманить что бы юзер честно открывая несколько вкладок одной и той же страницы не отхвачивал бед реквест при сохранении данных.
Это пока единственный вариант который я смог придумать против замазанного айфрейма, который был бы более надежным чем X-Frame-Options

DeepVarvar пишет:
Я пока остался при своем мнении -- реферер. Ибо реферер проще токена в реализации.

Насчет простоты да, согласен. Но согласись это HTTP, его заголовки - произвольный текст
никогда не знаешь что придет на ум хитрожопому программисту, поэтому лучше не доверять таким данным. Например против замазанного айфрейма реферер бессилен
 
 Top
Страниц (6): « 1 [2] 3 4 5 6 »
Сейчас эту тему просматривают: 0 (гостей: 0, зарегистрированных: 0)
« HTTP и PHP »


Все гости форума могут просматривать этот раздел.
Только зарегистрированные пользователи могут создавать новые темы в этом разделе.
Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
 



Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB