Атака на данные сеанса или предупрежден, значит вооружен

„Для человеческой глупости нет патча.“ — Кевин Митник

Атака на данные сеанса

Это атака, направленная на получение данных пользователя. Такая атака может принимать разные формы:

• Атака с незаконным посредником т.е. атака, когда хакер злоумышленник перехватывает данные сеанса на этапе их передачи по сети.
• Перехват сеанса (session forging) это когда злоумышленник использует идентификатор сеанса (возможно полученный в ходе атаки с незаконным посредником), чтобы выдать себя за другого пользователя.
• Подделка cookie подразумевает такую атаку, при которой злоумышленник подменяет данные в cookie, которые предположительно доступны только для чтения. Мы уже обсуждали это ранее.

Напоминаю, есть множество историй о сайтах, которые хранили в cookie что-то типа IsloggedIn=1, или же LoggedAsUser=Noname…

Повторяю: НЕ ДОВЕРЯЙТЕ ДАННЫМ, ХРАНЯЩИМСЯ В COOKIE !

• Фиксация сеанса - это когда пользователя обманом заставляют установить илт переустановить идентификатор своего сеанса.

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

Например, php (просто пример) позволяет передать идентификаторы сеанса внутри URL. Если злоумышленник убедит пользователя перейти по ссылке с фиксированным идентификатором сеанса, то пользователь превратится во владельца этого сеанса.

• Модификация сеанса - допустим злоумышленник вставляет потенциально опасные данные в сеанс пользователя, как правило посредством веб-формы, при отправке которой устанавливаются сеансовые данные.

Разберем на простом примере:

Допустим имеется сайт, который хранит в cookie простые настройки пользователя(пусть это будет цвет фона). Злоумышленник может обманом заставить пользователя перейти по ссылке, якобы для того установить новый цвет. Только вместо цвета он получит сценарий, инициирующий XSS-атаку. Если значение цвета не экранируется, то вредоносный код может быть выполнен с правами данного пользователя.

Для защиты, от вышеперечисленных атак, есть ряд общих принципов:

• Никогда не включайте в URL информацию о сеансе;
• Не храните в cookie сами данные. Там должен быть только идентификатор сеанса, по которому можно получить сеансовые данные, хранящиеся на сервере.

Отмечу что сеансы, создаваемые Django(request.session) ведут себя именно так. Подсистема сеансов помещает в cookie только идентификатор, а данные сеанса хранятся в базе.

• Помешайте подделать идентификатор сеанса.

Объясняю на примере Django: у фреймворка имеется внутренняя защита от атак на сеансы методом перебора. Идентификатор сеанса - это свертки, а не последовательные числа, поэтому угадать идентификатор практически невозможно. К тому же, при получении несуществующего идентификатора сеанса пользователю немедленно выдается новый.

В заключении отмечу, что подобного вида атаки практически невозможно обнаружить. И поскольку это так, в обязательном порядке используйте HTTPS протокол, и примите максимальные меры безопасности для ваших проектов, чтобы пользователи чувствовали себя комфортно…