After disabling web security I still cannot overcome same origin policy - html

I am using google chrome version 43.0.2357.81 on OS X and attempting to display a webpage within an iframe.
ie:
I followed this link with instructions to disable web security and found it helpful for displaying local files within iframes but I am still encountering the same origin error when trying to display disparate web pages.
Disable same origin policy in Chrome
I ran the command open -a Google\ Chrome --args --disable-web-security in terminal and received the banner message confirming that it worked:
You are using an unsupported command-line flag: --disable-web-security. Stability and security will suffer.
However when I view my webpage in chrome I still got a same origin error and was unable to view the site within the iframe.

This has nothing to do with Chrome itself; the server you call within the iframe sends back a http header with
X-Frame-Options SAMEORIGIN
setting. Even "chrome.exe --user-data-dir=c:\tmp\chrome2 --allow-file-access-from-files --disable-web-security" does not disable the iframe same origin check in Chrome. The only option you have is to switch the X-Frame-Options of your server to
X-Frame-Options ALLOWALL
(if you can).

Related

Why does Google Chrome automatically redirect `http://app` to `https://app` but doesn't do that to `http://app2` or `http://napp`?

Environment:
Ubuntu 18.04.6 Desktop 64-bit
Google Chrome 98.0.4758.80 (Official Build) (64-bit)
FireFox 92.0 (64-bit)
What I did:
Install apache2 (so it starts a default local website that I can access at http://localhost).
Edit /etc/hosts and add the following entries:
127.0.0.1 app
127.0.0.1 app2
127.0.0.1 napp
On Google Chrome, open the following URIs:
http://localhost: Successfully opened the "Apache2 Ubuntu Default Page" as an insecure domain.
http://app: Got redirected to https://app automatically and returned the error "This site can’t be reached"
http://app2: Same as http://localhost.
http://napp: Same as http://localhost.
On FireFox, open the following URIs:
http://localhost: Successfully opened the "Apache2 Ubuntu Default Page" as an insecure domain.
http://app: Same as http://localhost.
http://app2: Same as http://localhost.
http://napp: Same as http://localhost.
I searched on Google and saw posts that talk about the automatic redirect from http to https, such as How to Stop Chrome from Automatically Redirecting to https. I followed the posts by deleting the security policy for the domain app and clearing the browser cache of all the time, but I still got redirected from http://app to https://app. (In fact, I was using a freshly installed OS and Google Chrome and had never opened any websites before doing the test.)
Why does Google Chrome automatically redirect http://app to https://app but doesn't do that to http://app2 or http://napp?
I also learned that Chrome & Firefox now force .dev domains to HTTPS via preloaded HSTS and Google rolls out .app domains with built‑in HTTPS. So it looks like the browsers are using preloaded/builtin HSTS to enforce the use of HTTPS. But does http://app count as a case of .app domain?
I think it should be some browser settings because FireFox didn't do the redirection.
Simply put, Chrome uses a HSTS preload list to automatically redirect certain domains from HTTP to HTTPS. This preload list is "a list of sites that are hardcoded into Chrome as being HTTPS only." app is already included into this preload list, as shown by this link: "Status: app is currently preloaded." Therefore, when http://app is entered, Chrome automatically redirects it to https://app. But app2 and napp are not included, so http://app2 and http://napp are untouched.
I wrote the article Why does Google Chrome automatically redirect http://app to https://app but doesn't do that to http://app2 or http://napp? to explain this with more details and other related links.

Blocked current origin from receiving cross-site document at 'myRemoteSite' with MIME type application/json

I think happened in the latest update of Chrome. They're not letting any of these content types if they come from a site. This is problematic because I need the chrome developer tools to develop my app making calls to an api. Does anyone know how to disable or override this?
Change the directory in cmd to "cd Program Files (x86)\Google\Chrome\Application"
and execute the below command to disable chrome security and also avoid "Blocked receiving cross-site document warning."
C:\Program Files (x86)\Google\Chrome\Application>chrome.exe --user-data-dir="C:/Chrome dev session" --disable-web-security --user-data-dir --disable-features=CrossSiteDocumentBlockingIfIsolating

Deleting Chrome HSTS for facebook.com not working

I am currently doing some debugging on my website which involves calling the facebook API.
I've installed dnsmasq to work with my mac os X to redirect all request to facebook.com to 127.0.0.1
I have a echo server which will print out all the raw http request header on port 80 on my laptop.
Now comes my problem. When I access facebook.com, I realize chrome will automatically forward http:// to https:// for facebook.com
I googled and found the way of deleting this HSTS issue. I visit chrome://net-internals#hsts to see something like this:
HSTS chrome image
After entering "facebook.com" under "Delete domain", I can still query "facebook.com" in the input box below.
I tried clearing all user data on chrome, closing and reopening chrome and even using incognito mode.
Why is chrome still redirecting all request to facebook.com to https?
How can I disable this if chrome://net-internals#hsts is not
reliable?
The text next to the Delete domain box on chrome://net-internals/#hsts clearly states that preloaded entries cannot be deleted. This feature request was closed as WontFix in the Chrome bug tracker.
facebook.com and quite a few of its subdomains are included in Chrome's preload list.
You could use another domain name for your tests.
Just make api-calls to facebook-api-test.com, map that domain to localhost and proxy the calls.

Easyrtc permission denied and usermedia failed

I am using hublin. the camera and microphone was working fine locally but when i uploaded to server. camera permission pop does not appear, it just silently fails and at console there is error of
easyrtc.js:2100 invoking error callback PermissionDeniedError
easyrtc.js:2085 getusermedia failed
The problem is both with chrome and chromium however asking permission at firefox.
Also i tried to give permission manually but there is no cam-cross icon in rightcorner. In chrome settings>advanced settings>content-settings>camera>manage-exceptions there is no way to manually add specific url for allowing permission as in firefox.
Using of HTTPS for WebRTC applications is mandatory in Chrome. So, it just doesn't show permission dialog when working on a plain HTTP.
Hence, you should configure secure HTTP (HTTPS) on the web server (you can use certificates from LetsEncrypt - work like a charm). Or you can try to use some tricks/workarounds described in this article: https://webrtchacks.com/chrome-secure-origin-https/

Remote Debug "Chrome Mobile" to "PC"

I want to inspect and debug a Chrome Mobile application on my "chrome pc/machine",
so I've followed [this](http:// eveloper.chrome.com/devtools/docs/remote-debugging-legacy
) Google tutorial.
When I acessed localhost:9222, it lists the correct sites opened on my android chrome.
But the following error occurs when I click on "Inspectable pages". The console show the message
Document was loaded from Application Cache with manifest https://chrome-devtools-frontend.appspot.com/serve_rev/#178678/178678.manifest
Application Cache Checking event
[blocked] The page at 'https://chrome-devtools-frontend.appspot.com/serve_rev/#178678/devtools.html?ws=localhost:9222/devtools/page/0' was loaded over HTTPS, but ran insecure content from 'ws://<localhost>:9222/devtools/page/0': this content should also be loaded over HTTPS.
Uncaught SecurityError: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.
I encountered this problem too.
According to this report Chromium Issue 398817, you can add the --allow-running-insecure-content when launching Chrome.
This worked for me on Windows 7.