Риск
- При `User.new(params[:user])` злоумышленник может передать в `params[:user]` любые поля модели (например `admin`, `role`, `balance`, `user_id`, `approved_at`), тем самым эскалировать привилегии или изменить данные, к которым не должен иметь доступа. Пример: запрос с `{ user: { name: "Evil", admin: true } }` сделает пользователя админом при отсутствии ограничений.
Способы защиты (практические)
- Strong Parameters (Rails $4+$): явно разрешать поля:
- Пример: `user = User.new(params.require(:user).permit(:name, :email, :password))`
- Для старых версий (Rails $3$) — whitelist через `attr_accessible` или использовать гем `protected_attributes` (но лучше обновиться).
- Явное присвоение полей вручную:
- `user.name = params[:user][:name]` и т.д. — безопаснее при небольшом количестве полей.
- Ограничение на уровне модели:
- `attr_readonly` для полей, которые не должны меняться после создания.
- Валидации/колбеки: игнорировать изменения чувствительных полей, если пользователь не имеет права.
- Ограничение вложенных атрибутов: `accepts_nested_attributes_for :profile, reject_if: ...` и разрешать только нужные атрибуты.
- Авторизация на уровне объектов: использовать Pundit/CanCanCan — даже если поле передано, проверить, имеет ли текущий пользователь право на изменение.
- Логирование и мониторинг необычных изменений (изменение ролей, балансов и т.п.).
- В тестах покрыть случаи mass-assignment и проверки, что чувствительные поля не меняются через контроллеры.
Другие типичные уязвимости веб‑фреймворков и краткие контрмеры
- SQL Injection — использовать параметризованные запросы/ORM (ActiveRecord), не подставлять строки в SQL.
- Cross‑Site Scripting (XSS) — экранировать вывод по умолчанию, использовать `sanitize`, Content Security Policy.
- Cross‑Site Request Forgery (CSRF) — включить и проверять токены (`protect_from_forgery`), для API — использовать токены/CSRF‑защиту по другому.
- Insecure Direct Object References (IDOR) — проверять права доступа к ресурсам, не полагаться на идентификаторы в URL.
- Remote Code Execution / Unsafe Deserialization — не вызывать `eval`, не использовать `YAML.load`/marshal на данных от пользователя; использовать безопасные парсеры.
- Server‑Side Request Forgery (SSRF) — валидировать и ограничивать URL/хосты, куда сервер делает запросы.
- File upload vulnerabilities — проверять тип содержимого, размеры, сохранять вне веб‑корня, сканировать файлы.
- Open redirects — валидировать целевой URL при редиректах.
- Clickjacking — установить `X-Frame-Options`/CSP frame-ancestors.
- Недостаточная аутентификация/брютфорс — использовать безопасные хеши паролей, rate limiting, MFA.
Короткий чеклист при разработке
- Всегда белый список параметров в контроллерах.
- Принцип наименьших привилегий и централизованная авторизация.
- Экранирование вывода и стандартные механизмы защиты (CSRF, CSP).
- Проверка и валидация входящих данных, отказ от небезопасной десериализации.
Это покрывает основную суть риска mass assignment и практические способы защиты, а также другие распространённые уязвимости и контрмеры.