Как я где-то случайно заметил, ходят споры насчёт способов авторизации пользователей. Одни считают, что можно после первой проверки заносить данные в сессию и далее просто проверять переменную сессии на существование, другие утверждают, что можно подменить идентификатор сессии и таким образом зайти через чужой идентификатор. Даём свои "за" и "против" и обосновываем.
это можно сделать всегда независимо от кол-ва проверок, если есть скарденная сессия. Главное не писать в куки пароль. А вообще, если честно, сабж вообще не понял
Сто процентно безопасно. Но я бы при логинке если авторизация прошла успешно, заносить md5 user_agent'a + соль в сессию, а уж потом сравнивать значения - тогда точно никто сессию не угонит, да и авторизация не будет слетать при смене ip.
Попробуем разобраться Для начала, определим участников: Code: Алиса - первый участник, в нашем случае - пользователь Боб - второй участник, сервер Мэллори - злоумышленник Итак, первый протокол: Code: Переменные: 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 станет известен Мэллори, он сможет отправлять и получать сообщения от имени Алисы. Перейдём ко второму протоколу: Code: Новые переменные: 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 атаки, что в большинстве случаев и нужно
О_о есть еще много способов как использовать xss.... К примену в активках реально устроить фрейм на связку, csrf... Ajax/json-hijacking, XML-injection иногда способов куча
ChaaK Угу, все это конечно очень относится к теме заданной ТСом - сессия и способы авторизации? Может вы еще перечислите вообще все виды атак? И это тоже будет очень в тему? Возможно, конечно, не правильно сформулировал - пусть будет так - "бессмысленными XSS за тем, чтобы получить сессию"
Мне показалось, я подробно объяснил. Разумеется, саму сессию получить с помощью XSS нельзя - она храниться на сервере, можно получить её идентификатор, который может быть в куках или в адресе. Как только он получен - хэш и соль становятся бессмысленными, имеет значение только строка user_agent, которую совсем несложно узнать, если это была XSS. Даже если Мэллори не знает, какой браузер использует Алиса (что уже маловероятно), он будет просто по очереди использовать разные заголовки, в порядке убывания распространённости браузера. С учётом статистики понадобится всего около 5 попыток
делать привязку к ип/индентификатор сесии, правдо при смене ип(например пров лаганул а ип динамический) надо заново логинется(кстати именно так на ачате), конечно сушествует вероятность того что угнавшему ид сесии удастся зайти с этого ипа(например одинаковый пров с nat) но это вероятность мала,имхо.