Application Pool Identity folder permissions in Sitecore

windows-server

ApplicationPoolIdentity is the best practice to use in IIS7. It is a dynamically created, unprivileged account. To add file system security for a particular application pool see IIS.net’s “Application Pool Identities”.

Here is a quick guide how to add rights to correct AppPool -profile on Windows Explorer

  1. Open Windows Explorer
  2. Select Sitecore installation directory.
  3. Right click the file and select “Properties”
  4. Select the “Security” tab
  5. Click the “Edit” and then “Add” button
  6. Click the “Locations” button and make sure you select thelocal machine. (Not the Windows domain if the server belongs to one.)
  7. Enter “IIS AppPool\Sitecore” in the “Enter the object names to select:” text box. (Don’t forget to change “Sitecore” here to whatever you named your application pool.)
  8. Click the “Check Names” button and click “OK”.

Refer to Sitecore Installation and Security guide for proper settings.

Time for SSL-only internet

There is really no reason why you should not be running  only HTTPS (also known as HTTP over TLS, or Transport Layer Security), on your website. Even you are not running any authentication today there is a good change you will in the future. Furthermore, if you care about SEO Google is going to rank your site higher when you have taken care of security (See: HTTPS as a ranking signal). 

I have been lately configuring few sites to run in HTTPS and here are some tips.

  • Decide the kind of certificate you need: single, multi-domain, or wildcard certificate
  • You need dedicated IP, it’s easier that way
  • Buying certificate. If you are new on HTTPS and you are not sure which certificate to buy, then buy the cheapest one with single domain. If you are paying more than 10 USD for the certificate and you just need to get your website working on HTTPS then you are probably paying for extra.
  • Make sure you are use 2048-bit key certificates, I don’t think anyone is selling anything else anymore.
  • Use relative URLs for resources that reside on the same secure domain
  • Use protocol relative URLs for all other domains. This means you need to ensure that all third party services support SSL because otherwise you’ll give your users browser warnings alongside some security concerns. For example if you use javascript CDN make sure URL’s are pointing src=”http://cdn. => src=//cdn
  • Check out Google Site move article for more guidelines on how to change your website’s address
  • Don’t block your HTTPS site from crawling using robots.txt
  • Allow indexing of your pages by search engines where possible. Avoid the noindex robots meta tag.
  • Configure redirect from HTTP to HTTPS
  • I recommend RapidSSL or PositiveSSL I have been using PositiveSSL from namecheap but there is even cheaper ones in https://www.cheapestssls.com/. Also there is free certificate at https://www.startssl.com/ but I have not try it personally. Though, free is probably never free. Maybe it is OK for test enviroments and sandboxes but I would use RapidSSL or PositiveSSL for production. 

Be secure out there… you can test your server security level and configuration with the Qualys Lab tool.

 

How does OpenSSL vulnerability affects me?

If you are running Unix and HTTPS you should review your server. If you are website user on Mac or Windows you might need to change your passwords on some of the services. 

I found this good FAQ summarising the vulnerability from Reddit and thought to copy & paste here:

— clip —

What should I be doing as a user?

If you’re on Linux, update to the latest openssl libraries (ensure that the package was updated today and covers CVE-2014-0160). Ubuntu and Debian already have packages out to fix this.

If you’re on OSX, the latest openssl available there is 0.9.8, which is not vulnerable. You don’t need to update anything (unless you installed a vulnerable version manually, in which case you should update)

If you’re on Windows, it doesn’t come with openssl. If you installed it yourself (through cygwin, for example), you should check what version it is and try to update it if is a vulnerable version.

If you did have a vulnerable version of openssl installed, you should restart all of your computer applications after you update it to ensure they start using the new library.

What should I be doing as a sysadmin / website administrator / other?

Immediately update openssl libraries on any system having vulnerable versions which are hosting SSL/TLS services. Again, make sure the update covers CVE-2014-0160. If you’re using openssl 1.0.0 or older, you’re not vulnerable to this bug.

It is probably reasonable to consider any private keys from vulnerable services to be compromised, and as such you should replace those keys/certs and revoke the old certs. Failure to revoke the old cert could mean that any private keys acquired using the vulnerability could then be used to impersonate your site on the internet with full PKI trustworthiness – a very bad outcome.

Can I test to see if an external website is vulnerable to this?

Unfortunately the only way to determine if a website you don’t manage is vulnerable to this is to try and exploit it. I’d recommend against trying this unless you are fully aware of the potential legal repercussions of doing so.

What does this mean for accessing my bank / facebook / other random website?

If the website you are connecting to hosts SSL (HTTPS) and has this vulnerability, an attacker connecting to that website can view a small window (64k) of memory from the application which is terminating SSL. This window may contain a lot of things, including SSL certificates, SSL session data, or usernames/passwords, depending on the design of the terminating app.

As such, the most prudent thing to do would be to avoid connecting to those services until you can be reasonably assured that they are not affected by this vulnerability. Unfortunately this is a bit of a quagmire as determining if they’re affected is difficult to do. There is no good solution to this, other than to wait for those various websites to confirm they have fixed the issue, or to verify they aren’t vulnerable through third-parties or by testing yourself (see above regarding legal repercussions of testing yourself).

If you find that a site which you have used was vulnerable to this issue, you should change your username/password as soon as it has been confirmed fixed, for prudence sake.

Luckily most bank software is very slow to update (meaning they’re often on openssl 0.9.8, which isn’t affected), or makes use of proprietary SSL libraries, and as such it is unlikely that they are affected by this vulnerability. I’ve seen tests against a bunch of banks and saw no notable ones which are affected by this vulnerability. Unfortunately there will be some financial institutions affected by this.

— clip —

Is this a design flaw in SSL/TLS protocol specification?

No. This is implementation problem, i.e. programming mistake in popular OpenSSL library that provides cryptographic services such as SSL/TLS to the applications and services.

In following Elastica’s CTO Dr. Zulfikar Ramzan walks through the mechanics of the Heartbeat (Heartbleed) flaw (at a high level), how an attacker can exploit it, and its underlying ramifications.

OpenSSL Heartbeat (Heartbleed) Vulnerability (CVE-2014-0160) and its High-Level Mechanics from Elastica Inc on Vimeo.

See also http://heartbleed.com/

Multi-factor authentication for Sitecore

Untitled Document - New Page-We have worked a lot on secure login in recent months including integration with NemLoginPingFederate and AD FS and after having headaches with SAML assertions. We decided to create a simple module that hardens default Sitecore login with SMS token. It extends normal Sitecore login with extra step that asks you to give random code that is sent to your mobile phone. Mobile phone number is stored to your user profile. When you give right username and password the server will send unique key in SMS to your phone. This increases security on logins because no longer bad guys can guess your username+password and this way access to Sitecore. If you are using AD integration on your Sitecore instance you still can use this module (taken we can read your phone number).

Authentication workflow in Sitecore login

Step 1: Write your username and password

step1

Step 2: Read SMS token from your phone

Step 3: Write SMS Code to Login Screen

step2

Step 4: Login Notice that since I already know who user is after step 2 I can extend this very easily by choosing to scope User Interfaces, for example normally regular editors only use Page Editor and IMHO it is just confusing even show them anything else.

Costs

There will be a fee on the module and you will also need to have access to SMS gateway since SMS’s are not free. If you are not a developer we can install this for your Sitecore as long as you are running any version of Sitecore 7 or 6.  For the SMS gateway we are right now supporting Twilio (REST) and generic SMS gateways (GET). If you like to get hint on the pricing take a look Twilio pricing. So far I have noticed that Twilio is slightly more expensive that others that I have seen but their API and Support (SLA) is good so you know what you are paying for. For more info on licensing contact me at @jpkeisala or call Addition +45 33 69 04 02.

Road map

Custom Login Page
If you have even looked login screen of Sitecore you may have noticed it is not very customizable but fortunately we can replace it. We are changing login screen of Sitecore to “normal web page”, default look looks like Sitecore normal login screen. However, UI is customizable and uses Twitter Bootstrap.

 

What is Multi-factor authentication?

Multi-factor authentication (also MFA, two-factor authenticationtwo-step verification, TFA, T-FA or 2FA) is an approach to authentication which requires the presentation of two or more of the three authentication factors: aknowledge factor (“something only the user knows“), a possession factor (“something only the user has“), and an inherence factor (“something only the user is”). After presentation, each factor must be validated by the other party for authentication to occur. More about the concept in wikipedia.