Model Binding is quite a nice feature and may add a plus to the overall security if it is properly used.
Here is how it works (the code and the features apply to ASP.NET MVC but may be the same in Ruby):
Suppose you have a form in a web page:
<form action="/SendData">
Email: <input type="text" name="email" id="email"><br>
Address:<input type="text" name="address" id="address"><br>
<input type="submit" value="Submit">
</form>
You write a class like this:
class Contact{
String Email{get;set;}
String Address{get;set;}
}
With model binding the function that deals with the user request can be:
public ActionResult SendData(Contact contact){
//do something with contact.Email and contact.Address
}
As you can see, model binding automatically puts the data it received in the HTML request in an object of the type Contact.
Furthermore, you can define validation functions, by using DataAnnotations.
class Contact{
[Required(ErrorMessage="Input email please!")]
[RegularExpression("^some_regex"),ErrorMessage ="Error"]
String Email{get;set;}
[Required(ErrorMEssage="Input address please!")]
String Address{get;set;}
}
and check it like this:
public ActionResult SendData(Contact contact){
if(ModelState.IsValid)
{
//do something with contact.Email and contact.Address
}
}
As you can see, it easy to add validation and some common mistakes(like badly written SQL Queries may be avoided).
Now to explain the problem that lead to the GitHub hack (mass binding):
What happens if you have properties in your class that do not appear in the form:
<form action="/SendData">
Email: <input type="text" name="email" id="email"><br>
<input type="submit" value="Submit">
</form>
If an attacker also sends a variable with the name address, the framework will automatically bind it, without knowing that in the original form there was no such input.
In the GitHub case, the developers probably used an Object that had a property that differentiated between administrators and normal users(isAdmin for example). By sending this parameter in the login form (or another page), together with the user and password, the attacker could have gained access to administrative functionality.
There are several ways to solve this issue( blacklist binding, whitelist binding), but I recommend using Interfaces and Classes that only contain the properties from the form (or have the other attributed marked as read-only ).
Whitelist binding example:
public ActionResult SendData(
[Bind(Include="Email")]Contact contact)
{
//...
}
Regarding the affected frameworks, probably most of them are affected (Ruby and ASP are), but this is not a vulnerability itself, it's only bad programming. As long as the programmers address this functionality properly, everything should be OK.
I don't think that an automated tool could detect this kind of problems, but a thorough code review should solve it.
