Подделка сессий не является каким-то видом атаки, это целый класс атак, нацеленных на данные пользовательской сессии. Они могут принимать ряд различных форм:
Человек посередине — атакующий читает данные сессии в момент когда они проходят мимо него по сети.
Подделка сессии — атакующий использует идентификатор сессии (возможно полученный с помощью атаки «человек посередине») для того, чтобы притвориться другим пользователем.
Примером этих двух форм будет ситуация когда атакующий, сидя в кофейне, используя локальную WiFi сеть будет ловить идентификаторы сессий. Затем эти идентификаторы будут использоваться, чтобы представиться оригинальным пользователем.
Подделка cookie — атакующий переопределяет данные (они могут быть в режиме «только для чтения») в cookie. Глава «Сессии, пользователи и регистрация» детально описывает работу cookie, одной из ярких особенностей которых является простота незаметного изменения содержимого браузером или злонамеренными пользователями.
Существует длинная история о сайтах, которые хранили cookie подобные IsLoggedIn=1 или даже LoggedInAsUser=jacob. Чрезвычайно просто воспользоваться таким подарком.
Проще говоря, не стоит доверять данным, сохранённым в cookie.
Фиксация сессии — атакующий принуждает пользователя обновить идентификатор пользовательской сессии.
Например, PHP позволяет передавать идентификаторы сессий через URL (т.е., http://example.com/?PHPSESSID=fa90197ca25f6ab40bb1374c510d7a32). Атакующий просто подставляет такой идентификатор в URL ссылки, на которую нажмёт пользователь, заставляя последнего подключиться к указанной сессии.
Фиксация сессии используется при «рыбалке», принуждая пользователя вводить свою персональную информацию в аккаунт, которым владеет атакующий. Последний может просмотреть свой аккаунт и получить введённые данные.
Отравление сессии FIXME — атакующий внедряет в пользовательскую сессию потенциально опасные данные. Обычно это происходит при отправке форм, которые использует пользователь для установки данных сессии.
Каноническим примером будет сайт, который сохраняет простые пользовательские настройки (подобные цвету фона страницы) в cookie. Атакующий может подвести пользователя к нажатию ссылки для отправки «цвета», который на самом деле содержит данные для XSS атаки. Если переданные данные не экранируются на стороне сервера, пользователь может снова внедрить вредоносный код в свою среду.
Существует целый ряд основных принципов, следование которым может защитить вас от этих атак:
Никогда не позволяйте информации о сессии быть в URL.
Среда Django для работы с сессиями, описанная в главе «Сессии», просто не позволяет так делать.
Не используйте данные в cookie напрямую. Вместо этого, храните идентификатор сессии, которая в свою очередь хранится в базе данных (например).
Если вы используете встроенную среду для работы с сессиями (т.е., request.session), это будет выполняться автоматически. Среда использует единственный cookie, в котором хранится единственный идентификатор сессии, а данные самой сессии хранятся в базе данных.
Не забывайте экранировать данные сессии, если вы отображаете их в шаблоне. Обратитесь к секции «Межсайтовый скриптинг (XSS)» и запомните, что он применяется к любой информации, которую создал пользователь, а также к любой информации, полученной от браузера. Вы должны рассматривать информацию из сессии, как информацию полученную от пользователя.
Не позволяйте атакующим перехватывать идентификаторы сессий.
Несмотря на то, что практически невозможно определить ситуацию, когда кто-то похитил идентификатор сессии, Django обладает встроенным механизмом защиты от атак прямого перебора идентификаторов сессии. Идентификатор сессии хранится в виде хэша (а не в виде последовательного числа), это затрудняет прямой перебор, а пользователь всегда получает новый идентификатор сессии, как только пытается использовать несуществующий идентификатор, что помогает избежать фиксации сессии.
Следует отметить, что ни один из этих принципов не защитит вас
от атаки «человек посередине». Этот тип атак
практически невозможно распознать. Если ваш сайт позволяет
авторизованным пользователям просматривать важные данные, вы
должны всегда передавать их с помощью
протокола HTTPS. Также, если ваш сайт использует SSL, вы
должны назначить True значению
SESSION_COOKIE_SECURE — это заставит
Django отправлять cookie с идентификатор сессии по протоколу
HTTPS.
| Пред. | Уровень выше | След. |
| Подделка HTTP запросов | Начало | Внедрение E-mail заголовка |
0 comments | Make a comment