Contents tagged with Security

  • Security Issue in ASP.NET MVC3 JsonValueProviderFactory

        Introduction:

              Model binding(a mechanism for mapping action method parameters with request data), is one of the most popular feature of ASP.NET MVC. The default model binder get its data from different value providers. In ASP.NET MVC 2, by default, these value providers include FormValueProvider, QueryStringValueProvider, RouteDataValueProvider and HttpFileCollectionValueProvider. ASP.NET MVC 3 added two additional value providers, ChildActionValueProvider and a value provider for Json. Json value provider makes it very easy to model bind your action method parameters with incoming Json data, but I have found a security issue with this value provider.  In this article, I will show you the security issue regarding Json value provider and also show you how to protect against this security threat.

  • Understanding 400 Bad Request Exception

        Introduction:

              Why I am getting this exception? What is the cause of this error. Developers are always curious to know the root cause of an exception, even though they found the solution from elsewhere. So what is the reason of this exception (400 Bad Request).The answer is security. Security is an important feature for any application. ASP.NET try to his best to give you more secure application environment as possible. One important security feature is related to URLs. Because there are various ways a hacker can try to access server resource. Therefore it is important to make your application as secure as possible. Fortunately, ASP.NET provides this security by throwing an exception of Bad Request whenever he feels. In this Article I am try to present when ASP.NET feels to throw this exception. You will also see some new ASP.NET 4 features which gives developers some control on this situation.

       Description:

       http.sys Restrictions:

               It is interesting to note that after deploying your application on windows server that runs IIS 6 or higher, the first receptionist of HTTP request is the kernel mode HTTP driver: http.sys. Therefore for completing your request successfully you need to present your validity to http.sys and must pass the http.sys restriction.

               Every http request URL must not contain any character from ASCII range of 0x00 to 0x1F, because they are not printable. These characters are invalid because these are invalid URL characters as defined in RFC 2396 of the IETF. But a question may arise that how it is possible to send unprintable character. The answer is that when you send your request from your application in binary format.

               Another restriction is on the size of the request. A request containg protocal, server name, headers, query string information and individual headers sent along with the request must not exceed 16KB. Also individual header should not exceed 16KB.

               Any individual path segment (the portion of the URL that does not include protocol, server name, and query string, for example, http://a/b/c?d=e,  here the b and c are individual path) must not contain more than 260 characters. Also http.sys disallows URLs that have more than 255 path segments.

               If any of the above rules are not follow then you will get 400 Bad Request Exception. The reason for this restriction is due to hack attacks against web servers involve encoding the URL with different character representations.

               You can change the default behavior enforced by http.sys using some Registry switches present at