Я должен запутывать базу данных ID от своих пользователей?
Популярный факторный ответ здесь является чем-то вроде игрушечного ответа. Да, памятка полезна для повторных вызовов этой функции, но связь тривиальна - в случае «факториала печати (N) для 0..M» вы просто повторно используете последнее значение.
Многие из других примеров здесь просто «кеширование». Это полезно, но игнорирует удивительные алгоритмические значения, которые несет для меня слово «мемоизация».
Гораздо более интересными являются случаи, когда разные ветви одного вызова рекурсивной функции сталкиваются с идентичными подзадачами, но в нетривиальном шаблоне, так что на самом деле индексация в некотором кеше действительно полезна.
Например, рассмотрим n размерных массивов целых чисел, чьи абсолютные значения суммируются с k. Например. для n = 3 примерами могут быть k = 5 [1, -4,0], [3, -1,1], [5,0,0], [0,5,0]. Пусть V (n, k) будет числом возможных уникальных массивов для данного n, k. Его определение:
V(n,0)=1; V(0,k)=0; V(n,k) = V(n-1,k) + V(n,k-1) + V(n-1,k-1);
Эта функция дает 102 для n = 3, k = 5.
Без запоминания это быстро становится очень медленным для вычисления даже для довольно скромных чисел. Если вы визуализируете обработку в виде дерева, каждый узел вызывает вызов V (), расширяющийся до трех дочерних элементов, у вас будет 186,268,135,991,213,676,920,832 V (n, 0) = 1, в вычислениях V (32,32) ... Реализуется наивно эта функция быстро становится неисчислимой на доступном оборудовании.
Но многие из дочерних ветвей в дереве являются точными дубликатами друг друга, хотя не каким-то тривиальным способом, который можно легко устранить, как факториальную функцию. С помощью памятки мы можем объединить все эти дубликаты. Фактически, с запоминанием V (32,32) выполняет только V () 1024 (n * m) раз, что является ускорением в 10 ^ 21 раз (что становится больше с ростом n, очевидно,) или около того в обмен для довольно небольшого объема памяти. :) Я считаю, что такого рода фундаментальное изменение в сложности алгоритма гораздо интереснее, чем простое кэширование. Это может облегчить неразрешимые проблемы.
Поскольку числа python являются, естественно, bignum, вы можете реализовать эту формулу в python с запоминанием, используя словарь и ключи кортежа только в 9 строках. Дайте ему шанс и попробуйте без памятки.
12 ответов
Нет, вы просто делаете дополнительную работу для себя.
Пока вы проводите достаточно тестов, изменение идентификатора здесь или там не даст пользователям доступа к чему-либо они не должны, тогда вы можете иметь видимые идентификаторы.
В некоторых ситуациях может быть полезно скрыть их или иметь непоследовательные номера, или, возможно, не начинать отсчет с нуля. Например, если кто-то получил заказ номер 3, он может начать задавать вопросы ...
IMO: No, you shouldn't obfuscate IDs. If security is a concern for your application, you need other security measures anyway. Security by obscurity is not enough, it just gives you a false sense of security.
BTW, if you do just a little math, chances are that other IDs - obscured too - are still predictable. In many cases, the bad guy doesn't care which account he breaks into, as long as it isn't his own ;-)
Я бы сказал, что в целом это нормально, но есть некоторые подводные камни:
Если ваши числа являются последовательными, вы открываете «игры на угадайку» (например, пользователь меняет детали? Id = 4511 для подробностей? Id = 4512 для просмотра чужих данных). Чтобы противодействовать этому, вам в первую очередь нужна надлежащая безопасность. Однако в некоторых случаях этого будет недостаточно, потому что раскрытие информации о существовании может быть проблемой само по себе. Возьмем, к примеру, Youtube, они используют более развернутые идентификаторы, чтобы избежать соскабливания экрана роботов.
Если вы сделаете предположения о природе идентификаторов, у вас могут возникнуть проблемы (например, если вы будете манипулировать идентификаторами непосредственно в графическом интерфейсе или сортировать элементы на основе идентификаторов). Это может быть неприятным сюрпризом, если вам нужно сбалансировать нагрузку на вашу БД и получить отдельные диапазоны идентификаторов.
Повторное использование идентификаторов. Например MySql: ■ Двигатель InnoDB сбрасывает последовательности при перезапуске (до последнего максимального значения). Это может сильно вас укусить, если вы действительно удаляете.
Но все эти подводные камни также применимы к пользовательским id: s, но, вероятно, они являются источником этих людей. На мой взгляд, наиболее гибким решением являются GUID: s, потому что вы можете сгенерировать их где угодно и не столкнетесь ни с одной из вышеупомянутых проблем. Однако людям их труднее читать, так что это компромисс.
Да, вероятно, вам стоит.
Если пользователь злонамеренно изменяет эти идентификаторы, проверяет ли ваш код, чтобы убедиться, что запрашиваемые данные все еще являются данными, которые им разрешено просматривать ?
Идентификатор проще скрыть, чем проводить повсеместную проверку вручную.
Отредактируйте, на этот раз яснее:
Если вы отобразите на экране список с идентификаторами от 1 до 20, очень легко проверить, что ответ был между 1 и 20. Если вы показываете на экране фактические идентификаторы, вам либо нужно было потратить память на кэширование идентификаторов, либо нужно сделать еще один вызов базы данных / более длинный запрос, чтобы убедиться, что они не предоставляют вам неверные данные.
Если вы используете суррогат Идентификаторы, я думаю, это станет проще.
Вам следует скрыть идентификаторы базы данных от пользователей
Почему? Это деталь реализации, о которой им (пользователю) не нужно беспокоиться. Я ID 123311122? Какая разница! (Если, может быть, я в аське). Посмотрите, например, как SO минимизирует (но не устраняет) уязвимость.
С другой стороны, использование предсказуемых идентификаторов - это еще один вектор атаки, безопасность за счет неясности, но это еще один действенный инструмент. Я никогда не работал над программным обеспечением, где это было проблемой.
При этом,
Мне не нравится раскрывать пользователям что-либо, что говорит о внутреннем устройстве данных, однако обычно это всегда происходит, особенно когда дело доходит до создания раскрывающихся списков на основе источника данных. Мое решение состоит в том, чтобы иметь разные спецификации идентификации для таблиц, чтобы исключить инкрементные атаки и, где возможно, зашифровать значения строки запроса. Это не всегда возможно, учитывая очень популярные шаблоны URL-адресов MVC в .NET, поэтому я обычно использую уникальное имя столбца, а затем нормализую его для URL-адреса. Затем я ищу это значение в базе данных. Однако нет простого способа полностью обойти это.
Я бы сказал, что если этот идентификатор имеет какое-либо значение для пользователя, и вы имеете дело с приложением, чувствительным к данным, вам следует скрыть значение идентификатора. Что еще более важно, я бы порекомендовал вам проверить, есть ли у текущего пользователя доступ к данным, которые он запрашивает через URL-адрес. Например, если у вас есть URL-адрес типа mysite.com/account/view/12, имеет ли текущий пользователь доступ к этому идентификатору учетной записи (например, 12).
Если информация является общедоступной и не конфиденциальной, я бы сказал, что это не так. требуется, чтобы скрыть значения идентификаторов.
«Мне сказали, что я не должен использовать идентификаторы базы данных непосредственно в HTML-коде веб-приложений. ... Вы скрываете идентификаторы от пользователя? »
Пользователи ожидают, что они столкнутся с данными, которые они могут связать с реальным миром, с которым они имеют дело в своей работе.
« Идентификаторы баз данных »должны быть только частью пользовательского интерфейса. в той степени, в которой эти идентификаторы также являются частью реальной рабочей ситуации пользователя. Если это не так, тогда действительно приложение должно полностью защищать пользователя от таких полей.
Выполнение этого экранирования действительно означает «больше работы». , но это совершенно не имеет значения. Отсутствие этого экранирования означает предоставление пользователю приложения, с которым ему будет труднее работать, что в конечном итоге приведет к тому, что сам пользователь будет выполнять «больше работы» каждый день снова и снова.
Я рекомендую вам использовать понятные имена. Он более современный и более смысловой. Кроме того, это выглядит намного лучше, когда вы создаете ссылку.
Например, рассмотрите mysite / products.aspx? Id = 25 vs mysite / products / ferrari. Последний чище, легче запоминается (для пользователей) и т. Д.
Если вы в настоящее время используете идентификаторы в скрытых полях, попробуйте использовать сеанс для сохранения этих значений. Если вы используете их только в идентификаторах строк таблицы, которые вы упомянули, я не думаю, что стоит тратить время на их сокрытие.
ID: s в URI: s являются частью хорошего UI , если вы хотите, чтобы ваши пользователи могли ходить по этой дороге. Все URI в любом случае являются общедоступными, отвечающая страница должна обрабатывать запрос и основывать рендеринг на какой-либо аутентификации.
Транзакции и другие конфиденциальные материалы могут быть легко скрыты с помощью соленой + хешированной строки и сохранены в другом столбец в вашей базе данных, если вы хотите, но если вы все еще не проверяете ввод пользователя (который в веб-программировании явно может быть «перемещением по URI»), вы упускаете суть.
Как Грег ответил , порядковый номер, вероятно, не должен быть низким, но ответственность за такую обработку информации должна лежать не на веб-странице, а внутри организации ».
As an example of "publishing" an id to the public, look at the url for this post.
I tried https://stackoverflow.com/questions/1, but it looks like it was deleted. You've got to go to While applying opacity to a form should we use a decimal or double value? to find the "first" ordinal question ; )
... no harm done, just a reference to another post.
Если вы все же решите защищать идентификаторы строк в скрытых полях, вы можете посмотреть книгу Стива Сандерсона asp.net mvc на странице 415, где он представляет утилиту HMAC (Hashing Message Authentication Code). класс для этой цели. Конечно, это .NET, но вы можете понять суть. Вы можете увидеть это в Google Книгах (Сандерсон написал о лучшей книге по программированию, которую я читал).
Когда я помещаю идентификаторы строк в html, а бизнес-модель говорит, что пользователь должен иметь доступ к определенному набору строк , например, те, которые он / она вставил, я мог бы разработать таблицу db, чтобы включить столбец идентификатора пользователя и включить его в любые операции db (псевдокод: где @rowID = table.rowID И @userID = table.userID). Таким образом, если другой пользователь взломает идентификаторы rowID в скрытых полях, операция db не позволит ему увидеть другого пользователя ' s данные, потому что идентификаторы пользователей не совпадают. Конечно, этот подход предполагает, что вы используете какую-то аутентификацию, и она тоже не была взломана.