|
|
|
| При старте приложения, авторизация в MySQL происходит автоматически при помощи прописанного в тексте сложного логина и длинного мудреного пароля, а пользователю предлагается ввести логин и пароль, который проверяется на достоверность чтением из личной таблицы в базе MySQL.
Вопрос: безопасно ли использовать такую схему ? Что-то наволит на мысль, что авторизованным доступом можно воспользоваться в обход PHP...
Данные, передаваемые через строку запроса передаю с защитной контрольной переменной, которая содержит некую манипуляцию над числовыми значениями др. переменных. На странице более 50 ссылок с передачей переменных через GET, понятно, что при таком кол-ве значений, используя регрессионный метод можно быстро подобрать линейный метод шифрования.
Вопрос: Может есть способ защиты GET с менее значительной нагрузкой на сервер, чем md5 ? | |
|
|
|
|
|
|
|
для: Duran
(10.10.2005 в 09:12)
| | а что вы именно хотите защитить при передачи get
может вы попробуете воспользоваться сессиями? | |
|
|
|
|
|
|
|
для: cernos
(10.10.2005 в 12:04)
| | GET - есть передача через строку запроса. У меня достаточно большое древовидное меню и использовать форму для выполнения запроса по нажатию на пунктик как-то не хочется.
PHP формирует строку запроса вида http://site.php?par=1&par2=2&par3=3&check=6
В данном случае, переменная check является контрольной суммой значений всех переменных, в случае подмены/утери не менее одного значения проверка check покажет ошибку. Простое сложение легко просчитывается, а использование md5 слишком накладно для большого количества записей.
Сессии в данном конкретном случае не помогут или их использование не обоснованно. | |
|
|
|
|
|
|
|
для: Duran
(10.10.2005 в 09:12)
| | Лучше действительно использовать сессии - в этом случае, все данные храняться на сервере, а между клиентом и сервером передаётся только SID, который как правило передаётся через сессионные куки (их ещё не каждый браузер предоставляет, помоему только Opera). Кроме того, сессия имеет ограниченное время жизни в отличие от авторизации по GET-параметру. | |
|
|
|
|
|
|
|
для: cheops
(10.10.2005 в 14:02)
| | Хм... в среднем около 200 позиций меню одновременно доступно пользователю, в каждой позиции 4 переменных. Вы предлагаете их в сессии запаковать ?
А что насчет авторизации ?
Она производится через сессию, но не прямым вводом пароля и логина для MySQL, а является лишь логическим ключем (провенрка наличия в таблице базы) для входа в систему.
Фактическая авторизация происходит до подачи запроса на ввод логина и пароля.
Это меня и беспокоит. | |
|
|
|
|
|
|
|
для: Duran
(10.10.2005 в 15:18)
| | Сессия вытерпит... не очень понятно... т.е. пользователь вообще не вводит ничего? А как определяется что пользователь тот, за кого он себя выдаёт - ведь у него может быть множество IP-адресов для выхода в Интернет - не очень понятен вот этот момент? | |
|
|
|
|
|
|
|
для: cheops
(10.10.2005 в 15:23)
| | :-).
Приношу извенения за не ясный вопрос :))).
Сайт предназначен для использования авторизованного доступа к данным в рамках корпоративной сети - так проще из-за политики доменной безопасности (ничего не придется устанавливать).
Существует некая таблица пользователей, в которой прописаны их логин, пароль и привилегии (в рамках приложения). При старте, происходит подключение к серверу MySQL при помощи прописанного в скрипте сложного логина и пароля (устраняет попытку подбора), затем выводится запрос на ввод логина и пароля для входа в систему. При вводе происходит проверка наличия введенных значений с данными, содержащимися в таблице авторизованного персонала. Ну далее понятно :-).
Суть вопроса вот в чем - поскольку сервер MySQL уже является авторизованным даже не введя пароля, возможно ли воспользоаться MySQL ?
На счет GET - спасибо за подсказку :)). Попробую сегодня реализовать... | |
|
|
|
|
|
|
|
для: Duran
(10.10.2005 в 17:12)
| | Вас беспокоит не найдётся ли ушлый зарегистрированный пользователь или его знакомый, который воспользуется паролем, который обнаружит дыру и потрёт всё, что нажито непосильным трудом? :))) Да это возможно при помощи SQL-инъекции - сказать является ли код дырявым или нет, можно только проанализировав его, но выкладывание его на обозрение увеличивает шансы на взлом. Если злоумышленику не доступны исходный PHP-код и структура таблиц - шансы взлома не велики, только увлечённый маньяк будет кропеть над кодом... кроме того, в рамках организации всегда проще выследить крысу, так примерно известно кто, где и когда сидит, а все оращения к серверу фиксируются в лог-файле. | |
|
|
|