ASP.NET MVC 3/4: Anti-Hacking

Not so long ago, I read another article on SQL injections in Habré, the article was devoted to true PHP, there were disputes about how to deal with data from the user, through what functions to drive them away, with PHP familiar with the surface, but I learned the big picture. Then the idea was born to show how things are going with security in ASP.NET MVC.

First of all, we will create a simple website, I will not describe step-by-step creation, I’ll just say a bunch of technologies used: ASP.NET MVC4 and Entity Framework 4.3.1 (ORM for working with databases). The project can be downloaded at the end of the article.
')
As a result, we received a site with one static news and the ability to add comments.

Cross-Site Scripting (XSS)

---

Let's start our hacking with XSS, we will implement scripts on the page by adding comments.
Now we will try to add a comment with the script:



Click add a comment and get an error, alas, we have not reached the method:



What is the fastest way to make a website work? Certainly chop off validation for the method:

[ValidateInput(false)] 

This is not a task, again our script is not executed:



This happens because, by default, all text is encoded and output encoded, the situation can change:

 @Html.Raw() 

It is worth remembering that the user can not be trusted; you need to save only the checked content, for example, as the habr parser does, deleting potentially dangerous content. Also, with the help of XSS, you can steal data using a banal img tag that is hidden, while loading the page confidential data can get to a third party. Once again, although I gave an example of how to still write the script to the database, you should always remember that at one point a new developer may appear who will add ajax features using jquery and using $ .html () will return the XSS hole to security.

SQL injection

---

For hacking the site using injections, I made a separate page, on which there is a field for searching comments by the name of the author, there is no point in doing methods for working with models of numbers, bool values ​​and other things, since I’ll not convey my string at the binding stage (binding) input parameters and models, this data will be deselected.



Actually, as long as I did not try to do something, it did not work out, the use of ORM was to blame, there are no string concatenations there, the data is passed by parameters and escaped. It’s hard to imagine a person who does not use ORM or other safe methods when working with a database (example from servitRM ) (first of all, I’m talking about preventing the user from inserting data in the form in which you received it by concatenating strings) the project is from scratch and there are no restrictions on technology, perhaps, if some old modules are used and there is no time to rewrite - this can be somehow justified, but then all responsibility falls on the developer.

Cross-Site Request Forgery (CSRF)

---

An example of this attack could be, for example, a website with a local currency and you only need one POST request to transfer money to another user. The attacker makes a form on his site, where in action (form action) points to another site, creates hidden parameters: the amount,
wallet, etc ... Being authorized on that site you will transfer money to it (other options: removal of something, additions, in general most of POST requests).

To combat this, MVC has a helper for presentation, which should be in the form body:

 @Html.AntiForgeryToken() 

Now the attribute for the controller's (Action) method:

 [ValidateAntiForgeryToken] 

Let us check that we succeeded (I added this logic to the page with XSS), we make the usual query:



In addition to hidden fields, we also had cookies:



Now, we’ll remove this hidden field and look at the result (at least three options, remove it from the view, delete it using Firebug and more interesting for me via Composer in Fiddler, drag a successful query and simply delete this parameter in Request Body):



It is worth remembering that this parameter is not generated with each request and by intercepting the package in the future you can hack.

Information hiding

---

Many do not give this attention, but I believe that this item is very important. When choosing a lock for a metal door, I found out that many locks are opened elementarily with the help of a drill, be there three thick bolts (cylinders that move out), but it is enough to drill one hole in the right
place (as it were, deliver a pinpoint blow to weak points) and the lock is open. Similarly, if you say that you have such and such IIS, such and such version of ASP.NET, etc. You provide invaluable assistance to the burglar! I love to clean the Elmah logs with a cup of tea and watch how my site is trying to find php, mysql, using wonderful services to determine which CMS is used, etc.

Here is what my site is returning now:



Remove X-Powered-By:

 <system.webServer> ... <httpProtocol> <customHeaders> <remove name="X-Powered-By" /> </customHeaders> </httpProtocol> ... </system.webServer> 

ASP.NET version:

 <system.web> ... <httpRuntime enableVersionHeader="false" /> ... </system.web> 

MVC version in Application_Start:

 MvcHandler.DisableMvcResponseHeader = true; 

And the most difficult is the server, for which we will make the HttpModule:

  public class CustomServerHeaderModule : IHttpModule { public void Init(HttpApplication context) { context.PreSendRequestHeaders += OnPreSendRequestHeaders; } public void Dispose() { } private void OnPreSendRequestHeaders(object sender, EventArgs e) { HttpContext.Current.Response.Headers.Set("Server", "Apache 2000 Server"); } } 

and add to the config:

  <system.webServer> ... <modules runAllManagedModulesForAllRequests="true"> ... <add name="CustomServerHeader" type="HackingMVC.HttpModules.CustomServerHeaderModule" /> </modules> ... <system.webServer> 

As a result, we got the following result:

Instead of conclusion

---

Not for nothing is ASP.NET famous for its security, MVC is actively developing, which with each version becomes more and more interesting. Some points were not considered, I missed something, but it’s enough just to mention something, in any case it is impossible to consider such a voluminous topic in one article. It is worth focusing on the fact that it is very important to use SSL on the site, because otherwise your data may be stolen during authorization, session on any page, authorization token or any other data stolen, which negates a lot of protection. Keep in mind both JSON Hijacking and the fact that it doesn’t simply throw a warning if you try to retrieve data via a GET request without specifying permission, in this way you should give only those data that are not afraid to lose. I showed only a part of the problems that you may encounter and which you should pay attention to when developing.

PS Wishes and options for hacking this site are welcome: zip-archive . (8.7 MB, since the downloaded NuGet packages are included in the solution / project (solution)) or without a zip-archive package (706 KB).

UPDATE: Added archive without packages. A few words about hashing: the site uses Forms authorization for the admin, the password is stored in clear text in the web.config, which is done for clarity when viewing the source. In real projects, password hashing must be used, both in the config and in the database. You also need to use salt to obtain data with a well-known hashing algorithm to pass the passwords through the tables and the salt must be different, so that you cannot recognize the value and a hash of one password to find identical passwords, which will speed up hacking.