1

I've an apache 2.4 acting like reverse proxy. I use a simple form login to authenticate user before to proxy it to target server.

the login page is very simple:

<!doctype html>
<html lang="it">
<head><title>AUTENTICAZIONE</title>

</head>
<body>

<script type="text/javascript">
</script>

<form method="POST" action="/dologin2.html">
  Username: <input type="text" name="httpd_username" value="" />
  Password: <input type="password" name="httpd_password" value="" />
  <input type="submit" name="login" value="Login" />
  <input type="hidden" name="httpd_location" value="https://sgsvrsiimws11lx.sistemi.group/primoacc/sigma/app" />
</form>
</body>
</html>

I've a problem with firefox and chrome with this page:

Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-AbpHGcgLb+kRsJGnwFEktk7uzpZOCcBY74+YBdrKVGs='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.

In my httpd.conf i've already set this:

Header set Content-Security-Policy "frame-ancestors 'unsafe-inline' 'self' sgsvrsiimws11lx.sistemi.group;"

I've set it because some angular object on the backend was not loaded.

I've try to set the Content-Security-Policy in a lot of way but the javascript in the login page has always the error.

with chrome even if I've that error I can login, with firefox no.

How can set correctly in apache the Content-Security-Policy header to works correctly with my login page?

thanks

Gabriele
  • 21
  • 2
  • 5

1 Answers1

0

The Header set Content-Security-Policy "frame-ancestors 'unsafe-inline' 'self' sgsvrsiimws11lx.sistemi.group;" does not restricts inline scripts execution.
And you can remove 'unsafe-inline' token because frame-ancestors directive does not support it.

Looks like you "target server" sends a login page with own Content Security Policy having default-src 'self' rule.

Check in Dev Tool what CSP header do you really have in browser, here is tutorial.
If your "target server" publishes its own CSP, you have to add 'unsafe-inline' into it, not into reverse proxy config. The 'unsafe-inline' token should be inserted into script-src directive (or default-src if script-src is not used).

Notice: I hope you know that 'unsafe-inline' reduces ability of CSP protection. You can use 'nonce-value' or 'sha256-AbpHGcgLb+kRsJGnwFEktk7uzpZOCcBY74+YBdrKVGs=' (it's taken from Chrome's warning) to safe allow inline scripts.

granty
  • 7,234
  • 1
  • 14
  • 21
  • Thanks for reply. the login page is on apache document root not on target server. I've this error before to go on the target server since the login is used to authenticate before. – Gabriele Feb 26 '21 at 11:40
  • Have a look which CSP do you have in browser. `default-src 'self'` is published somewhere, maybe in .htaccess. Or maybe you have a third-party iframe in the login page? – granty Feb 26 '21 at 16:09
  • I'm using an include file for my configuration and for reverse proxy, I've find that in httpd.conf there is default-src 'self' and I've check with debug mode in browser that the login.html come with CSP header default-src 'self'. now how can I override the httpd.conf setting for the single login page? or how I've to change the CSP in httpd.conf to allow javascript? thanks! – Gabriele Feb 26 '21 at 16:29
  • the strange thing is that the resources that i retrieve in reverse proxy come with the CSP Header that I set in my include file... so all the resources that are in the backend and come through the reverse proxy have the CSP header that I set in my include file, the login.html that reside on reverse proxy uses the httpd.conf configuration... – Gabriele Feb 26 '21 at 16:33
  • To allow inline script you have to use `default-src 'self' 'unsafe-inline'` or `default-src 'self'; script-src 'self' 'unsafe-inline';`. `Header set` [replacing](https://httpd.apache.org/docs/current/mod/mod_headers.html#header) any previous header with this name, so the last one only is in act. To have some logic you can use `Header setifempty Content-Security-Policy ` or use `Header always set`. In last case you'll have both CSP header published that is not always suitable. – granty Feb 26 '21 at 17:30