Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
Самоучитель MySQL 5. Авторы: Кузнецов М.В., Симдянов И.В. Программирование. Ступени успешной карьеры. Авторы: Кузнецов М.В., Симдянов И.В. Объектно-ориентированное программирование на PHP. Авторы: Кузнецов М.В., Симдянов И.В. PHP Puzzles. Авторы: Кузнецов М.В., Симдянов И.В. Самоучитель PHP 5 / 6 (3 издание). Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум PHP

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Подводные камни авторизации на PHP
 
 автор: Duran   (10.10.2005 в 09:12)   письмо автору
 
 

При старте приложения, авторизация в MySQL происходит автоматически при помощи прописанного в тексте сложного логина и длинного мудреного пароля, а пользователю предлагается ввести логин и пароль, который проверяется на достоверность чтением из личной таблицы в базе MySQL.
Вопрос: безопасно ли использовать такую схему ? Что-то наволит на мысль, что авторизованным доступом можно воспользоваться в обход PHP...
Данные, передаваемые через строку запроса передаю с защитной контрольной переменной, которая содержит некую манипуляцию над числовыми значениями др. переменных. На странице более 50 ссылок с передачей переменных через GET, понятно, что при таком кол-ве значений, используя регрессионный метод можно быстро подобрать линейный метод шифрования.
Вопрос: Может есть способ защиты GET с менее значительной нагрузкой на сервер, чем md5 ?

   
 
 автор: cernos   (10.10.2005 в 12:04)   письмо автору
 
   для: Duran   (10.10.2005 в 09:12)
 

а что вы именно хотите защитить при передачи get
может вы попробуете воспользоваться сессиями?

   
 
 автор: Duran   (10.10.2005 в 13:40)   письмо автору
 
   для: cernos   (10.10.2005 в 12:04)
 

GET - есть передача через строку запроса. У меня достаточно большое древовидное меню и использовать форму для выполнения запроса по нажатию на пунктик как-то не хочется.
PHP формирует строку запроса вида http://site.php?par=1&par2=2&par3=3&check=6
В данном случае, переменная check является контрольной суммой значений всех переменных, в случае подмены/утери не менее одного значения проверка check покажет ошибку. Простое сложение легко просчитывается, а использование md5 слишком накладно для большого количества записей.
Сессии в данном конкретном случае не помогут или их использование не обоснованно.

   
 
 автор: cheops   (10.10.2005 в 14:02)   письмо автору
 
   для: Duran   (10.10.2005 в 09:12)
 

Лучше действительно использовать сессии - в этом случае, все данные храняться на сервере, а между клиентом и сервером передаётся только SID, который как правило передаётся через сессионные куки (их ещё не каждый браузер предоставляет, помоему только Opera). Кроме того, сессия имеет ограниченное время жизни в отличие от авторизации по GET-параметру.

   
 
 автор: Duran   (10.10.2005 в 15:18)   письмо автору
 
   для: cheops   (10.10.2005 в 14:02)
 

Хм... в среднем около 200 позиций меню одновременно доступно пользователю, в каждой позиции 4 переменных. Вы предлагаете их в сессии запаковать ?
А что насчет авторизации ?
Она производится через сессию, но не прямым вводом пароля и логина для MySQL, а является лишь логическим ключем (провенрка наличия в таблице базы) для входа в систему.
Фактическая авторизация происходит до подачи запроса на ввод логина и пароля.
Это меня и беспокоит.

   
 
 автор: cheops   (10.10.2005 в 15:23)   письмо автору
 
   для: Duran   (10.10.2005 в 15:18)
 

Сессия вытерпит... не очень понятно... т.е. пользователь вообще не вводит ничего? А как определяется что пользователь тот, за кого он себя выдаёт - ведь у него может быть множество IP-адресов для выхода в Интернет - не очень понятен вот этот момент?

   
 
 автор: Duran   (10.10.2005 в 17:12)   письмо автору
 
   для: cheops   (10.10.2005 в 15:23)
 

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

На счет GET - спасибо за подсказку :)). Попробую сегодня реализовать...

   
 
 автор: cheops   (10.10.2005 в 20:32)   письмо автору
 
   для: Duran   (10.10.2005 в 17:12)
 

Вас беспокоит не найдётся ли ушлый зарегистрированный пользователь или его знакомый, который воспользуется паролем, который обнаружит дыру и потрёт всё, что нажито непосильным трудом? :))) Да это возможно при помощи SQL-инъекции - сказать является ли код дырявым или нет, можно только проанализировав его, но выкладывание его на обозрение увеличивает шансы на взлом. Если злоумышленику не доступны исходный PHP-код и структура таблиц - шансы взлома не велики, только увлечённый маньяк будет кропеть над кодом... кроме того, в рамках организации всегда проще выследить крысу, так примерно известно кто, где и когда сидит, а все оращения к серверу фиксируются в лог-файле.

   
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования