Categories
Bloggers
Blogs RSS feed

Building a secured Sitefinity website

by Georgi Chokov

During the past few weeks I spotted a trend among our customers - web security and hacking concerns. With this blog post, we will cover how Sitefinity is protecting you from being hacked with some of the well known web attacks. We will also mention some of the basics you should keep in mind while building an Asp.Net Website.

Sitefinity against well known web attacks

SQL Injection and Blind SQL Injection

Before I write why SQL injection is not possible with Sitefinity, here is what Wikipedia says about SQL Injection - code injection technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another. SQL injection attacks are also known as SQL insertion attacks.(the entire article - http://en.wikipedia.org/wiki/SQL_injection).

SQL Injection attacks are not possible with Sitefinity. Every database query that gets executed is constructed by our Object-Relational Mapper. we do not insert user inputted data into the queries. Furthermore we are using parameterized stored procedures for every API method. It's important to note that if you have any custom functionality, you should be filtering the data before you construct the queries to your own tables, but using an ORM  for your own data layer will still help a lot. With this kind of attack, the user authentication is usually where the hackers try to hit - we use stored procedures for any user authentication as well, so 3rd party sql code will not go to the query.

Cross-site scritping /XSS/ attacks

Again from Wikipedia - a type of computer security vulnerability typically found in web applications which enable malicious attackers to inject client-side script into web pages viewed by other users. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites were roughly 80% of all security vulnerabilities documented by Symantec as of 2007. Their impact may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site, and the nature of any security mitigations implemented by the site's owner. (the entire article - http://en.wikipedia.org/wiki/Cross-site_scripting)

Asp.Net comes with a feature called Event Validation. It basically validates forms and fields upon submitting for any special and "sensitive" characters. The Event validation is enabled by default for all pages and modules in Sitefinity. The event validation can be enabled/disabled from the web.config file:

<system.web>   
<pages validateRequest="true" />   
</system.web> 

 

We use both client side and server side validators wherever it is possible.

Passwords storage

It's a fact that 30% of all web sites across the internet store the user passwords in a plain text. It is a mistake Sitefinity does not do though. Using the default membership providers coming with the application, you will store your users' passwords in hashed + salted form, which makes the reversing impossible.  

Asp.Net features

Beyond the form validation, you should also take care of encrypting the viewstate and the authentication cookies. In Asp.Net, these features are usually turned on by default. The viewstate is encrypted before rendering the page. Every page/template could have its own encryption settings, which could be bad in case many developers are working on the same project. In order to enable the encryption of the viewstates for all pages, the following web.config entry is needed:

<configuration> 
   <system.web> 
      <pages ViewStateEncryptionMode="Always" /> 
   </system.web> 
</configuration> 

The following MSDN article is explaining about the security settings of the authentication cookies, as well as encrypting the ViewState and the cookie in the same way on all servers, when working in load balanced and web farm environments - http://msdn.microsoft.com/en-us/library/ms998288.aspx

 

Deploying the project

There are several things you should know before you deploy the application on the live server:
- Running in medium trust will prevent file Input/Output operations. usually the only directory in which write rights are possible, is the App_Data directory.

- Verify that ASP.NET Errors are not returned to the client. In Sitefinity we do not handle some of the errors with a purpose - Sitefinity is a developer tool, and what speaks best to developers are the error messages that they get. This should not be the case when the application is deployed though - whenever an error occurs, make sure that you display friendly messages and no stack trace or code. The errors can be configured from the web.config file:

<system.web> 
    <customErrors mode="RemoteOnly" defaultRedirect="FriendlyMessage.htm">  
      <error statusCode="404" redirect="FriendlyNotFoundError.htm"/>  
      <error statusCode="500" redirect="FriendlyServerError.htm"/>  
    </customErrors> 
</system.web> 

- You can encrypt sensative parts of the web.config file

Server Security

Sometimes the web attacks start with the server being hacked first. Once the attacker has access to your server, he could damage your website. If you have your own server, virtual or physical one, you will have to ensure that the server software is updated, and the firewall is set up correctly.

Other good practices:
- ApplicationPool identity user must not have Administrative rights, and must have access only to the web site files rather to the entire server.
- Administration of the CMS could be locked by IP addresses - only the addresses of your content writers/administrators should be in the firewall exclusion list.

Resources used for this blog post:

MSDN:

Wikipedia:

There is a lot more on the topic, but the right baby steps are usually preventing 99% percents of the problems which might occur later.

14 comments

Leave a comment
  1. Gabe Sumner Jan 29, 2010
    Awesome post Georgi.
  2. Lino Tadros Jan 29, 2010
    Very cool!  excellent article, Georgi, yo da man!
  3. Yasen Jan 29, 2010
    Really neat :)
  4. Michael Jan 29, 2010
    Great post Georgi. Thanks!
  5. Georgi Chokov Feb 01, 2010
    Thank you too guys!
  6. Paul Feb 02, 2010
    Great information! Thank you!
  7. KingKong Feb 03, 2010
    I had some doubts about this, but now everything is clear for me. Sitefinity seems to be very good, cheap and extensible CMS. 
  8. David Feb 04, 2010
    Thanks Georgi for the great article.  Would you consider LinqToSql secure like ORM?
  9. Georgi Feb 11, 2010
    David,
    Apologies for the late reply on your question. We will definitely try to do it. On another hand, if we are talking about 4.0, there is "LinqToSitefinity" which will use the stored procedures :)
  10. Zia Partovi Jan 06, 2011
    SQL injection using ORM Injection is indeed possible.  Please check following url:

    http://www.owasp.org/index.php/Testing_for_ORM_Injection_(OWASP-DV-007)
  11. jelly gamat gold g Sep 19, 2013
    Nicely presented information in this post, I prefer to read this kind of stuff. The quality of content is fine and the conclusion is fine. 
  12. bram Oct 09, 2013
    Georgi,
    I noticed that username and password are sent to server in plain text format. Is there any built in function that will encrypt/hash username and password before sending them to server?
  13. Celebrity Plastic Surgery Dec 20, 2013
    Really a great addition even what you have just presented open my mind. I have read this marvelous post
  14. Jelly Gamat Jan 20, 2014
    I agree with your opinion
    this must be the latest lesson for me
    thank you .
    http://goo.gl/Aaa4cS

    Leave a comment