i am developing an nodejs express application that is running in the ibm cloud. Via Hostedscan i tested my application for security issues.
im getting follwing result:
"X-Content-Type-Options Header Missing"
The Anti-MIME-Sniffing header X-Content-Type-Options was not set to 'nosniff'. This allows older versions of Internet Explorer and Chrome to perform MIMEsniffing on the response body, potentially causing the response body to be interpreted and displayed as a content type other than the declared content type.
Current (early 2014) and legacy versions of Firefox will use the declared content type (if one is set), rather than performing MIME-sniffing.
my url that have a risk:
https://xxx.xxx.xxx.xxx:xxxxx/socket.io/socket.io.js
its a get method
i implemented following solution
(server.js)
const helmet = require("helmet")
.....
app.use(helmet.noSniff())
with this code a part of the security issues where gone like :
https://xxx.xxx.xxx.xxx:xxxxx/
https://xxx.xxx.xxx.xxx:xxxxx
https://xxx.xxx.xxx.xxx:xxxxx/chatroom
but the secuirty risk with https://xxx.xxx.xxx.xxx:xxxxx/socket.io/socket.io.js is still reminding.
i also tryed in my index.html following, because i thought the security risk could be because my client is also interacting with socket.io
<script
src="https://cdnjs.cloudflare.com/ajax/libs/socket.io/4.5.1/socket.io.js"
integrity="sha512-xxxxxxxx....."
crossorigin="anonymous">
</script>
does anyone have an approach?
Related
all.
I am thinking about a issue using pdfTron SDK(an SDK help load pdf) in my application. This SDK is able to load local pdf files, working like a charm. I decide to load an online pdf file in my web application, using pdfTron SDK, e.g. 'https://cdn.mendix.tencent-cloud.com/documentation/developerportal/tencent-deploy.pdf'. This file is accessible in browser, directly, but when I use scripts, like:
instance.UI.loadDocument('https://cdn.mendix.tencent-cloud.com/documentation/developerportal/tencent-deploy.pdf');
};
I directly got an error when running the application, which shows
Request URL: https://cdn.mendix.tencent-cloud.com/documentation/developerportal/tencent-deploy.pdf
Request Method: HEAD
Status Code: 403
Referrer Policy: strict-origin-when-cross-origin
I think this is a CORS issue. But I cannot understand why I can use browser getting this file, while scripts does not. How can I resolve this? Thanks
I would suggest to read the documentation on pdfTron concerning "webview" and "loadDocment".
WebView is used to get the pdf you want to use from any source(file or web), in your case, you need to use "initialDoc" property, that is where you would place "cdn.mendix.tencent-cloud.com/documentation/developerportal/…".
Then "instance.UI.loadDocument" is used to identify the html element where you want to place the fetched document.
Sample
API Docs
I also try a CORS config in my document server(nginx), like this:
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';
This works now. But It seems that if the document server is not yours, you cannot do this. Hope this help!
I've been using helmet to implement Content-Security-Policy and have not had any problems until I upgraded the Node version I was using from 6 to 16.
I return a styled HTML element when the app first loads, and I use a nonce on the style tag. After upgrading node versions, nothing loads and I see this message in the browser console:
Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'nonce-uXeTuzCq2Sp5MWrSBuypzA=='". Either the 'unsafe-inline' keyword, a hash ('sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='), or a nonce ('nonce-...') is required to enable inline execution.
Here is the CSP configuration that I am currently using with helmet.
const sources = [];
sources.push((req, res) => `'nonce-${res.cspNonce}'`);
sources.push("'self'");
app.use(
helmet.contentSecurityPolicy({
directives: {
defaultSrc: sources,
scriptSrc: sources,
styleSrc: sources,
frameAncestors: sources
}
})
);
I've tried different configurations for the directives but nothing is working.
I'm confused because the error message in the console suggests using a nonce, but I am using one. In the network tab I can see the CSP on the header and there is a nonce on the style tag as expected.
It ended up not being an issue with helmet, but with styled-components, a dependency of a front end library that was added along with the Node upgrade. I just had to add a __webpack_nonce__ along with the existing nonces and everything worked as expected.
When i debug javaScript on devtool.
chrome.runtime
see "http://www.qq.com",it show:
chrome.runtime is undefined. see http preview.
But when i debug it on https site (https://www.qq.com ).it work fine. see https preview.
tips: all script run on top frame.
Can i change "chorme:flags" to enable it ?
i got why now.
"chrome.runtime.sendMessage" not exist when no extension installed.---since chrome 66+.
see:https://bugs.chromium.org/p/chromium/issues/detail?id=835287
Comment 29 by rdevlin....#chromium.org, Apr 25 For at least some of
these cases from the duped bugs, I think this was caused by revision
39f8939309fe39bccc17fa1280b6c7f25c411947. This modified the
externally_connectable property of the cryptotoken component extension
(automatically built into Chrome) to only accept incoming connections
from https URLs, whereas previously it was all URLs. When it was set
to all URLs, chrome.runtime.sendMessage would always be available
because any URL could potentially send a message to the cryptotoken
component extension.
However, this is working as intended. The cryptotoken extension only
accepts connections from https origins (so any others would be
ignored), and sending a message to any other extension would require
the receiving extension to list the URL in the externally_connectable
options. Additionally, this means that before, any extension relying
on this behavior would likely have failed to send the message, but
done so asynchronously (once the message failed to find an appropriate
receiver) rather than synchronously (since runtime is undefined). If
the extension lists the URL in externally_connectable, then
chrome.runtime should still be present. If the extension does not
list the site in externally_connectable, then chrome.runtime not being
available is intended behavior.
Is there any case in which chrome.runtime is undefined for
non-sandboxed chrome-extension:// pages, or for web pages where an
installed extension specifies that web page's URL in the
externally_connectable field of the manifest? If so, please attach an
extension that demonstrates this issue. If not, this sounds like it's
WAI.
fix: add one extionsion with:manifest.
"externally_connectable": {
"ids": [
"*"
],
"matches": [
"http://test.yoursite.in:9090/*",
"*://*.chromium.org/*"
]
},
thinks all.
Using a browser REST client to POST to the activity stream at e.g.
https://connectionsww.demos.ibm.com/connections/opensocial/basic/rest/activitystreams/#me/#all
...with the settings prescribed in IBM Connections OpenSocial API > POSTing new events
...results in the following response:
<error xmlns="http://www.ibm.com/xmlns/prod/sn">
<code>403</code>
<message>You are not authorized to perform the requested action.</message>
<trace></trace>
</error>
What am I missing?
This same approach works nicely on IBM Connections 4.0.
Which setting needs 'switching on'?
Try a URL like this... https://sbtdev.swg.usma.ibm.com:444/connections/opensocial/basic/rest/activitystreams/#me/#all
I added the Basic/Rest component, and it worked for me.
1 - Added URL https://sbtdev.swg.usma.ibm.com:444/connections/opensocial/basic/rest/activitystreams/#me/#all
2 - Changed Method to Post
3 - Added Content-Type: application/json
4 - Authentication -> Basic
5 - Logged IN
6 - Posted
Same thing here: 403 when I make an AJAX call to an IBM Connections 6.0 REST API url. Same error in Chrome, Firefox and IE11. When I open the same URL in a separate browser tab, everything works fine.
Comparing the http headers of both calls, and fiddling with Postman, the diference is the presence and value of the atribute Origin.
Seems that Connections allows calls from its own server. For example, when: Origin: connections.mycompany.com.
It also allows calls when Origin is not defined, which happens when the url is called from a separate browser tab.
There is a doc at IBMs Support site that confirms this - http://www-01.ibm.com/support/docview.wss?uid=swg21999210. It also suggests a workaround that did the job for me: unsetting the Origin attribute in the IBM HTTP Server that is in front of your Connections instance. Add the lines below to the httpd.conf file:
Header unset Origin
RequestHeader unset Origin
I'm writing an extension that requests XML content from a server and displays data in a popup/dialog window. I've added the website to my manifest.json permissions like so:
"permissions": [
"http://*/*"
],
Later I added the following code to my background page:
function loadData() {
var url = "http://www.foo.com/api/data.xml";
var xhr = new XMLHttpRequest();
xhr.open('GET', url, true);
...
xhr.send();
the problem is, that I get the cross-site security error "Origin chrome-extension://kafkefhcbdbpdlajophblggbkjloppll is not allowed by Access-Control-Allow-Origin. "
The thing is, with "http:///" in the permissions I can request "http://www.foo.com/api", but I can't find any way to allow "http://www.foo.com/api/data.xml".
I've tried both "http:////*" and http://www.foo.com/api/data.xml" in the "permissions". What else should I be doing?
This should work (SOP doesn't apply to chrome extensions),so there are three possibilities:
There is some mistake somewhere
Just to make sure use add <all urls> permission and check that extension really have this permission. (e.g. execute chrome.runtime.getManifest() in console when inspecting background page )
Server itself is checking Origin header and is rejecting request if origin value is unexpected
You can quickly check this by using some http tester and sending request manually (for example Dev Http Client for chrome, since I'm one of the developers). If it shows the same error, it means that the server is really checking origin header.
To fix this you will have to make server somehow accept your origin , or you can use chrome.webRequest to set valid origin header to all the requests sent to the target server (standard XHR api doesn't allow modification of Origin header)
Chrome bug
Well in this case you can only report this error and wait for the best