Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Misconfigured Content Security Policy
#1
Kindly assist to resolve the below vulnerability

Description:  A misconfigured Content Security Policy (CSP) can expose a web application to various security vulnerabilities, compromising the integrity, confidentiality, and availability of the application and its data. The misconfiguration can occur due to overly permissive settings, the use of insecure directives, or a lack of specificity in defining resource sources.

Impact: The presence of unsafe-inline in the Content Security Policy (CSP) does not have an immediate impact if no inline scripts are used or executed. Unsafe-eval is also present which allows the use of JavaScript’s eval() function and similar methods (e.g., setTimeout() with string arguments) However, it weakens the overall security posture by allowing potential future 

It is recommended to Remove unsafe-inline and Remove unsafe-eval


here is CSF currently using
aReply.AddHeader('Content-Security-Policy', 'default-src https: ' + quotedstr('self') +
    '; img-src https: ' + quotedstr('self') +
    '; object-src https: ' + quotedstr('self') +
    '; style-src https: ' +  quotedstr('self')+
    ' '+ quotedstr('unsafe-inline') +
    '; script-src https: ' + quotedstr('self')+
    ' '+ quotedstr('unsafe-inline') +
    ' '+  quotedstr('unsafe-eval') +
    '; frame-ancestors ' + QuotedStr('self'));

Remove the unsafe-inline and unsafe-eval will meet the purpose?
Reply
#2
if remove the unsafe-inline from the script-src then the application not working. I am using Intraweb version 15.3.5. Kindly assist to resolve this vulnerability
Reply
#3
Hi Pramod,

IntraWeb requires eval to work. There is no real alternative to it.

Depending on what you are using it is possible to remove unsafe-inline (we would need to analyse your existing application/pages).

I'll get in touch via email so we can arrange that.

Cheers,
Reply
#4
BTW, I've said it before and it's not too much to repeat:

The "protection" that CSP claims to give is overly estimated and so are the "weakenesses" that it says that it pretends to fix.

All resources used by IntraWeb (scripts and styles) are protected by a nonce which is unique in the context that they are being used. Eval() is only used in this context, i.e. the source of the code being executed is always guaranteed, otherwise the browser would block it (because of the missing/mismatched nonce attribute in the code).

Besides that, common attacks that CSP claims to protect your application from, such as (this is a PHP example):

// Insecurely rendered server data
<div id="user-name">${req.query.username}</div>

// User visits:
https://yourapp.com/?username=<script>st...)</script>

Won't ever succeed in IntraWeb because of the combination of the nature of the strong typed, compiled language used in the backend (not evaluated at runtime such as PHP), plus all the security features that IntraWeb has out of the box (e.g. validation of all parameters received in ALL requests).
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)