#ruby-on-rails #ruby #security
#ruby-on-rails #ruby #Безопасность
Вопрос:
Я в основном программист на Java, и на самом деле удивительно, что нам не нужно беспокоиться о множестве проблем безопасности, о которых приходится беспокоиться разработчикам php или даже rails. Нам приходится беспокоиться о них, но я думаю, что наша работа на самом деле намного проще. Вы просто используете Java (там уже есть большие бонусные баллы) и используете Spring с Spring security… и вы в основном закончили. Java и сервлеты на самом деле действительно хороши в этом отношении.
Теперь, когда я работаю в Rails, я думаю, что самые большие проблемы с безопасностью, которых я больше всего боюсь, — это параметры — как в тех, которые поступают от контроллеров (поскольку они динамические хэши, в отличие от SpringMVC), так и необходимость включать больше скрытых значений в формы.
Но это заставило меня задуматься — вам действительно нужно быть осторожным с тем, что вы принимаете при создании новых моделей или даже обновлении моделей. Если вы просто слепо передаете параметры своим моделям, могут произойти плохие вещи. На самом деле, такие вещи, как роль пользователя и прочее, могут быть изменены, если вы не будете слишком осторожны.
Это почти как если бы я хотел написать код настройки вручную, чтобы убедиться, что он не перезаписывает то, чего не должен. И даже если есть рамочный механизм для обработки этого… Я бы все равно хотел протестировать каждый рискованный атрибут модели, просто чтобы быть более уверенным, что он не будет перезаписан при создании и обновлении.
Несмотря на то, что Java пользуется дурной репутацией в плане производительности, кажется, что она справляется с этим материалом намного лучше.
В любом случае, мой вопрос заключается в следующем: какой лучший ресурс / советы / advice для устранения распространенных ошибок безопасности / проблем / подводных камней с использованием rails — особенно ориентирован на разработчика Java / Spring, который привык работать в среде с более точным отслеживанием состояния.
Еще лучше, какой был бы хороший контрольный список, который нужно периодически просматривать?
И последнее, какие тесты вы бы порекомендовали, чтобы убедиться, что все надежно?
Ответ №1:
По крайней мере, из-за вашей озабоченности по поводу назначения данных объектам вашей модели без надлежащей проверки, загляните в attr_accessible объявление; оно позволяет назначать только указанные атрибуты посредством массового присвоения:
user = User.new(params[:user])
user.approved = params[:user][:approved]
user.role = params[:user][:role]
Возможно, вам пригодится вся 27-я глава книги Ruby on Rails 3rd edition. (Я еще не обновил свое 4-е издание книги, не уверен, какую главу рекомендовать из новой книги. 🙂
Комментарии:
1. Другие методы ActiveModel::MassAssignmentSecurity также могут быть полезны.
2. Я обязательно изучу их подробнее. Я все еще боюсь, что когда вы создаете нового пользователя, устанавливаете роль, но не раскрываете роль, я предполагаю, что вы повторно установили роль снова, когда сохраняете пользователя. Верно? При обновлении, вероятно, меньше проблем с attr_accessible … но создание кажется наиболее рискованным.
Ответ №2:
Я не использую ActiveRecord (я использую DataMapper), но, как правило, я никогда не выполняю массовое присвоение и всегда явно передаю только те атрибуты, которые хочу изменить. Rails 3 по умолчанию экранирует все содержимое в ваших представлениях, если вы явно не выводите эти необработанные данные в .erb.
Кроме того, меня действительно беспокоит, что ActiveRecord не очень помогает вам, если вам нужно перейти к использованию SQL для чего-то. Вы должны избегать ввода самостоятельно, что может подвергнуть вас риску человеческой ошибки, позволяющей выполнять произвольный SQL в ваших запросах. Базовое соединение DataMapper с DataObjects поддерживает готовые инструкции «из коробки», и фактически, потребовалось бы больше работы, чтобы избежать их использования.
В Rails 3 также включена защита CSRF по умолчанию. Также по умолчанию сеансовые cookie-файлы доступны только для HTTP, что затрудняет их кражу с помощью JavaScript.
Я действительно думаю, что, помимо того, что Rails поощряет использование массового назначения, вы довольно хорошо защищены в плане безопасности.
Комментарии:
1. ActiveRecord 3.1 (наконец) по умолчанию использует подготовленные инструкции.
2. Хорошая информация. Не могли бы вы прокомментировать создание новых записей? Например, в Java действительно часто, когда вы создаете новый объект, вы сначала настраиваете все необходимые ассоциации… но в Ruby эти ассоциации будут потеряны при отправке формы, если они не указаны в скрытых параметрах. Итак, вы настраиваете их при сохранении нового объекта? Кроме того, если вы можете прокомментировать, как вы тестируете длинные списки параметров, это было бы потрясающе.
3. Я вас не понимаю. Где данные формы попадают в ассоциации? Ассоциации обычно выводятся из параметров URL, если ваш дизайн RESTful. Например,
POST => /posts/:post_id/commentsвключает в себя:post_id, для которого вы делаете комментарий, поэтому сначала найдите этоPost, затем создайтеCommentдля него. Хотя я не совсем понимаю, что вы имеете в виду.4. Допустим, у вас есть образец для подражания и модель пользователя. Пользователь связывается с ролью. Вы определенно не хотите иметь /roles / 1 /user для создания нового пользователя 😉 Это то, что вы хотите сохранить за кулисами, не так ли? Итак, когда вы выполняете User.new, вы еще не можете передать роль. В Java вы можете — потому что вы можете отслеживать состояние на сервере. Ruby не сможет этого сделать, если вы предварительно не сохраните его. Java работает в памяти постоянно, в отличие от Ruby. Итак, я вижу единственный способ связать роль с пользователем, когда вы выполняете действие Post. Правильно?