Коли починаєш роботу над MVP, люди часто запитують нас: “Чи безпечний Ruby on Rails?”.
По-перше, не існує програмного забезпечення, яке б було на 100% безпечним, і немає фреймворка, який би був безпечніший за інші. Це не означає, що ми не можемо нічого зробити для забезпечення безпеки. У цьому дописі ми проаналізуємо деякі вбудовані механізми безпеки, які надає Ruby on Rails, а також інші заходи безпеки, які необхідно використовувати для побудови більш безпечного програмного забезпечення.
Безпека залежить від людей, які використовують веб-фреймворк, а також від решти технічного стеку:
- база даних
- веб-сервер
- і, можливо, інші компоненти, такі як API, зберігання файлів тощо.
Кожен незалежний компонент технічного стеку може бути атакований і має бути захищений. У цьому дописі ми зосередимося лише на веб-фреймворку.
Веб-додатки відносно легко атакувати, оскільки вони прості для розуміння і їх можна маніпулювати з мінімальними знаннями. За даними OWASP Top Ten, найпоширеніші ризики безпеки веб-додатків включають порушення доступу, ін'єкції (кросс-сайт скриптинг, SQL-ін'єкції тощо), небезпечний дизайн, вразливі та застарілі компоненти тощо. Щоб запобігти або мінімізувати ці ризики, ви повинні розуміти ці атаки.
Вбудовані механізми безпеки Rails
Rails надає вбудовані механізми безпеки для запобігання деяким з найпоширеніших ризиків безпеки веб-додатків. Але ви повинні використовувати їх так, як це вказано у фреймворку.
Cross-Site Request Forgery (CSRF)
Цей метод атаки працює шляхом включення шкідливого коду або посилання на сторінку, яке створює підроблені запити до веб-додатку, видаючи їх за запити від користувача. Якщо сесія для цього веб-додатку не вичерпалася, зловмисник може виконати несанкціоновані команди, використовуючи акаунт користувача.
Перша контрзахода від цієї атаки — правильне використання GET та POST, як цього вимагає W3C. Друга контрзахода, яка увімкнена за замовчуванням у Ruby on Rails, — це додавання токена безпеки до запитів, який ми перевіряємо на сервері. Усі форми, згенеровані Rails, включають цей токен. Якщо токен, відправлений на сервер, не збігається з очікуваним, запит буде скасовано, і жодних змін у системі не буде зроблено.
Ін'єкції
Ін'єкції — це клас атак, що маніпулюють вхідними даними користувача шляхом надсилання довільного коду, який виконуватиметься всередині програми. Найвідомішими прикладами ін'єкцій є кросс-сайт скриптинг (XSS) та SQL-ін'єкції.
SQL-ін'єкція стосується коду, який буде виконано на базі даних. Якщо атака успішна, зловмисник може отримати доступ до записів, які раніше були поза його досяжністю. Він може вкрасти особисту інформацію, паролі або надати своєму користувачу адміністративні привілеї.
Методи запитів Ruby on Rails мають вбудований фільтр для спеціальних SQL-символів, які використовуються для виконання цих атак, і за замовчуванням автоматично очищають вхідні дані. Але якщо ви використовуєте фрагменти SQL, особливо в умовах (where("...")), санітизацію потрібно застосовувати вручну.
Зробіть звичкою думати про наслідки безпеки, коли використовуєте зовнішні дані в SQL-рядках.
З іншого боку, атаки XSS (кросс-сайт скриптинг) мають на меті ін'єкцію коду, який виконуватиметься в веб-браузері користувача. Якщо атака успішна, зловмисник може:
- вкрасти особисту інформацію, таку як куки для автентифікації, щоб видавати себе за користувача в додатку
- змінити елементи на сторінці, щоб показати фальшиву інформацію
- перенаправити жертву на інший вебсайт для фішингу або викрадення іншої інформації
За замовчуванням Rails автоматично екранує весь HTML (якщо тільки ви не вказали, що цього не робити, що не рекомендується).
Це означає, що будь-який код, який намагається ін'єктувати зловмисник, не буде виконаний, і браузер не виконає його.
Ви можете ознайомитися з повним списком ризиків безпеки та їхніх контрзаходів у розділі безпеки в документації Rails.
Активне співтовариство, широке впровадження та часті оновлення
Оновлення вашого коду є важливим, коли ми говоримо про безпеку. Сканери веб-додатків можуть легко знайти старі версії програмного забезпечення і мають велику бібліотеку відомих вразливостей для кожної з них. Тому мати застарілу версію Rails — це проблема безпеки, яку потрібно вирішити якомога швидше. Якщо хочете, ви можете дізнатися більше про те, що включає в себе оновлення додатків Ruby on Rails.
Не менш важливо, що команда Rails має групу спеціалізованих інженерів, які працюють над покращенням безпеки та усуненням помилок, пов'язаних із безпекою. Вони знаходяться досить швидко, оскільки такі великі компанії, як Shopify, GitHub, Airbnb та Basecamp, активно використовують Rails. Кожного разу, коли вразливість виправляється, для всіх актуальних версій фреймворку випускається нова версія з інструкціями, як оновити та як працює виправлення.
Відповідальність користувача
Існують деякі ризики безпеки та вразливості, яких Rails не може запобігти за замовчуванням, і які зазвичай є відповідальністю користувача. Гарною практикою є сканування нашого додатку на вразливості за допомогою сканера веб-додатків, такого як Brakeman (спеціально розроблений для додатків Ruby on Rails), ZAP або w3af.
Однак у сфері безпеки немає срібної кулі. Будь-який сканер веб-додатків перевірятиме ваш додаток, але вони не враховують контекст. Більшість з них не знають ваших бізнес-правил, і є деякі вразливості, які вони можуть не здогадатися, як виявити, такі як порушений контроль доступу. Контроль доступу стосується політики, яка забезпечує, щоб користувачі не могли діяти поза межами своїх дозволених прав. Це залежить конкретно від бізнес-логіки. Відповідальний користувач фреймворку повинен запобігати тому, щоб користувачі їхнього додатку мали можливість читати, змінювати або знищувати несанкціоновані ресурси поза межами своїх прав. Це можна зробити, реалізувавши належну авторизацію користувачів за допомогою Ruby-бібліотеки, такої як pundit або cancancan.
Наступні кроки
Відповідаючи на питання "Чи безпечний Ruby on Rails?": так, але лише якщо ви знаєте, що робите. В кінцевому підсумку, безпека — це складне, кросс-функціональне питання для всіх додатків, і єдиний спосіб бути настільки безпечними, наскільки це можливо, — це мати уважну та досвідчену команду.
Безпека залежить від людей, які використовують веб-фреймворк, але, як ви бачите, Rails має хороший набір вбудованих механізмів безпеки, які можуть запобігти найпоширенішим атакам. І ми, як користувачі фреймворку, повинні бути вдячні за це. Водночас деякі поширені ризики безпеки та вразливості не можуть бути запобігані фреймворком за замовчуванням, і ми повинні бути обізнані з питаннями безпеки. І знову ж таки, гарною практикою є регулярне сканування нашого додатку на вразливості.
Завжди будуть зловмисники, і потрібно бути готовими зустріти їх з самого початку.
Перекладено з: Is Ruby on Rails secure?