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:
|<pages validateRequest="true" /> |
We use both client side and server side validators wherever it is possible.
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.
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:
| <system.web> |
| <pages ViewStateEncryptionMode="Always" /> |
| </system.web> |
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:
| <customErrors mode="RemoteOnly" defaultRedirect="FriendlyMessage.htm"> |
| <error statusCode="404" redirect="FriendlyNotFoundError.htm"/> |
| <error statusCode="500" redirect="FriendlyServerError.htm"/> |
| </customErrors> |
- You can encrypt sensative parts of the web.config file
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:
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.