#php #mysql #security
#php #mysql #Безопасность
Вопрос:
У меня есть простая система обмена сообщениями. Будет реализован код на PHP, MySQL и, возможно, Java. Теперь я хочу защитить идентификаторы получателей. На данный момент я использую автоматически созданные первичные ключи (1, 2, 3) таблицы user. Но это, конечно, небезопасно. Поскольку все остальные идентификаторы можно угадать, считая от 1 до xxx. Итак, какова наилучшая деловая практика для защиты идентификатора. Преобразуйте его в MD5 (возможно, с помощью какого-нибудь пароля «myencryptionkey» userId —> MD5)? Если идентификатор получателя слишком легко воспроизвести, спамеры будут использовать эту систему в своих целях.
Я думаю, что это общая проблема. А также для «приглашений в дружбу». Если каждый сможет догадаться, как создаются идентификаторы, вы сможете отправлять тонны приглашений в друзья.
Еще одна идея: как насчет шифрования идентификаторов пользователей случайно созданным ключом. Я генерирую случайный ключ и сохраняю его в сеансовом файле cookie. Итак, у каждого есть другой идентификатор пользователя 123. Итак, мне нужна функция для шифрования и дешифрования с помощью заданного целого числа.
Как страницы, подобные facebook, защищают свои первичные ключи?
Ответ №1:
Идентификаторы обычно предсказуемы. Это не проблема.
Делая их непредсказуемыми, вы, по сути, делаете идентификаторы секретными. Доступ имеет тот, кто знает секрет. Это называется security by obscurity и совсем небезопасно.
Если вы хотите ограничить доступ, вам следует ввести некоторые меры контроля доступа. Например, разрешите пользователям входить в систему и предоставлять права просмотра на основе их идентификатора пользователя / роли.
Комментарии:
1. Вы правы. Я не позволю этому пользователю отправлять сообщения другим пользователям, которых нет в списке друзей. Таким образом, если кто-то манипулирует идентификатором получателя, сообщение не будет отправлено. Предположим, что измененный идентификатор пользователя не находится в дружеских отношениях, хорошо. Но что такое с приглашениями? Конечно, очень многие должны иметь возможность отправлять приглашения в друзья всем остальным. Возможно, пример обмена сообщениями был не самым удачным. Как предотвратить то, чтобы спамер / хакер мог угадать идентификаторы и отправить тонны приглашений? На мой взгляд, это можно просто сделать, зашифровав идентификаторы.
2. @brill Тогда я бы предложил просто добавить к обычным числовым идентификаторам также имя пользователя (только для ссылки на его профиль), например
example.com/profile/123slava. Шифрование не сделает ее более безопасной, вы просто потеряете производительность. Имя / фамилия пользователя будет своего рода паролем для обычного первичного ключа с наименьшими неудобствами для обычных пользователей и без потери производительности при работе с запутанными идентификаторами.
Ответ №2:
Я вижу проблему только в том случае, если в вашей системе есть дыры, которые позволяют людям использовать ваши идентификаторы, хотя я понимаю озабоченность, и это иногда приходило мне в голову, по этой причине я мог бы предложить, хотя и не обязательно быть сторонником, использовать GUID для каждого уникального ключа.
Они могут автоматически генерироваться при вставке записей и устранять фактор угадываемости.
Я бы сказал, что они также довольно значительно увеличивают размер по сравнению с целым числом — это проблематично, зависит от масштаба и других областей системы.
Комментарии:
1. Конечно, MySQL поддерживает автоматическую генерацию идентификаторов GUID для поля в качестве идентификатора, вам вообще не нужно генерировать и вставлять их самостоятельно.
2. При использовании GUID сохраняйте сопоставление GUID=> ID в отдельной таблице и сохраняйте числовые идентификаторы во всех других таблицах. Это гарантирует вам лишь минимальную потерю производительности (время на поиск GUID=> ID) вместо того, чтобы выполнять поиск на основе строк каждый раз, когда вы обращаетесь к запутанному первичному ключу.
3. @ThiefMaster: Это просто избыточность.