Обзор безопасности приложений, ориентированный на Ruby on Rails.
Хотя может показаться заманчивым отдавать предпочтение скорости и функциональности во время разработки, пренебрежение безопасностью может иметь серьезные последствия как для приложения, так и для его пользователей.
XSS, CSRF, IDOR и SQLi — звучит знакомо? Вот некоторые из страшных уязвимостей, которым может быть подвержено веб-приложение, и отсутствие достаточной бдительности при создании может привести к ненужной эскалации и поставить под угрозу рост вашей расширяющейся клиентской базы.
Некоторые из бизнес-рисков включают утечку данных и нарушение конфиденциальности, атаки типа «отказ в обслуживании» и финансовые потери, ведущие к отсутствию доверия клиентов и ущербу для репутации.
Итак, какие они?
XSS относится к межсайтовому скриптингу. Вредоносные скрипты внедряются в веб-приложение, которое затем запускается в браузерах ничего не подозревающих пользователей. Эти скрипты могут красть конфиденциальные данные, манипулировать сеансами пользователей или искажать веб-сайт.
CSRF — атаки с подделкой межсайтовых запросов обманом заставляют аутентифицированных пользователей неосознанно выполнять нежелательные действия на веб-сайте, используя их аутентифицированный сеанс.
Перехват сеанса происходит, когда злоумышленник крадет идентификатор сеанса пользователя путем перехвата или другой успешной атаки и использует его, чтобы выдать себя за пользователя без необходимости аутентификации.
Фиксация сеанса происходит, когда злоумышленник устанавливает идентификатор сеанса пользователя до входа пользователя в систему. После входа пользователя злоумышленник может использовать фиксированный идентификатор сеанса, чтобы выдать себя за пользователя и получить несанкционированный доступ.
Внедрение SQL происходит, когда злоумышленники вставляют вредоносный код SQL в поля ввода пользователя, тем самым манипулируя запросами к базе данных приложения.
IDOR — атаки с использованием небезопасных прямых ссылок на объекты происходят, когда злоумышленники манипулируют URL-адресами или параметрами для доступа к ресурсам, на просмотр или изменение которых у них нет прав.
Массовое назначение — это уязвимость в системе безопасности, которая может возникнуть, когда разработчики позволяют пользователям одновременно устанавливать несколько атрибутов объекта, а злоумышленник использует эту возможность для манипулирования конфиденциальными атрибутами или получения несанкционированного доступа к приложению.
Перенаправления и перенаправления позволяют динамически перенаправлять пользователей на основе вводимых пользователем данных. Злоумышленники могут использовать непроверенные переадресации и перенаправления для перенаправления пользователей на вредоносные веб-сайты.
Насколько плохо?
В 2009 году Twitter, который тогда работал на Rails, обнаружил уязвимость перечисления пользователей в своих конечных точках API. Злоумышленники могут определить, действительно ли имя пользователя, наблюдая за ответом API. Затем эта информация может быть использована для социальной инженерии или целевых атак. Больше здесь.
Github в 2012 году столкнулся с инцидентом безопасности из-за уязвимости массового назначения. Уязвимость позволяла злоумышленникам получить административный доступ к существующим репозиториям.
По словам Томаса Престон-Вернера, основной причиной уязвимости стала неправильная проверка входящих параметров формы.
Shopify пострадал от уязвимости Insecure Direct Object References (IDOR) в 2019 году. Злоумышленники манипулировали URL-адресами для доступа к ресурсам, для которых у них не должно было быть разрешения, ставя под угрозу данные магазина клиентов. Больше здесь.
На протяжении многих лет сам официальный гем Rails страдал от множества уязвимостей. Благодаря активному сообществу разработчиков исправления CVE регулярно внедряются в каждую версию Rails, а изменения хорошо документируются.
Что вы можете сделать?
Основные действия по предотвращению общих уязвимостей остаются одинаковыми в разных языках программирования. Rails, например, включает превентивные меры безопасности в свои модули по умолчанию. Кроме того, рекомендуется использовать инструменты анализа уязвимостей, такие как Brakeman.
Некоторые из предварительных действий, которые следует рассмотреть, включают:
XSS
Всегда очищайте пользовательский контент перед его отображением на веб-страницах.
Внедрите политику безопасности контента (CSP) на своем веб-сервере, чтобы контролировать, какие ресурсы могут быть загружены браузером, и ограничивать источники, из которых могут выполняться сценарии. Это предотвращает запуск неавторизованных скриптов на ваших веб-страницах.
CSRF
Используйте встроенную в Rails защиту от CSRF, добавив protect_from_forgery в файл ApplicationController. Убедитесь, что для любых конфиденциальных действий, таких как обновление или уничтожение данных, требуется токен аутентификации для предотвращения атак CSRF.
SQLI
Используйте интерфейс запросов ActiveRecord для предотвращения уязвимостей SQL-инъекций. Фактические значения отправляются в базу данных отдельно от SQL-запроса, что исключает возможность непосредственного добавления пользовательского ввода к оператору SQL.
user = User.where("username = ? AND password = ?", params[:username], params[:password]).first
Это предотвращает потенциальную инъекцию, поскольку БД обрабатывает пользовательские входные параметры как данные, а не как исполняемый код SQL.
Кроме того, ActiveRecord автоматически экранирует специальные символы и очищает вводимые пользователем данные при построении запросов. Это гарантирует, что любые символы, которые могут быть интерпретированы как команды SQL, обрабатываются как обычные данные.
ИДОР
Всегда применяйте надлежащие проверки авторизации, чтобы пользователи могли получать доступ только к тем ресурсам, которые им разрешено просматривать или обновлять. Такие библиотеки, как Devise, могут использоваться для аутентификации и авторизации пользователей.
Массовое назначение
Strong Parameters — это функция, представленная в Rails 4, которая позволяет вам указать, какие атрибуты разрешены для массового назначения. Он обеспечивает безопасный способ внесения атрибутов в белый список и отклонения любых неожиданных параметров.
Используйте настраиваемые обратные вызовы и проверки в модели, чтобы обеспечить дополнительные проверки безопасности разрешенных атрибутов. Сюда могут входить проверки, основанные на роли пользователя, статусе ресурса или других критериях, специфичных для приложения.
Будь проще?
Добавляя дополнительные проверки и балансы доступа для предотвращения потенциальных угроз приложениям, мы стремимся сделать систему более сложной. Крайне важно найти баланс между воротами безопасности и модульностью системы.
Дизайн системы должен быть простым для понимания и расширения. В то же время об известных уязвимостях следует позаботиться как можно скорее.
Простая система повышает осведомленность пользователей о рисках безопасности, упрощает обновления и исправления, позволяет быстрее реагировать на угрозы и сводит к минимуму человеческие ошибки. Простота есть основа утонченности.
Защита вашего приложения от распространенных проблем безопасности необходима для эффективной защиты конфиденциальных данных. Упреждающие методы обеспечения безопасности являются важным аспектом создания надежных и безопасных приложений Rails.
Потратьте время на то, чтобы понять и устранить эти потенциальные угрозы, чтобы создать заслуживающий доверия пользовательский опыт.
Если вам интересны подобные истории, подписывайтесь/подписывайтесь на меня.
Ресурсы для дальнейшего чтения
https://cheatsheetseries.owasp.org/cheatsheets/Ruby_on_Rails_Cheat_Sheet.html
