Отслеживание параметров браузера и ОС пользователя как мера предотвращения угона аккаунтов (обновлено)

    Уважаемые Хабровчане! Вчерашний вариант статьи я полагал, что находится в черновиках. И посему отобразился недописанным. Предлагаю полную, дописанную версию

    image

    Многие он-лайн сервисы стремятся обезопасить аккаунты своих пользователей самыми различными способами. Кто-то отслеживает IP-адрес, сбрасывая кукисы при его изменении (так происходит на Секлабе; вКонтакте просто просит подтвердить последние 4 цифры мобильника). У кого-то сессия живёт ограниченное время, заставляя пользователя авторизоваться снова и снова. У этих способов есть свои достоинства и недостатки. Но какой бы из механизмов не использовался, отслеживание параметров браузера и ОС пользователя придаст дополнительную защиту от угона аккаунтов (как дополнительная защита, но ни в коем случае не основная). И очень странно, что я до сих пор не смог встретить ни одного сервиса, поддерживающего этот механизм защиты.

    Задайтесь вопросом: в каких случаях при очередном посещении ресурса у пользователя кукисы будут аналогичны прошлому посещению, но изменятся данные браузера и используемой ОС (которые можно выцепить из User-Agent)? Только в 3-х случаях:

    1. Пользователь авторизовался с разных компьютеров (например, дома и на работе) и по некоторым причинам использует разные браузеры.
    2. Пользователь авторизовался с 1 компьютера в разных браузерах (этим будут страдать, пожалуй, только веб-разработчики и особо любопытные). Либо те, кто загаживает ОС непонятными фенечками (привет любителям vkSaver)
    3. У пользователя угнали сессию.

    Детектить предлагается не весь параметр User-Agent, а тип браузера (IE, FF, Chrome, Safari и т.д.) и операционную систему (Windows, Linux, MacOS). Это решит проблемы ложного срабатывания при обновлении ПО на компе пользователя.

    Да, User-Agent можно подменять. Но:
    1. Довольно часто с этим никто из угонщиков сессии не парится.
    2. Подмену User-Agent можно определить (читайте ниже как).

    Рассмотрим предлагаемый метод защиты в дополнение к имеющимся. В совокупности с классическими случаями угона сессии.



    Отслеживание изменения IP адреса


    Это хорошая практика. Но не поможет, если у пользователя нету мозгов хватило ума заходить на свой аккаунт через беспроводную сеть, где его сессию и прослушали. Либо он стал жертвой атаки «человек посередине» от злоумышленника, находящегося в одной подсети с ним у провайдера (не смейтесь, случай хоть и бородатый, но всё ещё частенько встречающийся). Скорее всего, злоумышленник не будет париться с изменением User-Agent. На то мы и рассчитываем. В итоге, доп защита срабатывает.

    Сессия живёт ограниченное время

    Ну мало того, что это неудобно для пользователя (часто авторизоваться). Так ещё и ситуация абсолютно аналогична предыдущей. И опять же: изменение User-Agent может быть чётким сигналом попытки угона сессии.

    А что делать тем, кто всё-таки пользуется разными браузерами дома и на работе?


    Как вариант, можно одну из переменных cookies генерить на основа User-Agent. Т.к. злоумышленники довольно часто копируют себе все cookies сервера без разбора, то тут-то они и попалятся, скопировав себе и переменную, привязанную для другого User-Agent.

    «Ну, подменить User-Agent труда не составит, с этим только школота недостаточно опытные взломщики не справятся»,
    — скажет тут кто-то их посетителей.

    image

    Действительно, кому нужно — тот сможет подменить. Но на помощь приходит интересный способ определения браузера через javascript. Метод очень действенный, сам проверял.
    image

    Хотя, и этот способ можно обойти: т.к. javascript выполняется в браузере, на стороне пользователя (потенциального злоумышленника), то мы можем контролировать его выполнение и, тем самым, обойти проверку (Firebug как один из вариантов). Но об этом нужно чётко знать. К тому же, обфусцированность скрипта сильно затруднит задачу.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 60

      +11
      4. Браузер в очередной раз незаметно обновился
        +2
        Значит в этот момент пользователю придётся авторизоваться заново. И в этом нету какого-то криминала…
          0
          Я не предлагаю привязываться ко всему user-agent. Предлагаю детектить использование разных браузеров (Opera, FF, Chrome) и т.д. и на различных платформах (Windows, Linux, MacOS и т.д.)
          +6
          5. Пользователь установил какую-то программу, которая изменила User-Agent.
          6. Пользователь обновил ОС
            0
            Обновил Винду до Линукса? :)
              0
              В User-Agent пишется и версия ОС, вплоть до билда. Вроде.
                0
                Что мешает отфильтровать? Парсинг строки — это примитивнейшая задача (в данном случае точно).
                  –1
                  Смысл привязываться к UA теряется. Чем больше инфы из него берём, тем сильнее безопасность (если у злоумышленника нет возможности получить UA).
                    +1
                    И тем больше ложных срабатываний. Классическая проблема найти порог срабатывания. Вспомните датчики ударов (не должны срабатывать при дребезге от звука с улицы) или датчики движущихся объектов в квартире с мелкими домашними животными (на которых также не должны срабатывать).
                      0
                      Если мы формулируем задачу в терминах User-Agent, то промежуточного порога нет. Либо полное соответствие есть, либо его нет.
                        0
                        Возможно, название статьи не шибко удачное. Но сама суть статьи проливает свет на то каким способом и что предлагается детектить.
            +2
            7. Установленное расширения браузера изменило User-Agent.
              0
              2. Пользователь авторизовался с 1 компьютера в разных браузерах (этим будут страдать, пожалуй, только веб-разработчики и особо любопытные).
              Заглючила опера, запустил хром. Ну или проще — играет в игру в %любимый браузер% открыто дофига вкладок и что бы игра не тупила открываем не его, а %любимый браузер2%/
                0
                Расскажу свою историю. На ноутбуке установлены 2 браузера. Лиса и Хром. У первого стоит настройка восстанавливать предыдущую сессию при запуске. Второй просто отрывает страницу быстрого доступа. Если нужен активный серфинг надолго — запущен FF. Если нужно что-то быстро отрыть и глянуть — запускаю Хром. Иногда увлекаюсь и открываю попутно ещё пяток вкладок.
                  +1
                  Как вариант, можно одну из переменных cookies генерить на основа User-Agent. Т.к. злоумышленники довольно часто копируют себе все cookies сервера без разбора, то тут-то они и попалятся, скопировав себе и переменную, привязанную для другого User-Agent.
                  0
                  А с какой стати кукисы на разных компьютерах у одного и того же пользователя пусть даже под одним браузером будут аналогичны? Вроде бы они в любом случае имеют встроенный параметр времени создания, который всегда будет разным, не?
                    0
                    Серверу время создания не передаётся, только имя и значение. Если алгоритм формирования значения не зависит от времени создания, агента, адреса и прочих переменных факторов, а только от постоянных (например имя пользователя), то куки будут на всех компах одинаковые. Вернее могут быть разные (срок истечения), но сервер этой разницы не увидит. Если разработчик хочет, то он вкладывает в алгоритм формирования куки переменные факторы, если не хочет — не вкладывает.
                      0
                      А, точно, я как раз скорее срок истечения имел в виду, но почему-то думал что он прозрачно передается серверу, который и принимает решение принимать/не принимать/продлять срок действия кукисов. А получается что по истечении браузер сам убивает куки и продлить их вообще ни как нельзя. Спасибо за разъяснение.
                      0
                      Пример: для авторизации вконтакте достаточно скопировать себе переменную remixsid. Остальные переменные в кукисах удаляем. И будет Вам счастье.
                      +1
                      В очередной раз изобретён алгоритм проверки «отпечатков пальцев»?
                      phpclub.ru/detail/article/sessions
                        0
                        Да. С небольшим НО: в своей статье предлагаю детектить попытку подмены user-agent
                        0
                        > этим будут страдать, пожалуй, только веб-разработчики

                        Не соглашусь, обычные пользователи достаточно часто или тыкают в первый попавшийся браузер, или действуют по принципу «повис IE — запущу FF» (и наоборот).
                          0
                          Разные браузеры хранят разные куки, а значит, в любом случае пользователь получит разные сессии.
                            0
                            Браузеры хранят, что им сервер отдаёт. Если ид сессии у сервера md5(login+remoteIp), то после логина на каждом браузере я могу между ними безболезненно переключаться.
                              0
                              Тогда уж надо md5(login), чего тут мелочиться?
                          0
                          Из-за роутера может быть несколько компьютеров с разными браузерами + телефоны + планшетники.
                            0
                            Как вариант, можно одну из переменных cookies генерить на основа User-Agent. Т.к. злоумышленники довольно часто копируют себе все cookies сервера без разбора, то тут-то они и попалятся, скопировав себе и переменную, привязанную для другого User-Agent.
                              0
                              А вот это уже интересный вариант.

                              Но с тем же успехом можно сохранять в сессию хеш от IP-адреса, например.
                                0
                                Если общий NAT то IP не поможет.
                                  0
                                  Одно другому не мешает. Если атакующий находится в одной подсети с жертвой, то IP будут одинаковые.
                                  Статья обновлена, там всё про это написано.
                              0
                              Имхо, запоминать (не важно как) User-Agent можно как подстраховку для текущей сессии по желанию пользователя. То есть если строка (её хэш) не совпали, то вылогинивать. Но только по желанию, иначе много неудобств (каждый раз логиниться) может доставить при санкционированном использовании. И пользователю не нужно объяснять в терминах User-Agent, а предложить что-то вроде «Привязывать сеанс работы к используемому браузеру. При смене браузера нужно будет ввести пароль повторно.».
                                0
                                Статья несколько обновилась. Теперь ситуация не такая ужасная )
                                0
                                В любом случае, даже если делать такую возможность, то делать ее опциональной, так как не все пользователям подойдет.
                                  0
                                  Если уж браться за безопасность в таком ключе, то стоит изучать поведение пользователей. Если при изменении IP, браузера и любых иных глобальных параметров клиента, клиент начинает сразу менять пароль, посылать почту, ставить оценки, можно задуматься о том, что аккаунт угнали и кто-то начинает его использовать в корыстных целях. Для уточнения тех же поведенческих признаков, присущих оригинальному пользователю, стоит составлять портрет пользователя (что он обычно делает и когда). В результате мы сможем определить оригинальность пользователя даже без определения параметров его подключения.
                                    +1
                                    Идея интересная. Но на практике мало приходная. Во-первых, это потребует достаточных ресурсов. Тот же ВКонтакте скорее будет тратить все ресурсы на развитие сети для привлечения большего кол-ва пользователей (или даже удержания имеющихся), нежели на вот такие вот вещи.

                                    И потом: как быть со всплесками активности, порождённых самим пользователем? Я вот по праздникам как напьюсь, так начинаю всяким людям в соц сетях писать всякую хрень ))) Можно тогда провести другую исследовательскую работу: "разлогивание в любимой соц. сети после изменения поведения в силу употребляемых накануне алкогольных напитков как мотивация к борьбе с алкоголем в странах России и СНГ"
                                      0
                                      Это верно. Но это будет поводом как раз оборвать сессию. Заодно и всякая хрень до людей не дойдет за один раз, придется второй раз сессию начинать без ограничений уже ;)
                                      0
                                      Для меня довольно частое поведение при резкой смене окружения начинать «брутфорсить» пароль, восстанавливать и менять его.
                                        0
                                        Поэтому я и предлагаю сначала составлять поведенческий портрет пользователя, а не полагаться на догмы о том, как пользователь должен себя вести.
                                          0
                                          Среднестатический или индивидуальный? Блокировать пользователя или разлогинивать?
                                            0
                                            Индивидуальный. Разлогинивать и при следующем входе капчу ему на распознание ;)
                                          0
                                          А более конкретно? Как предлагаете это всё реализовывать на практике?
                                            0
                                            Что «это»? Я имею в виду, что принятие решений об отказе в обслуживании на анализе поведения чревато большим числом ошибок второго рода — доступ санкционированный, но принимается за не таковой. Применимо, имхо, только для критических сервисов типа финансовых или других субъективно важных. Если бы не моя зависимость именно от Хабра, то давно бы плюнул на разгадывание его капчи, которую очень редко получается разгадать с первого раза. А Хромиум не считает Хабр достойным запоминания пароля.
                                        +1
                                        Я с коллегой, в далеком 2004 году, писали для СПБ ГУ ИТМО систему одноразовых пропусков, где идентифицировали пользователей по ряду параметров, формировавших отпечаток. При изменении отпечатка — сессия сбрасывалась. В отпечаток входили IP, ОС и версия, браузер и версия, разрешение экрана, текущее время. Со временем — самое интересное: если сессию решит перехватить злоумышленник, то возникнет другое расхождение во времени между реальным клиентом и злоумышленником. Из-за изменения расхождения во времени можно будет «спалить» перехват.
                                        По сей день использую в своих логин-формах эти наработки.
                                          0
                                          А если «внезапно» возникнет расхождение во времени между реальным пользователем и… кем?

                                          Помнится в далёком 2004-м году активно практиковался перевод времени для обхода «некоторых счётчиков» «некоторых программ». Настолько активно, что я задолбался писать батники (фиг с ними) и, главное, объяснять юзерам, включая юзеров, имеющих право распоряжаться сотнями миллионов рублей, как им обойти счётчик времени, чтобы сэкономить тысяч так 20 (мою тогдашнюю зарплату).
                                            0
                                            Заковыка в том, что Вы действовали исходя из того, что знали, какое время на машине и какое время должно быть. А как Вы узнаете, какое время на клиенте? Ведь для обхода этого препятствия (а оно не единственное из геморройных), нужно точно синхронизировать свои часы с часами удаленного клиента. Как Вы это планируете провернуть, при условии, что у Вас нет физического доступа к машине клиента? И не забываем, клиент может общаться с сервером по SSL.
                                            0
                                            Разрешение экрана — интересная мысль. Геммора взломщику добавит
                                              0
                                              Такой подход можно конечно обойти, но с определенной вероятностью — не с первого раза. А после первого раза IP попадет в бан к файрволу.
                                              Вообще, используя весь возможный комплекс мер, задача эмуляции клиента настолько усложняется, что не каждый полезет дальше. Ну а раз полез, значит ему действительно туда надо, значит свои цели… :)
                                            0
                                            Просили передать сюда:

                                            Если злоумышленник получил доступ к кукисам он и все стальное(предлагаемое в статье для защиты) тоже может узнать. Защиты это практически не добавит, а ложными срабатываниями пользователя мучить будет.
                                              0
                                              Ага. А железная дверь с 2-я замками не спасёт, потому что её можно взорвать. Поэтому пусть стоит деревянная на щеколде. А то ещё париться с открытием 2- замков простому хозяину квартиры…

                                              Те, кто просили это сюда передать имеют большой опыт в угонах сессии? Думаю, что нет.
                                              Это только в крутых американских фильмах крутой хакер, нажав пару кнопочек, ломает всю защиту. На практике, не зная всего механизма защиты, взломщик из-за всех этих наворотов, в 70%-90% случаев попалится. Пока он поймёт что к чему, его IP будет уже забанен.

                                              Ещё раз повторяю: никто и никогда в здравом уме не будет утверждать, что в 100% случаев механизм защиты невозможно обойти. Ибо на каждую хитрую попу найдётся попа похитрее. Тем более, что теорему о бесконечных обезьянах никто не отменял. Посему и я этого не утверждаю. Вопрос безопасности в экономике: требуется заставить потенциального взломщика потратить на преодоление защиты больше средств, чем он получит в случае преодоления защиты. Поэтому взломы останутся, от этого никуда не деться. Но большинство взломщиков забьют болт на это дело и будут искать бреши в других местах.
                                                0
                                                требуется заставить потенциального взломщика потратить на преодоление защиты больше средств, чем он получит в случае преодоления защиты


                                                Не могу поставить плюс, но полностью поддерживаю предыдущего оратора! Этому учат на уроках по информационной безопасности.
                                                0
                                                Кто-то из коллег еще использует кукисы, как основу для защиты своих сайтов? :)
                                                Можно как элемент, не более. И не хранить там метку типа LoginSuccsess=True…
                                                  0
                                                  А Вы в своих проектах кукисы вообще не используете?
                                                    0
                                                    Только для пользовательских настроек, не имеющих отношения к безопасности. Кроме галочки «Запомнить логин».
                                                    0
                                                    А вы храните идентификатор сессии пользователя где-то еще?
                                                      0
                                                      Я его идентификатор сессии пользователя не храню, его браузер хранит, если куки включены. Имелось ввиду каким образом сервер понимает — «залогинен» пользователь или нет.
                                                      0
                                                      Я согласен, и дело не в том что это дополнительное усложнение для потенциального взломщика, а просто ненужная защита, т.к. действительно, получив куку получить наряду вместе с ней всю информацию о клиенте не видится сложным.
                                                      0
                                                      Тут вспомнил одну вещь: интересный способ определения браузера через javascript можно обойти: т.к. javascript выполняется в браузере, на стороне пользователя (потенциального злоумышленника), то мы можем контролировать его выполнение и, тем самым, обойти проверку (Firebug как один из вариантов). Но об этом нужно чётко знать. К тому же, обфусцированность скрипта сильно затруднит задачу.
                                                        0
                                                        ОС совершенно точно можно детектировать по реакции на неправильные TCP-пакеты. Возможно и семейство браузеров можно опознать по реакции на некоторые отклонения от оптимистичного сценария протокола HTTP? Такое уже не подделать, хотя никто не может помешать злоумышленнику просто иметь на готове такую же систему, как и у вас.
                                                          0
                                                          оптимистичного сценария протокола HTTP

                                                          Забавное словосочетание )) Оптимистичного нету. Есть RFC которые описывают, в том числе, и протокол HTTP. Что есть рекомендация, а не жёсткий свод правил.

                                                          В принципе, по такой схеме по «отпечатку пальца» определяют тип HTTP-сервера. Можно и клиента так, наверное, детектить. Просто это в голову никому не приходило. Хотя такой подход может быть неэффективным с точки зрения он-лайн сервиса, но кое-где такой подход может иметь право на жизнь.
                                                        0
                                                        Не знаю, не знаю… Меня лично не парит залогиниться лишний раз после обновления лисы, не настолько часто это происходит, зато я знаю что украденная кука бесполезна (камень в огород вконтакта). С другой стороны есть сайты, которые бесят своими разлогиниваниями когда из-под одного аккаунта ходим на него с женой с разных компьютеров.
                                                        Мое личное имхо: привязывать сессию надо к всему, что относительно постоянно, но количество одновременных сессий не ограничивать. Неплохо давать возможность контролировать список сессий с возможностью выключать их.

                                                        Only users with full accounts can post comments. Log in, please.