 |
||||||
 |
 |
|||||
 |
|
 |
|
 |
 |
 |
|
|||
 |
|||
 |
|||
 |
|||
 |
|||
Читатели моего блога достаточно компетентны в сетевых технологиях, но всё-таки для начала приведу пару слов о принципах действия динамических веб-сайтов. Когда вы открываете подобный сайт (скажем, интернет-магазин), он автоматически присваивает вам случайный номер, называемый идентификатором сессии (этот номер сохраняется в cookie браузера и передаётся сайту при открытии каждой страницы). Он служит как опознавательный знак для веб-сайта, дабы он мог отличать вас, когда вы переходите от страницы к странице, и на каждой странице отображать, к примеру, ваше персональное меню или корзину с покупками, выбранными ранее. Вся эта информация -- персональное меню, покупки -- размещается на диске сервера во временном файле, одноимённом с номером сессии. К сожалению, за всем этим удобством скрывается угроза безопасности: если злоумышленник сумеет тем или иным образом узнать номер вашей текущей сессии, он сможет передать его с собственного компьютера и эффективно выдать себя за вас и, как следствие, получить доступ ко всем вашим приватным данным на данном веб-сайте. В заключение отмечу, что однажды присвоенная сессия действует не вечно: если вы не проявляете активность на сайте в течение некоторого времени (обычно, часа), она аннулируется; однако файл сессии может быть удалён очень нескоро! Итак, возвращаемся к поставленной задаче. Поскольку при авторизации на сайте пароль открыто передаётся через Сеть, наблюдателю на канале связи ничего не стоит перехватить его, чтобы в дальнейшем входить на сайт под именем легитимного пользователя. Таким образом, цели, преследуемые в данной работе: - защита от пассивных атак, т.е. простого прослушивания трафика между пользователем и сайтом с целью перехвата пароля; - защита от активных атак, т.е. более открытых действий злоумышленника, направленных, к примеру, на захват текущей авторизованной сессии. Перед потенциальным злоумышленником также стоят две альтернативные цели: - задача-минимум: захватить сессию легитимного пользователя; - задача-максимум: раскрыть пароль пользователя. Наиболее элегантное и простое решение здесь -- SSL, обеспечивающий шифрование всего трафика между пользователем и сайтом на транспортном уровне, а также аутентификацию сайта. Как уже отмечалось, это сравнительно дорого... Альтернатива На этапе аутентификации пользователя для входа на сайт можно применить простой протокол "запрос-ответ", не раскрывающий пароль на канале связи. Для этого потребуется реализовать миниатюрное приложение на javascript, обеспечивающее необходимые преобразования на стороне пользователя. Как часто бывает в таких описаниях, роль пользователя выполнит Анна, а сервера -- Борис; числовые индексы переменных обозначают номер этапа, значение которого принимает переменная. Протокол может выглядеть так: 1) Анна инициирует начало протокола (для этого ей нужно открыть страницу с формой для ввода имени и пароля). Вместе с этим, Борис определяет IP-адрес Анны (который ещё пригодится), а также присваивает ей (передаёт) идентификатор неавторизованной гостевой сессии -- sid. 2) Далее Борис генерирует и отправляет Анне r = H(k,t1,ip1), где H -- операция хэширования, k -- секретный показатель, известный только Борису, t1 -- метка времени начала исполнения протокола, ip1 -- IP-адрес Анны, определённый на этапе 1. Кроме того, Борис сохраняет ip1 и t1 в переменных сессии Анны.3) Анна вычисляет h = H(r,u,p), где u и p -- её логин и пароль, соответственно.4) Анна возвращает Борису h,u,sid1 5) Время поступления ответа на этапе 4 сравнивается с меткой времени, сохранённой на этапе 2. Если ответ получен в допустимом интервале, исполнение протокола продолжается. 6) Борис по u извлекает из базы данных пароль Анны p. 7) Борис самостоятельно вычисляет h' = H( H(k,t1,ip4), u4, p6) 8) Борис сравнивает h, полученный от Анны на этапе 4, с h', вычисленный им самим на этапе 7. 9) При их соответствии Борис генерирует новый идентификатор авторизованной сессии sid', помещает ip4 в переменные сессии и сообщает sid' Анне. Векторы атак Попробуем атаковать протокол с различных направлений. В роли пользователя снова выступит Анна, сервером будет Борис, Николай -- пассивным наблюдателем, Виктор -- активным взломщиком. На начальном этапе Николай, находясь на канале связи между Борисом и Анной, может определить идентификатор сессии, присвоенный Анне. Это не даёт ему преимуществ, поскольку пока это сессия неавторизованного гостя, не обладающего привилегиями. Этап 2, опять же, не сообщает Николаю ничего полезного. Хотя он знает IP Анны и может угадать метку времени, он не имеет представления о секретном ключе Бориса, используемом для имитозащиты передаваемых данных. Когда на этапе 4 Анна возвращает свои подсчёты серверу, Николай видит лишь очередной хэш, не несущий информации о пароле. Хотя ему известны и значение r (перехваченное на этапе 2), и логин Анны, он никогда не видел её пароль, так что его восстановление из h равносильно (в идеале) полному перебору результата функции хэширования. Получается, что у Николая не слишком много шансов определить пароль Анны, и наша основная задача -- скрыть пароль на канале связи -- выполнена. Но может быть взлом удастся более смелому Виктору, обладающему также более серьёзными ресурсами для нападения? У него есть несколько вариантов. Например, он мог бы попытаться подделать значение h, передаваемое на этапе 4, но, не зная пароль Анны, это бесперспективно -- Борис выявит расхождения в пересчитанном h' на восьмом этапе. Виктор мог бы вклиниться в протокол на этапе 9 и перехватить идентификатор авторизованной сессии. Однако если Анна включила в настройках openSpace привязку сессии к IP, такая смена адреса (поскольку легитимный адрес Анны Борис сохранил в переменных сессии) тут же приведёт к инвалидации сессии. Казалось бы, вариантов нет. Но вместо всего этого шаманства Виктор пойдёт самым простым путём, известным как "атака гроссмейстера". Расположив свой компьютер на канале связи между Борисом и Анной, он атакует протокол с самого первого этапа. Когда Анна запрашивает с сайта страницу логина (инициирует протокол), Виктор перехватывает запрос и пересылает его от своего имени (т.е. со своего IP). В результате Борис назначает Виктору гостевой идентификатор sid Анны. Виктор, притворившись Борисом, пересылает идентичные данные от себя к Анне (запрошенную страницу и sid). Анна вычисляет ответ на запрос Бориса и возвращает его наряду с остальными данными. Виктор вновь пассивно ретранслирует эту информацию Борису. Тот проверяет правильность ответа, используя IP, хранящийся в сессии и убеждается в том, что ответ получен он Анны, ведь пароль должна была знать только она. Следовательно, Борис создаёт авторизованную сессию и возвращает её номер источнику запроса -- Виктору! Здесь нет возможности определить, что источник не тот, за кого себя выдаёт; и даже после авторизации сессия не будет прервана, поскольку IP источника (Виктора) идентичен на всех этапах протокола. Чтобы успешно завершить нападение Виктор лишь должен вернуть Анне от имени Бориса какую-нибудь стандартную ошибку HTTP и прервать связь, чтобы она списала всё это на проблемы с сервером. Контрзащита К сожалению, я не вижу иного пути улучшить этот протокол, кроме следующего: 1) Анна инициирует исполнение протокола. Борис узнаёт её IP и присваивает ей гостевой sid. 2) Борис посылает r = H(k,t1) 3) Анна вычисляет и возвращает Борису h = H(r,u,p,ip), u, sid1, где ip -- известный ей самой IP-адрес её машины.4) Борис по u извлекает из базы данных пароль Анны p. 5) Борис вычисляет h' = H( H(k,t1), u3, p4, ip3), используя для ip3 источник ответа, полученного на этапе 3.6) Борис сравнивает h и h', при соответствии которых помещает ip3 в переменные новой авторизованной сессии, а её идентификатор возвращает Анне. Что будет, если и теперь Виктор попытается транслировать сообщения между участниками протокола, а в конце захватить авторизованную сессию? На этапе 3 он перехватывает значение h. Не зная пароля Анны он не может изменить его, поэтому передаёт Борису в исходном виде. Разумеется, Борис получает IP Виктора в качестве источника ответа и использует этот IP на этапе 5, повторно вычисляя хэш. В итоге, на этапе 6 Борис обнаруживает расхождения и прерывает протокол. Проблема здесь в том, что для данного протокола любой посредник -- будь то легитимный прокси, NAT или исходящий узел сети Tor -- также расценивается нападающим. В этом случае можно, к примеру, предоставить Анне самостоятельно указать на третьем этапе IP, соединение с которого Борис примет. В общем, это просто тренировка для ума, и весьма маловероятно, что подобное будет реализовано на практике. Но всё же, какие ещё есть недостатки или потенциал для улучшения? |
SSL защищает также при необходимости и от манипуляции с IP адресами в сети (что не так сложно как кажется). Виктор может использовать слабости в DNS, захват серверов провайдера, чтобы ретранслировать не только подставные данные, но и IP. Два Виктора могут даже проложить туннель "псевдоАнна-псевдоБоб" через Интернет, где манипулировать виртуальными IP, как им вздумается, так чтобы ни Анна, ни Борис ничего не заподозрили. //unknown |
||
|
||
|
||
Да, полагаю, это сущностное ограничение протоколов, не прибегающих к асимметричной криптографии. Кроме того, преследовалась потребность, чтобы клиентская часть была реализуема на javascript. Совершенно верно. Более того, раз Анна соединяется с неаутентифициророванным сервером, то Виктор может запросто подсунуть ей незаверенный сертификатом javascript, который выдаст ему все пароли, даже не разрушая сам криптопротокол. |
||
|
||
Виктор может запросто подсунуть ей незаверенный сертификатом javascript, который выдаст ему все пароли, даже не разрушая сам криптопротокол. Точно. Я исходил из того, что при необходимости Анна сможет провести аудит полученного javascript'а, только забыл отметить это в описании. |
||
http://www.pgpru.com/Форум/Офф-топик/ЗащитаHTTP-авторизацииБезSSL Реализация: http://www.pgpru.com/Библиотека/Черновики/ПротоколHttpАвторизации |
||
 |
