So recently I have been tasked with making standard hyperlinks work on a website that open pages on an intranet site. This works in Chrome on the same environment but not in IE 8. This is the clients current supported browser.
The issue is that in IE the setting Websites in less privileged web content zone can navigate into this zone. is disabled by policy settings, so if you attempt to open a link from the site to an intranet site, in IE 8 you get an Access Denied error.
Now obviously given this is disabled and can't be enabled in the short term (if at all) and given that providing them a link to copy is not an agreeable solution, I have been asked to see what is possible.
One url points to the sitemap of the intranet site. I also do not have access to the intranet site code.
Things I have tried:
Using javascript opening a window - Access Denied
Using javascript to open a blank window and injecting javascript to update the window.location, this also resulted in an Accesss Denied because the new window appears to be on the original domain (rather than blank).
IIS Reverse proxy, clicking on the link appears to host the intranet site from within the current site. This worked well but two features failed to work on the intranet site due to internal redirects, so wasn't feasible.
Performing a redirect from a mapped internal link to the required intranet link at IIS and .Net Controller levels, both of these fail as redirects are disabled on the client machine.
IFrame, eurgh - Access Denied
So my question is given that the feature is disabled by IE can any one think of the way around this?
Thanks
Just in-case anyone finds this useful. I managed to resolve this using the IIS Reverse proxy. There was an issue with some internal redirects not being handled, which was under a different sub folder to the rest of the site. But the main issue I had in getting this to work was that calls to .aspx files on the external site were actually being caught by the internal site's page handler, which meant that the rewrite rules for certain calls were getting handled as pages internally and returning a 404 page.
As our internal site uses razor under MVC, the page handler isn't used, so I was luckily able to remove the page handlers within the web.config. If this wasn't the case, I would have had to reorder the handlers so that the redirect rules handled the call before the handler.
Related
In our web app/site, I need to use an iframe or a popup window to validate if the current token is valid and refresh it if no.
So, I create an iframe, and set the property 'src' to the validation link such as "https://<domain_name>/auth?client_id=xxx" which is different to our app domain https://<app_domain>. and the return value will like "https://<domain_name>/code=yyyy"
document.createElement('iframe');
and I added the message handle for the web app/site, like
window.addEventListener("message", this.messageHandler);
in the messageHandler, I will check if the message is from a specified website, and then validate the "code" value, blabla, etc.
But when running in Chrome, I always got the error
"Blocked autofocusing on a element in a cross-origin subframe."
what confused me is:
it always failed when running in the Chrome browser, but it can work fine in Firefox and Edge chromium.
I tried to set iframe.sandbox = "allow-forms allow-scripts allow-same-origin", the problem still existed.
If the validating token failed in iframe or timeout, I will create a popup window to continue validating and refresh the token. But every time, using popup window can always succeed. If it is really a cross-origin issue, why using iframe failed but using popup window succeeded.
I didn't use window.postmessage. because I don't know how to pass the return value of iframe/popup-window to the main page.
I used CORS extension of Chrome or using parameter --disable-web-security when launching Chrome. the problem still existed.
when I created the iframe or popup window. it is very simple, I just set the iframe.src property, there is no element being created.
any help will be much appreciated.
p.s.
I refer to the following doc:
Blocked autofocusing on a form control in a cross-origin subframe
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
Support for iframes in web development will only get worse over time as they are a security black hole, browsers are gradually over time locking out features and use of them.
I am assuming you are doing this because you are validating a user on a third party service, validating by watching the response of a third party service website?
Without knowing the service you are using I cannot comment specifically but for anyone looking to do something similar I would highly suggest not doing this:
As mentioned, iframes are constantly having features locked down due to security concerns
An attacker could change the source of the iframe and submit their own iframe to look like it has been correctly validated
It's unlikely that the page you are using as your iframe src is intended for this use, which will come back and bite you when the 3rd party developer changes how their page behaves, which they likely will do without knowing it's going to break your application
I recommend:
Finding a stable API the 3rd party service offers and using that
Finding another service if none exist
Apologies to rain on your parade!
I disagree that iframes are a security risk, rather they can be if not implemented properly.
How to implement them properly should be asked in another question and probably starting with a carefully implemented Content Security Policy as a priority.
I also use iframes within a Chrome extension that has to pass rigorous Google security.
As for the question, I've noticed that error too and I am focusing on an input box when the iframe is loaded and the focus works! I put it down to being a Chrome bug as the warning suggests it has stopped auto focusing when it hasn't.
As for the un-related point about passing the value back to the parent holding the iframe, I can help you with that, but you should ask it in a new question.
Disable some feature of browser setting
Browser Changes
chrome://flags/#cookies-without-same-site-must-be-secure
chrome://flags/#same-site-by-default-cookies
chrome://flags/#enable-removing-all-third-party-cookies
Above URL just paste it and disabled it. Then ok and relaunch the browser.
Then done it.
I have created project "Progressive Web App" based on JavaScript with Visual Studio 2017. The created project contains a file "package.appxmanifest". When the app is started it navigates to the URI, which is defined as StartPage in the manifest. This HTML-page contains a link, which should navigate to an other site.
window.location.href = 'other site'
This link works only when this URI is explicitly registered in the manifest as "Content-URI" (ApplicationContentUriRules).
Is it possible to allow all links without entry in Content-URIs?
UWP applications created with PWA, while relying on browsers, still feature the UWP sandbox application.
The link that appears in the Content-URI means that the link is trusted, and its sub-routes are accessible in the UWP window. But if you access an external link, the behavior will be directed to the browser, which will open the page by the browser.
You can use the wildcard "*" to match the links you need as much as possible, as described in the Content URI page, but that doesn't mean all links are allowed to be accessed in the UWP window.
Best regards.
From MS Docs:
Through ACURs, otherwise known as a URL allow list, you are able to give the URLs of your PWA direct access to Windows Runtime APIs. At the Windows OS level, the right policy bounds will be set to allow code hosted on your web server to directly call platform APIs. You define these bounds in the app package manifest file when you specify your PWA's URLs as ApplicationContentUriRules.
Your rules should include your app’s start page and any other pages you want included as app pages. If your user navigates to a URL that is not included in your rules, Windows will open the target URL in the Microsoft Edge browser rather than your standalone PWA window (WWAHost.exe process). You can also exclude specific URLs.
Maybe you can set a general allowance rule (not sure though if this is the right way to proceed):
<Application Id="App" StartPage="https://maApp.com/home">
<uap:ApplicationContentUriRules>
<uap:Rule Type="include" Match="https://*.*" WindowsRuntimeAccess="all" />
</uap:ApplicationContentUriRules>
In general with PWAs, you define a scope for your service worker in the web manifest. Then if the user clicks a link that navigates inside of this defined scope, the link will open within the PWA window.
If you want the link to be opened in a browser tab (hence outside of your PWA), you must add target="_blank" to the anchor tag.
If you want to read more about PWAs and web manifest I wrote an article about it.
UPDATE
With PWAs usually you want to navigate only within the scope of your app. If you need to redirect to an external resource/web site, the target page should be opened in an external browser page and not within the PWA scope. Therefore the current behaviour seems correct to me.
It is possible to use wildcards in the Rules.
E.g.: http://*.mydomain.com/pwa/*/content
But as one Dave puts it:
However the Store places restrictions on submitting apps that use the
http://* rule or rules with an asterisk in the second effective domain
name label. For example, http://*.com is also restricted for Store.
So, try to reduce the Rule-set the hostnames that are known in advance.
I've been working on a requirement that involves a website fetching/manipulating data stored on a different domain. There didn't seem a way except for enabling CORS on the other server to allow me to get and modify data from a different domain. However, that caused some issues with Office 365 apps and I had to take a different approach.
The approach is to use postMessage to talk to a hidden iframe (not a good approach, but I was insisted to use it) on the page that is running on the target domain. The source page posts message along with information about the REST call to the hidden iframe which makes a requests on behalf of the parent page and uses postMessage to return back the results.
Everything works fine except for when the website is being used on an iPhone. Turned out placing alert calls in the script running inside the target iframe makes it to work but removing the alert calls sort of disables the target iframe from making those cross-origin network calls.
My theory is that it is due to the security of mobile Safari that in order to make cross-origin calls from an iframe running on a different domain, the user needs to provide their consent by interacting at least once with the embedded iframe. Does that sound correct?
The comment by diodeus-james-macfarlane is the closest that we could go but the iframe being hidden, there was no way we could have placed a control for the user to interact with, even if that was only for it to work.
To my surprise, turning off a setting on the SharePoint site made it work. The setting was around mobile view compatibility and without that, the iframe is able to make HTTP requests, send and receive messages to and from the parent webpage.
I am using a Javascript widget (specifically Accuweather) on my aspx page and it detects it as a call to another domain.
The Javascript widget is present on most of the site as it is in the master page.
It is showing me the error "This page is accessing information not under its control" and can get annoying for some users.
This happens on the Intranet Zone of our site.
I know one way to solve it is by changing the "Access data sources across domains" to Enable instead of Prompt. However, we have other sites that we don't want to be affected by the change. Changing the Intranet Zone affects all of the Intranet Sites.
Another possible way is, instead of being in the Intranet Zone, transfer it to Trusted Sites (which is configured properly already). However, our setup is to automatically detect the Intranet Zone. How can we do this?
Can anyone help?
Thank you!
I'm having a few problems with an application that integrates sharepoint, SQL reporting services and a bunch of custom forms that are built using ASP.NET MVC.
Assuming my servers are as follows;
MOSS
SSRS
Custom forms
In MOSS, my portal has need on occassion to popup a custom form to capture user input. I've done this by using a jQuery dialog (using Boxy), which iframes the custom form in and passes the url of the portal into it. When the custom form is finished, it navigates the parent window (the MOSS portal) to the URL passed in, which effectively refreshes the page.
This was working fine until we threw in the complexity of SSRS.
Now in MOSS, I have a report that lists some data, but the SSRS report viewer web part seems to iframe it's report content in, which means the hyperlinks from the report can't ask the parent to overlay the same dialogs (as it's cross domain) and if it were to perform the overlay itself, it would just overlay the iframe.
Sorry for the long post, getting to the point - this is an internal intranet application only. Is it possible to allow cross domain scripting somehow so that the popup dialogs can all be controlled from javascript within the sharepoint portal and SSRS and my custom forms can just invoke javascript methods on the parent?
Preferably I wouldn't want to have to do configuration in the client browser to allow this to happen, as I'd have to roll that change out to all the machines within the estate - which is a significant number.
Thanks in advance, beer available to anyone who can solve my woes ;)
Cheers,
Tony
IE8, Firefox 3, recent Opera and Safari/Chrome support postMessage which allows cooperating pages on different domains to talk to each other:
http://ajaxian.com/archives/cross-window-messaging-with-html-5-postmessage
If you are stuck with older browsers, you have few options. The cleanest is to send everything that needs to communicate with each other through the same proxy, although in the OP's situation it looks like this isn't possible.
The next cleanest is to use Flash's cross-domain facility.
Another option is xssinterface, which wraps postMessage where available and uses some voodoo involving cookies and polling where it isn't.
The only other option is to use hidden iframes - to send a message to a page, change the iframe's location to one on the destination page's domain and poll in the destination page - but again I think the proxying in the OP's case makes this unworkable.
There is another option in addition to those Andrew provides. You can dynamically inject script tags into the DOM, wherein the src attribute can point to a javascript file on any domain.
In jQuery you accomplish this by specifying "jsonp" as the datatype for the ajax request. You can read more about this approach here:
http://blog.ropardo.ro/2009/09/23/cross-domain-ajax-calls/
I finally got around these issues by using hidden iframes as suggested. I posted an article on my blog with more details and pushed the code onto codeplex:
http://www.deepcode.co.uk/2009/11/overcoming-cross-domain-issues-between.html