SQL Injection

Ruby on Rails — чудовий фреймворк для створення веб-додатків. Він надає безліч чудових функцій, використовується багатьма організаціями, а мова є однією з найкращих для вивчення для нових розробників. Як би захоплююче не було стрибнути в програмування, створення програми не обходиться без певних ризиків. Як і всі мови програмування, Rails чутливий до різних вразливостей безпеки. OWASP (Open Web Application Security Project) регулярно оновлює список десяти найбільших уразливостей у програмуванні. У цій публікації я маю намір розглянути деякі з цих поширених уразливостей, про які, на мою думку, повинен знати новий розробник Rails, і надам деякі ресурси, як уникнути інших.

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

https://rails-sqli.org/

Sessions

Сесії — це фантастичний спосіб розшифрувати маркер автентифікації користувача та зберегти інформацію про нього, не змушуючи його входити на кожній сторінці або щоразу, коли він повертається до вашої веб-програми. Однак, хоча вони є більш безпечними, ніж традиційні файли cookie, вони не мають власного набору вразливостей. По-перше, в Rails термін дії сеансу не закінчується. Щоб пом’якшити це, найкраще було б реалізувати gem, як-от devise, який дозволить користувачам виходити з сеансу після закриття програми, або налаштувати вікно закінчення терміну дії. Нижче наведена документація для налаштування вікна закінчення сеансу. Знімок екрана з: https://guides.rubyonrails.org/security.html

По-друге, сеанс також може бути вразливим до різноманітних форм викрадення сеансу. Згідно з Вікіпедією, існує чотири основні методи, які використовуються для захоплення сеансу користувача: фіксація сеансу, підключення до сеансу, міжсайтові сценарії та зловмисне програмне забезпечення. Для отримання додаткової інформації перейдіть за посиланням: https://en.wikipedia.org/wiki/Session_hijacking

Gem Vulnerabilities

Ruby gems значно полегшують життя. Бібліотеки gem, такі як Twilio, bcrypt, bootstrap, rest-client та багато інших, можуть додати багато динамічних функцій до веб-додатків. Пошук нових може бути дуже захоплюючим. Однак вони не приходять без власних турбот. Оскільки Ruby є відкритим вихідним кодом, погані актори можуть скористатися перевагами різних бібліотек. У липні спільнота, відповідальна за підтримку Ruby Gems, видалила 18 шкідливих версій 11 бібліотек gem, одна з яких була клієнтською. Знімок екрана з www.zdnet.com/article/backdore-code-found-in-11-ruby-libraries/

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

Конфіденційні файли

Оскільки багато веб-додатків розміщено на GitHub, більшість їхніх репозиторіїв можуть бути доступними та перегляданими іншими. Тому було б гарною ідеєю видалити ці конфіденційні файли, перш ніж надсилати їх на Github. OWASP пропонує список прикладів файлів для видалення. Знімок екрана взятий із https://cheatsheetseries.owasp.org/cheatsheets/Ruby_on_Rails_Cheatsheet.html

Ensuring Users are being Secure

Існує кілька способів переконатися, що, коли користувач використовує вашу програму, він використовує найкращі методи, щоб зробити себе менш вразливими до будь-яких потенційних експлойтів. Обов’язково налаштуйте суворі та надійні перевірки, які гарантують, що користувач використовує вашу програму за призначенням. Якщо вони зберігають пароль, не забудьте вказати параметри перевірки, щоб переконатися, що їхній пароль містить суміш великих і малих літер, цифр і символів. Крім того, переконайтеся, що ваш спосіб зберігання паролів не зберігає їх у вигляді простого тексту. Такі дорогоцінні камені, як bcrypt і divise, є чудовими ресурсами, які гарантують, що користувачі створюють складні паролі, і що вони не зберігаються як звичайний текст.

Крім того, розгляньте можливість надання або посібника, або певної документації, щоб надати користувачам найкращі методи використання вашої програми (не використовуйте повторно паролі, не використовуйте звичайні паролі, не передавайте конфіденційні дані через невідомі мережі тощо). Жоден додаток не є на 100% захищеним, тому ми робимо все можливе, щоб наші користувачі робили все, щоб захистити себе так само, як ми робимо наші, щоб захистити їх.

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

Посилання на ресурси:
Ruby’s guidelines on handling security: https://guides.rubyonrails.org/security.html

Rails’ examples on how not to write sql queries: https://rails-sqli.org/

Resource on Common Vulnerability Exploits: https://www.cvedetails.com/vulnerability-list/vendor_id-12043/product_id-22568/Rubyonrails-Ruby-On-Rails.html

OWASP Ruby on Rails Vulnerability CheatSheet: https://www.owasp.org/index.php/Ruby_on_Rails_Cheatsheet

Посилання на оригінал статті: https://kmarks2013.medium.com/5-common-rails-security-vulnerabilities-58d39be9a270