Защищенная авторизация на сайте на ява-скрипт

Цитата ("tvv"):

Вот ее-то и можно перехватить снифером, если она не защищена.

там предполагается проверка по ip. если подменили ip или любым другим способом обходят эту проверку то да, дело дрянь - злоумышленник получит доступ. Можно, конечно сделать так чтобы при перехвате сессии авторизированного пользователя выкидывало, но это мало что решит. Хотя некоторый положительный момент в этом есть - пользователя можно предупредить о том, что возникла такая проблема. Он со своим паролем сможет оперативно заблокировать аккаунт и предупредить администрацию.

Цитата ("tvv"):

Выже же написали, что наибольшую опасность представляют сниферы из локалки пользователя (например домашней сети)

да я понял. но вариант с выкидыванием при перехвате сессии все равно в силе. хотя это повляет на некоторые другие аспекты... в общем все равно это все костыль

(Прошу прощения, сообщение выше нечаянно затерлось)

Цитата ("frig"):

да я понял. но вариант с выкидыванием при перехвате сессии все равно в силе.

Ну как это в силе? Система же никак не определит, что пользователь уже будет другим, подмененным. IP то же, все заголовки такие же. Соответственно никто никого никуда не выкинет.

Я думал о таком варианте. При каждом запросе страницы пользователь отдает серверу ключ, а сервер отдает клиенту кукой следующий ключ. Соответственно если в процессе кто-то загрузит страницу с текущим ключом - он получит страницу и перехватит следующий ключ. А первого пользователя выкинет, так как его ключ будет уже не действителен. проблема в том, что если произойдет некоторый сбой, пользователь отдаст свой ключ, а не получит новый, но его выкинет. Я эту ситуацию не продумывал, это первое что приходит в голову из потенциальных проблем. Ну и конечно да, сессия рвется при закрытии окошка, работаем в одно окошко и т.д.

Опасность представляют:

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

Все они имеют возможность снифить весь незащищенный трафик, и все они будут заходить на ресурс от имени жертвы под тем же IP, что и сама жертва.

Цитата ("frig"):

При каждом запросе страницы пользователь отдает серверу ключ, а сервер отдает клиенту кукой следующий ключ. Соответственно если в процессе кто-то загрузит страницу с текущим ключом - он получит страницу и перехватит следующий ключ.

А как поведет себя такая авторизация, если пользователь на одной из страниц F5 (refresh) нажмет?
А если в двух-трех табах браузера откроет разные страницы сайта?

Цитата ("tvv"):

Опасность представляют:

- незащищенные и слабо защищенные wifi сети, так как все пользователи как на ладони

по поводу админов провайдера и пользователей локалки не все так страшно сейчас - сейчас все чаще дают реальный IP, пускай и динамический и так просто его не подменить. Во всяком случае если речь о провайдерах. Если корпоративная локалка то да, там все плохо.

Цитата ("tvv"):

А как поведет себя такая авторизация, если пользователь на одной из страниц F5 (refresh) нажмет?
А если в двух-трех табах браузера откроет разные страницы сайта?

Цитата ("frig"):

Ну и конечно да, сессия рвется при закрытии окошка, работаем в одно окошко и т.д.

выкинет, само собой :-)

Цитата ("frig"):

Ну и конечно да, сессия рвется при закрытии окошка, работаем в одно окошко и т.д.
выкинет, само собой :-)

Мда... запретить пользователю табы, запретить рефреш страницы по F5, запретить кнопку Back браузера, отнять возможность ставить закладки на внутренние страницы сайта и т.д. ...
Самое интересное, что этот запрет будет чисто административным, так как технически это запретить невозможно.
Это тупиковый путь.

Цитата ("tvv"):

Это тупиковый путь.

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

Цитата ("tvv"):

Правильно, через сессионную куку. Вот ее-то и можно перехватить снифером, если она не защищена. Затем записать куку в свой браузер, и все — хакер, находящийся в локалке пользователя, уже в сессии пользователя на ресурсе.

вот по этому надо смотреть размеры экранов, ip, версию и вид браузера и т.п.

ArtPro, а поможет ли? Все эти данные передаются клиентом, а значит могут быть подделаны.

Цитата ("frig"):

ArtPro, а поможет ли? Все эти данные передаются клиентом, а значит могут быть подделаны.

если уж совсем ВСЕ, то уж ничто не поможет... если ВСЕ данные подделаны - то это клиент

Цитата ("tvv"):

Опасность представляют:

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

Цитата ("frig"):

- незащищенные и слабо защищенные wifi сети, так как все пользователи как на ладони

Т.е. опасность представляют именно те, кто может работать под тем же IP, что и настоящий пользователь. И от них все навороты в алгоритме не защищают. Навороты защищают только от тех, кто проснифает трафик пользователя и потом попытается использовать полученные данные для аутентификации с другого IP. Т.е если некий троян, проснифал трафик юзера и отправил нужные данные из этого трафика своему владельцу, то вот от этой ситуации навороты защитят. Если вероятность подобной атаки нулевая, или ничтожно мала по сравнению с вышеуказанными атаками, то смысл всех этих наворотов вообще пропадает. В остальных моментах схема будет защищать не лучше стандартной аутентификации по http.

Итого напрашивается вывод - предложенная схема на практике не даст никаких преимуществ по сравнению с обычной по http.