Перейти к контенту

Басни о куках


Рекомендуемые сообщения

Ух блин вы бы лучше о подстановке через куки SQL иньекций подумали

Сейчас просто шквал идет попыток через SQL-иньекци посредством кукисов пробить форумы...

Ссылка на комментарий
Поделиться на других сайтах

  • Ответы 95
  • Создана
  • Последний ответ

Лучшие авторы в этой теме

Лучшие авторы в этой теме

Что тут думать, разбираем входящие данных регулярными выражениями и инъекции курят бамбук... Кроме того, в 2.1.x да и вообще в 2.0 SQL Injection — ба-а-а-альшая редкость.
Ссылка на комментарий
Поделиться на других сайтах

Уязвимость в ЖАЛОБА уже тоже обсжудали

 

Dr.Freddy

Угу если бы. Сам форум куки свои фигово проверяет. Вообще надо сделат так тчобы утащив куки получаеш кукиш а не вход по юзвером.

Ссылка на комментарий
Поделиться на других сайтах

То же самое — запускаем куки через регексп. Насчет защиты от кражи кук юзера — предложи реализацию.
Ссылка на комментарий
Поделиться на других сайтах

То же самое — запускаем куки через регексп. Насчет защиты от кражи кук юзера — предложи реализацию.

Привязка к типу браузера стандартными средствами IPB.

Уже реализовано, но по-умолчанию галка отключена.

Если я ничего не путаю :D

Ссылка на комментарий
Поделиться на других сайтах

И что, это защита? Крадём куки и заходим на форум под нужным браузером, не так уж их и много.
Ссылка на комментарий
Поделиться на других сайтах

И что, это защита? Крадём куки и заходим на форум под нужным браузером, не так уж их и много.

Ок, дописываем удаление сессии из таблицы в случае несовпадения IP с тем, в котором сессия была создана. Этого достаточно? :D

Ссылка на комментарий
Поделиться на других сайтах

Ок, дописываем удаление сессии из таблицы в случае несовпадения IP с тем, в котором сессия была создана. Этого достаточно?
Нет. Не вижу, как это защитит от кражи куков.
Ссылка на комментарий
Поделиться на других сайтах

Ок, дописываем удаление сессии из таблицы в случае несовпадения IP с тем, в котором сессия была создана. Этого достаточно?
Нет. Не вижу, как это защитит от кражи куков.

Это защитит от подмены куков по меньшей мере.

Ну есть кукиз, а что ты с ним сделаешь, если тебя форум не опознает?

Ссылка на комментарий
Поделиться на других сайтах

NaFigator

Ок, дописываем удаление сессии из таблицы в случае несовпадения IP с тем, в котором сессия была создана. Этого достаточно?

Любопытный вариант, хотелось бы взглянуть :D

Но вот как сильно будет всё подтормаживать? Ведь при каждом обращении будут ипы сверяться. А если онлайн несколкьо сотен человек?

Ссылка на комментарий
Поделиться на других сайтах

NaFigator
Ок, дописываем удаление сессии из таблицы в случае несовпадения IP с тем, в котором сессия была создана. Этого достаточно?

Любопытный вариант, хотелось бы взглянуть :D

Но вот как сильно будет всё подтормаживать? Ведь при каждом обращении будут ипы сверяться. А если онлайн несколкьо сотен человек?

Ну это же не ibf_posts ;)

Ссылка на комментарий
Поделиться на других сайтах

NaFigator

 

Это защитит от подмены куков по меньшей мере.
В таблицу сессий пишем тип браузера. Толку ноль: от кражи куков это не спасёт (взломщик зайдёт позже, когда сессия уже подохнет). А если привязывать конкретный тип браузера к конкретному юзеру, это сильно ограничивает его в пользовании форумом, во-первых, а во-вторых, никак не защищает: взломщик воспользуется тем же самым браузером, вот и всё. Сравнение IP опять-таки не поможет: ну убьёт сессию, и что дальше? Взломщик создаст новую.

 

Опиши алгоритм по шагам, я не понимаю, чего ты добьёшься этим способом, кроме как снятия скорости с форума и неудобства для пользователей.

Ссылка на комментарий
Поделиться на других сайтах

NaFigator

 

Это защитит от подмены куков по меньшей мере.
Сравнение IP опять-таки не поможет: ну убьёт сессию, и что дальше? Взломщик создаст новую.

 

Опиши алгоритм по шагам, я не понимаю, чего ты добьёшься этим способом, кроме как снятия скорости с форума и неудобства для пользователей.

Погоди-погоди, как взломщик создаст новую? Что-то я не понимаю.

Я представляю себе агоритм так:

1. Юзер вводит логин-пароль, жмёт сабмит, создаётся сессия, которая действует только для того IP, которым она создана.

2. Юзеру в кукизы пишется хэш и сессия.

3. Юзер не разлогинивается, а просто закрывает браузер - сессия в БД остаётся.

5. Хакер крадёт хэш Юзера, сессию, прописывает их себе в кукизы, входит на форум.

6. Форум берёт из кукизов сессию и хэш, отправляет форуму.

7. Форум проверяет связку IP-сессия и если она неверная - убивает сессию вообще.

8. Хакер обламывается, ошибка пишется в лог админам.

9. Юзер заходит на форум и оказывается разлогиненным. Ругается и логинится заново.

 

Всё. Что-то не учёл?.. :D

Ссылка на комментарий
Поделиться на других сайтах

Всё. Что-то не учёл?..
А то. На просторах СНГ это прямо-таки кастрация авторизации — просто потому, что множество народу ходит через модемные пулы и при каждом коннекте получает новый IP-адрес. Таким образом их постоянно будет разлогинивать, а лог админов будет забит сообщениями об этих, совершенно мирных с точки зрения безопастности, входах.

 

Кроме того, если спёрт хэш пароля, юзера всё равно с большей степени вероятности поломают — md5 криптостоек лишь до определённой ступени.

Ссылка на комментарий
Поделиться на других сайтах

Тут ты прав, про модемы я совсем не подумал.

Ну ок, логи не пишем, а эту фичу делаем для юзеров опциональной.

 

Всё же что-то.

Ссылка на комментарий
Поделиться на других сайтах

Чтото надо делать

а если на последнем этапе при выводе страницы проверять есть ли попытка кражи куков типо: document.cookie ??

Изменено пользователем freeman85
Ссылка на комментарий
Поделиться на других сайтах

NaFigator
Ок, дописываем удаление сессии из таблицы в случае несовпадения IP с тем, в котором сессия была создана. Этого достаточно?

Любопытный вариант, хотелось бы взглянуть ;)

Но вот как сильно будет всё подтормаживать? Ведь при каждом обращении будут ипы сверяться. А если онлайн несколкьо сотен человек?

 

Притормаживать не будет т.к. проверять надо не на каждый клик, а только на старт сессии. А она создаётся у кого как, ну раз в 15 минут обычно.

 

NaFigator

 

Это защитит от подмены куков по меньшей мере.
В таблицу сессий пишем тип браузера. Толку ноль: от кражи куков это не спасёт (взломщик зайдёт позже, когда сессия уже подохнет). А если привязывать конкретный тип браузера к конкретному юзеру, это сильно ограничивает его в пользовании форумом, во-первых, а во-вторых, никак не защищает: взломщик воспользуется тем же самым браузером, вот и всё. Сравнение IP опять-таки не поможет: ну убьёт сессию, и что дальше? Взломщик создаст новую.

 

Опиши алгоритм по шагам, я не понимаю, чего ты добьёшься этим способом, кроме как снятия скорости с форума и неудобства для пользователей.

 

Тут надо не сессию какую-то особенную контролировать, а все сесии определённого человека. Хранить для него IP адреса (маски) и в случае несовпадения, килять сессию. Точнее не килять, а не создавать её, чтобы избежать свопинга запросов.

Я на этом форуме точно знаю двоих у кого это реализовано.

 

Погоди-погоди, как взломщик создаст новую? Что-то я не понимаю.

...

Всё. Что-то не учёл?.. :D

 

3. Юзер не разлогинивается, а просто закрывает браузер - сессия в БД остаётся.

Она там ненадолго останется. Убьётся сама, без посещения этого самого юзера, если он не будет на форуме в течение какого-то времени. Чтобы она оставалась, её надо "подкармливать" апдейтами. Но даже если ты всё время будешь присутствовать на форуме, она всё-равно время от времени меняется.

Сразу видно, что functions.php ты плохо знаешь :)

 

5. Хакер крадёт хэш Юзера, сессию, прописывает их себе в кукизы, входит на форум.

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

Одно радует, что наверняка у него будет другой IP.

Ссылка на комментарий
Поделиться на других сайтах

Злоумышленник не может украсть сессию

Если он сможет впихнуть ссылку с снифером, то уркадет

 

Впринципе можно делать динамические куки т.е. для кажой запрошеной пользователем странички кука выдается новая

Ссылка на комментарий
Поделиться на других сайтах

Если он сможет впихнуть ссылку с снифером, то уркадет

Ну это да, но просто это бесполезно. Информация о session_id очень быстро устаревает и не стоит того, чтобы её красть, я думаю, что просто не успеют её украсть. И красть нужно под тем же IP.

 

так что с идеей. перед падачей браузеру парсером выдрать все document.cookies ? это накладно? :D

ты вообще понимаешь что ты говоришь?

словосочетания document.cookies и перед падачей браузеру противоречат друг другу т.к. document.cookies - объекты браузера, к которым идёт доступ через javascript, их php вообще не знает. Возможно ты что-то другое хотел сказать?

Ссылка на комментарий
Поделиться на других сайтах

при генерации страницы, еще до отдачил клиенту(браузеру) перед выходом проверить т.е. пресечь выход сочетаие слов document.cookies

 

не могу найти тему, в ней кто-то выложил мод... где также вырезал коментарии типа <!-- -->, а после уже клиенту(браузеру) выдавалась страница............. т.е. тогда он экономил трафик.

 

а сейчас нам нужно чтобы браузеру не передлось сочетание слов document.cookies.

 

попытайтесь хоть понять что я говорю, не ужели сложно

 

т.е. в этом случае, он в любой части... в аватаре, в подписе, в личке или теме не давал бы вывести клиенту(браузеру) эти злощасные "два слова."

Изменено пользователем freeman85
Ссылка на комментарий
Поделиться на других сайтах

Ой-ли. А поможет? :D в фильтр мата занести не пробовал? ;)
Ссылка на комментарий
Поделиться на других сайтах

так что с идеей. перед падачей браузеру парсером выдрать все document.cookies ? это накладно? :D

Автоматически фильтровать контент вообще гиблое дело... ;)

Хотя тебе правильно подсказали насчёт мат-фильтра.

Ссылка на комментарий
Поделиться на других сайтах


×
×
  • Создать...

Важная информация

Находясь на нашем сайте, вы соглашаетесь на использование файлов cookie, а также с нашим положением о конфиденциальности Политика конфиденциальности и пользовательским соглашением Условия использования.