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

[Ru}{eeZ]

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

[Pashkela]

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


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

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

[Chaak]

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

[astrologer]

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

Для начала, определим участников:
Алиса - первый участник, в нашем случае - пользователь
Боб - второй участник, сервер
Мэллори - злоумышленник

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

Переменные:

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 и соль, если они не обеспечивают дополнительную проверку?

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

[Gifts]

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

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

[Chaak]

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

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


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

[Gifts]

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

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

[astrologer]

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

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

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

[AkyHa_MaTaTa]

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