Вопросы Теги

Использование идентификаторов базы данных в URL-адресе [дубликат]

Мы можем использовать Java 8, используя:

  1. В build.gradle (Project: myProject) добавьте следующий 
    classpath 'me.tatarka:gradle-retrolambda:x.x.x' //x.x.x is recent version
  2. В build.gradle (Module: myModule) добавьте следующее 
    apply plugin: 'me.tatarka.retrolambda'

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
}
93
задан orip 16 October 2009 в 07:04
поделиться

6 ответов

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

Вот несколько хороших правил:

  1. Используйте защиту на основе ролей для контролировать доступ к операции. Как это сделать, зависит от платформы и структуры, которую вы выбрали, но многие поддерживают декларативную модель безопасности, которая автоматически перенаправляет браузеры на этап аутентификации, когда действие требует определенных полномочий.
  2. Использовать программную безопасность для управления доступ к объекту. Это сложнее сделать на уровне структуры. Чаще всего это то, что вам нужно записать в ваш код и, следовательно, больше подвержено ошибкам. Эта проверка выходит за рамки проверки на основе ролей, гарантируя не только то, что у пользователя есть полномочия для операции, но также имеет необходимые права на конкретный объект, который изменяется. В системе на основе ролей легко проверить, что только менеджеры могут давать рейзы, но помимо этого вам нужно убедиться, что сотрудник принадлежит отделу конкретного менеджера.
  3. Для большинства записей в базе данных условия 1 и 2. Но добавление непредсказуемых идентификаторов можно рассматривать как небольшую дополнительную страховку или «безопасность в глубину», если вы покупаете это понятие. Однако одно место, где непредсказуемые идентификаторы являются необходимостью, относится к идентификаторам сеанса или другим токенам аутентификации, где сам идентификатор аутентифицирует запрос. Они должны генерироваться криптографическим RNG.
73
ответ дан erickson 26 August 2018 в 19:50
поделиться
  • 1
    ИМО, добавляя непредсказуемые идентификаторы, является «безопасностью через безвестность». подхода и может привести к ложному чувству безопасности. Лучше сосредоточиться на (1) и (2) и убедиться, что ваш контроль доступа прочен. – stucampbell 9 August 2014 в 13:45
  • 2
    Использование криптографического RNG определенно не «безопасность через неизвестность». Злоумышленник не ближе к угадыванию идентификаторов объектов, даже когда она знает, как вы их генерируете. Безопасность через неясность означает, что если обнаруженный алгоритм обнаружен, его можно использовать. Это не относится к хранению секретов, таких как ключи или внутреннее состояние ГСЧ. – erickson 14 August 2017 в 15:24
  • 3
    @stucampbell Возможно, но это не значит, что вы не должны использовать непредсказуемые идентификаторы вообще. Ошибки случаются, поэтому непредсказуемые идентификаторы являются дополнительным механизмом безопасности. Кроме того, контроль доступа не является единственной причиной их использования: предсказуемые идентификаторы могут выявлять конфиденциальную информацию, такую ​​как количество новых клиентов в течение определенного периода времени. Вы действительно не хотите раскрывать такую ​​информацию. – Stijn 16 April 2018 в 11:10
  • 4
    @Stijn вы не можете сказать, что я «действительно не хочу» раскрывать, сколько у меня клиентов. Я имею в виду, что McDonald's имеет огромный знак, что они подали 10 миллиардов гамбургеров. Это не риск для безопасности, это предпочтение. Кроме того, вам нужно войти в систему, прежде чем вы увидите какие-либо URL-адреса в большинстве приложений, где мы все равно будем беспокоиться об этом. Поэтому мы знали бы, кто чинил данные. – Wayne Bloss 17 May 2018 в 11:11
  • 5
    Одна вещь, о которой я не упоминал в этом разговоре, заключается в том, что с точки зрения устранения неполадок и простоты использования может быть очень удобно, чтобы идентификаторы были открыты в URL-адресе, чтобы помочь направлять пользователей на определенный ресурс или иметь возможность чтобы точно рассказать, какой ресурс они просматривают. В основном вы можете избежать проблем бизнес-аналитики, запустив автоматическое увеличение при более высоком значении, просто чтобы предложить одну идею. – Chockomonkey 12 July 2018 в 20:30

Общая мысль идет по этим строкам: «Раскрывайте как можно меньше информации о внутренней работе вашего приложения для кого-либо».

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

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

19
ответ дан Arjan Einbu 26 August 2018 в 19:50
поделиться
  • 1
    Доступ к ресурсам, которые они не должны видеть - только если я не проверю разрешения (что я и делаю, в противном случае у меня другая проблема с безопасностью). Раскрытие информации о "внутренней обработке" - это точно мой вопрос. Почему это проблема? – orip 28 December 2008 в 15:18
  • 2
    @orip: Все дело в том, чтобы быть как можно более безопасным. Если вы такой программист, который не ошибается, то это не проблема. В противном случае просмотр меньшего количества деталей затрудняет использование вашего кода, если (когда) вы совершаете ошибки. Само по себе, вы правы, это не добавляет безопасности. – Adam Bellaire 28 December 2008 в 18:20
  • 3
    @Adam: поверхностная безопасность может быть хуже, чем никакой безопасности. Без какой-либо безопасности вы явно, с поверхностной безопасностью, вы можете подумать, что она добавляет что-то неважное. – orip 29 December 2008 в 02:30

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

Например. пользователь может легко изменить параметр id в этом qs и посмотреть / изменить данные, которые они не должны http: // someurl? id = 1

25
ответ дан John Topley 26 August 2018 в 19:50
поделиться
  • 1
    если вы используете последовательные идентификаторы, вы правы, но если нет, то это ничего не раскрывает – orip 28 December 2008 в 15:17
  • 2
    Если я не проверю разрешения, у меня другая проблема с безопасностью. – orip 28 December 2008 в 15:18
  • 3
    @orip: Как я уже сказал, это зависит от того, что кто-то может обнаружить, исследуя несколько идентификаторов. Есть ли образец? Могут ли они использовать эту информацию для получения информации, которой они не предназначены? – some 28 December 2008 в 15:55
  • 4
    @John: Спасибо за редактирование. Английский не мой родной язык :) – some 28 December 2008 в 16:30
  • 5
    но ответ является точным: «может» – Seun Osewa 29 December 2008 в 05:08
  • 6
    Я сделал именно это: использовал последовательные идентификационные номера, чтобы определить размер пользовательской базы участника. – Micah 16 October 2009 в 01:55
  • 7
    Они повсюду. Многие shoppingsites используют порядковый номер для идентификатора заказа. Поместите один заказ за одну дату, а другой - в другую дату, и вы знаете, сколько заказов они получили за этот период. Даже если вы не знаете, сколько денег стоят заказы, вы по-прежнему получаете представление о том, как хорошо работает бизнес. – some 16 October 2009 в 09:31
  • 8
    Вопрос не в том, что вы будете проверять разрешения. Если новый найм, который вы не знаете, будет проверять разрешения. – Brian White 5 April 2012 в 22:01
  • 9
    @BrianWhite - вот почему вы хотите, чтобы процесс проверки кода был на месте, чтобы вы могли обучать их, прежде чем они попали в производство. – candu 7 August 2015 в 16:22
  • 10
    Конечно. В большинстве мест есть политика проверки кода. И одновременно, проблемы безопасности изобилуют в Интернете. SQL-инъекция является одной из самых распространенных, несмотря на все образование – Brian White 7 August 2015 в 22:52

Мы используем идентификаторы GUID для идентификаторов базы данных. Утечка их намного менее опасна.

11
ответ дан Joshua 26 August 2018 в 19:50
поделиться
  • 1
    Это то, что я хотел бы предложить. Лот с меньшей вероятностью угадает GUID в вашей базе данных. – Jon Erickson 28 December 2008 в 21:16
  • 2
    Это приводит к штрафу за производительность. См. здесь – Jeshurun 27 June 2015 в 20:10
  • 3
    Интересная вещь об использовании указаний заключается в том, что вы можете позволить клиентам генерировать идентификаторы базы данных. Интересная вещь 2 заключается в том, что у них нет проблем с зашифрованными базами данных, как это делает auto incrementing ids. – Brian White 7 August 2015 в 22:59
  • 4
    Используете ли вы эти GUID также в html-коде как атрибуты идентификатора для идентификации пользователей, комментариев, сообщений? Чтобы указать, какую ссылку щелкнул пользователь или какой пост он хочет прокомментировать? – trzczy 3 November 2017 в 12:49

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

Вы постоянно пытаетесь делегировать вещи своему управлению доступом;) Это может быть в вашем приложении, но я никогда не видел такой последовательной внутренней системы за всю свою карьеру. Большинство из них имеют модели безопасности, которые были предназначены для использования не в Интернете, а некоторые из них добавили дополнительные роли посмертно, а некоторые из них были заперты за пределами базовой модели безопасности (поскольку роль была добавлена ​​в другом операционном контексте, скажем, перед веб-сайтом).

Таким образом, мы используем синтетический локальный идентификатор сеанса, потому что он скрывает столько, сколько мы можем уйти.

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

5
ответ дан krosenvold 26 August 2018 в 19:50
поделиться
  • 1
    Интересно, хотя я бы подумал, что проверка всех входных данных (включая параметры URL) для каждого запроса очень подходит для Интернета. – orip 16 October 2009 в 07:00

Несмотря на отсутствие риска безопасности данных , это абсолютно опасный риск безопасности бизнес-аналитики , поскольку он предоставляет как размер данных, так и скорость. Я видел, как предприятия получают от этого вред и написали об этом анти-шаблоне в глубину. Если вы просто не строите эксперимент, а не бизнес, я бы настоятельно предложил сохранить ваши личные идентификаторы вне поля зрения общественности. https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e

14
ответ дан Peter 26 August 2018 в 19:50
поделиться
Другие вопросы по тегам:

Похожие вопросы: