Alternative for strict-dynamic in unsupported browsers - safari

I have been working on implementing CSP for our web-application and have noticed that on older browsers, the following error is thrown:
Error] The source list for Content Security Policy directive 'script-src' contains an invalid source: ''strict-dynamic''. It will be ignored.
Is there an alternative attribute I can use for browsers that do not yet support this property? Or, should I just remove it?

Related

Refused to load the script 'xyz.js' because it violates the following Content Security Policy directive with ChromeDriver Chrome headless Selenium

I am running selenium with headless chrome and getting error refused to load the image , because it violates the following Content Security Policy directive. I am parsing third party url. So what change or option i need to set in selenium to remove error.
Content Security Policy
Content Security Policy a tool which developers can use to lock down their applications in various ways, mitigating the risk of content injection vulnerabilities such as cross-site scripting, and reducing the privilege with which their applications execute.
CSP is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as defense-in-depth. It reduces the harm that a malicious injection can cause, but it is not a replacement for careful input validation and output encoding.
Content Security Policy Directives
As per Content Security Policy Directives to mitigate the risk of cross-site scripting attacks, web developers should include directives that regulate sources of script and plugins. They can do so by including:
Both the script-src and object-src directives, or
a default-src directive
In either case, developers should not include either 'unsafe-inline', or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself; they are best avoided completely.
Chrome Content Security Policy
In order to mitigate a large class of potential cross-site scripting issues, Chrome's extension system has incorporated the general concept of Content Security Policy (CSP) . This introduces some fairly strict policies that will make extensions more secure by default, and provides you with the ability to create and enforce rules governing the types of content that can be loaded and executed by your extensions and applications.
In general, CSP works as a block/allowlisting mechanism for resources loaded or executed by your extensions. Defining a reasonable policy for your extension enables you to carefully consider the resources that your extension requires, and to ask the browser to ensure that those are the only resources your extension has access to. These policies provide security over and above the host permissions your extension requests; they're an additional layer of protection, not a replacement.
On the web, such a policy is defined via an HTTP header or meta element. Inside Chrome's extension system, neither is an appropriate mechanism. Instead, an extension's policy is defined via the extension's manifest.json file as follows:
{
...,
"content_security_policy": "[POLICY STRING GOES HERE]"
...
}
Solution
Create a new Chrome Profile
Browse to the extension page for Disable Content-Security-Policy and Add to Chrome permanently.
Use the same customized Chrome Profile along with the extension while initiating your script:
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
options = Options()
options.add_argument("user-data-dir=C:\\Users\\user_name\\AppData\\Local\\Google\\Chrome\\User Data\\Profile 2")
driver = webdriver.Chrome(executable_path=r'C:\path\to\chromedriver.exe', chrome_options=options)
driver.get("https://www.google.co.in")
tl; dr
An Introduction to Content Security Policy
Issue 546106: CSP: Chrome complains the style-src hashes mismatch even though it shows them to be the same

If I use an API from a non-SSL website, are browsers required to give a mixed content error?

The title says it all. If I use an API from a non-SSL website, do I know I will I get a mixed content error from browsers? That is, is a mixed-content error for that case what the relevant standards require browsers to do?
Yes you will get a mixed-content error. Any insecure context
request/response is mixed content:
A request is mixed content if its url is not a priori authenticated, and the context responsible for loading it requires prohibits mixed security contexts.
A response is mixed content if it is an unauthenticated response, and the context responsible for loading it requires prohibits mixed security contexts.
The and the context responsible for loading it requires prohibits mixed security contexts just means the requesting context is secure context—basically, a document with an https origin.
See also the Active content examples section of the MDN Mixed content article:
<script> (src attribute)
<link> (href attribute) (this includes CSS stylesheets)
<iframe> (src attribute)
XMLHttpRequest requests
All cases in CSS where a url value is used (#font-face, cursor, background-image, and so forth).
<object> (data attribute)
Notice that the list includes XMLHttpRequest requests. (It should be updated to also include fetch() requests).
See also the example at https://developers.google.com/web/fundamentals/security/prevent-mixed-content/what-is-mixed-content#an_xmlhttprequest_example

How to Prevent Cross-Site Request Forgery Attack?

We ran Burp Suite on our product and found some security vulnerabilities. The tool detected some of the CGI files which are vulnerable to Cross-Site Request Forgery attacks (CSRF).
As usual I did search for CSRF protection module on CPAN and found CGI::Application::Plugin::ProtectCSRF.
I'm wondering how can I integrate this module into our application in a generalized way? The documentation is not clear to me. How do I configure this module and make minimal changes to make sure whole application is secured from CSRF.
I also came across mod_csrf (an Apache module to prevent CSRF). Is installing this module and setting below in apache configuration file enough to prevent CSRF?
<VirtualHost>
CSRF_Enable on
CSRF_Action deny
CSRF_EnableReferer off
</VirtualHost>
I can understand that you found the documentation for CGI::Application::Plugin::ProtectCSRF unclear: it is a little impregnable
All that the Perl module appears to do is to add a hidden field to each HTML form with the name _csrf_id and a random value derived from various sources and encoded through SHA1. The protection comes when the response from the client requires that the same value must be returned to the server
It is quite nicely coded, but it uses custom subroutine attributes, and the documentation for the attributes pragma says this
WARNING: the mechanisms described here are still experimental. Do not rely on the current implementation
I cannot tell from my quick review whether the subroutine prototypes are essential to the module, but I recommend that you use the Apache mod_csrf module instead, which is likely to be more thoroughly tested than the Perl module, and has proper documentation
Since we were using in house server, not apache, therefore, mod_csrf was not possible to implement.
I ditched ProtectCSRF module as the documentation was unclear.
I solved it by doing below:
Add an element in header template which is common to all pages, this element contains CSRF token which is being passed from server
Create a JavaScript function and bind it to onload event. This JS function does below tasks:
a) Find forms in current page
b) If forms are found then create a hidden "input" element and append it to each form
c) Take the value which was put in header and assign it to above created elements
d) Now all forms have a hidden input element which contains CSRF token from point 1
Now whenever a form gets submitted this hidden element will also be submitted, whose value we are verifying at server end. If tokens do not match then there is CSRF, for which we throw the error and block request

Load the API library in chrome app (for google wallet)

According to this documentation I should be able to include <script src="https://sandbox.google.com/checkout/inapp/lib/buy.js"></script> in html of my packaged app, but I received an error:
Refused to load the script
'https://sandbox.google.com/checkout/inapp/lib/buy.js' because it
violates the following Content Security Policy directive: "default-src
'self' chrome-extension-resource:". Note that 'script-src' was not
explicitly set, so 'default-src' is used as a fallback.
Also I've tried to attach buy.js (which I just copied from mentioned url) but it also produces an error in buy.js:
Refused to frame
'https://checkout.google.com/inapp/frontend/app/payments.html?formFactor=DES…extension://ihligbifffjddjffdiapccakkdglodcj&rti=i:48847aba&rt=o:-519cd794'
because it violates the following Content Security Policy directive:
"frame-src 'self' data: chrome-extension-resource:".
What is the problem here?
You're doing it wrong. This buy.js is a simple cross-app messaging script which talks to internal Google In-App Application inside Chrome.
You must package the buy.js library with your app, and load the library from its location in your package.
Check this for more info

Resource interpreted as Document but transferred with MIME type application/xml

I have some RESTful APIs that I am building using Apache CXF. I was using the browser to test my results and this works fine mostly.
However, in some cases I get "Resource interpreted as Document but transferred with MIME type application/xm" error on Chrome and with firefox I get "XML Parsing Error: no element found"
The strange thing is that if I restrict my response by adding some conditions then it works fine. This makes me thing its related to the size of response. I have searched the web but I didn't find any concrete answers.
What am I missing? Any help is appreciated.
Thanks.
I am using Apache Camel to route my requests to different services. I had the streamCache flag enabled for my CamelContext configuration. Disabling the streamCaching resolved the issue.
Details about stream caching can found at the following url:
http://camel.apache.org/stream-caching.html