Главное меню
все форумы все темы форума добавить тему
Проблема флеш и безопасности сессий.
Думаю, все знакомы с механизмом сессий: на сервере создается хранилище (это может быть файл, запись в БД или memcache и. т.п.), имеющее идентификатор. В хранилище помещаются данные относящиеся к текущему клиенту и клиенту отдается идентификатор сессии. То есть этакая сейфовая ячейка с ключом на предъявителя - кто идентификатор предъявил, тот к данным доступ и имеет. То есть уязвимым местом получается идентификатор - если его удастся украсть, то получаем доступ к аккаунту пользователя.
 
Попробуем защитить сессию. Что если в сессию сохранить дополнительные данные о пользователе? Начнем с сохранения IP. Продолжая нашу сейфовую тему можно сказать что в ячейку мы положили указание работнику банка, предоставить доступ только человеку имеющему ключ и приехавшему из Нью-Бердичева. Открыли ячейку, прочитали указания, проверили паспорт - из Нью-Бердичева? - Вот вам доступ.
 
Так уже лучше. Но Нью-Бердичев - город большой... я бы даже сказал мегаполис. Людей там много... Ведь вполне может оказаться что злоумышленник, похитивший сессию, находится с ее владельцем в одной подсети. Сидят они в "условном мобильном интернете" от "условного Билайна" за одним IP в количестве миллиона человек - вполне сравнимо с населением мегаполиса Нью-Бердичев... А давайте положим в сейф еще фотографию владельца сессии? В качестве фотографии у нас будет выступать USER_AGENT передаваемый браузером. Пришел человек с ключом, открыли сейф, сравнили город, сравнили фотографию: усы, лапы и хвост на месте - даем доступ. Похожие люди, конечно, есть (USER_AGENT'ы хоть и многообразны, но все же конечны) но они должны быть родом из Нью-Бердичева (иметь определенный IP) и иметь ключ от сейфа (передать идентификатор сессии). То есть безопасность явно выше чем в первом и втором случае.
 
И вот тут нам захотелось красоты и удобства: мы решили что нам на сайте непременно нужен флеш. И пусть он обязательно взаимодействует с сервером. Это же красиво, удобно и современно. То есть наш браузер не сам отправляется в ячейку за сессией, а посылает своего знакомого - флеш-плагин. Знакомый приходит в банк, предъявляет ключ, он из Бердичева, но на фотографию ни капли не похож. Тут возможны варианты: либо ему выдают новую ячейку (но ключ-то у него от старой), либо очищают старую и разрешают пользоваться ей. Полная ерунда в общем - нам же не ячейка нужна, а данные в ней.
 
Напрашивается решение - положить в ячейку две фотографии - свою и знакомого. Да вот беда - у знакомого такая внешность неприметная, что за него может даже белый медведь сойти, не говоря уже о злоумышленнике.
 
Собственно, тут заканчивается то, что я знаю наверняка и начинаются предположения. Самый простой вариант - отключить проверку USER_AGENT. Безопасность в этом случае снижается, но зато проблемы уходят. Плохо то, что флеш может использоваться где-то в одном месте и крайне редко, а безопасность страдает везде и постоянно. Еще один вариант - выдавать флешу два ключа: идентификатор сессии и специальный ключ, говорящий о том, что его предъявитель имеет "кривой" USER_AGENT. В этом случае проверять будем только соответствие ключей. То есть приходит в банк ваш приятель, называет номер ячейки, доказывает что он из Бердичева, а когда фотография не совпадает - говорит "Я волшебное слово знаю - 'пожалуйста'". И если на обратной стороне фотографии действительно написано "пожалуйста", то даем ему доступ. Вот такую схему я, наверное, и попробую реализовать. А то постоянные ошибки ajax-лоадеров уже порядком утомили.
мне кажется, что вполне достаточно ограничиться проверкой IP:
1.ответственность за сохранность сессии должна лежать на пользователе, ибо если попа не болит, то голова ничему не учится... если спалил сессию один раз, в следующий раз будет аккуратнее.
2.какова цена данных?
2.1.если злоумышленник получит доступ к личным фоткам жертвы, см. пункт 1 - жертва виновата сама.
2.2.если злоумышленник получит список конфеток, которые любит жертва, ничего страшного и незачем заморачиваться со сверхсекъюрностью.
2.3.если речь идет о банковских счетах, тогда надо устанавливать защищенное соединение - это и будет дополнительной проверкой знакомых, родственников и бывших любовниц из Бердичева, которых мы отправили в банковскую ячейку.
Пользователь не всегда имеет возможность обезопасить себя. В случае XSS уязвимости на сайте, похитить идентификатор сессии или токен автологина можно даже без его ведома. Так что такой подход мне не кажется верным.
 
Что касается данных, то тут мое мнение таково: пользователь может потерять данные, но не должен потерять аккаунт. Я сам прекрасно понимаю ущербность подобной позиции, но на сегодняшний день она мне кажется приемлемой с точки зрения соотношения удобства и безопасности.
 
В последних ревизиях я все же модифицировал код таким образом, чтобы при несовпадении юзерагента, но присутствии правильного CSRF-токена сброса сессии не происходило. Думаю, это будет и удобно и безопасно.