ASP.NET MVC

By now, developers should really understand how to build a form and properly secure it. But this still seems to allude some. It’s rather embarrassing to fail security assessments for certain secuirty flaws that can be easily avoided.

In this blog, a refresher on the basics will be covered for securing your post as well as writing an extension to add to your MVC Infrastrucutre to be used by all of your team members.

It does not cover data validation. I am really focusing on the form and the action of that form. In addition, this is also from the perspective of a business web application that is only accessed via an authenticated user.

Let’s get started…

Poorly Secured Form and Action

Let’s take a simple Edit many developers write everyday and show the numerous flaws with this. Here is the Razor View:

When a user navigates to the Edit page for from a link, double clicking a row in a grid, or by any other means, that action should be called via a HTTPGet; therefore the first Action is called due to the HTTPGet attribute on that method. Once on that page, the user then modifies the data and clicks a submit button in a form performing a POST thus calling the second Action decorated with HTTPPost.

When do you want to use an ActionMethodSelectorAttribute? In my opinion, pretty much on every Action in your controller.

Rules to live by:

1. If you are selecting data to display in your Action method, then your Action should be decorated with the HTTPGet Attribute.

2. If you are creating, updating or deleting data via your Action method, then your Action should be decorated with the HTTPPost Attribute.

Oh, and by the way, using HTTPPost helps prevent some attacks via CSRF (see next section). Without that ActionMethodSelectorAttribute, it’s easy for a hacker to create links that a user can click and unknowingly modify their data.

Without the HTTPPost a well crafted link (obviously depending on your model and your action etc…) can be used to update sensitive info. Even worse, if your id is just an identity column in SQL Server and if you did not properly secure your form, a hacker could call this link over and over again for each identity id in your database, thus updating your data to what ever he wants.

Pretty scary if your site really contains sensitive information like account information, employee data or critical business processes that if disrupted by a hacker causes serious damage to your company’s reputation.

So use HTTPPost and you will prevent the above hacks via get from working.

Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is the #8 security flaw on the OWASP Top 10 for 2013. Follow the link for great information about CSRF. For nitty grittey detail, read “Part 5: Cross-Site Request Forgery (CSRF), 1 Nov 2010 in Troy Hunt’s OWASP Top 10 book. It’s free. This will explain in great detail how an attacker can take advantage of your site. Luckily for us, we don’t have to implement the “Synchronizer Token Pattern” as Tony explains. Instead, we just need to add the following in our form:

@Html.AntiForgeryToken()

Then on the Controller’s Action, the following ActionFilter must be added.

Note: The user must accept cookies. This only works with POST Requests. It does not work with GET Requests.

Without a valideAntiForgeryToken, the server will threw exceptions like the following:

Can this be circumvented? Why, yes…. But, a hacker has to actually get the AntiForgeryToken, then craft a POST using the correct form values. Gettign the AntiForgeryToken is possible if your site is vulnerable to XSS or your users are on older browser’s that allow cross-domain access. Therefore, dropping support for older browsers in web applications is critical when the data is sensitve. But that might be easier said than done.

The next step is to check the referrer.

Checking the Referrer

The next issue that I see with the above code is that the post could originate from another site. There are expections, but for most business web application, a post originates from your site.

In order to check the referrer, you need to write a Attribute that inherits from AuthorizeAttribute:

Checking the Origin

Authenticated or Authorized

Next check the user to see if the user is authenticated and authorized to perform the action.

Finally

Build an HTML Extension to make this even easier to follow in your Business Application. It is so easy to do…

Conclusion

These techniques help tremendously when securing your site, protecting your data and for passing security assessments. So don’t forget to use them in all your forms and protect your reputation, your companies reputation and your bottom line.

Using server filtering is rather easy with Kendo UI MVC, unless your new to it. Then that first couple hours is pretty frustrating untill you find the right article, information and samples. I have very few gripes with Telerik and Kendo UI but they do have a problem with the Kendo UI Demos. They do not include enough sample code from controllers and web services. So hopefully this will help out those newbies to KendoUI.

When would I use this?

Server-side Filtering, Paging, and Sorting with the Grid or ListView.

How to use it?

When would I use this? Server-side Filtering with the Grid or ListView.

First thing you want to do is add the following the following using statement to you Controller or API Controller:

using Kendo.Mvc.Extensions;

Now, you can easily take advantage of ToDataSourceResult extension method to convert any IQueryable or IEnumerable to a DataSourceResult object. It will help you page, filter, sort or group your data using the information provided by the DataSourceRequestObject.

Now in the method, you just call ToDataSourceResult on your IQueryable or IEnumerator. Pretty simple, although you have to be careful when dealing with large volumes of data o make sure your implementation does not return all the data before applying filter, sorting, and paging.

How is ToDataSourceResult being implemented under the hood by Telerik? C# Extension Methods. If you need a refresher, check it out here: