Защита от Http Session Hijacking

20 Мая 2011 Безопасность
2 0

Занастольгировал по русским буквам и скачал журнальчик Хакер и там прочитал, что на конференции Chaos Construction на одну из стен выводятся данные о перехваченных HTTP сессиях и это вроде бы как своеобразная стена позора. Если кто-то зашел на сайт по незащищенному каналу, то его сессия легко перехватывается и это вроде бы как позор. Интересно, для кого позор – для пользователя, или для владельцев сайтов?

Лично у меня на сервере перехват сесии возможен, потому что у нас только определенные части сайта идут по https протоколу. Там, где шифрование на фиг не нужно, его просто нет и пользователя даже выкидывает с https на нормальный http протокол. А не фиг загружать сервера своими тупыми шифрованиями там, где это не нужно. Безопасность хороша до тех пор, пока она не становится параноидальной. Так делают нормальные сайты, которые я знаю – например, ebay, amazon. Это то, что приходит мне на макушку мозга. Я как-то не вникал, но надеюсь, что большинство поступает так же.

На сайте моего клиента перехват HTTP сессии возможен. Ты можешь захватить сессию и даже по наслаждаться, что у тебя в куках стоит чужая сессия. Ты можешь погулять по сайту таким образом по открытым областям. Но стоит только зайти в защищенную область сайта, которая содержит важные для пользователя данных, как твой Http Session Hijacking итдет лесом и хакер нежно и ласково возвращается в свою родную сессию лоха позорного.

Как достигается эта защита? Банально. При входе на сайт создается два идентификатора сессии. Первый идентификатор http only и доступен по http протоколу. Второй идентификатор сессии устанавливается с флагом secure и передается только по https протоколу. Когда пользователь просто шляется по каталогу сайта, смотрит товары клиента и занимается остальной фигней, он думает, что он спиониздил с помощью Http Session Hijacking чужую сессию. Но стоит обратится к защищенной функции, как серверу отправляется https запрос в котором авторизация происходит не по http идентификатору сессию, а по защищенному https идентификатору, который передается только по протоколу https и его уже спиониздить на много сложнее.

После авторизации по защищенному идентификатору происходит проверка на соответствие https идентификатора http и если они не соответствуют в базе данных (именно соответствуют, а не равны, равными они не могут быть, потому что они разные и уникальные), то пользователю дается Отсос Петрович и сохраняется информация в логе для ФБР. А не хрен пытаться хакить чужие аккаунты. На счет ФБР конечно же шутка, но все логится на будущее и если надо, то можно заняться вычислением гада позорного.

Некоторые делают две совершенно независимые сессии для защищенного и не защищенного протокола ради защиты от Http Session Hijacking, но я такого делать не стал. Не вижу смысла заниматься такой фигней. Самое главное – правильно расставить права на все разделы сайта и правильно указать, какие должны быть открыты и подвержены атаке Session Hijacking, а какие должны быть защищены.

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым