Я бачив це знову і знову протягом останніх 30 років: люди дозволяють базі даних встановлювати ідентифікатор або первинний ключ таблиці з бази даних. На перший погляд це здається простим і всі знають, що слід дозволити базі даних робити важку роботу, з числовими “Sequence” номерами потрібно дозволити базі даних робити роботу, оскільки може бути кілька застосунків або потоків, що створюють нові записи в таблиці. НЕ РОБІТЬ ЦЬОГО!
По-перше, якщо вам коли-небудь знадобиться об’єднати дві бази даних, які тепер мають ті ж ідентифікатори первинного ключа для тієї ж таблиці, ви програли. Вам доведеться придумати схему для зміни ідентифікаторів, можливо, додати 10 000 до кожного ідентифікатора. Що, якщо у вас є більше 10 000 рядків? Вам також доведеться оновити всі дочірні записи, це може бути не так просто, якщо в базі даних визначені обмеження.
По-друге, якщо ви викриваєте свої дані як API, то рано чи пізно це станеться, і ви самі відкриєте вашу систему для того, що хакери люблять бачити.
Нехай я поясню:
Я можу увійти і отримати доступ до своєї інформації, можливо, до моїх покупок, так:
GET https://secureserver.com/purchases/123
Звучить просто, правда? Я отримую покупки для користувача з ідентифікатором 123. Але що, якщо я роблю ще один виклик:
GET https://secureserver.com/purchases/100
Тепер ви отримуєте покупки для користувача 100, але це не ви. Ви тільки що дозволили зовнішньому хакеру отримати доступ до вашої бази даних. Припустимо, що це щось особисте, наприклад, “Chia Pet”. Тепер хакер знає, що користувач з ідентифікатором 100 придбав “Chia Pet”. Інший виклик до API для користувача з ідентифікатором 100 показує, що користувач – це Ілон Маск. Чи дійсно ми хочемо, щоб весь світ знаав, що у Ілона Маска фетиш до “Chia Pet”? Ви щойно розкрили свої захищені дані, і ви втратите довіру своїх клієнтів. Але це може бути гіршим, API також може розкрити День Народження, Адреси, Номери Соціального Забезпечення, можливо навіть Номери Кредитних Карт (якщо ви не дотримуєтеся правил PCI).
Тепер подивімось на використання UUID для виклику.
GET https://secureserver.com/purchases/4a21-64E2-4514-623a
Набагато безпечніше, оскільки додавання числа сюди чи туди, ймовірно, не дасть доступу до жодної інформації.
Отже, мораль цієї історії така: НІКОЛИ НЕ ВИКОРИСТОВУЙТЕ ЦІЛІ ЧИСЛА для ідентифікаторів первинного ключа!
Зверніть увагу, що використання UUID для ключа означає, що ви тепер використовуєте рядок, що є великим кроком вперед, і ви можете об’єднати дві бази даних без жодних проблем.
Колись (10 років тому) бази даних були повільними, і людям радили не використовувати рядки для ключів через проблеми з продуктивністю, тепер кожна база даних в певному розмірі використовує хешовані ключі, тому більше не існує проблеми з продуктивністю.
Ви все ще маєте загальну проблему з авторизацією. Припускається, що у вашій системі вже вирішено питання аутентифікації, так що ви знаєте, хто увійшов у систему. Вам також потрібно переконатися, що до своїх ресурсів можуть отримати доступ лише авторизовані користувачі. Це означає, що коли хтось намагається отримати доступ до користувача або покупок, і ці дані не належать йому, він отримує помилку.
Це потрібно сприймати серйозно, багато хто використовує цей простий метод для вторгнень, деякі з найбільших американських роздрібних торговців викривали дані клієнтів саме таким чином. Навіть деякі з найбільших служб зберігання паролів для безпеки стикалися з такими проблемами і були викриті. Не дозвольте вашій компанії стати наступною жертвою. Виправте це сьогодні!
Удачі, не соромтеся зв’язатися та слідкуйте за мною.
Слідуйте за мною, будь ласка.
Я живу в Каліфорнії все своє життя. Я виріс в Силіконовій долині і бачив так багато змін.
Не соромтеся слідкувати за мною на Medium і YouTube. У мене є курси на Udemy, і я тільки що розпочав нову серію під назвою “Fast and Simple Development”, де ви можете вивчити нові технології і навички, які потрібні для підвищення своєї кваліфікації на ринку праці сьогодні, або просто продовжувати рости, додаючи технічні навички до свого резюме.
https://www.youtube.com/@fastandsimpledevelopment?sub_confirmation=1
https://www.udemy.com/user/tomjay2
https://www.linkedin.com/in/thomas-d-jay
https://www.thomasjayconsulting.com/
ОРИГІНАЛ СТАТТІ: Stop using Integer ID’s in your Database
АВТОР СТАТІ: Tom Jay
