How do I secure the Sitefinity back end pages? - General Discussions - General Discussions - Progress Community
 General Discussions

How do I secure the Sitefinity back end pages?

  • How do I secure the Sitefinity back end pages?
  • I have seen various forum threads on this topic, but most are very, very old. What are the current best practices 5.x to secure the Sitefinity backend pages from hackers?

    - I have seen some say apply SSL to the /Sitefinity folder via IIS, but then others say that causes issues with themes that are located in App_Data

    - I have seen some posts say that backend pages are forced to http not https unless some setting is enabled for each individual page.

    Any updates to these practices? What do you do to keep your site secure?
  • Good question.
  • I am also curious. What is the best way?

    Regards,
    Peter
  • Telerik seem to indicate their preference with their own site - try to access the sitefinity folder of this site and you get a 403 forbidden - which would seem to suggest they may be applying an IIS whitelist to that page or section of the site.
  • Interesting question and also something that would be good to see answered.
    What I have seen in the past is a key being required when accessing a admin backend. It would be good if sitefinity built something like this in to its site.
    e.g. if you try to access www.mydomain.com/sitefinity it would just point you back to the home page, if however you entered www.mydomain.com/sitefinity?myKey you would get the admin login page.

  • I tried the solution in this article. When I am going to my site www.domain.com/sitefinity I am still redirected to www.domain.com/.../SWT the http). When I try to login (through http) I am getting an error  "Missing configuration for the requesting relying party "https://www.domain.com".  When I replace the http in the url through https, it works! Why is it not redirected immediately to https?

  • @Telerik, what do you suggest for securing backend pages? Or is the suggestion in the article mentioned in the previous message the way to go (and if so, how can the mentioned issue be fixed)?
  • FWIW: This is my current solution,  courtesy  of Telerik support.
    This is basically a 4/5 implementation of the method I used on previous V3 sites.

    IIS IP Address restrictions:
    --------------------------------------
    /Sitefinity
    - Add Address Whitelist for Folder
    - Access for unspecified Clients = Deny    (Feature Settings at Folder)

    /Sitefinity/Services
    - Access for unspecified Clients = Allow    (Feature Settings at Folder)

    Of course, Security restrictions are always a ‘YMMV’ solution, and I can only vouch for it working my own sites, but so far it gives me what I need:
    - Anonymous users can access the public site
    - White-listed addresses can access the admin site
    - Non-listed addresses get a 403 forbidden if they try to access the admin site
  • So if I understand this right, there is no SSL solution for Admin access? The Sitefinity folder will be open to man in the middle attacks unless we restrict access to it on an IP basis and then use something like a VPN tunnel to reach it remotely?

    I really hope there is something better than that, but I at least need to know if what I stated above is true so that we can plan accordingly.
  • @Dan

    Just to be clear about my current solution - this is a specific approach I took (to emulate what I had been doing in the past with V3) and tech support gave me guidance on that request.

    I didn't ask 'what is the best solution?' and it may well not be the best... I simply asked 'how do I do use IIS IP whitelists with V5?'.

    However, I've actually encountered an issue with it since, and am currently trying to resolve it... I'll update if/when I do.
  • We use an F5 appliance, Big IP for load balancing and SSL offloading... We're getting a new wildcard cert for our domain soon.. I had intended on using our appliance to force SSL on all page requests with /sitefinity.  As long as I don't write a rule to force them back to HTTP if they go to a page without /sitefinity I'm thinking it should keep them in HTTPS which is preferable because editing a lot of content types remove the /sitefinity from the url.  If they happened to go back to the public site they would probably stay in HTTPS but considering it's only my admin users I'm not too concerned about that.  When we get this cert and I apply a solution I'll post back.  I know it's not exactly a universal solution but then again a simple Big IP irule like this could probably be written in IIS URL Rewriting pretty easy to accomplish the same thing. 
  • Tony - I am pretty certain that the Sitefinity backend will revert to HTTP on each click, even if you start with HTTPS.
  • Well one of the good things about Big IP is that as far as the Sitefinity servers are concerned all requests are coming from the Big IP load balancing IPs in HTTP traffic (which looks funny on my IIS logs when 99.9% of the traffic came from one of two IPs).  This has its advantages for me potentially forcing SSL as Sitefinity will most likely be unaware it's even occurring.  However a major disadvantage of using this load balancer is licensing and the load balancing module in Sitefinity, or so we speculate with the significant admin performance issues we experience in our current environment. 

    Anyways it'll be worth a shot for me, but if it can't be replicated with something like IIS rewrite it won't be a very good solution for anyone who doesn't already have a need for one of these appliances in their enterprise.  Has anyone tried URL Rewrite though to see if it can force SF HTTPS on specific rules?  If it did force SSL and it only reverted back to HTTP on various content edits you could circumvent that with an additional rule that looks for /Action/Edit and the various other requests.  What I'm concerned about is when my browser calls something like /Telerik.Web.UI.Webresource.axd.. I believe Big IP would let me circumvent most of the forces to SSL, but I'm not entirely sure if it would force a web service like that.. I'm thinking it all depends on session management and how our appliance deals with calls like that from the same session.. Sounds like my whole theory could be busted before I even try it, but it won't hurt anything to give it a shot.
  • From the little I have learned through trial and error I think you are on the right track. I'm coming to the same conclusions. I'm just surprised that there isn't more information published about the best practices of securing Sitefinity. Hopefully someone who has secured a Sitefinity site will see this thread and add some additional knowledge.