Начало и введение. Сам по себе протокол HTTP не предполагает никаких стандартов, с помощью которых приложение могло бы управлять сеансом пользователя. Тут дело в том, что протокол очень стар. В то время, как Вы наверное слышали, все эти фишки были совершенно не нужны. Но прошло время и в интернете стали совершать операции денежного характера все кому не лень. А, как известно там, где деньги – там и воры. И вот какие-то хитрые дяденьки понаделали различные надстройки над нашим любимым HTTP. Теперь приложение, с которым работает пользователь должно знать ответы на такие вопросы как: Где пользователь находится в текущий момент времени? Является ли текущий пользователь по-прежнему тем, кто вошёл в систему? Вопрос номер 2 наиболее актуален. Настало самое время спросить – «Ну а мы то тут причём?» Да притом, что если управление сеансом реализуется на стороне клиента (То есть на нашей стороне) то у нас есть полное право на то что бы посмотреть эту информацию. И может быть даже немного изменить ее, если потребуется. Собственно настало время ознакомить неискушенного читателя с методами управления сеансом (со стороны приложения). Атрибут сеанса Краткое описание Идентификатор пользователя Используется в тех местах, где используют базы данных. В основном реализуется это в виде последовательности чисел, в простонародии именуемой – номером. Зачастую этот самый «номер» есть номер строки базы данных, в которой храниться информация о пользователе. Пользовательская роль Эта штука определяет то, какие типы пользователей могут работать с приложением. Например, есть у нас право изменять информацию или нет. Непосредственно профиль Ну, на мой взгляд, здесь ничего интересного. В основном всякие настройки. Редко интересные данные. Имя Используется не так уж часто. Вот когда вы заходите на форум античата, Вы можете наблюдать это самое своё имя Идентификатор сеанса В этом случае – сервер назначает сеансу определённый идентификатор, который используется в течение определённого сервером времени. Я люблю порядок во всём (Родители, правда, совершенно другого мнения ) потому делим изучение предмета на несколько частей: Делай раз : Приготовление кофе. Шутка. Хотя куда уж без кофе? Для начала нам нужно определить, с чем мы непосредственно имеем дело. Как только определили – читаем дальше. Делай два: Перехватить информацию о сеансе нужного нам пользователя и изменить свою. Но для этого надо ещё отснифить чью-то сессию, что не всегда представляется возможным. Ну тут я думаю все согласны. Делай три: Путём дифференциального анализа мы можем попытаться самостоятельно попробовать изменять значение идентификатора. Эту тему я в дальнейшем опишу подробнее. Плюс в том, что ничего перехватывать не нужно. Минус в том, что может ничего не получиться. Ну, главное процесс Делай четыре: Если что-то подсказывает, что идентификатор находится в скрытом (зашифрованном) виде, то это уже немного другая тема. Можно конечно попробовать раскриптовать самому, но на этом я пока что останавливаться не буду. Едем дальше. Минус одна кружка кофе. Смотрим в исходный код страницы. Конечно, это очень маловероятно, но в скрытых полях (Нажимаем ctrl + F и ищем слово hidden) может быть что-нибудь полезное. Повторюсь – маловероятно. Хотя могут быть и такие данные как – насколько пользователь пьян (Сколько раз пароль был набран неправильно), вполне вероятно, что идентификатор сессии (устал уже от этого слова) тоже будет передаваться где-нибудь там. Куки. Тут без примера не обойтись. Смотрим. ----- Set-Cookie: autolog= dGNsb3ZlcjpydWxlenp6; expires=Sat, 01-Mar-2007 12:00:00 GMT; patch=/; domain=antichat.ru ----- Сразу понятно, что в поле autolog находится что-то кодированное. Вероятнее всего это base64. Кому интересно может и раскодировать (Специально для самых маленьких группа RuSH выпустила специальную для таких целей утилитку. ) Наиболее вероятно что это пара логин:пароль. Смотрим дальше. Нет слова secret. Значит куки передаются по незащищённому HTTP. Ну со сроком действия кукиса надеюсь всё понятно. Не всё так просто. Гадостные серверы могут генерировать уникальные идентификаторы случайным образом. Так что кроме снифинга тут ничем не поможешь. Хотя можно и брутфорсить. Но это уже без меня. Для примера, когда пользователь (дольше буду писать ХАКЕР )первый раз обращается к приложению, сервер генерирует для него специальный идентификатор, который сохраняется в чём то вроде таблицы сеансов. Тут же хранятся все сведения о сеансе, которые предоставляет этот идентификатор. Сейчас потяжелее: Теперь при каждом запросе хакером новой страницы приложение получает от клиента маркер сеанса и производит выбор соответствующих ему значений из таблицы сеансов, следовательно, пока идентификатор сеанса (Уххх. Пойду кофе заварю ещё) (Отвлёкся - Объяснял отцу его домашнее задание…) так вот, пока он (идентификатор, а не отец ) работает, приложению достаточно обратиться к проиндексированной строке таблицы сеансов (назовём её так), чтобы получить всю нужную ему информацию. С точки зрения сервера преимущество налицо – клиенту (или хакеру в нашем случае) передаётся только одно значение – следовательно, полностью сессию не отснифуеш, не отредактируешь и не подделаешь. Всё это имеет смысл только при работе с протоколом SSl. Иначе хакер может пытаться подобрать нужный идентификатор до тех пор, пока у него это не получится, если конечно идентификатор подбирается не случайным образом, а по какой-то закономерности. Даже если алгоритм и сложен, для нас закономерность всё равно лучше. Выявить её можно опять же дифференциальным анализом. Перекур и перекоф. Кто не курит – может начинать. Нет тут ничего плохого. А теперь поближе присмотримся к анализу содержимого идентификатора. Для начала нам нужно решить, что представляет наибольший интерес для нас. Инфа передаётся в одной переменной или в нескольких переменных? Текстовые или строковые идентификаторы (Я уже ненавижу это слово)? Шифруется или кодируется? (кто на данном этапе не понял разницу между шифрами и кодами – направляется в срочном порядке учить мат. часть). Существует ли опять же какая-либо закономерность? Временная отметка, например, идентифицируется по постоянно увеличивающемуся значению. Как упоминалось ранее, при кодировании каких либо значений может использоваться алгоритм base64. Если хакер имеет дело с очевидно числовым значением, то ему открывается широкое поле деятельности: Например, если идентификатор сеанса равен 123456789, то можно далее действовать так: попытаться подставить следующие значения (Если сервер без проблем принимает эти значения – то 999999 999999999 ………………. 99999999999999999999999999999 20 цифр и более - переменная имеет однозначно строковый тип. -128 127 8-битовое целое число со знаком. 0 255 8-битовое целое число без знака. -32768 32767 16-битовое целое число со знаком 0 65535 16-битовое целое число без знака -2147483648 2147483647 32-битовое целое число со знаком 0 4294967295 32-битовое целое число без знака Такая проверка даст нам дополнительную информацию о низкоуровневой архитектуре приложения. Эпилог. Он же резюме. Ну, вроде пока что всё. Если полезть дальше, то я утыкаюсь носом прямо в дебри анализа средневзвешенных значений, медиан и мод. Если кому-то интересно, то могу попробовать написать дальше. Статья получилась не совсем о взломе, но, тем не менее, даёт, как мне кажется, понятие об изучаемом предмете. Всё вышеописанное не претендует на СУПЕР новую информацию, я всего лишь хотел помочь людям, которые интересуются данной темой. Повторюсь – никогда ранее не писал статьи. Не судите строго. (c)Trampled_clover neintruder@yahoo.com