Inline JavaScripts do not allow secure Content Security Policy #593
Comments
|
There's an ongoing effort to move to Twig templates. The move of JS from inline to separate files will be tackled as part of that effort, and/or be much simpler after that change. You're welcome to help move the Twig changes forward! |
thijskh
pushed a commit
that referenced
this issue
Aug 14, 2017
See issue #593 for a problem description. SimpleSamlPHP makes use of unsafe inline Javascript and CSS elements. Although most generated HTML uses SimpleSamlPHP's own headers, the keepPost option in an authentication request uses the headers of the PHP application it is sent from. This forces web applications using SimpleSamlPHP to allow 'unsafe-inline' in their Content Security Policy. This commit fixes this issue for the keepPost page ''only'', to allow PHP applications using SimpleSamlPHP to use a more strict Content Security Policy. This does not take away from possible XSS vulnerabilities in other parts of SimpleSamlPHP.
|
Largely solved in new UI. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I have an installation of SimpleSamlPHP 1.14 and I have tried to achieve "A" rating of my site at https://securityheaders.io/ The tool checks for having a Content Security Policy defined by a HTTP header.
The problem is that SimpleSamlPHP uses a lot of in-line JavaScripts and CSS styles, so the policy must contain "style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline';" to keep them working, but such setting is considered as insecure because in-line scripts and styles can be injected by an attacker.
The recommended solution is to move all scripts and style into separate files and link them.
See https://en.wikipedia.org/wiki/Content_Security_Policy and https://hacks.mozilla.org/2016/02/implementing-content-security-policy/ for details on CSP.
The text was updated successfully, but these errors were encountered: