Я должен затенить значения первичного ключа?
Я создаю веб-приложение, где фронтэнд является высокоспециализированной поисковой системой. Поиск обрабатывается в основном URL, и пользователь выдан к подкаталогу, когда они нажимают на результат поиска для более подробного дисплея. Эта передача делается как ПОЛУЧИТЬ запрос с первичным ключом, передаваемым в строке запроса. Я, кажется, вспоминаю чтение где-нибудь, что представляющий первичные ключи пользователю не была хорошая идея, таким образом, я решил реализовать обратимое шифрование.
Я начинаю задаваться вопросом, параноик ли я просто. Обратимое шифрование (base64), вероятно, легко повреждается кем-либо, кто хочет попробовать, делает URL очень ужасными, и также дольше, чем они иначе были бы. Я должен просто отбросить шифрование и представить мои первичные ключи ясное?
8 ответов
То, что вы делаете, в основном обфускация. Обратимо зашифрованный (а base64 на самом деле не считается шифрованием) первичный ключ по-прежнему остается первичным ключом.
То, что вы читали, сводится к следующему: вы обычно не хотите, чтобы ваши первичные ключи имели какое-либо значение вне системы. Это называется техническим первичным ключом , а не естественным первичным ключом . Вот почему вы можете использовать поле автоматического номера для идентификатора пациента, а не SSN (который называется естественным первичным ключом ).
Технические первичные ключи обычно предпочтительнее естественных первичных ключей потому что вещи, которые кажутся постоянными, меняются, и это может вызвать проблемы. Даже страны могут возникнуть и прекратить свое существование.
Если у вас есть технические первичные ключи, вы не хотите делать их де-факто естественными первичными ключами, придавая им значение, которого у них нет. Я думаю, что в URL-адрес можно указать первичный ключ, но безопасность - это отдельная тема. Если кто-то может изменить этот URL-адрес и получить доступ к чему-то, к чему у него не должно быть доступа, то это проблема безопасности, и ее нужно решать с помощью аутентификации и авторизации.
Некоторые будут утверждать, что пользователи никогда не должны их видеть. Не думаю, что вам нужно заходить так далеко.
Это проблема безопасности, и ее необходимо обрабатывать путем аутентификации и авторизации.Некоторые утверждают, что они никогда не должны быть видны пользователям. Не думаю, что вам нужно заходить так далеко.
Это проблема безопасности, и она должна решаться посредством аутентификации и авторизации.Некоторые утверждают, что они никогда не должны быть видны пользователям. Не думаю, что вам нужно заходить так далеко.
Просто отправьте первичные ключи. Пока ваши операции с базой данных изолированы от пользовательского интерфейса, это не проблема.
Если вы беспокоитесь о том, что кто-то изменит URL-адрес на попробуйте посмотреть на другие значения, тогда, возможно, вам нужно будет взглянуть на генерацию токенов.
Например, вместо того, чтобы давать пользователю значение «SearchID», вы даете ему SearchToken, который представляет собой некоторое длинное уникальное псевдослучайное значение (Read: GUID), которое вы затем сопоставляете с SearchID внутренне.
Конечно, ты » Мне также необходимо применить безопасность сеанса и программное обеспечение, потому что даже уникальный URL-адрес с непоследовательным идентификатором не защищен от перехвата каким-либо образом между вашим сервером и пользователем.
Об опасностях раскрытия первичного ключа вы можете прочитать " автоинкремент считается вредным ", Джошуа Шахтер.
URL-адреса, содержащие идентификатор, будут подвела вас по трем причинам.
Во-первых, указан URL-адрес для какой-то объект, вы можете выяснить URL-адреса созданных объектов вокруг него. Это показывает количество объекты в вашей базе данных в возможные конкуренты или другие люди, которых вы могли бы не хочу иметь эту информацию (как классно продемонстрированный союзниками угадать уровень производства немецких танков глядя на серийные номера.)
Во-вторых, в какой-то момент какой-нибудь рывок получить идею написать сценарий оболочки с помощью цикла for и попытаться получить каждый отдельный объект из вашей системы; этот определенно неинтересно.
Наконец, в случае с пользователями, это позволяет людям выводить своего рода социальная иерархия. Засвидетельствуйте частые угон и / или взлом высокопрестижные низкоразрядные идентификаторы ICQ.
Если вы пытаетесь защитить ввод запроса к базе данных, просто используйте параметризованные запросы. Нет вообще никаких причин скрывать первичные ключи, если ими манипулирует публика.
Когда вы видите base64 в URL-адресе, вы практически гарантированно, что разработчики этого сайта не знают, что они делают, и сайт уязвимы.
Если вы скрываете первичные ключи из соображений безопасности, не делайте этого. Это называется безопасностью через неизвестность, и есть способ лучше. Сказав это, есть по крайней мере одна веская причина для сокрытия первичных ключей, а именно, чтобы кто-то не мог очистить весь ваш контент, просто проверив строку запроса в URL-адресе и определив, что они могут просто увеличить значение идентификатора и удалить каждую запись. Решительный скребок все еще может обнаружить ваши способы скрытия и сделать это, несмотря на все ваши усилия, но, по крайней мере, вы не упростили эту задачу.
Для ваших целей (создание поисковой системы) преимущества шифрования первичных ключей базы данных с точки зрения безопасности незначительны. Кодировка Base64 - это не шифрование - это безопасность через неясность, и она даже не станет препятствием для злоумышленника.
URL-адреса, включающие идентификатор, будут подведут вас по трем причинам.
Неправильно, неправильно, неправильно.
Во-первых - каждый запрос должен быть проверен, независимо от того, приходит ли он в виде HTTP GET с идентификатором, или POST, или вызова веб-сервиса.
Во-вторых - правильно сделанный веб-сайт нуждается в защите от ботов, которая основывается на отслеживании IP-адресов и анализе частоты запросов; скрытие идентификаторов может помешать некоторым людям написать shell-скрипт для получения последовательности объектов, но есть и другие способы эксплуатировать веб-сайт с помощью атаки типа bruteforce.
Третье - идентификаторы ICQ ценны, но только потому, что они связаны с пользователями и являются основным средством идентификации пользователя; это единственный в своем роде подход к аутентификации пользователя, не используемый ни одним другим сервисом, программой или веб-сайтом.
Итак, в заключение... Да, вам нужно беспокоиться о скреперах, DDOS-атаках, защите данных и куче других вещей, но сокрытие идентификаторов не решит ни одну из этих проблем должным образом.