Предотвратить модификацию («взлом») скрытых полей в форме в rails3? - PullRequest
1 голос
/ 24 сентября 2011

Допустим, у меня есть форма для отправки нового сообщения.

Форма имеет скрытое поле, в котором указывается идентификатор категории. Мы также на представлении шоу для этой самой категории.

Меня беспокоит то, что кто-то, использующий что-то вроде firebug, может просто отредактировать идентификатор категории в коде, а затем отправить форму - создав сообщение для другой категории.

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

Какие-нибудь решения?

EDIT:

Вот лучший вопрос - возможно ли получить идентификатор категории в контроллере создания для сообщения, если его нет в скрытом поле?

Ответы [ 3 ]

2 голосов
/ 24 сентября 2011

Есть ли у вашего сайта концепция списков разрешений / контроля доступа для самих категорий? Если бы у пользователя был доступ к другой категории, я бы сказал, что здесь нет проблем, поскольку ничто не мешает ему перейти в эту другую категорию и сделать то же самое.

Если ваши категории каким-либо образом ограничены, то я бы рекомендовал вложить ваше сообщение в категорию (маршруты вложенных ресурсов) и выполнить before_filter, чтобы обеспечить вам доступ к соответствующей категории.

config/routes.rb

resources :categories do 
  resources :posts
end

app/controllers/posts_controller

before_filter :ensure_category_access

def create
  @post = @category.posts.new(params[:post])
  ...
end

private
def ensure_category_access
   @category = Category.find(params[:category_id])
   # do whatever you need to do. if you don't have to validate access, then I'm not sure I'd worry about this.  
   # If the user wants to change their category in their post instead of 
   # going to the other category and posting there, I don't think I see a concern?
end

URL будет выглядеть как

GET /categories/1/posts/new СООБЩЕНИЕ /categories/1/posts

2 голосов
/ 24 сентября 2011

Никогда, никогда не доверяй пользователю, конечно; -)

Теперь, как уже говорилось, можно с очень высокой степенью достоверности полагаться на скрытые поля для временного хранения / размещения (хотя, как правило, это также может быть полностью обработано на сервере во время сеанса). а также): ASP.NET следует этой модели, и она оказалась очень защищенной от несанкционированного доступа при правильном использовании - так в чем же секрет?

Проверка хеша aka MAC (код аутентификации сообщения) . ASP.NET MAC и его использование кратко обсуждаются в этой статье 1014 *. Короче говоря, MAC - это хеш данных формы (созданный с использованием секретного ключа сервера и, возможно, сеанса), который встроен в форму как скрытое поле. Когда происходит отправка формы, этот MAC-адрес пересчитывается из данных и затем сравнивается с исходным MAC-адресом. Поскольку секреты известны только серверу, клиент не может (реально) сгенерировать действительный MAC из самих данных.

Однако я не использую RoR и не знаю, какие модули, если таковые имеются, могут реализовывать такие меры безопасности. Я действительно надеюсь, что кто-то может предоставить более глубокое понимание (в своем собственном ответе ;-), если такие решения существуют, потому что это очень мощная конструкция и легко допускающая безопасную для каждой формы связь данных и проверка.

Счастливого кодирования.

2 голосов
/ 24 сентября 2011

PST прав - никогда не доверяй пользователю. Дважды проверьте значение, отправленное через представление в вашем контроллере, и, если оно не соответствует чему-либо действительному, выгоните пользователя (автоматический выход из системы) и отправьте администратору электронное письмо. Вы также можете заблокировать учетную запись пользователя, если это происходит.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...