Deliver superior customer experiences with an AI-driven platform for creating and deploying cognitive chatbots
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
The content you're reading is getting on in years
This post is on the older side and its content may be out of date.
Be sure to visit our blogs homepage for our latest news, updates and information.
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.
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.
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:
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:
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
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:
- 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.
View all posts from The Progress Team on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.