Comments 60
4. Браузер в очередной раз незаметно обновился
5. Пользователь установил какую-то программу, которая изменила User-Agent.
6. Пользователь обновил ОС
6. Пользователь обновил ОС
Обновил Винду до Линукса? :)
В User-Agent пишется и версия ОС, вплоть до билда. Вроде.
Что мешает отфильтровать? Парсинг строки — это примитивнейшая задача (в данном случае точно).
Смысл привязываться к UA теряется. Чем больше инфы из него берём, тем сильнее безопасность (если у злоумышленника нет возможности получить UA).
7. Установленное расширения браузера изменило User-Agent.
UFO just landed and posted this here
Расскажу свою историю. На ноутбуке установлены 2 браузера. Лиса и Хром. У первого стоит настройка восстанавливать предыдущую сессию при запуске. Второй просто отрывает страницу быстрого доступа. Если нужен активный серфинг надолго — запущен FF. Если нужно что-то быстро отрыть и глянуть — запускаю Хром. Иногда увлекаюсь и открываю попутно ещё пяток вкладок.
Как вариант, можно одну из переменных cookies генерить на основа User-Agent. Т.к. злоумышленники довольно часто копируют себе все cookies сервера без разбора, то тут-то они и попалятся, скопировав себе и переменную, привязанную для другого User-Agent.
А с какой стати кукисы на разных компьютерах у одного и того же пользователя пусть даже под одним браузером будут аналогичны? Вроде бы они в любом случае имеют встроенный параметр времени создания, который всегда будет разным, не?
Серверу время создания не передаётся, только имя и значение. Если алгоритм формирования значения не зависит от времени создания, агента, адреса и прочих переменных факторов, а только от постоянных (например имя пользователя), то куки будут на всех компах одинаковые. Вернее могут быть разные (срок истечения), но сервер этой разницы не увидит. Если разработчик хочет, то он вкладывает в алгоритм формирования куки переменные факторы, если не хочет — не вкладывает.
А, точно, я как раз скорее срок истечения имел в виду, но почему-то думал что он прозрачно передается серверу, который и принимает решение принимать/не принимать/продлять срок действия кукисов. А получается что по истечении браузер сам убивает куки и продлить их вообще ни как нельзя. Спасибо за разъяснение.
Пример: для авторизации вконтакте достаточно скопировать себе переменную remixsid. Остальные переменные в кукисах удаляем. И будет Вам счастье.
В очередной раз изобретён алгоритм проверки «отпечатков пальцев»?
phpclub.ru/detail/article/sessions
phpclub.ru/detail/article/sessions
> этим будут страдать, пожалуй, только веб-разработчики
Не соглашусь, обычные пользователи достаточно часто или тыкают в первый попавшийся браузер, или действуют по принципу «повис IE — запущу FF» (и наоборот).
Не соглашусь, обычные пользователи достаточно часто или тыкают в первый попавшийся браузер, или действуют по принципу «повис IE — запущу FF» (и наоборот).
Из-за роутера может быть несколько компьютеров с разными браузерами + телефоны + планшетники.
Имхо, запоминать (не важно как) User-Agent можно как подстраховку для текущей сессии по желанию пользователя. То есть если строка (её хэш) не совпали, то вылогинивать. Но только по желанию, иначе много неудобств (каждый раз логиниться) может доставить при санкционированном использовании. И пользователю не нужно объяснять в терминах User-Agent, а предложить что-то вроде «Привязывать сеанс работы к используемому браузеру. При смене браузера нужно будет ввести пароль повторно.».
В любом случае, даже если делать такую возможность, то делать ее опциональной, так как не все пользователям подойдет.
Если уж браться за безопасность в таком ключе, то стоит изучать поведение пользователей. Если при изменении IP, браузера и любых иных глобальных параметров клиента, клиент начинает сразу менять пароль, посылать почту, ставить оценки, можно задуматься о том, что аккаунт угнали и кто-то начинает его использовать в корыстных целях. Для уточнения тех же поведенческих признаков, присущих оригинальному пользователю, стоит составлять портрет пользователя (что он обычно делает и когда). В результате мы сможем определить оригинальность пользователя даже без определения параметров его подключения.
Идея интересная. Но на практике мало приходная. Во-первых, это потребует достаточных ресурсов. Тот же ВКонтакте скорее будет тратить все ресурсы на развитие сети для привлечения большего кол-ва пользователей (или даже удержания имеющихся), нежели на вот такие вот вещи.
И потом: как быть со всплесками активности, порождённых самим пользователем? Я вот по праздникам как напьюсь, так начинаю всяким людям в соц сетях писать всякую хрень ))) Можно тогда провести другую исследовательскую работу: "разлогивание в любимой соц. сети после изменения поведения в силу употребляемых накануне алкогольных напитков как мотивация к борьбе с алкоголем в странах России и СНГ"
И потом: как быть со всплесками активности, порождённых самим пользователем? Я вот по праздникам как напьюсь, так начинаю всяким людям в соц сетях писать всякую хрень ))) Можно тогда провести другую исследовательскую работу: "разлогивание в любимой соц. сети после изменения поведения в силу употребляемых накануне алкогольных напитков как мотивация к борьбе с алкоголем в странах России и СНГ"
Для меня довольно частое поведение при резкой смене окружения начинать «брутфорсить» пароль, восстанавливать и менять его.
Поэтому я и предлагаю сначала составлять поведенческий портрет пользователя, а не полагаться на догмы о том, как пользователь должен себя вести.
А более конкретно? Как предлагаете это всё реализовывать на практике?
Что «это»? Я имею в виду, что принятие решений об отказе в обслуживании на анализе поведения чревато большим числом ошибок второго рода — доступ санкционированный, но принимается за не таковой. Применимо, имхо, только для критических сервисов типа финансовых или других субъективно важных. Если бы не моя зависимость именно от Хабра, то давно бы плюнул на разгадывание его капчи, которую очень редко получается разгадать с первого раза. А Хромиум не считает Хабр достойным запоминания пароля.
Я с коллегой, в далеком 2004 году, писали для СПБ ГУ ИТМО систему одноразовых пропусков, где идентифицировали пользователей по ряду параметров, формировавших отпечаток. При изменении отпечатка — сессия сбрасывалась. В отпечаток входили IP, ОС и версия, браузер и версия, разрешение экрана, текущее время. Со временем — самое интересное: если сессию решит перехватить злоумышленник, то возникнет другое расхождение во времени между реальным клиентом и злоумышленником. Из-за изменения расхождения во времени можно будет «спалить» перехват.
По сей день использую в своих логин-формах эти наработки.
По сей день использую в своих логин-формах эти наработки.
А если «внезапно» возникнет расхождение во времени между реальным пользователем и… кем?
Помнится в далёком 2004-м году активно практиковался перевод времени для обхода «некоторых счётчиков» «некоторых программ». Настолько активно, что я задолбался писать батники (фиг с ними) и, главное, объяснять юзерам, включая юзеров, имеющих право распоряжаться сотнями миллионов рублей, как им обойти счётчик времени, чтобы сэкономить тысяч так 20 (мою тогдашнюю зарплату).
Помнится в далёком 2004-м году активно практиковался перевод времени для обхода «некоторых счётчиков» «некоторых программ». Настолько активно, что я задолбался писать батники (фиг с ними) и, главное, объяснять юзерам, включая юзеров, имеющих право распоряжаться сотнями миллионов рублей, как им обойти счётчик времени, чтобы сэкономить тысяч так 20 (мою тогдашнюю зарплату).
Заковыка в том, что Вы действовали исходя из того, что знали, какое время на машине и какое время должно быть. А как Вы узнаете, какое время на клиенте? Ведь для обхода этого препятствия (а оно не единственное из геморройных), нужно точно синхронизировать свои часы с часами удаленного клиента. Как Вы это планируете провернуть, при условии, что у Вас нет физического доступа к машине клиента? И не забываем, клиент может общаться с сервером по SSL.
Разрешение экрана — интересная мысль. Геммора взломщику добавит
Такой подход можно конечно обойти, но с определенной вероятностью — не с первого раза. А после первого раза IP попадет в бан к файрволу.
Вообще, используя весь возможный комплекс мер, задача эмуляции клиента настолько усложняется, что не каждый полезет дальше. Ну а раз полез, значит ему действительно туда надо, значит свои цели… :)
Вообще, используя весь возможный комплекс мер, задача эмуляции клиента настолько усложняется, что не каждый полезет дальше. Ну а раз полез, значит ему действительно туда надо, значит свои цели… :)
Просили передать сюда:
Если злоумышленник получил доступ к кукисам он и все стальное(предлагаемое в статье для защиты) тоже может узнать. Защиты это практически не добавит, а ложными срабатываниями пользователя мучить будет.
Если злоумышленник получил доступ к кукисам он и все стальное(предлагаемое в статье для защиты) тоже может узнать. Защиты это практически не добавит, а ложными срабатываниями пользователя мучить будет.
Ага. А железная дверь с 2-я замками не спасёт, потому что её можно взорвать. Поэтому пусть стоит деревянная на щеколде. А то ещё париться с открытием 2- замков простому хозяину квартиры…
Те, кто просили это сюда передать имеют большой опыт в угонах сессии? Думаю, что нет.
Это только в крутых американских фильмах крутой хакер, нажав пару кнопочек, ломает всю защиту. На практике, не зная всего механизма защиты, взломщик из-за всех этих наворотов, в 70%-90% случаев попалится. Пока он поймёт что к чему, его IP будет уже забанен.
Ещё раз повторяю: никто и никогда в здравом уме не будет утверждать, что в 100% случаев механизм защиты невозможно обойти. Ибо на каждую хитрую попу найдётся попа похитрее. Тем более, что теорему о бесконечных обезьянах никто не отменял. Посему и я этого не утверждаю. Вопрос безопасности в экономике: требуется заставить потенциального взломщика потратить на преодоление защиты больше средств, чем он получит в случае преодоления защиты. Поэтому взломы останутся, от этого никуда не деться. Но большинство взломщиков забьют болт на это дело и будут искать бреши в других местах.
Те, кто просили это сюда передать имеют большой опыт в угонах сессии? Думаю, что нет.
Это только в крутых американских фильмах крутой хакер, нажав пару кнопочек, ломает всю защиту. На практике, не зная всего механизма защиты, взломщик из-за всех этих наворотов, в 70%-90% случаев попалится. Пока он поймёт что к чему, его IP будет уже забанен.
Ещё раз повторяю: никто и никогда в здравом уме не будет утверждать, что в 100% случаев механизм защиты невозможно обойти. Ибо на каждую хитрую попу найдётся попа похитрее. Тем более, что теорему о бесконечных обезьянах никто не отменял. Посему и я этого не утверждаю. Вопрос безопасности в экономике: требуется заставить потенциального взломщика потратить на преодоление защиты больше средств, чем он получит в случае преодоления защиты. Поэтому взломы останутся, от этого никуда не деться. Но большинство взломщиков забьют болт на это дело и будут искать бреши в других местах.
Кто-то из коллег еще использует кукисы, как основу для защиты своих сайтов? :)
Можно как элемент, не более. И не хранить там метку типа LoginSuccsess=True…
Можно как элемент, не более. И не хранить там метку типа LoginSuccsess=True…
Я согласен, и дело не в том что это дополнительное усложнение для потенциального взломщика, а просто ненужная защита, т.к. действительно, получив куку получить наряду вместе с ней всю информацию о клиенте не видится сложным.
Тут вспомнил одну вещь: интересный способ определения браузера через javascript можно обойти: т.к. javascript выполняется в браузере, на стороне пользователя (потенциального злоумышленника), то мы можем контролировать его выполнение и, тем самым, обойти проверку (Firebug как один из вариантов). Но об этом нужно чётко знать. К тому же, обфусцированность скрипта сильно затруднит задачу.
ОС совершенно точно можно детектировать по реакции на неправильные TCP-пакеты. Возможно и семейство браузеров можно опознать по реакции на некоторые отклонения от оптимистичного сценария протокола HTTP? Такое уже не подделать, хотя никто не может помешать злоумышленнику просто иметь на готове такую же систему, как и у вас.
оптимистичного сценария протокола HTTP
Забавное словосочетание )) Оптимистичного нету. Есть RFC которые описывают, в том числе, и протокол HTTP. Что есть рекомендация, а не жёсткий свод правил.
В принципе, по такой схеме по «отпечатку пальца» определяют тип HTTP-сервера. Можно и клиента так, наверное, детектить. Просто это в голову никому не приходило. Хотя такой подход может быть неэффективным с точки зрения он-лайн сервиса, но кое-где такой подход может иметь право на жизнь.
Не знаю, не знаю… Меня лично не парит залогиниться лишний раз после обновления лисы, не настолько часто это происходит, зато я знаю что украденная кука бесполезна (камень в огород вконтакта). С другой стороны есть сайты, которые бесят своими разлогиниваниями когда из-под одного аккаунта ходим на него с женой с разных компьютеров.
Мое личное имхо: привязывать сессию надо к всему, что относительно постоянно, но количество одновременных сессий не ограничивать. Неплохо давать возможность контролировать список сессий с возможностью выключать их.
Мое личное имхо: привязывать сессию надо к всему, что относительно постоянно, но количество одновременных сессий не ограничивать. Неплохо давать возможность контролировать список сессий с возможностью выключать их.
Sign up to leave a comment.
Отслеживание параметров браузера и ОС пользователя как мера предотвращения угона аккаунтов (обновлено)