What is it? Content Security Policy (CSP) is a mechanism for adding additional security to websites to eliminate several attack types. It works by adding a header to web traffic from the originating server that states how the server should operate. This means that every page loaded from the site is protected by these settings. There is a wide range of CSP options depending on a particular site’s needs. D2L has adopted a few types of CSP options outlined below to solve specific potential issues. Further options may be adopted as future needs arise. CSP can report on potential violations even when not enforcing the policies as well as report on violations when the policy is enforced. Meaning D2L has visibility into when and how many attempts are made that violate our chosen settings. Iframe Blocking The Frame-Ancestors CSP Policy is used to block the ability for some websites to IFrame the originating site in this case Brightspace. This is used to prevent clickjacking attacks as well as provide a better user experience. D2L utilizes this CSP policy on the login page currently with plans to later add it site-wide. Note, the site-wide policy should not currently be used as it causes known breakages with tools such as Lessons. Site-wide IFrame blocking will be fully released later. SVG Execution Blocking The Sandbox CSP Policy is used to block execution of JavaScript within an SVG file. This is used to prevent phishing or social engineering attacks to obtain user information. D2L utilizes the Sandbox policy without allowing scripts to prevent execution of JavaScript within SVG files. This CSP policy is only added to the header of SVG pages when rendered. SVG files will still load but they will be unable to execute code. Who is affected? All new and existing clients will have these protections enabled in the August release. Clients using Login Page Management (LPM) can manage their configurations within the Config Variable Browser. Clients using Custom ASP pages or Custom Hosted Login Pages will not be able to disable or modify their own settings. Clients using these custom pages use server-side settings that apply to all clients using these custom pages so individual modifications are not possible. If a client needs custom settings, they will need to discontinue usage of their custom login page. There are some generic exemptions that have been applied to all clients regardless of login page type.For clients using Login Page Management, there are a few known clients with IFraming occurring that needs further investigation/possible client changes. These instances will be exempted from the change in August. D2L will be in contact with the affected clients to discuss further. LPM Clients can add URL exemptions for themselves as needed (see below section on client configuration). Many of the IFraming attempts occurring are clients switching back and forth between their primary and non-primary URLs. Usage of the non-primary URL can cause many tools to break and should be avoided. Why are we doing this? IFrame Blocking Iframing Brightspace affects the user experience and accessibility of Brightspace as well as allowing for potential attacks lessening the site security. The main security concern this lessens is the ability for clickjacking attacks to occur. From a user perspective, Brightspace was built to be a top-level application and many components don’t function or don’t function well if IFramed. Brightspace was built to be responsive to device size but by IFraming within a smaller window Brightspace cannot resize itself properly. Brightspace opens many dialogs to prompt users during workflows which block out the rest of the application so the user can focus. When Brightspace is IFramed, the dialogs would only block the iframe which could confuse the user. For accessibility, screen readers and keyboard only users have a terrible experience interacting with Brightspace within an iframe. Brightspace will perform certain actions to the top-level frame when breaking out of our own frames, when Brightspace is within an iframe this results in Brightspace breaking out of the iframe and taking over the outer page. Brightspace has its own top and side navigation so it will also be a very disjointed experience for the user trying to figure out which navigation elements to use. In summary, the experience for users when Brightspace is IFramed is very poor and disjointed removing the usability and accessibility benefits Brightspace prides itself on providing. SVG Execution Blocking Allowing JavaScript to execute within a SVG allows for certain social engineering attacks. SVGs from untrusted sources shouldn’t be allowed to execute to avoid attacks. SVGs can be used as images without needing JavaScript to execute. What control do clients have? Clients do have some control over the CSP settings via the Config Variable Browser. IFrame Blocking Note, custom login page clients cannot manage their settings via the CVB. If they change the settings it will not be reflected in their login page headers. This only affects IFrame blocking for the login page.The config variable d2l.Security.ContentSecurityPolicy.AddtnlAncestors controls which URLs are allowed exceptions to IFrame Brightspace. This will be the most likely config that clients might modify to add exceptions for their site. Several URLs are listed by default to allow for standard tools to function. We recommend if further URLs will be added to add to the existing list. If the existing list is removed some functionality may break. The current site URL does not need to be included in this list. Note, we do not recommend adding untrusted sites to this list and strongly recommend against adding exceptions for things like localhost.URLs should be separated by a space. The format of the URLs should be one of the below examples (note the third format listed is the most common notation to use): http://*.example.com: Matches all attempts to load from any subdomain of Example Domain using the http: URL scheme.mail.example.com:443: Matches all attempts to access port 443 on mail.example.com.https://store.example.com: Matches all attempts to access store.example.com using https:. The config variable d2l.Security.ContentSecurityPolicy.HeaderEnabled determines if the CSP header is included at all either for reporting or enforcement. We typically do not recommend disabling this variable. On = CSP header is included on some requests based on how other configs are configuredOff = CSP header is not included for any requests The config variable d2l.Security.ContentSecurityPolicy.ReportingOnly determines if iframe blocking is enforced or not. If the variable is ON, enforcement of the CSP policy does not occur. We recommend leaving this OFF so the policy is enforced and adding trusted sites to the addntlancestors variable if possible. There are certain clients where further investigation/conversation is needed who will have this variable remain ON. If this variable is ON for your site after the 20.22.08 release, please discuss with your D2L contact prior to enabling to avoid any major disruptions in site functionality.On = CSP header reports violations onlyOff = CSP header is enforced SVG Execution Blocking The config d2l.Security.ContentSecurityPolicy.SvgAllowScripts controls whether SVG JavaScript execution is allowed. It is recommended to not allow JavaScript execution unless it is coming from a trusted source so most clients should leave this config disabled. On = allow JavaScript execution Off = block JavaScript execution How to get client reporting? The CSP reports are not available to clients directly within the System Log. D2L can provide these logs as needed. Your D2L representative can obtain recent logs for you if required.