Викриття ідентифікаторів бази даних - ризик безпеки?

Я чув, що відкриття ідентифікаторів бази даних (наприклад, у URL-адресах) є ризиком для безпеки, але у мене виникають проблеми з розумінням того, чому.

Будь-яка думка чи посилання на те, чому це ризик чи чому це не так?

РЕДАКТУВАННЯ: звичайно, доступ обмежений, наприклад, якщо ви не можете бачити ресурс, foo?id=123ви отримаєте сторінку помилок. Інакше сама URL-адреса має бути секретною.

EDIT: якщо URL-адреса є секретною, вона, ймовірно, містить генерований маркер, який має обмежений термін служби, наприклад, дійсний протягом 1 години і може бути використаний лише один раз.

EDIT (місяці пізніше): моя сучасна краща практика для цього - використовувати UUIDS для ідентифікаційних номерів та викривати їх. Якщо я використовую послідовні номери (як правило, для продуктивності в деяких БД) як ідентифікатори, мені подобається генерувати маркер UUID для кожного запису як альтернативний ключ, і викриваю це.

Враховуючи належні умови, виявлення ідентифікаторів не є ризиком для безпеки. І на практиці було б надзвичайно обтяжливим розробити веб-додаток, не виставляючи ідентифікаторів.

Ось кілька хороших правил, яких слід дотримуватися:

1. Використовуйте захист на основі ролей, щоб контролювати доступ до операції. Як це зробити, залежить від обраної вами платформи та основи, але багато хто підтримує декларативну модель захисту, яка автоматично перенаправляє браузери на етап аутентифікації, коли для дії потрібен певний авторитет.
2. Використовуйте програмну безпеку для управління доступом до об'єкта. Це складніше зробити на рамковому рівні. Частіше це потрібно записати у свій код, і тому воно більше схильне до помилок. Ця перевірка виходить за рамки рольової перевірки, забезпечуючи не лише те, що користувач має повноваження на роботу, але і має необхідні права на конкретний об'єкт, що змінюється. У системі, що базується на ролях, легко перевірити, чи можуть підвищувати підвищення лише керівники, але крім цього вам потрібно переконатися, що працівник належить до конкретного менеджерського відділу.
3. Для більшості записів бази даних умови 1 і 2 є достатніми. Але додавання непередбачуваних ідентифікаторів може розглядатися як трохи додаткове страхування або "безпека в глибині", якщо ви купуєте це поняття. Однак одне місце, де непередбачувані ідентифікатори є необхідністю, - це ідентифікатори сеансу чи інші маркери аутентифікації, де ідентифікатор сам підтверджує запит. Вони повинні бути породжені криптографічним RNG.

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

Це залежить від того, на що стоять посвідчення особи.

Подумайте про сайт, який з конкурентних причин не хоче оприлюднювати, скільки членів у них є, але за допомогою послідовних ідентифікаторів це все одно розкриває його в URL: http://some.domain.name/user?id=3933

З іншого боку, якщо вони замість цього використовували ім'я користувача для входу: http://some.domain.name/user?id=some, вони нічого не розголошували, про що користувач ще не знав.

Загальна думка випливає за такими напрямками: "Розкривайте кому-небудь мало інформації про внутрішню роботу вашого додатка".

Розкриття ідентифікатора бази даних вважається розкриттям деякої інформації.

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

Ми використовуємо GUID для ідентифікаторів баз даних. Витікати їх набагато менш небезпечно.

Якщо ви використовуєте цілі ідентифікатори у своєму db, ви можете полегшити користувачам бачити дані, які вони не повинні, змінюючи змінні qs.

Наприклад, користувач може легко змінити параметр id у цьому питанні та побачити / змінити дані, які вони не повинні http: // someurl? Id = 1

Коли ви надсилаєте ідентифікатори бази даних своєму клієнту, ви змушені перевіряти безпеку в обох випадках. Якщо ви зберігаєте ідентифікатори у своєму веб-сеансі, ви можете вибрати, чи хочете / вам це потрібно зробити, тобто потенційно менше обробки.

Ви постійно намагаєтесь делегувати речі до вашого контролю доступу;) Це може бути у вашій заяві, але я ніколи не бачив такої послідовної системи бек-енду протягом усієї своєї кар’єри. Більшість з них мають моделі безпеки, розроблені для використання не в Інтернеті, а деякі мають додаткові ролі, додані посмертно, а деякі з них зафіксовані за межами основної моделі безпеки (тому що роль додана в іншому операційному контексті, скажімо перед Інтернетом).

Тому ми використовуємо синтетичні локальні ідентифікатори сеансу, тому що вони приховують стільки, скільки ми можемо відійти.

Існує також випуск не цілих ключових полів, що може стосуватися перерахованих значень і подібних. Ви можете спробувати переоцінити ці дані, але, швидше за все, ви опинитеся як маленькі таблички, що скидаються на бобі .