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

Question

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

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

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

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

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

Среда: LAMP (PHP)

Спасибо всем

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

На вашем месте я бы использовал Integer Primary Key (автоматический идентификатор) на вашем столе а также добавить GUID с уникальным ограничением и индексом по умолчанию UUID()

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

Answer 4

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

Некоторые другие параметры будут:

• Создайте случайный хеш в каждой строке (хотя это будет неприятный бессмысленный URL)
• Создайте 'slug' для каждой строки (например, "bad-idea-to-have-two-unique-ids-in"). Вы должны явно убедиться, что это уникально, например, добавив что-то еще к нему.

Answer 5

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

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

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

Answer 6

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

$id = (int)$id;.

Другой вопрос касается ограничения доступа к некоторым записям. Эту проблему вы можете решить простым редактированием запроса, добавив туда несколько правил доступа. Например, если у вас есть пользователи типа admin / editor / reader / guest, вы можете сохранить права доступа в поле 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');

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

Answer 7

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

Answer 8

Если вы хотите убедиться, что люди не просто угадывают 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 и т. Д. И т. Д.).

Answer 9

Уровень угрозы зависит от масштаба и аудитории:

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

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

Answer 10

То, что вы описываете, - это уязвимость, известная как Direct Object Reference. Это не так уж плохо, но Небезопасные прямые ссылки на объекты являются и являются # 4 в первой десятке OWASP.

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

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

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