Security: Protecting SharePoint Server Applications

 Version Disclosure (SharePoint)

 Description:

 Same as point 1.

 Fix:

 It's not recommended to remove these headers and it's better to accept the risk in this case because these will affect the SharePoint crawling and other features except you have an anonymous website with limited features.

 References:

 https://www.wictorwilen.se/sharepoint-mythbusting-the-response-header-contains-the-current-sharepoint-version

 https://www.wictorwilen.se/sharepoint-2013-sharepoint-health-score-and-throttling-deep-dive

 https://dirkvandenberghe.com/2011/06/07/remove-http-response-headers-for-internet-facing-sharepoint-sites.html

 https://blog.michelbarneveld.nl/michel/archive/2009/11/08/x-sharepointhealthscore-a-new-sharepoint-2010-http-header.aspx

 Version Disclosure (IIS)  

Description:

Same as point 1.

 Fix:

Create custom HTTP Module as following:

 namespace MyNamespace{

  public class HttpHeadersCleanup : IHttpModule { public void Init(HttpApplication context) { context.PreSendRequestHeaders += PreSendRequestHeaders; }

  private static void PreSendRequestHeaders(object sender, EventArgs e) { HttpContext.Current.Response.Headers.Remove("Server"); } 

     public void Dispose() { }

    }}

 Then add the following setting in web.config

  <system.webServer> 

      <modules> 

          <add name="HttpHeadersCleanup " type="MyNamespace.HttpHeadersCleanup, MyAssembly" /> 

      </modules> 

 References:

 https://www.frederikvig.com/2010/11/removing-http-headers-for-asp-net-sites/

 Cookie Not Marked as HttpOnly 

Description:

 In General, it's always recommended to set HttpOnly flag to cookies to prevent XSS script risk against these cookies like Auth Token Cookie which then it can be used in hijacking and other attacks. In SharePoint if you are using Form authentication then by default SharePoint flag Auth Token with HttpOnly but there are some cookie in SharePoint not flagged with HttpOnly like "wss_keepsessionauthenticated" .

 Fix:

 Add this setting to web.config 

 <system.web> <httpCookies httpOnlyCookies="true" requireSSL="true" />

 References:

 https://murmurofawebmaster.blogspot.com/2013/07/wsskeepsessionauthenticated.html

 Insufficient Transport Layer Protection

 Description:

  "HTTPs everywhere" , it's a top priority to protect the information in transit by using TLS/SSL to provide secure communication. Also In case of anonymous site, it's helpful to you to increase the site rank in Google search engine using HTTPs and by the way HTTPs (represents top layer of TLS/SSL) which provides 3 goals:

1. Confidentiality to protect the data in transit from sniffing by using tools like fiddler or wireshark , hijacking or MITM attacks (Main goal).
2. Integrity by protecting the data from tampering during transition so it will reject the request if anyone in the middle of transit modify the packets.
3. Authenticity by tell and give the visitors assurance about your domain and who you are talking to.

 I will list all best practices to consider when implementing HTTPs in Your SharePoint Site:

• Configure SSL for SharePoint https://blogs.msdn.com/b/fabdulwahab/archive/2013/01/21/configure-ssl-for-sharepoint-2013.aspx
• Test its security level, configuration, implementation, key strength … test it with the Qualys Lab tool https://www.ssllabs.com/ssltest/ and fix the issues and try to make the grade "A" As possible.
  • To Disable Old Protocols ,weak ciphers and Poodle attack protection then follow steps in this article https://www.hass.de/content/setup-your-iis-ssl-perfect-forward-secrecy-and-tls-12
• Avoid Self-signed certificate , expired or invalid certificates due to lake of the authenticity.
• Avoid Mixed content mode because still hacker can steal the session by sniffing HTTP content like image or js requests in HTTPs site.
• Avoid Redirection from HTTP to HTTPs and also avoid only implementing HTTPs on login page because still hacker can steal the session by sniffing even without username and password.
• Make sure to use "secure" cookies in case of sensitive cookies like Auth Token in Forms Membership , by using  requireSSL="true" /> in web.config https://www.owasp.org/index.php/SecureFlag
• Make sure to have end to end secure channels because in some cases they only implemented the HTTPs to load balance level only and it's better to include the internal requests
• Use HTTP Strict Transport Security(HSTS) to force the browser to browse the site to a certain time ( based on Max age value ) in HTTPs without need to send redirection request from HTTP to HTTPs (this header not support it in all browsers). For more information , check https://www.owasp.org/index.php/HTTP_Strict_Transport_Security

 Finally you can start with "StartSSL" for free certificates https://www.startssl.com/?app=1 or "CloudFlare" which add security controls to your site and provide fee SSL https://www.cloudflare.com/features-security

 References:

 https://googlewebmastercentral.blogspot.com.au/2014/08/https-as-ranking-signal.html

 https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

 Stack Trace and Errors Disclosure (ASP.NET)  

Description:  

 It's recommended to stop disclosing information because of unhandled errors, trace and debug .With easy steps , you can prevent leaking these information which might help an attacker to gain more information and potentially focus on the development of further attacks.

 Fix:

 Change these settings in web.config 

• Set <customErrors mode="On" on web.config
• Remove <trace enabled="false" (by default is not enabled)
• Set <compilation debug=”false” />
• Set <SafeMode CallStack="false"

Also do the same in web.config file in _layout folder.

 Clickjacking

 Description:

 It’s recommended to prevent clickjacking risk on your website and you can find more details about it in this article - Clickjacking in OWASP https://www.owasp.org/index.php/Clickjacking

 Fix:

 The easiest fix for this risk to add this header X-Frame-Options to HTTP Response but remember this way is not supported in all browsers.

 Configure IIS to add an X-Frame-Options header to all responses for a given site, follow these steps:

1. Open Internet Information Services (IIS) Manager.
2. In the Connections pane on the left side, expand the Sites folder and select the site that you want to protect.
3. Double-click the HTTP Response Headers icon in the feature list in the middle.
4. In the Actions pane on the right side, click Add.
5. In the dialog box that appears, type X-Frame-Options in the Name field and type SAMEORIGIN in the Value field.
6. Click OK to save your changes.

 References:

 https://blog.kotowicz.net/2009/12/5-ways-to-prevent-clickjacking-on-your.html

 https://www.owasp.org/index.php/Clickjacking 

 https://support.microsoft.com/en-us/kb/2694329

 https://styledpoint.com/blog/including-sharepoint-2013-in-an-iframe-without-x-frame-options-error/ 

 Validation Request  Description:

 Request validation, a feature of ASP.NET since version 1.1, prevents the server from accepting content containing un-encoded HTML. This feature is designed to help prevent some script-injection attacks whereby client script code or HTML can be unknowingly submitted to a server, stored, and then presented to other users.

 Fix:  

 SharePoint like other .NET content management systems which has a lot of places where rich text needs to be submitted to the server so By default Microsoft disable ValidateRequest in web.config and if you try to enable it then you will not able to create pages with Html editors contents.In this case you need to accept the risk and keep this feature disable but take care for your SharePoint and make sure it's patched with up to date fixes and In case you have custom code , make sure to validate and encode the input at the client and server sides using libraries like AntiXSS and others.

 References:

 https://msdn.microsoft.com/en-us/library/hh882339(v=vs.110).aspx

 https://www.asp.net/whitepapers/request-validation

 https://www.troyhunt.com/2010/03/request-validation-dotnetnuke-and.html

 https://www.nuget.org/packages/AntiXss/

 Max Upload Document / Max Request length 

 Description:

 It's recommended to decrease the amount in these settings "Maximum Upload Size" and "maxRequestLength" to limit the impacts of the load, response time and data capacity in the server especially in case of DoS attacks.

 Fix:

 You can follow steps in the following link https://support.microsoft.com/en-us/kb/925083 and make sure these values meet your business requirements.

 References:

 https://technet.microsoft.com/en-us/library/ee424404(office.14).aspx#Section3c

 Persistent XSS flaw in SharePoint 2013

 Description:

This particular vulnerability, CVE-2015-2522, is caused by insufficiently sanitizing user-supplied input in a number of input points like notes, keywords, and comments. For more details you can check this link https://blog.fortinet.com/post/sharepoint-2013-xss-vulnerability-discovered

 Fix:

 Update your SharePoint with the latest new version of CU to address this and other issues.

 Note: Only SharePoint 2013 with version build 15.0.4571.1502 and before should update as soon as possible.

 Health Check(Security)

 Description:

 SharePoint Health Analyzer is a feature that enables administrators to schedule regular, automatic checks for potential configuration, performance, and usage problems in the server farm. SharePoint has four Health check rules related to Security as following:

1. Accounts used by application pools or service identities are in the local machine Administrators group.
2. Business Data Connectivity connectors are currently enabled in a partitioned environment.
3. Web Applications using Claims authentication require an update.
4. The server farm account should not be used for other services.

 Fix:

 Most of the below rules are best practices so fix these issues which has detected by the SharePoint Health Analyzer and in case you want to ignore them then make sure to have a good reason.

1. Fix for Point 1 https://technet.microsoft.com/en-us/library/hh344224.aspx
2. Fix for Point 2 https://technet.microsoft.com/en-us/library/jj891123.aspx
3. Fix for Point 3 https://technet.microsoft.com/en-us/library/ff686815.aspx
4. Fix for Point 4 https://technet.microsoft.com/en-us/library/ff805056(v=office.14).aspx

 The server farm account should not be used for other services.

 Description:

 The account used for the SharePoint timer service and the central administration site, is highly  privileged and should not be used for any other services on any machines in the server farm.

 In SharePoint Health Analyzer you could find similar warning like Accounts used by application pools or service identities are in the local machine Administrators group or others warnings and all related to inappropriate setup service accounts. 

 Fix:

 To install SharePoint ,you have to have appropriate administrative and service accounts on servers running SharePoint and SQL Server.

 Plan for administrative and service accounts in SharePoint 2013 https://technet.microsoft.com/en-us/library/cc263445.aspx 

 References:

 https://technet.microsoft.com/en-us/library/cc678863.aspx 

 https://technet.microsoft.com/EN-US/library/hh377944.aspx

 Require Use Remote Interfaces permission

 Description:

 It's recommended to prevent Anonymous user from accessing Client Object Model interfaces. When this option is checked, it simply means that the user must possess the Use Remote Interfaces permission which allows access to SOAP, Web DAV and Client Object Model.

 Note:By default this option is checked in SharePoint 2013 

 References:

 https://blogs.msdn.com/b/kaevans/archive/2013/10/24/what-every-developer-needs-to-know-about-sharepoint-apps-csom-and-anonymous-publishing-sites.aspx