25 October 2014

MVC Model Binding Vulnerability

MVC Model Binding Vulnerability
Reference Link:
For example User Entity
public class User
{
    public string FirstName { get; set; }
    public bool IsAdmin { get; set; }
}
When you want to let a regular user change their first name, you give them the following form.
@using (Html.BeginForm()) {
   
     @Html.EditorFor(model => model.FirstName)
        
    
}
There is no input in the form to let a user set the IsAdmin flag, but this won't stop someone from crafting an HTTP request with IsAdmin in the query string or request body. Maybe they saw the "IsAdmin" name somewhere in a request displaying account details, or maybe they just got lucky and guessed the name.
composing the attack
If you use the MVC model binder with the above request and the previous model, then the model binder will happily move the IsAdmin value into the IsAdmin property of the model. Assuming you save the model values into a database, then any user can become an administrator by sending the right request. It's not enough to leave an IsAdmin input out of the edit form.
Fortunately, there are at least 6 different approaches you can use to remove the vulnerability. Some approaches are architectural, others just involve adding some metadata or using the right API.

Weakly Typed Approaches

The [Bind] attribute will let you specify the exact properties a model binder should include in binding (a whitelist).
[HttpPost]
public ViewResult Edit([Bind(Include = "FirstName")] User user)
{
    // ...
}
Alternatively, you could use a blacklist approach by setting the Exclude parameter on the attribute.
[HttpPost]
public ViewResult Edit([Bind(Exclude = "IsAdmin")] User user)
{
    // ...
}
If you prefer explicit binding with the UpdateModel and TryUpdateModel API, then these methods also support whitelist and blacklist parameters.
[HttpPost]
public ViewResult Edit()
{
    var user = new User();
    TryUpdateModel(user, includeProperties: new[] { "FirstName" });
    // ...
}

Strongly Typed Approaches

TryUpdateModel will take a generic type parameter.  You can use the generic type parameter and an interface definition to restrict the model binder to a subset of properties.
[HttpPost]
public ViewResult Edit()
{
    var user = new User();
    TryUpdateModel<IUserInputModel>(user);

    return View("detail", user);
}
This assumes your interface definition looks like the following.
public interface IUserInputModel
{
    string FirstName { get; set; }
}
Of course, the model will also have to implement the interface.
public class User : IUserInputModel
{
    public string FirstName { get; set; }
    public bool IsAdmin { get; set; }
}
There is also a [ReadOnly] attribute the model binder will respect. ReadOnly metadata might be want you want to use if you never want to bind the IsAdmin property. (Note: I remember ReadOnly not working in MVC 2 or MVC 1, but it is working in 3 & 4 (beta)).
public class User 
{
    public string FirstName { get; set; }

    [ReadOnly(true)]
    public bool IsAdmin { get; set; }
}

An Architectural Approach

Put user input into a model designed for user input only.
public class UserInputViewModel
{
    public string FirstName { get; set; }
}
In this approach you'll never bind against business objects or entities, and you'll only have properties available for the input you expect. Once the model is validated you can move values from the input model to the object you use in the next layer of software.
Based upon our convenience we can choose the approach.

12 October 2014

Revealing Module Pattern in Javascript

Revealing Module Pattern in Javascript


JavaScript Module pattern provides a way to wrap public, private methods (and variable) into a single entity and exposing only the public members to the world outside of module. This allows faster namespace resolution, avoid collision of the methods/variables with other global APIs since the namespace isn't populated with all many functions, and obviously provides cleaner code.

CalcModule = (function(){
            var mem = new Array(); //private variable

            var storeInMemory = function(val) {  //private function
                mem.push(val);
            };

            var add = function(a, b) {
                        var result = a + b;
                        storeInMemory(result); //call to private function
                        return result;
                    };

            var sub = function(a, b) {
                        var result = a - b;
                        storeInMemory(result); //call to private function
                        return result;
                    };

            var retrieveFromMemory = function() {
                        return mem.pop();
                    };

            return {
                add: add,
                sub: sub,
                popMemory: retrieveFromMemory
            };
})();

Instead we define all the functions public or not in the same way, and then in the return statement create a new object and add properties to it.

Advantages of Revealing Module pattern in Javascript
1. Consistent coding style inside the module for both private and public members.
2. Better control on the name of the public API, i.e., if it is required to change the name of add()         method to addition(), all we need to do is change the name in the return statement without effecting    the function name inside the module.
3.Control on what to make public, just adding/removing the properties in return statement is sufficient.
4.As always, cleaner code.

reference : http://viralpatel.net/blogs/javascript-module-pattern/

Consistency level in Azure cosmos db

 Consistency level in Azure cosmos db Azure Cosmos DB offers five well-defined consistency levels to provide developers with the flexibility...