-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Может ли хакер эмитировать IP адрес другого посетителя?
- Автор темы izx
- Дата начала
shultz
Guest
на самом деле не только диалапщики пострадают.
существует насколько я знаю ещё и load balanced при котором IP так же меняется в процессе. То есть пока есть установленное TCP соединение, то всё ок. задумался юзер минут на сколько -то, соединение овалилось по таймауту , послал очередной запрос - а адрес у него уже другой.
некоторые (например те кто делает phpBB) решают этот вопрос проверкой совпадения не IP а подсетки. частично решает вопрос с совсем уж левыми "взломщиками", тем не менее не решает вопрос в целом.
вообще я вижу так суть. если нужно обезопаситься -пускаем всё поверх https . перехватить - слабореально. проверять тгоже ничего не надо, никаких проверок IP - хттпс сам обо всём позаботится. минус - если юзер сам где-то ссылку вывесит. но это уже его проблеммы. с таким же успехом он может и пароли свои раздавать. ну а если уж совсем надо круто сделать - можно например ему персональный сертификат (X.509) дать (юзеру) и при каждом обращении проверять соотвествие сертификата.
существует насколько я знаю ещё и load balanced при котором IP так же меняется в процессе. То есть пока есть установленное TCP соединение, то всё ок. задумался юзер минут на сколько -то, соединение овалилось по таймауту , послал очередной запрос - а адрес у него уже другой.
некоторые (например те кто делает phpBB) решают этот вопрос проверкой совпадения не IP а подсетки. частично решает вопрос с совсем уж левыми "взломщиками", тем не менее не решает вопрос в целом.
вообще я вижу так суть. если нужно обезопаситься -пускаем всё поверх https . перехватить - слабореально. проверять тгоже ничего не надо, никаких проверок IP - хттпс сам обо всём позаботится. минус - если юзер сам где-то ссылку вывесит. но это уже его проблеммы. с таким же успехом он может и пароли свои раздавать. ну а если уж совсем надо круто сделать - можно например ему персональный сертификат (X.509) дать (юзеру) и при каждом обращении проверять соотвествие сертификата.
Не пойму, я для стенки объяснял то, что было в пред. сообщении?
При старте сессии:
1. редирект для HTTP авторизации - надежное хранение сессии и пароля для проверки
2. запись параметров браузера, коих очень много и % одинаковых браузеров практически нулевой
3. пароль в обычную куку (проверять только если куки включены, а это проверять, если браузер хотя бы 2 раза передавал куки)
4. пароль в защищенную куку
При изменении любого параметра - уничтожить сессию без вопросов.
При измении IP или длительном отстуствии юзера (причем сессия не была удалена сервером) - запросить защищенную куку. Дополнительно можно запросить пароль. При это временно блокировать сессию. Еще при этом же в форме писать в hidden полях все GET/POST переменные, чтобы не потерять текущее состояние юзера и не выкидывать на главную страницу после редиректов, требующих проверки защищенной куки или ввода пароля юзера.
Таким образом, проблемы смены IP или кражы номера сессии (особенно касается тупых юзеров, которые сами суют ссылки с сессиями всем подряд) не существует вообще. Можно сидеть и каждый раз подставлять новые левые прокси. При каждом изменении сайт незаметно для юзера (если нет установки дополнительно запросить пароль) проверит пароль HTTP авторизации, пароль в обычной куке (кроме куки сессии), пароль в защищенной куке, все параметры браузера. Далее PHP скрипт выдает форму с hidden полями с поступившими после смены IP GET/POST переменными и браузер вспоминает свое предыдущее сосотояние. Так сделано у меня в чате. И работает. Взломать никакими кражами номеров сессий или IP-подменой - нельзя. Кроме как перехватить все ключи или считать их из файла сессии на диске сервера. И даже юзер не сможет "взломать" самого себя, т.к. получить текущий пароль HTTP авторизации, да еще и куки, довольно проблематично.
При старте сессии:
1. редирект для HTTP авторизации - надежное хранение сессии и пароля для проверки
2. запись параметров браузера, коих очень много и % одинаковых браузеров практически нулевой
3. пароль в обычную куку (проверять только если куки включены, а это проверять, если браузер хотя бы 2 раза передавал куки)
4. пароль в защищенную куку
При изменении любого параметра - уничтожить сессию без вопросов.
При измении IP или длительном отстуствии юзера (причем сессия не была удалена сервером) - запросить защищенную куку. Дополнительно можно запросить пароль. При это временно блокировать сессию. Еще при этом же в форме писать в hidden полях все GET/POST переменные, чтобы не потерять текущее состояние юзера и не выкидывать на главную страницу после редиректов, требующих проверки защищенной куки или ввода пароля юзера.
Таким образом, проблемы смены IP или кражы номера сессии (особенно касается тупых юзеров, которые сами суют ссылки с сессиями всем подряд) не существует вообще. Можно сидеть и каждый раз подставлять новые левые прокси. При каждом изменении сайт незаметно для юзера (если нет установки дополнительно запросить пароль) проверит пароль HTTP авторизации, пароль в обычной куке (кроме куки сессии), пароль в защищенной куке, все параметры браузера. Далее PHP скрипт выдает форму с hidden полями с поступившими после смены IP GET/POST переменными и браузер вспоминает свое предыдущее сосотояние. Так сделано у меня в чате. И работает. Взломать никакими кражами номеров сессий или IP-подменой - нельзя. Кроме как перехватить все ключи или считать их из файла сессии на диске сервера. И даже юзер не сможет "взломать" самого себя, т.к. получить текущий пароль HTTP авторизации, да еще и куки, довольно проблематично.
Yurik
/dev/null
Была тут идея, завязано правда на жабаскрипты, но теоретически дает 100% гарантию независимо от IP и перехвата трафика.
1. При вводе пароля юзером он никуда не шлется, а сохраняется в Secure куку (дополнительный параметр там есть в спецификации). Особенность secure куки - что она не шлется серверу если соединение не https. На любой странице из секурной куки жабой мы можем выцепить пароль. Таким образом получаем межскриптовое хранение пароля на клиенте.
2. На каждую страницу (ну можно не на все а только защищенные) в пхп генерим случайный хеш (его для себя запоминает в $_SESSION).
3. Броузер жабаскриптом хеширует пароль из куки и полученный от севера случайный ключ (например через md5) и передает на следующую страницу.
4. На всех защищенных страницах проверяем
и тут же делаем unset($_SESSION['previous_random_hash']) чтобы повторно не можно было послать такой запрос.
1. При вводе пароля юзером он никуда не шлется, а сохраняется в Secure куку (дополнительный параметр там есть в спецификации). Особенность secure куки - что она не шлется серверу если соединение не https. На любой странице из секурной куки жабой мы можем выцепить пароль. Таким образом получаем межскриптовое хранение пароля на клиенте.
2. На каждую страницу (ну можно не на все а только защищенные) в пхп генерим случайный хеш (его для себя запоминает в $_SESSION).
3. Броузер жабаскриптом хеширует пароль из куки и полученный от севера случайный ключ (например через md5) и передает на следующую страницу.
4. На всех защищенных страницах проверяем
PHP:
md5('пароль'.$_SESSION['previous_random_hash'])==$_POST['pass'] ($_GET)!ataMAN
Guest
Наверное, нужно было обратиться на форум ява-скрипт, но раз ты говоришь, то, наверное, знаешь..
как выцепить пароль из секурной куки на любой странице??
document.cookie ее не содержит
Yurik
/dev/null
Вот откуда это все началось, но времени и надобности тогда проверить это не было
http://phpclub.net/talk/showthread.php?s=&threadid=28653&perpage=20&pagenumber=3
Похоже что это только для ИЕ:
http://msdn.microsoft.com/workshop/author/behaviors/reference/behaviors/userdata.asp
http://msdn.microsoft.com/workshop/author/persistence/howto/sessiondata.asp
http://phpclub.net/talk/showthread.php?s=&threadid=28653&perpage=20&pagenumber=3
Похоже что это только для ИЕ:
http://msdn.microsoft.com/workshop/author/behaviors/reference/behaviors/userdata.asp
http://msdn.microsoft.com/workshop/author/persistence/howto/sessiondata.asp
!ataMAN
Guest
а какие еще есть варанты сохранения информации на клиенте без их отправки серверу??
если одно окно, то еще можно покорячиться со фреймами..
а если юзверю хочется работать с большим количеством окон??
да и чтоб работало и в нн, и в опере..
вот такие неслабые у нас запросы
если одно окно, то еще можно покорячиться со фреймами..
а если юзверю хочется работать с большим количеством окон??
да и чтоб работало и в нн, и в опере..
вот такие неслабые у нас запросы
Cid
...двинутый новичок
>а какие еще есть варанты сохранения информации на клиенте без их отправки серверу??
Ну, если говорить о некоем идеальном случае, то вариантов нет вообще. Куки пользователь может и отключить, или какой-нибудь norton personal firewall с параноидальными настройками их будет тихо грохать... Javascript также отключается по желанию......
>покорячиться со фреймами..
а если юзверю хочется работать с большим количеством окон??
ну, с этим еще можно разобраться, хотя вопрос, скорее, по Javascript'у - при создании окна присваивать ему через window.name некий уникальный GUID, передавать его в другие фреймы, а формы из них сабмитить с target=GUID_того_самого_окна
Это стандарт, работает во всех JS-comaptible браузерах, вот только если JS, опять же, не отключен
Ну, если говорить о некоем идеальном случае, то вариантов нет вообще. Куки пользователь может и отключить, или какой-нибудь norton personal firewall с параноидальными настройками их будет тихо грохать... Javascript также отключается по желанию......
>покорячиться со фреймами..
а если юзверю хочется работать с большим количеством окон??
ну, с этим еще можно разобраться, хотя вопрос, скорее, по Javascript'у - при создании окна присваивать ему через window.name некий уникальный GUID, передавать его в другие фреймы, а формы из них сабмитить с target=GUID_того_самого_окна
Это стандарт, работает во всех JS-comaptible браузерах, вот только если JS, опять же, не отключен