Форум АНТИЧАТ - Проверка на существование и проверка данных (логинка и сессия)

Форум АНТИЧАТ (https://forum.antichat.xyz/index.php)

- PHP, PERL, MySQL, JavaScript (https://forum.antichat.xyz/forumdisplay.php?f=37)

Проверка на существование и проверка данных (логинка и сессия)

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

Цитата:

можно подменить идентификатор сессии и таким образом зайти через чужой идентификатор

это можно сделать всегда независимо от кол-ва проверок, если есть скарденная сессия.
Главное не писать в куки пароль.

А вообще, если честно, сабж вообще не понял

Сто процентно безопасно. Но я бы при логинке если авторизация прошла успешно, заносить md5 user_agent'a + соль в сессию, а уж потом сравнивать значения - тогда точно никто сессию не угонит, да и авторизация не будет слетать при смене ip.

Попробуем разобраться :)

Для начала, определим участников:

Код:

    Алиса   - первый участник, в нашем случае - пользователь

    Боб     - второй участник, сервер

    Мэллори - злоумышленник

Итак, первый протокол:

Код:



  Переменные:

  

    sess_id - идентификатор сессии

    check   - процедура проверки данных

    

    

  Протокол:

  

      Алиса                        Боб

     -------                      -----

     

     name, pass         =>

      

                                  check(name, pass)

                        <=        sess_id

      

      

     sess_id            =>

    

                                  check(sess_id)

                        <=        data

Несложно заметить, что данные проверяются только в первый раз, после чего безопасность протокола основана только на
идентификаторе сессии (sess_id).

Насколько надёжен такой подход? По умолчанию, размер sess_id - 128 бит, а значит, чтобы найти его методом перебора, понадобится около 2^128 взаимодействий с удалённой системой. Это не кажется очень реалистичным.

С другой стороны, если sess_id станет известен Мэллори, он сможет отправлять и получать сообщения от имени Алисы.

Перейдём ко второму протоколу:

Код:

  

  Новые переменные:

    

    session - данные сессии

    salt    - случайная соль

    

    

  Протокол:

  

      Алиса                                 Боб

     -------                               -----

     

     name, pass, user_agent       =>

                                           check(name, pass)

                                           

                                           salt = random()

                                           session.hash = md5(concat(user_agent, salt))

                                           

                                  <=       sess_id

      

     

     sess_id, user_agent          =>

     

                                           check(sess_id, session.hash)

                                  <=       data

Теперь, казалось бы, надёжность должна значительно повыситься, и даже при компрометации sess_id система останется безопасной.

Но рассмотрим то, как осуществляется проверка.
При каждом запросе Алиса будет отсылать sess_id, которому соответствует некий набор данных на сервере - session. Чтобы проверить, действительно ли это её сессия, необходимо вычислить хэш и сравнить его с сохранённым.

Для этого, в свою очередь, нужно получить ту самую соль, которая была использована при авторизации. Проблема в том, что единственное, что связывает "ту" Алису и "эту" и говорит, какую соль использовать - это sess_id. Замкнутый круг.

Зачем же здесь тогда функция md5 и соль, если они не обеспечивают дополнительную проверку?

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

astrologer При нормальном разграничении прав - Мэллори не сможет прочитать файл сессии. Если же у Мэллори будут права на чтение того же пользователя, что и пользователь данного хостинга - то прочитать можно гораздо более интересные файлы, а это уже полная компрометация сервера

Хэш от юзерагента+соль делает бессмысленным XSS атаки, что в большинстве случаев и нужно

Цитата:

Сообщение от Gifts

О_о есть еще много способов как использовать xss.... К примену в активках реально устроить фрейм на связку, csrf... Ajax/json-hijacking, XML-injection иногда :) способов куча

ChaaK Угу, все это конечно очень относится к теме заданной ТСом - сессия и способы авторизации? Может вы еще перечислите вообще все виды атак? И это тоже будет очень в тему?

Возможно, конечно, не правильно сформулировал - пусть будет так - "бессмысленными XSS за тем, чтобы получить сессию"

Цитата:

Сообщение от Gifts

Возможно, конечно, не правильно сформулировал - пусть будет так - "бессмысленными XSS за тем, чтобы получить сессию"

Мне показалось, я подробно объяснил. Разумеется, саму сессию получить с помощью XSS нельзя - она храниться на сервере, можно получить её идентификатор, который может быть в куках или в адресе.

Как только он получен - хэш и соль становятся бессмысленными, имеет значение только строка user_agent, которую совсем несложно узнать, если это была XSS.

Даже если Мэллори не знает, какой браузер использует Алиса (что уже маловероятно), он будет просто по очереди использовать разные заголовки, в порядке убывания распространённости браузера. С учётом статистики понадобится всего около 5 попыток :)

делать привязку к ип/индентификатор сесии, правдо при смене ип(например пров лаганул а ип динамический) надо заново логинется(кстати именно так на ачате), конечно сушествует вероятность того что угнавшему ид сесии удастся зайти с этого ипа(например одинаковый пров с nat) но это вероятность мала,имхо.