Securing
Sitefinity

Out of the box Sitefinity security is pretty good. You can check out their guidance at.
Sitefinity Security Best Practices

As I started writing this post I found it getting very long as I waffled on about the whys for all the settings. So I have cut all my waffle and just left links to further reading. Which I think is better. You should go and read this stuff and understand why it is important and how you can be exploited.

So the thing you can do for you site is secure the log on. You need to get a SSL certificate to ensure credentials are not sent over the network in clear text.

A good certificate can cost $400. But if your site is just a simple site and you can't afford the EV Green bar certificate, then there are plenty of cheap and free places to get a cert. And this is far better than the nothing that comes out of the box.

So at a minimum I would recommend you get one and secure your back end and any logon widgets you have and follow Sitefinity's guide.

Below are some steps you can take to secure your Sitefinity site just that little bit more.

Make the whole site require SSL.

If you get a SSL cert why not apply it to the whole site? Force every page and request to be secure? Can anyone give me a reason why we shouldn't? Do you ever run into the error where the browser says some content on this page is not secure? Do you realise that an insecure image can render all your secure pages insecure?

The easiest why to do this is use URLRewrite. The alternative is to manually go through Sitefinity and tick the box on every page or write code to update every page and hope your users don't forget to tick the box when they create a page. (Yeah, right)

Here is the rule.

<rewrite>
   <rules>
     <rule name="HTTP/S to HTTPS Redirect" enabled="true" stopProcessing="true">
       <match url="(.*)" />
       <conditions logicalGrouping="MatchAll">
         <add input="{SERVER_PORT_SECURE}" pattern="^0$" />
         <add input="{URL}" pattern="^/DefaultWorkflows" negate="true" />
       </conditions>
       <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
     </rule>
   </rules>
 </rewrite>

Note that Defaultworkflow still needs to be able to communicate over http. Not sure what the issue is there but currently its a requirement. (And a security hole in my opinion)

Have a read at Troy Hunt's blog
SSL is not about encrytion
Loading a free SSL certificate into Azure website
Lessons in insecure SSL

(I use DigiCert They have a real simple process to generate a request and create a cert by supplying you with a .exe which does it all for you. Cheapest cert is $175)

Also make a config change to your wsFederation element in your web config as instructed on the Sitefinity site.

<wsFederation passiveRedirectEnabled="true" issuer="http://localhost" realm="http://localhost" requireHttps="true"/> 

And add a second element to your tokenIssuer elementin the Security.config. (or go to Advanced Settings and expand the Security node to make them there.

<add key="Your key same as the first" encoding="Hexadecimal" membershipProvider="Default" realm="https://yoursite.com/" /> 

Ensure Custom errors are turned on

So make sure you have 404 or 500 errors handled. If they aren't then an attacker can get helpful info from your error returns. Plus your site looks bad if you are throwing the Yellow screen of death to your customers.
See a previous post - Error Handling in Sitefinity

Hide your headers

Not a huge one but always recommended. Hide unnecessary headers such as 'X-Powered-By'. And save your self some traffic bits.

Remove Powered by by adding this to your web.config

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

Remove the Server Header
This one is a little harder. You need to add some code to your Global.asax file.

protected void Application_PreSendRequestHeaders(object sender, EventArgs e)
{
    HttpContext.Current.Response.Headers.Remove("Server");
} 

Don't let your site run in a Frame

The attack is called ClickJacking.  Basically, someone creates a empty iFrame page which loads your site inside it. The hacker gets a user to click his special Url. As the user types in there log on thinking they are safe on your website, JavaScript in the parent frame runs sending keystroke data to the attackers database. 
To stop this you can add a header to your responses.

<add name="X-Frame-Options" value="SAMEORIGIN" /> 

Have a read at OWASP - Click jacking
And check if your bank website is protecting you. I know mine isn't. (See  A Safa web at the end.)

Secure your Cookies

In the Advanced settings of Sitefinity check the Security node.
In there set a AuthCookieDomain and a RolesCookieDomain and tick the boxes for AuthCookieRequiresSsl and RolesCookieRequiresSsl.

Also add to the web.config 

<httpCookies domain=".mydomain.com" requireSSL="true" /> 

Passwords

We all know the requirement. At least 8 characters, number and special character. But the better passwords are long ones. It takes 3 days to crack 'Tr0ub4dor&3' but 550 years to crack 'CorrectHorseBatteryStaple'. So in your password settings, up the length.
Here is a post on the numbers and one with a simple explanation.

How to check if you are secure?

First run your site through ASafaWeb. This will perform some quick checks for you. Put your banks website in it and see how they rate.

Then you may want to try ScanMyServer. A free service from Beyond Security. You can check my results by clicking the link in my footer. Go on check it.

You may want to also consider NetSparker.

A final note

A couple of times a year I catch a news article on someone who has been duped by online fraud. Without being harsh, (cause I know my mum would fall for them), but frankly its often the persons fault. Honestly, how many deceased billionaires are there in Nigeria that have picked you to share there fortune with? But I think what this shows is a much larger focus on 'social engineering' attacks rather than hacking directly into your website. The big iCloud attack of celebrity photos was more due to guessing stupid passwords than cracking Apples code.

So take time to educate your customers and clients on this. You don't want to be in a client meeting arguing over if the site was insecure or the users are insecure.

Leave a comment

Load more comments

Make a Comment

Name:

Email:

Message:

Enter the code

New code

Submit

Please check this input