Дуже цікаве відео, не так давно я почав свій шлях в використанні SQL та створенні баз даних і був радий дізнатись про такі вразливості та головне як від них захиститись. Дякую за вашу працю!
Ідея розповідати про основи безпеки в мене вже давно крутилася, але все ніяк руки не доходили створити блог... Можна почати з паролів, що мають містити &%$^@ і мінятися кожні х днів, про 2-factor vs 2-step authentication, про переваги і недоліки біометрії, симметрична і асимметрична криптографія... там цілу рубрику можна вести довго і пізнавально, далеко не лише розробникам.
на кожні типові мови є готові бібліотеки для взаємодії з бд не через голу SQL, а через синтаксичний цукор типу db->update(table, [key>value]) саме те для самописних проектів, і в ногу не стрелиш, і менше нечитабельного коду
Як в 2023 році написати код вразливим для sql ін'кцій? Ви згадали rust, там сама популярна бібліотека для спілкування з бд - sqlx, здавалося б, в цій бібліотеці пишеш прямі квері і підставляєш значення в них. А по-факту, система настільки захищена від них, що по запиту "sqlx sql injection", гугль майже нічого не знаходить😂 А от якщо дядько вирішив писати по голому залізу на расті комунікатор з бд, то цей дядько, напевно, буде самим розумним в кімнаті, і про таке не забуде😅
Ну якщо постаратись можна написати вразливий код. Наприклад let query = format!("SELECT * FROM users WHERE name = '{}'", user_input); let rows = sqlx::query(&query).fetch_all(pool).await.unwrap();
@@pavelognev108 робота з бд може відбуватися не тільки для бекенду. Та і скільки серверів на с++ написано? Для чого? Бо хтось вирішив що так краще) Думаю, тут так само буде)
Це плач душі. Це приклад як клепаються армії full-stack розробників, які роблять весь додаток швидко і навіть самі не розуміють трагедії що написали. Які запити до бази даних з фронта? Про що взагалі йде мова. Про Rest взагалі ніхто нічого не чув. Про принципи SOLID при побудові API теж ніхто не чув. Та взагалі при побудові будь яких додатків не має бути прив'язки до конкретних технологій. Фронт має передавати просто в параметрах запиту ту інфу яку треба зберегти. Бекенд має бути побудований настільки абстрактно що лише певний клас знає що під капотом mysql чи щось інше.
Недавно бачив презентацію якогось фронтенд фреймворка де на слайдах sql запит формувався прямо на стороні клієнта. Типу при натисканні на кнопку робимо інсерт
ORM це рішення, але тоді сама ORM пише запит замість тебе що призводить до меншого контролю над виглядом запиту. Тому часто високонавантажені сервіси не використовують orm принаймні не всюди
@@alex-kovalchuk тобто це потрібно що б SQL запит був чіткішим? І оптимальнішим? І на нього витрачалося менше часу? Я особисто використовую Sequelize, то навіть складні запити з джоїнами і фільтрами і всяким різним, на виході він формує нормальний запит) принаймні я не бачу що там оптимізовувати
Так, Spring як і будь які інші orm доволі гарно захищають від таких вразливостей. Там треба дуже постаратись щоб вдалось написати код вразливий до sql інєкцій
Так може, все ж таки, різниця в тому, використовувати дані які зберігаються в оперативній пам'яті і на диску? В принципі, in-memory sql баз данних окрім H2, майже не існує. (А h2 обганяє абсолютно всі бази данних взагалі, руйнуючі відразу два міфи: 1. Sql бази данних повільн, 2. Java повільна)
Сам убер використовує редіс для "швидкого доступу", будь-ласка, редіс це виключно in-memory key-value база данних. Живе вона тільки в оперативній пам'яті, ніколи ннікуди не зберігаючи своїх значення після закінчення життя додатку🤷♀️. Звичайно вона швидка.
@@12MrRetro 👀👀а до чого тут взагалі in-memory. Ми спілкувалися щодо Sql/NoSql баз даних. І як існування h2 руйнує міф, що Sql бази данних повільні? Вибачте, але ви говорите незв'язані між собою та дискусією речі. Ваш коментар не має сенсу.
Ти не повіриш, але у нас навіть таблиця є з назвою goods в базі PostgreSQL. Насправді все побудовано на мікросервісах і кожна команда пише на своїй мові. Використовується PHP, Golang, C#, JS, Lua (це принаймі що я чув)
Дуже сподіваюсь що не через мій відосик А взагалі механіка злому в Київстар суттєво складніша ніж те що я описував. У них немає таких дитячих вразливостей
![[UA] Eternal Fire проти NAVI | EPL Season 20 Malta](http://i.ytimg.com/vi/chvlsDygrZM/mqdefault.jpg)
Реєструйтесь на програму Information and Cybersecurity management
від SET University - bit.ly/3Gxa12n
дякую, пішов шукати сайти без екранування, сподіваюся буде весело)
Гарно пояснено важливі речі) Думаю деякі розробники про це дійсно не задумуються, а слід)
Дякую за відео та вашу працю! Слава Україні!
test
Дуже актуальне відео та загалом вивчення баз даних , особливо після подій з Київстаром та не тільки...
Дякуємо за роботу, більше відео про секюріті, більше!
нещодавно задали це питання на захисті лаби й тут виходить відео на цю тему так ще й українською. дуже приємно та вчасно
Відос топ, все подивився, від ін'єкцій не захистився
Дуже цікавий випуск та добрі пояснення. Дякую Вам, Алексе!
дуже дякую за відео, завжди хотів глянути як це виглядає
Чудове відео. Продовжуй робити те що робиш!!!
Дуже цікаве відео, не так давно я почав свій шлях в використанні SQL та створенні баз даних і був радий дізнатись про такі вразливості та головне як від них захиститись. Дякую за вашу працю!
Відео топове бажаю удачі
Чудовий контент, а для елюстрацій рекомендую спробувати excalidraw
Дякую, спробую. Я зараз в процесі підшуковування хороших інструментів
Дякую, гарний інструмент
прошу розказати про це Київстару🥲
Ідея розповідати про основи безпеки в мене вже давно крутилася, але все ніяк руки не доходили створити блог...
Можна почати з паролів, що мають містити &%$^@ і мінятися кожні х днів, про 2-factor vs 2-step authentication, про переваги і недоліки біометрії, симметрична і асимметрична криптографія... там цілу рубрику можна вести довго і пізнавально, далеко не лише розробникам.
Дякую
давай бiльше вiдео про security
Малюнки сам робив?) Дуже файні😂
Так, перші спроби ілюстрацій)
@@alex-kovalchuk бекенд програміста завжди видно по малюнках. Сам так малюю 😂
Чекаю відео, як не лягти як Київстар
на кожні типові мови є готові бібліотеки для взаємодії з бд не через голу SQL, а через синтаксичний цукор типу db->update(table, [key>value])
саме те для самописних проектів, і в ногу не стрелиш, і менше нечитабельного коду
Цікаве відео, дякую
Хм. Дійсно пишучи свою сторінку навіть не подумав про захист від такої загрози😅
Класне відео
Оце було дуже пізнавально (ні, я не айтішник)
а я то думав тут буде password = password, а тут нічосі інфа!!😮
прошу розказати про це Київстару🥲
А з чого ти взяв, що їх взламали з подомогою SQL injection? =)
Хоча відео і несе в собі базову(примітивну) інформацію і розраховане на нубиків, проте сам ролик інформативний і якісний. Новачки мають його зацінити.
Ви користуєтеся Arc Browser? Просто цікаво:)
Так, недавно пересів на нього. Покищо дуже подобається
коли відео про те, як правильно вимовляти SQL
Якось неправильно запам'ятав і постійно не так кажу. В сценарії ж англійською писав тому підказки не було 🥲
@@alex-kovalchuk це все добре, але як то правильно вимовляти?
Еск'юель
@@tireksik7193секʼюель
@@НікітаПроворов одні говорять ес кю ель, інші сіквель
Шкода, що Київстар не встиг подивитися це відео
SQL читається як "ЕС-к'ю-ел". "сі-к'ю-ел" це щось типу CQL (бозна, що воно таке).
Чому сік'юель якщо це ЕСк'юель. Вухо ріже. Це як Гугл читати гоогл
Є різні варіанти вимовлення SQL (/ˌɛsˌkjuːˈɛl/ або /ˈsiːkwəl/)
Порадьте будь ласка переносний роутер, зараз це актуально! Щоб із сімки роздавав вайфай коли мобільний телефон не тягне чи інші нюанси...
Як в 2023 році написати код вразливим для sql ін'кцій?
Ви згадали rust, там сама популярна бібліотека для спілкування з бд - sqlx, здавалося б, в цій бібліотеці пишеш прямі квері і підставляєш значення в них. А по-факту, система настільки захищена від них, що по запиту "sqlx sql injection", гугль майже нічого не знаходить😂
А от якщо дядько вирішив писати по голому залізу на расті комунікатор з бд, то цей дядько, напевно, буде самим розумним в кімнаті, і про таке не забуде😅
Ну якщо постаратись можна написати вразливий код. Наприклад
let query = format!("SELECT * FROM users WHERE name = '{}'", user_input);
let rows = sqlx::query(&query).fetch_all(pool).await.unwrap();
Чудово, залишилося ще вигадати, для чого нам бекенд на Rust...
@@pavelognev108 робота з бд може відбуватися не тільки для бекенду.
Та і скільки серверів на с++ написано? Для чого?
Бо хтось вирішив що так краще)
Думаю, тут так само буде)
Це плач душі. Це приклад як клепаються армії full-stack розробників, які роблять весь додаток швидко і навіть самі не розуміють трагедії що написали. Які запити до бази даних з фронта? Про що взагалі йде мова. Про Rest взагалі ніхто нічого не чув. Про принципи SOLID при побудові API теж ніхто не чув. Та взагалі при побудові будь яких додатків не має бути прив'язки до конкретних технологій. Фронт має передавати просто в параметрах запиту ту інфу яку треба зберегти. Бекенд має бути побудований настільки абстрактно що лише певний клас знає що під капотом mysql чи щось інше.
Недавно бачив презентацію якогось фронтенд фреймворка де на слайдах sql запит формувався прямо на стороні клієнта. Типу при натисканні на кнопку робимо інсерт
Як що до ORM? Це хіба не рішення?
ORM це рішення, але тоді сама ORM пише запит замість тебе що призводить до меншого контролю над виглядом запиту.
Тому часто високонавантажені сервіси не використовують orm принаймні не всюди
@@alex-kovalchuk тобто це потрібно що б SQL запит був чіткішим? І оптимальнішим? І на нього витрачалося менше часу? Я особисто використовую Sequelize, то навіть складні запити з джоїнами і фільтрами і всяким різним, на виході він формує нормальний запит) принаймні я не бачу що там оптимізовувати
Підскажіть, чи захищає Spring від sql ін'єкцій? Наприклад, якщо використовувати jpa repository для запису данних в базу.
Так, Spring як і будь які інші orm доволі гарно захищають від таких вразливостей.
Там треба дуже постаратись щоб вдалось написати код вразливий до sql інєкцій
Навіть я зрозумів
якщо б розетка використовувала sql базу для зберігання товарів, вона б відповідала на ваші запити приблизно.. ніколи
Якщо правильно налаштувати індекси, то для PostgreSQL об'єми розетки не важко перетравити. Той ж uber працює на MySQL
Так може, все ж таки, різниця в тому, використовувати дані які зберігаються в оперативній пам'яті і на диску?
В принципі, in-memory sql баз данних окрім H2, майже не існує.
(А h2 обганяє абсолютно всі бази данних взагалі, руйнуючі відразу два міфи: 1. Sql бази данних повільн, 2. Java повільна)
Сам убер використовує редіс для "швидкого доступу", будь-ласка, редіс це виключно in-memory key-value база данних. Живе вона тільки в оперативній пам'яті, ніколи ннікуди не зберігаючи своїх значення після закінчення життя додатку🤷♀️.
Звичайно вона швидка.
@@12MrRetro 👀👀а до чого тут взагалі in-memory. Ми спілкувалися щодо Sql/NoSql баз даних. І як існування h2 руйнує міф, що Sql бази данних повільні? Вибачте, але ви говорите незв'язані між собою та дискусією речі. Ваш коментар не має сенсу.
Ти не повіриш, але у нас навіть таблиця є з назвою goods в базі PostgreSQL. Насправді все побудовано на мікросервісах і кожна команда пише на своїй мові. Використовується PHP, Golang, C#, JS, Lua (це принаймі що я чув)
я новачок і юзаю монгу) маю іммунітет до цих ін'єкцій?
Немає sql БД - немає sql ін'єкцій. Щоправда, тепер в тебе вразливість до NoSQL ін'єкцій 😅
це ж треба знати назву бази та коллекції і як вона там зроблена з якими назвами)) @@alex-kovalchuk
Часто такі таблиці як users, orders, comments однакові і тому це методом проб ламають
Так це київстар через це впав?
Дуже сподіваюсь що не через мій відосик
А взагалі механіка злому в Київстар суттєво складніша ніж те що я описував. У них немає таких дитячих вразливостей
а може не потрібно було пару років тому жлобитись на Bug Bounty?
там багаторівнева атака, включаючи інсайдерів в самій компанії
Аж дивно як це відео злилося з подіями київстару. Ми щось про Олексія не знаємо???🤔😅
Тобто в джанґо з csrf я взагалі можу про це не паритись?
csrf з ін'єкцією не зв'язані, але так. Django займається екрануванням вхідних даних. Якщо не обходиш фреймворк, то все цілком захищено