"...and don't talk to strangers" - sounds familiar? It sure does. It’s a parent's advice and it’s given to kids all around the world.
But what’s happening here? If you look at it from the security angle, the parent is defining a policy for the kid to follow (aka. good advice). The parent's intention is to increase the kid’s security, but the enforcement of the policy is entirely in the child’s hands. The parent is probably nowhere near when the policy needs to be enforced.
The pattern is obviously widespread and well tested. So much so, that even computers use it: web servers instruct browsers to trust only particular sites for scripts, fonts, styles, or images and not talk to the others (the stranger). The mechanism used in this context is called Content Security Policy (CSP). Admittedly, calling it a manifestation of the server’s love for the user’s browser would be carrying the analogy a little too far.
But what is this good advice that a server might give to a browser, how does it work and how do you use it if you care for the security of users of an SAP S/4HANA system?
CSP basics
What are CSPs and what are they good for?
Technically, content-security-policy is a field in the header of an HTTP response. It is sent from the server to the browser to inform the browser about the resources the web page might load. More specifically, the CSP declares where additional resources like fonts, scripts, styles, and images might be loaded from the page.
The browser uses this information to detect unexpected behavior: if a page is known to not load any scripts from external sites (i.e., the site has a CSP with script-src 'self' or script-src 'none') makes requests to evil.com to get and execute JavaScript, the browser will prevent this – it knows from the CSP that evil.com is a stranger and won't talk to it.
CSPs are pretty flexible and allow definitions of sources for content down to specific hosts, paths on hosts, and protocols ("trust everything that comes via https:"). It even has special keywords to describe that a page will not execute inline script (i.e., there are no <script>-tags on the page) or that only specific scripts might be executed (using nonces and hashes).
This makes CSPs a powerful additional line of defense against multiple attacks. Consider stored cross-site scripting as the most prominent example:
Suppose a web page is vulnerable to cross-site scripting because it fetches data from the backend and just adds it to the page without output encoding (a bug that should be fixed). If an attacker managed to put a script into a database field that is read and displayed on the vulnerable page, the result will be an html page with a <script>-tag.
Without CSP, the browser will unsuspectingly execute the script and do what the attacker wants it to do. If the server knows that this particular page does not contain inline-scripting, it can set a CSP in the response header to tell the browser "No <script>-tags to be expected on this page". Now the browser has a chance: when the script comes along, the browser will know that something is not right. It will issue an error message (visible in the debugging console) and refuse to execute the script.
The mechanism is not limited to scripts. It also covers style sheets, fonts, images, frames, connections, and more.
Sounds cool. What could go wrong?
Coming up with a suitable CSP might be rather easy for simple web pages. It's a lot harder in complex applications like SAP S/4HANA. Such applications might pull content from sources that are configurable by the user or admin (think about custom fonts or style sheets) – so there's no one-size-fits-all CSP that can be delivered with the application.
Similarly, imagine you have a working CSP and then implement a CDN (content delivery network): suddenly, scripts and styles are served from another host – and will be blocked by the browser if you don't adjust your CSP.
Finally, a much less obvious example: if users of your system use browser extensions for their work (maybe for accessibility), these extensions might modify a loaded web page within the browser (change the font, execute scripts to read or translate the content, fetch related information from 3rd party websites...). The browser will evaluate these modifications of the page's CSP. And if the CSP does not admit the activities the browser extension performs, they will be blocked.
In the worst case, an unsuitable CSP will turn your application into a blank canvas – when all content is loaded from sources that are treated as "strangers" according to the CSP, nothing remains.
Implementation: find "your" policy
The examples above show that a CSP is not a simple switch-on-and-be-happy feature.
In a complex environment like SAP S/4HANA, finding the right CSP is an implementation project that involves extensive testing. Fortunately, CSPs come with a handy feedback tool.
Feedback: CSP reporting
By design, CSPs are defined on the server side but enforced on the client side. This means that mistakes made by the backend developer or admin become visible in the user's browser at runtime but not in the backend. To give some violation information back, a reporting endpoint can be defined within the CSP. If a violation of the CSP occurs, the browser sends some information about the context of the violation to this endpoint.
This does not only work for violations where the browser actually blocked something. With the header, you can define a policy that is not enforced, but violations will be reported (in the browser and towards the reporting endpoint). It's a "just testing" version of the "real", enforcing CSP.
Test – evaluate – adjust ... repeat
So how do you get to a suitable CSP for your SAP S/4HANA system? SAP S/4HANA offers configuration options for CSP headers (both enforcing and report-only) as well as reporting endpoints for receiving CSP violation reports.
CSPs can be set separately for every path. This enables different handling for different UI technologies or individual application endpoints. Of course, complexity grows rapidly when configurations become very specific. A decent middle ground is the definition of the CSP at the base path for every UI technology (/sap/bc/ui2/, /sap/bc/gui/, /sap/bc/webdynpro/ ...) plus a catch-all policy for the root /.
Finding the "right" CSP is an iterative process of setting, testing, evaluating, and adjusting:
- Set initial CSP as report-only in a test system for selected UI technologies.
- Run tests striving for maximum UI coverage.
- Analyze reported CSP violations, adjust CSP and re-test.
- Change CSP to enforcing mode on a test system.
- Run tests again striving for maximum UI coverage and paying special attention to broken UI features and appearance.
- Implement the CSPs in your productive system once a sufficient level of confidence is reached.
Luckily, you can use the enforcing content-security-policy and the testing content-security-policy-report-only simultaneously for the same path. So, you can set a relatively liberal but "UI-compatible" enforcing CSP plus a stricter report-only one as the candidate for the next iteration.
Further reading
General (and very good) documentation on CSPs is available from mdn web docs.
The open web application security project (OWASP) has a cheat sheet on CSP.
For more on the implementation of CSPs in SAP S/4HANA Cloud Private Edition, see the official help page and SAP Note 3224606. The note also provides an example CSP as a starting point for your project, some modifications you might want to apply depending on your setup, and some common issues seen with CSP reports. There's also a blog post that provides a walkthrough of the maintenance transaction.
In SAP S/4HANA Cloud Public Edition, life is easier. The system already has a CSP built-in. You only need to maintain script/font/style sources for your customizations (if you have any) and the system puts them into the CSP at the right places. For more details, see the official help pages here and here. An example is described in this blog post.
- SAP Managed Tags:
1 Comment
