Over the last two cycles of OWASP top 10, insecure direct object reference has been included as major security risk. An object reference is exposed and people can manipulate that to access other objects they aren't supposed to. But an apparently lesser-known problem is when the object itself is directly exposed. This happens when an object maps user-controlled form data directly to it's properties with out validation.
Perhaps this issue gets less press because every language calls this problem something different. In ruby, people call this mass assignment. In .NET and Java it's often referred to as reflection binding. Regardless of name, it is how the object obtains it's data which is of concern.
The params call wants to make life easy and will automagically map any form data that matches the object's parameters for you—unless you say otherwise. This is a very common convention used in MVC frameworks, because manually mapping a form POST to an object is annoying. The problem here is that it makes no difference to the controller whether you've exposed that field in the presentation layer. It just has to exist on the object.
In other words-- if you were updating a product quantity for your shopping cart, you might be able to change the price by guessing that a price field exists. Just add the price field to your POST parameters and it might override the value. This approach can be effective—but it is mostly a guessing game at that point. Some frameworks let you throw tons of arbitrary data and whatever sticks, sticks. Others will barf on invalid parameters.
With out any other validations, this is all kosher.
In the wild I've used this attack to escalate privileges by updating my profile and walking down to a permissions table. I've also run across places where you could register every user to come to an event. And another instance where you could take over other people's blog posts simply by editing your own profile.
This vulnerability is best identified with access to source code—and very few developers seem to protect against it.
When reviewing code, pay attention to how the constructor works and how fields are set on the object. Some properties are set via functions and you can't bind them directly. Other objects don't have empty constructors. This causes the attack to fail.
I frequently find this vulnerability on "update" and "create" controller actions.
You can, and I have, found this w/o source—its just harder. You do so by creating a loose type map through browsing the site.
Going to the object's "create" page and note all the form fields that are there. That is your basic "object". As you see these objects in other places on the site, they might reveal more about their structure.
The site will guide you in what you need to know about object relationships. If you are looking at your cart, and it has a list of products & their details-- the cart object has a list of products.
For everything else, there are common object relationships you can just assert. Carts do generally have products, just as people generally have permissions. Take some time and look over common object models on the interwebs.
This attack route exists on pretty much every MVC based framework. In particular, Spring, Struts, MVC.Net and Ruby on Rails are all vulnerable. Maybe others, but those are so popular I've not really looked much deeper into it.
It is true that developers can prevent this by white listing specific fields to bind—but they don't. The whole point of the convenience functions is convenience. If you've built an MVC application and didn't go out of your way to protect against this—you are most likely vulnerable to it.