Mass assignment vulnerability references

I am a fan of ASP.NET MVC. I am also a fan of security. The two posts below combine those interests by describing how to mitigate mass assignment vulnerabilities.

• What ASP.Net MVC Developers Can Learn From GitHub’s Security Woes
• 6 Ways To Avoid Mass Assignment in ASP.NET MVC

I am posting these so that my team can refer to them in future if needed.

Here's a bonus link. I can never remember this syntax: How to join two collections with LINQ

remove web transform files

Today I am sharing the process that I used to remove web.config transforms after a build. I wish that I could claim that I was able to implement this in a knowledge vacuum, but I had some help. As you can see, all I am doing is creating a list of all files not named web.config and then deleting them.

  <Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
    <ItemGroup>
      <DeleteAfterTransform Include="$(OutDir)_PublishedWebsites\$(TargetName)\Web.*.config" Exclude="$(OutDir)\_PublishedWebsites\$(TargetName)\Web.config" />
    </ItemGroup>
    <AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
    <Message Text="WebProjectOutputDir: $(WebProjectOutputDir)" Importance="low" />
    <Message Text="OutDir: $(OutDir)" Importance="low" />
    <Message Text="TargetName: $(TargetName)" Importance="low" />
    <Message Text="ProjectConfigTransformFileName: $(ProjectConfigTransformFileName)" Importance="low" />
    <TransformXml Source="Web.config" Transform="$(ProjectConfigTransformFileName)" Destination="$(OutDir)\_PublishedWebsites\$(TargetName)\Web.config" />
    <Message Text="Preparing to remove config transform files." />
    <Message Text="Files: @(DeleteAfterTransform)" />
    <Delete Files="@(DeleteAfterTransform)">
      <Output TaskParameter="DeletedFiles" PropertyName="deleted" />
    </Delete>
    <Message Text="Deleted Files: $(deleted)" />
  </Target>

I hope that you find this post useful.

WCF Web API security in a domain

I've been building REST services using WCF Web API for use in an intranet. Upon deployment from my desktop to a server I started experiencing the error below even though the hosting application, ASP.NET MVC 3, was successfully using Windows authentication.

System.NotSupportedException: Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service.

A Google search shows that this isn't a novel situation, but I couldn't get the configuration and incantation right for Web API. Luckily, after a couple of hours of researching and fiddling with the web.config, I came across this post that revealed the solution to me.

When registering the service route:

var config = new HttpConfiguration();
   config.Security = (u, s) => {
      s.Transport.ClientCredentialType = System.ServiceModel.HttpClientCredentialType.Windows;
      s.Mode = HttpBindingSecurityMode.TransportCredentialOnly;
   };

   routes.MapServiceRoute<YourType>("YourRoutePrefix", config);

I hope that this post saves someone some time.

MvcBuildViews in a CI environment

This post isn't going to break any new ground in the world of computer science, but I still wanted to say a few words about the importance of using MvcBuildViews in your continuous integration environment.

My team had just finished a quick and slightly dirty ASP.NET MVC 3 project. The three of us rapidly created a very usable internal departmental financial application with two of the members of the team being ASP.NET MVC neophytes. A lot of learning occurred during development, both about the basics of HTTP and client scripting as well as Visual Studio's ASP.NET MVC 3 tooling.

I was finishing off numerous TODO's toward the end of the project when I entered "/p:MvcBuildViews=true" in the MSBuild arguments section of the Team Build process tab. The build crashed immediately due to nonexistent namespace issues. It seems that a family of CRUD Views had been created at some point that used a Model that no longer existed. Apparently the plan had been to go back and clean up dead code, but there was never any follow-up due to other priorities. The dead Views certainly weren't hurting anything. Also, a user could only access them if they somehow typed in the correct URL, a near impossible eventuality. However, I abhor dead code and extra files in a project. It not only distorts the size and complexity of a project but also increases the size of the deployment.

Using MvcBuildViews helped me remove four Views from our final deployment package. That's a trivial amount for large, enterprise projects. However, for a small department application likes ours, that's 20% of the Views. So not only are there now dramatically fewer Views to manage, the steepness of the learning curve for new developers is reduced.

Anyone looking for work in Kathmandu?

I certainly have never been contacted about such an exotic job opportunity!

On November 16, 2011 at 1:00 AM Fine Tuners  wrote:

Dear Sir/Madam,
 
We have explored your company as one of the best ever growing software development company.  This is what we are interested in. 
FineTuners is a Kathmandu based software development and web development company. Our Outsourcing firm is  located at the heart of Nepal, Kathmandu. Nepal is well known for its culture, natural resources and on the top for Mount Everest, the highest pick of the world.
At present we are mainly focusing on the following areas as per the need of ever growing market:
·        Web services( Slicing/ Development/ full shop)
·        Web applications from simple web portals to the dynamic ecommerce sites)
We are a highly experienced team of intellectuals who are versatile in different development tools. Actually we are providing with different kinds of services, based on your requirement which you can choose. Else you can let us know the brief requirements of your projects such as technology, and services you require.
If this is the interest of yours, we are always standby to assist. You can explore us more via: www.fintuners.com . We are here to provide you with unlimited opportunities.
 
We offer you a trail project. If you like the work, then you pay us else you don’t have to pay for what is done. This is the best deal we can offer you to build up the trust.
     
     
    -- 
     
    -- 
    Best Regards,
    Sachit Pokhrel
    FineTuners
    www.fintuners.com
    skype: sunilpokharel1

SSRS 2208 Multi-value Default Parameters Not Being Used

I spent about an hour trying to track down what was causing my default multi-values from appearing in Business Intelligence Development Studio (BIDS) AKA Visual Studio 2008 (VS2008).

My dataset is simply a one-dimensional list of names of human beings, such as John Doe. The default values are were a subset of those names but they were not being selected either in Preview in BIDS or on the server.

This post gave me the idea to check my list of default values against the dataset. I knew that I didn't have NULL values in my dataset, but I realized that I did have some default values that didn't correspond to the list of values in my dataset. The default values had until recently matched their counterparts in the dataset, but staff turnover had changed two of the values from "Firstname Lastname" to "Firstname Lastname (DOMAIN\USERNAME)". As soon as I removed the two non-corresponding values all was well- the default values were selected as desired and the report again started executing as expected.

ELMAH, NuGet, SQL Server Compact 4.0, and EF Code-First

ELMAH + NuGet + SQL Server Compact 4.0 + EF Code-First = Trouble!

Following Scott Hanselman's directions, I installed ELMAH on Microsoft SQL Server Compact 4.0 (SQL CE). Because of the dependency of 'ELMAH on MS SQL Server Compact' on SQL CE (and I already had the 'Manage NuGet Packages' window open) I let NuGet install it for me. NuGet installed everything perfectly and soon I was happily logging exceptions and storing them in a *.sdf file. Cool.

I also used NuGet to install Entity Framework 4.1 and followed Scott Guthrie's post on Code-First Development with Entity Framework 4. I created a model, added a connection string to my ASP.MVC 3 application, and soon I was persisting data to a second *.sdf file. Still cool.

Finally it was time to push my application to a server. This is where things became uncool.

Could not load file or assembly 'System.Data.SqlServerCe.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.

After confirming that System.Data.SqlServerCe.Entity was in the bin directory, I started reviewing the versions of the SQL CE files, and then just to be sure I copied all of the files from my local installation of SQL CE to the server again. The problem still persisted.

I had used NuGet to install the version of SQL CE that ELMAH was using so I decided to research what the expected file versions were. These two great posts by ErikEJ caused me to formulate a theory that perhaps ELMAH and EF 4.1 were using the wrong or conflicting file versions. I made two changes to my application to test my theory.

1. Altered DbProviderFactories in my web.config file as described in this article.
2. Set up a binding redirect for System.Data.SqlServerCe as described in this article.

After making these two changes exception logging and data persistance to my two compact databases started working on the server. Maybe it's just me but it seems that a significant percentage of development troubleshooting is pure intuition!