Blanket accepting POST data to insert into your database is a terrible idea.

Rails gives you attr_accessible and attr_protected to alleviate this problem. Protip: the one from those two that you suggested to use is just as terrible an idea as allowing blind POST into your database. Blacklisting is always the wrong approach to security. I don't care if you have to repeat yourself and type more characters: use the whitelisting of attr_accessible.

But even if they're using attr_accessible to whitelist parameters, the failure mode here would have been exactly the same.

The real culprit is Apple. It's just not ok to add unexpected parameters to people's POSTs. If anything, they should have put it in an HTTP header instead.

I'm a Python/Django guy so I'm not intimately familiar, but is that really the case? I was under the assumption that the handler wouldn't pass any POST vars not in attr_accessible to the model. In which case additional, unexpected ones would become silently dropped.

According to http://guides.rubyonrails.org/security.html#countermeasures you're entirely correct that it won't raise any error, although the keys won't be dropped: attr_accessible drops the attributes when mass-assigned to a model, they're still available in the params hash.

> Mass assignment is a fairly normal thing to do

No, it's an abnormal thing to do and a security hole.

> any parameters you want the model to ignore can be marked as so

Which is complete insanity.

> Rails loves DRY.

Yes so does PHP, hence register_globals.

That's on the "idiotic" side of "I don't want to write stuff", and even the Rails staff stopped defending this insanity back in March.

If you want to argue against facts, please go elsewhere. Mass assignment is widely used in Rails.

Just because something is widely used does not mean it is not a security hole. Mass assignment is a security hole, plain and simple- in Rails and anywhere else.

> Mass assignment is widely used in Rails.

And register_globals was widely used in PHP, that does not make it anything but moronic.

I don't think register_globals has been widely used for at least 10 or 12 years. It's been deprecated for a while and was removed completely in 5.4.0.

Hence "was". It was widely used at one point, if only because it was enabled by default until 2002 (disabled by default was introduced in PHP 4.2)

I'm not a Rails guy, so you'll have to forgive ignorance here. Are you telling me that Rails only lets you blacklist parameters, not whitelist?

Because that seems entirely the wrong way around.

EDIT: looked at the link posted elsewhere here[1] and ound that it is possible to whitelist using "attr_accessible". Please tell me people know about and use this.

[1] http://guides.rubyonrails.org/security.html#mass-assignment

You can do either. The default used to be blacklist, but that was changed to whitelist recently.

You can do either. Whitelist is obviously preferred.

It allows either.

Sure, throw an error, but not a 5xx error. ISE 500 indicates that something went wrong on the server, not on the client. 400 Bad Request maybe?

I, for one, don't like having my application error logs polluted by script kiddies running against my wall...