| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/authelia/authelia | all versions | |
| github.com/authelia/authelia/v4 | ≥ 4.39.15, < 4.39.16 | 4.39.16 |
| authelia | = 4.39.15 |
Official Weighted Severity Rating: Low
This exploit is very unlikely to be the case for most users as it requires configuration of the Content Security Policy template value. Below represents a safe value, any other value other than unconfigured should be very carefully evaluated regardless of the fix.
server:
headers:
csp_template: ''
AUTHELIA_SERVER_HEADERS_CSP_TEMPLATE=
Provided the following conditions are met:
script-srcconnect-srclanguage cookie scoped to the fully qualified domain name of Authelia with the same site value of strict (which is not possible in most scenarios unless the application in 3 has the exact same domain or a subdomain of the Authelia domain).language cookie scoped for a domain that Authelia is sent cookies for.An attacker may potentially be able to inject javascript into the Authelia login page. Unless both the script-src and connect-src directives have been modified it's almost impossible for this to have a meaningful impact. However if both of these are and they are done so without consideration to their potential impact; there is a are situations where this vulnerability could be exploited.
This is caused to the lack of neutralization of the langauge cookie value when rendering the HTML template.
This vulnerability is likely difficult to discover though fingerprinting due to the way Authelia is designed but it should not be considered impossible. The additional requirement to identify the secondary application is however likely to be significantly harder to identify along side this, but also likely easier to fingerprint.
Upgrade to 4.39.16 or Downgrade to 4.39.14.
No current proof of concept exists that does not require manual manipulation of the browser which is effectively a local attack where all privileges have been compromised without the need for this attack vector (i.e. installation of userscripts or a browser plugin which would be able to compromise any website or web app). There is a decent chance one will exist or certain conditions exist that could lead to the vulnerability being exploitable.
Discovery of this flaw has prompted an deliberate evaluation of any other potential flaws similar to this which did not yield any results, as well as a deliberate evaluation of best practices in this area which has resulted in a minor tweak to hardening measures. These additional hardening measures should not have any effect (explicit definition of the script-src and connect-src policies, which are the same value as default was previously), but it should theoretically prevent an accidental change in the future degrading the existing security layers we implement.
The overwhelming majority of installations will not be affected and no workarounds are necessary. The default value for the Content Security Policy makes exploiting this weakness completely impossible. It's only possible via the deliberate removal of the Content Security Policy or deliberate inclusion of clearly noted unsafe policies.
The default Content Security Policy is completely secure and prevents any third party javascript the browser evaluates against it.
server:
headers:
csp_template: ''
Using a custom Content Security Policy is a very advanced choice that requires specialist knowledge. The use of unsafe-inline, unsafe-eval, unsafe-hashes, etc. are particularly problematic as they effectively allow arbitrary script execution (if a security policy includes an option that says unsafe it's probably a good indication you should not use it).
Both the next version and previous version of Authelia do not have this bug.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free