Каковы некоторые методы для хранения ключей базы данных в URL

Question

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

Например,

В моей таблице 3 поля: ID:int, Title:nvarchar(5), Description:Text

Я хочу создать страницу, которая отображает запись. Что-то вроде ...

http://server/viewitem.aspx?id=1234

1. Прежде всего, кто-нибудь может уточнить, почему это плохо?

2. и во-вторых, как можно обойти использование первичных ключей в URL?

Answer 1

Я думаю, что вполне разумно использовать первичные ключи в URL.

Некоторые соображения, однако:

1) Избегайте атак с использованием SQL-инъекций. Если вы просто слепо примете значение параметра URL-адреса id и передадите его в БД, вы рискуете. Убедитесь, что вы дезинфицируете ввод, чтобы он соответствовал формату ключа, который у вас есть (например, удалите все нечисловые символы).

2) SEO. Это помогает, если ваш URL содержит некоторый контекст об элементе (например, «большой пушистый кролик», а не 1234). Это помогает поисковым системам увидеть, что ваша страница актуальна. Это также может быть полезно для ваших пользователей (из истории моего браузера я могу узнать, какая запись без какой-либо цифры).

Answer 2

По сути это не так уж и плохо, но есть некоторые предостережения.

Предостережение: кто-то может вводить разные ключи и, возможно, получать данные, которые вы не хотели / ожидаете получить. Вы можете уменьшить вероятность успеха, увеличив пространство для ключей (например, сделав идентификаторы случайными 64-битными числами).

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

Предостережение три в том, что он подвержен атакам SQL-инъекций. Но вы бы никогда не допустили этих ошибок, верно?

Answer 3

Безопасность и конфиденциальность являются основными причинами, чтобы избежать этого. Любая информация, которая выдает вашу структуру данных, является дополнительной информацией, которую хакер может использовать для доступа к вашей базе данных. Как говорит mopoke, вы также подвергаете себя атакам SQL-инъекций, которые довольно распространены и могут быть чрезвычайно вредными для вашей базы данных и приложения. С точки зрения конфиденциальности, если вы отображаете какую-либо конфиденциальную или личную информацию, любой может просто заменить номер для получения информации, и, если у вас нет механизма аутентификации, вы можете подвергнуть риску свою информацию. Кроме того, если это так просто сделать запрос к вашей базе данных, вы открываете себя для атак типа «отказ в обслуживании», когда кто-то просто перебирает URL-адреса вашего сервера, поскольку они знают, что каждый получит ответ.

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

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

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

Answer 4

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

Как они могут быть опасны? Когда пользователям разрешено обновлять или удалять принадлежащие им записи, разработчики реализуют своего рода аутентификацию, но они часто забывают , чтобы проверить, действительно ли запись принадлежит вам. Злонамеренный пользователь может создать URL-адрес типа "/questions/12345/delete", когда он заметит, что «12345» принадлежит вам, и он будет удален.

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

Иногда существуют веские причины избегать раскрытия идентификаторов в URL. В таких случаях разработчики часто генерируют случайные хэши , которые они сохраняют для каждой записи и используют их в URL. Злоумышленнику, вмешивающемуся в строку URL, будет трудно угадать хеш, принадлежащий другому пользователю.

Answer 5

Я читал об этом, искал решение, но, как говорит @Kibbee, реального консенсуса нет.

Я могу придумать несколько возможных решений:

1) Если ваша таблица использует целочисленные ключи (вероятно), добавьте цифру контрольной суммы к идентификатору. Таким образом, (простые) инъекционные атаки обычно терпят неудачу. Получив запрос, просто удалите контрольную сумму и убедитесь, что она все еще совпадает - если они не совпадают, вы знаете, что URL был подделан. Этот метод также скрывает вашу «скорость роста» (в некоторой степени).

2) При первоначальном сохранении записи в БД сохраните «вторичный ключ» или значение, которое вы с радостью считаете открытым идентификатором. Это должно быть уникальным и, как правило, непоследовательным - например, UUID / Guid или хеш (MD5) целочисленного идентификатора, например http://server/item.aspx?id=AbD3sTGgxkjero (но будьте осторожны с символами, которые не совместимы с http). В северном направлении вторичное поле нужно будет проиндексировать, и вы потеряете преимущества кластеризации, которые вы получаете в 1).

Answer 6

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

@ Джон Вирголино упомянул шифрование всей строки запроса, что может помочь в этом процессе. Однако для большинства приложений кажется, что он зашел слишком далеко.

Answer 7

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

например, скажем, у вас был интернет-магазин, в котором продавались вещи от 2 продавцов. У торговца A были предметы (1, 3, 5, 7), а у торговца B - предметы (2, 4, 5, 8).

Если я делаю покупки на сайте Продавца А и вижу: http://server/viewitem.aspx?id=1

Тогда я мог бы попытаться поиграть с ним и набрать: http://server/viewitem.aspx?id=2

Это может позволить мне получить доступ к элементу, к которому я не должен обращаться, поскольку я делаю покупки в Merchant A, а не B. В целом, позволяя пользователям возиться с подобными вещами, это может привести к проблемам безопасности. Еще один краткий пример - сотрудники, которые могут просматривать свою личную информацию (id = 382), но они вводят чужой идентификатор, чтобы перейти непосредственно к чужому профилю.

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

Один механизм - хранить информацию в сессиях, но некоторым это не нравится. Я не веб-программист, поэтому я не буду вдаваться в подробности :)

Главное, чтобы система была защищена. Никогда не доверяйте данным, полученным от пользователя.

Answer 8

1. Использование целочисленных первичных ключей в URL-адресе представляет угрозу безопасности. Для кого-то довольно легко разместить сообщение, используя любой номер. Например, при обычном использовании веб-приложения пользователь создает запись пользователя с идентификатором 45 (viewitem / id / 45). Это означает, что пользователь автоматически знает, что есть 44 других пользователя. И если у вас нет правильной системы авторизации, они могут видеть информацию другого пользователя, создав свой собственный URL (viewitem / id / 32).

2a. Используйте правильную авторизацию. 2b. Используйте GUID для первичных ключей.

Answer 9

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

Это может быть просто ItemNumber вместо Id.

Идентификатор относится к БД, а не к бизнесу / пользователю.