авторитизация
Всем добрый день! Меня интересуют вот какой вопрос: нужно обеспечить аворатизацию пользователя при подключении к сервису; потльзователь вводит логин и пароль и затем они передаются серверу, но у меня и то и другое видно в строке браузера (...?login=123...)Как сделать чтобы скрыть эту передачу? Также, меня интересует алгоритм, по которому регистрируется пользователь и в дальнейшем происходит его идентификация, и как при выходе пользователя сервер узнает, что юзер отключился (закрыв, например, окно браузера)? Буду очень благодярен за любую помощь. Я использую JSP
По поводу передачи - POST.
Как узнаёт сервер закрыт ли браузер - читай про сессию (не студенчискую:))
integral
Также, меня интересует алгоритм, по которому регистрируется пользователь и в дальнейшем происходит его идентификация,
Значит излагаю исходя из опыта работы с PHP, аналоги в JSP уже сам найдешь, тем более алгоритм к языку ни как не привязан.
1) После ввода в форме регистрационых данных скрипт делает запрос к БД с целью поиска такого ника и пароля. Причем проверка должна вестись именно в паре! Ведь может так оказать, что такой ник окажется в базе, и пароль такой окажеться, НО! они будут принадлежать разным учетных записям. Если просто делать проверку наличия ника и пароля в базе, то может случиться, что пользователья будет авторизован, хотя такой учетной записи в БД и нет. Поэтому нужно проверять именно связку ник-пароль (т.е. аккаунт).
2) Если данные подтвержедены, то скрипт записывает в куки пользователя его имя и пароль. Но ни как информация о том, чт пользователь авторизован. Ни в ком случае нельзя писать в куки какую ни будь переменную в духе login = on, т.к. любочей человек сможет записать эту переменную себе в куки и авторизоваться на ресурсе без реальной процедуры авторизации. Поэтому нужно писать в куки именно пароль и ник. При каждом новом запуске скрипта он должен читать данные из куков, сравнивать их с данными из БД и только после этого считать пользователя авторизованные и предоставлять ему доступ. Если в куках пусто, просто оправлять его на страницу регистрации (т.е. проходим п. 1).
Но возможно ситуация, когда у пользователя куки отключены. Тогда стартуем сессию, пишем в нее ник и пароль (а так же, возможно, и другие нужные переменные), а в генерируемые URL на страницах дописываем SID сессии. После авторизации пользователь будет кликать ссылки на твоем сайте, т.е. эти страницы ты генерируешь для него скриптом, то в URL ссылок (href) дописываешь SID. При получении такого запроса от клиента ты находишь в пришедшем GET SID сессии, стартуешь её, проверяешь авторизационные данные записанные в ней.
В принципе оба способа хранения информации и принцип проверки авторизации одинаковы, только в первом случае авторизационные данных храняться в куках в открытом виде, во втором в специальном файле на сервере.
и как при выходе пользователя сервер узнает, что юзер отключился (закрыв, например, окно браузера)?
Ни как. Сам принцип, заложенный в идею клиент-серверных технологий не позволяют этого. Есть конечно постоянные открытые соединения, которые используют для чатов, но их только для чатов и применяют. Если это использовали для каждой страницы в сети, сервера бы рухнили.
Так что обычными метода это невозможно.
Только я без "кук"- сразу сделал хранение в сессии. И.. и именно с флагом, типа login=true;
У меня, по "сценарию", только один пользователь.
Я подозреваю, что при переходе со страницы на страницу id сессии в куках храниться и по этому у меня так всё здоровски работаетт. А если куки отключины, id приписывается к каждому линку автоматически или это надо как-то подкрутить-настоить?
у меня прописано на странице
session_start("MySite");
при авторизации проверяется соответственно логин и пароль,
если есть совпадение, то создается переменная, например
session_register("SesVar");
далее страницы просто проверяют зарегистрирована или нет
данная переменная
Реально этот способ обойти?
я, вот до веча, тоже мастерил с авторизацией.
Только я без "кук"- сразу сделал хранение в сессии. И.. и именно с флагом, типа login=true;
У меня, по "сценарию", только один пользователь.
Я подозреваю, что при переходе со страницы на страницу id сессии в куках храниться и по этому у меня так всё здоровски работаетт. А если куки отключины, id приписывается к каждому линку автоматически или это надо как-то подкрутить-настоить?
Именно так. Только вот какая директива отвечает за автоприклепление SID не помню, а вот за хранение SID в куках отвечает session.use_cookies.
Народ, а я делаю авторизацию так:
у меня прописано на странице
session_start("MySite");
при авторизации проверяется соответственно логин и пароль,
если есть совпадение, то создается переменная, например
session_register("SesVar");
далее страницы просто проверяют зарегистрирована или нет
данная переменная
Реально этот способ обойти?
Если это форум с поддежкой редактирования сообщений, то смысла во флаге авторизации (перменная SesVar) простонет. Насчет взломать... реально взлома вообще что угодно ;)
А реально ли взломать твой скрипт это не ясно, т.к. логика работы его неизвестна, настройски сервера тоже не ясны... может оказать, что сломать будет очень, легко, а может и так быть, что не так уж и просто.
Реально этот способ обойти?
если при передаче гетом или постом, проверяется только наличие сессии, то можно попробовать обмануть, сформировав нужный запрос (если конечно знаем какой на вид он должен быть) и подсунуть его пользователю с нужными правами (типа админа).
Наверное просто не сталкивались с уводом кук:). ИМХО всё должно хранится именно в сесси, только это сможет более или менее нормально защитить пользователя (хотя и тут есть подводные камни, но это уже из разряда "у хостера руки кривые").
Чёго то не пойму. Проходит пользователь проверку, далее в сессию ему кидается флаг "авторизован" и что? При чём тут навигация на субмитах? И ещё, попробуй ка доберись до сесси не пользуясь неверными настройками сервера и не зная её номер.
Есть понятие "время жизни сессии". По нему и определяют.
если при передаче гетом или постом, проверяется только наличие сессии, то можно попробовать обмануть, сформировав нужный запрос (если конечно знаем какой на вид он должен быть) и подсунуть его пользователю с нужными правами (типа админа).
Нельзя. Алоритм создания имен сессии таков, что переплюнет по сложности любой пользовательский пароль.
Наверное просто не сталкивались с уводом кук:).
Смотря что подразумевать под этим термином. Конкретизируй/приведи практический пример.
Чёго то не пойму.
Поясняю. Имеется SID который ты хочешь передавать через POST от одной странице к другой. При это навигацию делаем через <A>. Как при этом ты будешь передавать SID если, на сколько я помню, POST-данные передаются только при клике по INPUT type="submit"?
Шаманство с JS не берем.
Есть понятие "время жизни сессии". По нему и определяют.
Не смешивай мух и мед ;)
В такой вот формулировке "...и как при выходе пользователя сервер узнает, что юзер отключился (закрыв, например, окно браузера)?", ответ один: сервер это узнать не может ни как. Скрипт отработал, завершил работу отдав клиенту некие данные и сервет тут же "забыл" о клиете. Поэтому он ну ни как не может узать, что там клиент закрыл. Это заложено в самой логике клиент-серверной модели.
А время жизни серсии в данной контексте совершенно не причем.
Мне проводить тут дискусию о пользе XSS атак?:)
Про header() тут кто нить слышал? А вообще для них уже всё предусмотренно: есть куки - в них, нету - в url.
Собственно "отключается" он после каждого запроса. А по времени жизни определяется "теоретическое присутствие". Почему теоритическое? Да потому, что пользователь может читать боооольшуууую статью (время жизни сессии по умолчанию кажется 20 минут) и времени установленного по умолчанию может не хватить.
Мне проводить тут дискусию о пользе XSS атак?
Не припомню, что бы о таком слышал, ладно, поиском поишем потом (хотя сам всегда куки использую, да разве только я? все их юзат. Ну почти все :D ).
Про header() тут кто нить слышал? А вообще для них уже всё предусмотренно: есть куки - в них, нету - в url.
А я о чем? О том же. set_cookie выдало FALSE пишем SID в URL-у
По вопросу клиент-сервер. Давай еще раз. Вопрос:
и как при выходе пользователя сервер узнает, что юзер отключился (закрыв, например, окно браузера)?
Твой ответ? Без взяких там простанных рассуждений о времени жизни сесии. КАК конкретно он об это узнает?
Просто ждём возвращения.:)
Собственно последнее я привёл просто так. Вся сила ответа была в header() :). Веди им можно передавать POST тоже;)
Я просто сказал как об этом "узнают".
Ладно, будем считать, что куки в этом случае не главное зло. Есть дыра, через неё и лезут, просто если авторизационные данные в куках, то долучить их будет легко.
На сколько мне помниться, POST это данные отправляемы от клиента (т.е. браузера) и формировать на его стороне header мы ну как не можем. А заставлять его этого делать, это не дело.
В общем на там и сходимся, ответ на вопрос integral: Ни как. Как я говорил с самого начала.
По поводу передачи - POST.
На сколько я понимаю, тут подразумевалась передача из формы данных не через URL. Если я ошибся, то прошу автора поста меня поправить.
К теме не относится, тут человечиский фактор не обсуждается. Попрошу по существу.
т.е. тема безопасности, к теме не относится? вот это - существо?
т.е. тема безопасности, к теме не относится? вот это - существо?
Я ещё раз повторяю. Был вопрос и обсуждается он. По поводу ссылок. Если у разработчиков руки нормальные, то они делают эллементарное подтверждение действия (confirm()). Если ты можешь предложить КОНКРЕТНЫЕ действия, то создавай тему для обсуждения.
так... сессии пользователь отключить не может, поэтому давайте предположем, что отключены куки - всё, нет их в природе. Как всётаки практичнее передавать id сессии со страницы на страницу?
Один из способов стандартен: при формировании страниц через URL связаных ресурсов. Т.е. через GET.
Поясняю конкретным примером: пусть на странице у нас есть тег <a href="index.php">, т.е. ссылка со страницы регистрации на главную страницу. Пользователь прошел процесс авторизации, и мы ему возращаем страницу в коде которой не такая ссылка, а вот такого вида:
<a href="index.php?SID=sess_6a9f44e2929928b8b965c8aa4644c714>
если скрипту придет такая ссылка, он получит идентификатор сессии через метод GET. Значине этого идентификатора храниться в супер глобальном массиве $_GET['SID']. Вот по этому значению и стартуем сессию. Естественно, при этом пользователю лучше не давать такую URL кому либо, т.к. это будет означать авторизацию для любого, кто знает SID.
Как мы уже обсуждами с shaelf-ом SID в URL напрямую лучше не вбивать. Более разумно SID каким либо алгоритмом обработать и только после этого отпралять клиенту. В этом случае даже при перехвате SID хакер не получит доступ к учетке.
В этом случае даже при перехвате SID хакер не получит доступ к учетке.
хакер, может навредить учетке и без доступа к самой учетке
хакер, может навредить учетке и без доступа к самой учетке
Каким это образом?
Каким это образом?
тока вот, приводил пример shaelf - вот ссылка
тока вот, приводил пример shaelf - вот ссылка
Я ещё раз повторяю. Это относится к социальной инженерии и багам в некоторых браузерах. Не чего общего с авторизации тут нету!!! Максимум что тут можно сделать это повесить подтверждение или передавать через POST (т.к. в ссылке его потделать нельзя) всё! Это не баг или фича - это просто тупая невнимательность.
Не чего общего с авторизации тут нету!!!
имхо, тут общее есть с авто авторизацией, т.е. момент когда человек может зайти с внешнего ресурса и автоматом пройти авторизацию, тем самым подтвердить свою личность и выполнить то или иное действо.
имхо, тут общее есть с авто авторизацией, т.е. момент когда человек может зайти с внешнего ресурса и автоматом пройти авторизацию, тем самым подтвердить свою личность и выполнить то или иное действо.
Ты конкретику предложить можешь? Скажем защиту которая отличается от той, что привел тут я? Или можешь предложить способ при котором данная ссылка бы несработала (учитывай при этом удобство и доступность)?
Ты конкретику предложить можешь? Скажем защиту которая отличается от той, что привел тут я? Или можешь предложить способ при котором данная ссылка бы несработала (учитывай при этом удобство и доступность)?
передача POSTом возможно подойдет для "защиты" внутри движка, т.е. с его же страниц. а вот с внешних страниц такая защита уже не пройдет, потому как можно и POST передать, тут уже надо проверять что то типа рефера, но бывает что реферы отключены и тогда пользователь не сможет ничего передать вообще. есть вариант формировать для страницы уникальный ид и привязывать его к отправляемой форме.
+ Нельзя сформировать ссылку
- Все ссылки на редактировать/ответить должны быть в виде кнопок.
Как? Редактирование хедеров тут не рассматривается по причине, что в ссылку ты их не подсунешь.
Конкретно к какой страничке?
Теперь подумай, что проще и надёжней, на каждом "исправить", "удалить" и т.д. сделать подтверждение (подсунули ссылку, он зашёл, а там его спрашивают - "Вы действительно хотите удалить" 95% зададутся вопросом - "Что удалить?"), или это?
- Все ссылки на редактировать/ответить должны быть в виде кнопок.
ссылку на редактирование можно и гет оставить, а вот удаление обязательно пост, как и сохранение изменений после редактирования. ничего отрицательного здесь я не вижу, кнопку можно оформить как угодно, хоть картинкой, хоть текстом.
Редактирование хедеров тут не рассматривается по причине, что в ссылку ты их не подсунешь.
вовсе не обязательно редактировать хедеры. к примеру, если исправлено то все в порядке, если нет - новое сообщение.
Конкретно к какой страничке?
к каждой где есть форма отправки
Теперь подумай, что проще и надёжней, на каждом "исправить", "удалить" и т.д. сделать подтверждение (подсунули ссылку, он зашёл, а там его спрашивают - "Вы действительно хотите удалить" 95% зададутся вопросом - "Что удалить?"), или это?
т.е. ты думаешь, что нельзя будет взять ссылку уже с этой страницы подтверждения, и ее предлагать?
Не кто не говорил, что это плохо, просто это ограничивает, вот и всё.
И куда ведёт эта ссылка? Там пусто, вернее присутствует только верхнее и боковое оформление. В центре - пустота.
Возможно.
Подтверждение через JavaScript на onClick.
И куда ведёт эта ссылка? Там пусто, вернее присутствует только верхнее и боковое оформление. В центре - пустота.
сорри, вот верная ссылка
Подтверждение через JavaScript на onClick.
ровным счетом ничего не даёт
ровным счетом ничего не даёт
Спасибо. Попробую покапать в этом направлении.
2integral Ты вообще за темой следишь? Или задал вопрос и убежал?
Ты забыл одну МАЛЕНЬКУЮ незначащую вещь... :) сайты уже пишуться в первую очередь ДЛЯ ПОИСКОВИКОВ!!! а не для узверей, а твоя сешон айди в сцилках ООЧень хорошо действует на роботов... :)) По этой причине его НИКТО из серьезных проектов не использует!!!! Этот способ прокатит только для интранет сайтов!!! и только!!!!
Ты забыл одну МАЛЕНЬКУЮ незначащую вещь... :) сайты уже пишуться в первую очередь ДЛЯ ПОИСКОВИКОВ!!! а не для узверей, а твоя сешон айди в сцилках ООЧень хорошо действует на роботов... :)) По этой причине его НИКТО из серьезных проектов не использует!!!! Этот способ прокатит только для интранет сайтов!!! и только!!!!
Связь не прямая. SID в урлу дописывается только после авторизации в код страницы. Для неавторизованных пользователей (и боисковых ботов) SID-а в урле не будет.
Хм... ну а теперь ты предложи метод передачи SID от страницы к странице на сайте при условиях, что:
1) куки не используютьс по этой или иной причине;
2) SID не должен быть в URL-е.
3) Ни какого шаманства с JS (считаме, что он тоже выключен/недоступен).
4) Навигация идет через <A>.
Ты забыл одну МАЛЕНЬКУЮ незначащую вещь... :) сайты уже пишуться в первую очередь ДЛЯ ПОИСКОВИКОВ!!! а не для узверей.
Сайты для поисковиков пишутся оооочень маленькими конторами. Среднии и большие делают это для сокращения работы менеджерам и удобству клиентов, но не как не для поисковиков. Так что твоё мнение ошибочно.