Announcement

Collapse
No announcement yet.

Content Security Policy CSP

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Content Security Policy CSP

    A Content Security Policy (CSP) is set by a server header that describes what content can be loaded into the DOM.

    The CSP limits a third party script's ability to inject malicious code into your web page. For example, a third party could inject a script that logs keystrokes to copy your user's credit card numbers.

    Most third party scripts come from trusted sources such as Google, PayPal, Fontawesome, LiveChat, etc. But these third party scripts can also block or slow the rendering of your web page as they compete for network resources.

    Third party scripts can also introduce insecure content to your https page.

    My intent is to control the network resources to improve my page speed on mobile devices and to enforce strict secure protocol (HSTS) in the near future.

    I used the Principal of Least Privileged (POLP) and then incrementally granted permissions to required resources. Of course, I include trusted third party partners for a reason so I have to allow them the resources they need.

    What I found is that these third parties sometimes make mistakes and inject insecure content or become a resource hog and load a large font file.

    I also found that some users have browser adware extensions that inject coupon codes onto the DOM that I can interrupt.

    Below is a utility script that can help you log or track your CSP violations.

    You'll need to modify the policy for your web site and it took a few weeks for me to make changes to the policy and better understand what was going on on my DOM.

    First create a PAGE uri for CSP reporting:

    PAGE > ADD >
    CODE: CSPR
    NAME: Content Security Policy Reporter
    TEMPLATE:

    Code:
    <mvt:assign name="g.content_data" value="s.content_data" />
    <mvt:item name="ry_toolbelt" param="Json_Parse|mivadata|g.content_data|verbose" />
    
    <mvt:assign name="g.filepath" value="'/reports/'"/>
    <mvt:assign name="g.filename" value="'csp.txt'"/>
    <mvt:assign name="g.newline" value="asciichar(10)"/>
    
    <mvt:assign name="g.headerrow"     value="'json' $ g.newline" />
    <mvt:assign name="g.file_row" value="g.content_data $ g.newline" />
    <mvt:assign name="g.file_exists" value="sexists(g.filepath $ g.filename)"/>
    
    <mvt:if expr="g.file_exists" >
        <mvt:assign name="g.write_line" value="file_append( g.filepath $ g.filename, 'script', g.file_row )"/>
    <mvt:else>
        <mvt:assign name="g.file_created" value="file_create(g.filepath $ g.filename,'script', g.headerrow)"/>
        <mvt:assign name="g.write_line" value="file_append( g.filepath $ g.filename, 'script', g.file_row )"/>
    </mvt:if>
    
    
    <mvt:if expr="g.content_data" >
        <mvt:assign name="g.csp_mail_to" value="'[email protected]'" />
        <mvt:assign name="g.csp_mail_from" value="'[email protected]'" />
        <mvt:assign name="g.csp_mail_subject" value="'Content Security Policy Exception'" />
        <mvt:assign name="g.csp_mailmessage" value="g.content_data" />
        <mvt:do file="g.module_library_utilities" name="g.email_sent" value="SendEmail(g.csp_mail_to,g.csp_mail_from,'',g.csp_mail_subject,'',g.csp_mailmessage)" />
    </mvt:if>
    
    
    <mvt:if expr="g.email_sent" >
        <mvt:assign name="g.has_header" value="miva_output_header( 'Status', '204')" />
        <mvt:assign name="g.has_header_flush" value="miva_output_flush()" />
    </mvt:if>

    Then go to the new CSPR page's URI tab and add:

    CANONICAL: /content-security-policy-reporter.html

    Each page can have its own CSP.

    You would go to the Page > Items > http_headers and assign.

    Select the http_headers tab, the select Add. You will add a key value pair.

    Header: Content-Security-Policy-Report-Only
    Value: Your custom policy

    Here is an example policy with comments:

    Code:
    // Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback)
    default-src 'self';
    
    // Define from where the protected resource can load images,
    img-src https: https://*.gstatic.com data:;
    
    // Define which scripts the protected resource can execute
    script-src https: https://*.paypalobjects.com 'unsafe-inline' 'unsafe-eval';
    
    // Define which styles (CSS) the user applies to the protected resource
    style-src https: 'unsafe-inline';
    
    // Define from where the protected resource can load fonts
    font-src https://*.gstatic.com https://*.fontawesome.com https://*.livechatinc.com https://*.googleusercontent.com data:;
    
    // Restricts from where the protected resource can embed frames. Note, deprecated in CSP2
    // A lot of third partys use document.write to create an iframe to inject their content and I couldn't easily sandbox their iframe
    frame-src https://*.google.com https://*.braintreegateway.com https://*.livechatinc.com https://*.googletagmanager.com https://*.doubleclick.net https://*.youtube.com gsa:;
    
    // Defines directive specifies valid sources for Worker, SharedWorker, or ServiceWorker scripts
    worker-src 'self' data: https: ;
    
    // Define from where the protected resource can load video and audio
    media-src https://*.livechatinc.com;
    
    // Define which URIs the protected resource can load using script interfaces
    connect-src https://www.yourdomain.com https://*.cloudflare.com https://*.googleapis.com https://*.googlesyndication.com https://*.googletagmanager.com https://*.shopperapproved.com https://*.googlecommerce.com https://*.google-analytics.com https://*.googleadservices.com;
    
    // Specifies a URI to which the user agent sends reports about policy violation
    report-uri https://www.yourdomain.com/content-security-policy-reporter.html
    The above example has some calculated risks with the inclusion of unsafe-inline' 'unsafe-eval' but it is just an example that can be adjusted.

    There is a link below for a good reference to a more detailed discussion of CSP.


    Mitigate the risk of cross-site scripting attacks by whitelisting trusted origins with a Content Security Policy.
    http://www.alphabetsigns.com/
Working...
X