Плохая идея иметь два уникальных идентификатора в таблице базы данных?

Question

Я хочу, чтобы пользователи могли просматривать записи из моей базы данных, следуя URL-адресу.

Я предполагаю, что это не очень хорошая идея иметь такой URL-адрес, где идентификатор просматриваемой записи является идентификатором автоматического увеличения числа записей!

http://www.example.com/$db_record_id 

Выше предоставлена ​​информация без информации. Это правда? Не создавал бы мой собственный идентификатор для каждой строки, представляющий ту же проблему?

Есть ли лучший способ решить мою проблему.

Окружающая среда: LAMP (PHP)

Спасибо всем

Answer 1

Если бы я тебя, я хотел бы использовать в качестве первичного ключа (автоматическая ОПОЗНАВАНИЕ) на вашем столе , а также добавить GUID с уникальным индексом ограничение & на нем, по умолчанию в UUID()

Затем буровой установки вашей страницы, чтобы ввести идентификатор GUID в URL-адрес и использовать его для поиска в своей таблице.

Answer 2

Вы даете слишком мало информации для действительно полезный ответ.

• Как создается URL-адрес?
• Как программное обеспечение находит записи для отображения?

Это, я согласен, проблематично разоблачить идентификаторы, подобные этому. Решение commmon состоит в том, чтобы генерировать временные идентификаторы каждый раз, когда вы запрашиваете базу данных для набора записей, и храните временный идентификатор tempID-> real. Затем поместите эти временные идентификаторы в URL-адрес и переведите на сервер.

Answer 3

Вы даете из двух частей информации:

• легко предсказуемые URL, записи
• легко узнать, сколько записей в наборе в общем

Являются ли эти вещи проблема для вашего приложения, затем используйте что-то еще.

Вы можете использовать GUID для ключа Db, но это может иметь потенциальное влияние на производительность в больших наборах данных.

Answer 4

Ввод идентификатора записи в URL-адрес обычно не является проблемой. Например, посмотрите URL-адрес этого окна браузера, и вы увидите идентификатор этого вопроса.

Вы можете скремблировать или шифровать значение, если вы по какой-то причине не хотите, чтобы идентификатор был четко виден. Это, конечно, не безопасный метод, если вам нужно защитить некоторые записи от просмотра, тогда вы должны объединить его с какой-то аутентификацией, например, идентификатор сеанса зарегистрированного пользователя.

Редактировать:
Для правильной защиты нужно сосредоточиться на реальной проблеме. Если определенные страницы должны иметь ограниченный доступ, проблема заключается не в том, что кто-то может определить URL-адрес страницы, проблема в том, что любой может просмотреть страницу. URL-адрес всегда может быть получен каким-либо способом или другим (например, обнюхиванием пакетов), поэтому безопасность должна быть реализована каким-то другим способом.

Answer 5

Возможно, вам стоит открыть другой уникальный идентификатор, например заголовок вместо первичного ключа? Выявление вашего ПК не обязательно создает угрозу безопасности, но вы можете получить более высокий результат поиска, если вы можете открыть другой атрибут.

Answer 6

Одной из возможных проблем с этим подходом является то, что кому-то очень легко получить все страницы/записи, последовательно увеличивая идентификатор в URL-адресе. Это может быть не то, что вы хотите, однако вы не должны полагаться на использование неясных URL-адресов для обеспечения безопасности.

Некоторые другие варианты будут:

• Генерация случайных хэш на каждой строке (хотя это будет неприятный бессмысленны URL)
• Генерация «слизняка» для каждой строки (например, «плохой идеей -в-у-два-Unique-иды в). Вам нужно, очевидно, убедиться, что это уникально, например. добавив к нему что-то еще.

Answer 7

Это не очень хорошая идея, как уже сказано (вы практически разоблачаете каждую строку в таблице), и я не думаю, что это необходимо.

Я думаю, что пользователи получат эту страницу после определенного сценария (выбор элемента из списка или что-то еще), поэтому у вас будет представление страницы и контроллер (если вы пытаетесь использовать архитектуру MVC) который будет обрабатывать любую необходимую обработку и отправит на страницу просмотра, которая может быть просто www.yoursite.com/displayElement.htm

Таким образом, идентификатор просто передается как переменная сеанса и нигде не отображается.

Но на случай, если я ошибаюсь, и вы показываете какой-то каталог, чтобы пользователи могли добавлять страницы в закладки, вам просто нужно добавить механизм обфускации, который создаст сложную строку на основе ID, вид кодирования идентификатора перед отправкой его на URL-адрес и декодирование его в коде для получения фактического идентификатора.

Answer 8

Основной ключ в запросе пользователя сам по себе не уязвим. Просто введите его в целочисленное значение и все это

$id = (int)$id;.

Другой вопрос касается ограничения доступа к некоторым записям. Эта проблема вы можете решить, просто отредактировав свой запрос, добавив там некоторые правила доступа. Например, если у вас есть пользователи типа админ/редактор/чтения/гостя вы можете сохранить права доступа в поле SET и добавить в запрос условие

SELECT ... 
FROM mytable 
WHERE 
    id = (int)$id 
    AND 
    (FIND_IN_SET('admin', access) OR FIND_IN_SET('editor', access)) 

... 
if (!$fetch = mysql_fetch_acssoc($res)) 
    throw new Exception('Record not found or you have no permission to access it'); 

Так что, не волнуйтесь Abour первичных ключей - они довольно безопасно, если вы не забудете их перевести в целое число, чтобы избежать SQL-инъекций.

Answer 9

Если пользователь может просмотреть эту страницу в любом случае, я не вижу проблем с использованием идентификатора. Если они хотят получать удовольствие от изменения URL-адреса и перейти на случайные страницы, у меня не будет проблем с этим.

Если страницы не будут отслеживаться кем-либо, у меня на самом деле все равно не будет проблем с этим. Потому что, если это так, у вас должна быть какая-то проверка авторизации в любом случае, которая помешала бы им видеть страницы, которые им не разрешено видеть.

Answer 10

Что вы описываете, это уязвимость, известная как Direct Object Reference. Они не являются изначально плохими, но Insecure Direct Object References являются и являются # 4 в OWASP Top Ten.

Вы можете обеспечить прямую ссылку на объекты, проверив, что объект принадлежит текущему пользователю, если он его не отображает.

Кроме того, даже сообщение об отказе в доступе может передавать информацию. Если ваш параметр был, например, номером заказа, злоумышленник мог бы узнать, сколько заказов ваша компания имеет на самом деле, даже если вы не показываете их, просто увеличивая число, пока не получите 404.

Лично я просто использую GUID как форма ссылки на косвенные объекты, но, очевидно, не как первичный ключ в базе данных.

Answer 11

Уровень угрозы зависит от сферы применения и аудитории:

1. Является ли это внутреннее приложение падла? Если это так, вам, вероятно, не нужно беспокоиться об этом.
2. Является ли это общедоступной информацией (например, сообщениями Twitter)? Опять же, вам, вероятно, не нужно беспокоиться об этом. На самом деле, предсказуемые URL-адреса, вероятно, идеальны для связи.
3. Могут ли ваши прошедшие проверку подлинности пользователи изменить любую запись или увидеть то, что они не должны? Вы можете уменьшить этот риск, внедряя систему собственности.
4. Может ли это вызвать однократное действие или уязвимость XSS? Если можете, вы делаете это неправильно.

В целом, я выступаю за предсказуемые URL. При этом важно подумать о том, как их можно использовать и кто их видит.

Answer 12

Если вы хотите убедиться, что люди не просто угадывают URL-адреса, то вот простой подход. Это никоим образом не является безопасным (т. Е. Не используйте этот метод для проверки доступа), но он будет следить за тем, чтобы вы не могли просто ввести случайный URL-адрес и получить sendt на эту страницу.

Дополнить идентификатор другой информацией в URL-адресе. Я предлагаю соленый хэш идентификатора.

При создании URL:

$id = 5; 
$hash = md5($id . "MY_SALT_VALUE"); 
$url = "/$id/$hash"; 

И при отображении записи:

$params = explode(',', $_SERVER['REQUEST_URL']); 
$id = $params[0]; 
$hash = $params[1]; 
if($hash != md5($id ."MY_SALT_VALUE")) { 
    die('Uh oh! You guessed the URL, didn\'t you! Bad user!'); 
} 
$data = $MyModel->load($id); 
if(!$data) { 
    die('No such record'); 
} 
DisplayModel($data); 

Конечно, это макет (говорить слишком много сообщений об ошибках, просто die() ИНГ вместо собственно 404 страницы и т. д. и т. д.).