We created a custom application and linked it to the dashboard. The UI is loading inside the dashboard in Mobile App but not loading in Edge/Chrome. In the browser, UI is loading after clicking the primary action button.
Modern web browsers have become increasingly restrictive about how content is handled from secure contexts (i.e., https) and unsecure contexts (i.e., http) and generally doesn't like to mix the two.
Banno Online is served up in an https context so all of the content (including plugins) should be served up with https as well.
The only exception to that general rule is localhost (e.g., for local development such as the Simple Plugin Example).
It's worthwhile to read up on these pages for the Plugin Framework:
Restrictions
Authentication
Related
Almost all useful extensions require permission to access and modify all data on a page.
We can't be sure that a chrome extension is malicious in the sense if it's leaking my data or not.
I realise that many extensions which I use for example the great suspender, even though it needs access to all site data, it doesn't need to communicate with outside world.
Is there a way to block specific chrome extensions from making any network requests at all. ( can we block all outgoing/incoming traffic to a chrome extension. )
I can't keep monitoring a extension 24/7 to see when is it leaking data, For all you know it could be leaking once a month.
No, there's no way to block just the network communication of an extension without blocking its site access (aka "host permissions") entirely. That's because a malicious extension can open a tab with its controlling site (or a hidden iframe in the background script) and insert js code as a standard DOM script which the browser will attribute to the page itself so it'll be able to communicate with the site's domain to upload the exfiltrated data.
So, what you can do practically is to protect the most sensitive sites you use from all extensions by adding a local ExtensionSettings policy with runtime_blocked_hosts that contains that site(s). This will prevent all extensions from accessing the entire site either via content scripts or network requests. Example: {"*": {"runtime_blocked_hosts": ["*://lastpass.com"]}}. And if you have an extension you trust then you can relax this rule for that extension by using runtime_allowed_hosts. See the policy link above for more examples.
I have a site whose pre-production environments use HTTP basic authentication to prevent unauthorized access. Recently, we've added a CDN (AWS Cloudfront) and we intend to use basic authentication (FWIW, using Lambda#Edge) for those pre-production CDN environments, as well.
While we've already implemented basic authentication on the web application (we're able to access the site after authentication), and have rudimentarily implemented basic authentication on the CDN (we're able to, say, access an image directly, after authentication), we're having trouble combining the two.
The web application includes images in the normal ways (e.g., via HTML and CSS includes). For instance, my site, https://www.example.com, has the following in its HTML:
<img src="https://cdn-files.example.com/foob.png" />
Using Chrome, when hitting the web application, I get a double-challenge (one for the app's domain and one for the CDN, each in turn), and the image loads.
Using Firefox, I get a single challenge, and the page loads, but the image fails to load (that request's response is 401).
Question 1: (Most streamlined option.) Is it possible, through the right configuration settings, to get the browser to pass through the credentials from the app's domain to the CDN domain? If so, what configurations are needed?
If not:
Question 2: (Less streamlined: Double-challenge.) What's the right combination of configurations (presumably, headers, etc.) to get the images, etc., to load on the web app?
I would prefer not to embed the credentials in the URLs, if at all possible.
I'm trying to understand function of the landing page. According to specification:
The iLandingPage field, when non-zero, indicates a landing page which the device manufacturer would like the user to visit in order to control their device. The UA MAY suggest the user navigate to this URL when the device is connected.
As far as I do understand the main purpose of landing page to provide
notification to the user which page is recommended to be used with WebUSB complaint device. So I have a couple of questions:
is landing page also preventing user from accessing the other websites? Is Chrome (Chromium) blocking access to the sites that are not matching landing page?
is landing page mandatory? Can we avoid using at all by simply setting iLandingPage to 0?
if URL for landing page is mandatory - what would be preferred way of making it configurable (i.e. like after uploading firmware to the device)?
I saw in one of the thread information about blacklist for WebUSB devices . How can I access WebUSB blacklist in Chrome/Chromium?
is landing page also preventing user from accessing the other websites? Is Chrome (Chromium) blocking access to the sites that are not matching landing page?
No, the landing page is not used to limit which websites can access the device. In an earlier version of the WebUSB API draft, there were custom descriptors that defined filters for which domains could access which interfaces. Those descriptors are no longer used, so any site served over HTTPS can request access to your device.
The landing page is only used to prompt the user that there is a companion web page for the USB device that was just detected. The user is not obliged to click on it and on some platforms (Windows, Android), the notification is not shown at all due to technical limitations.
is landing page mandatory? Can we avoid using at all by simply setting iLandingPage to 0?
It is not mandatory - you can simply set it to zero. In fact, if you do not want a landing page, you do not even need to supply the WebUSB Platform Capability Descriptor. Chrome will still allow you to manually select your device from the device picker even without the descriptor.
if URL for landing page is mandatory - what would be preferred way of making it configurable (i.e. like after uploading firmware to the device)?
As above, it is not mandatory, but since the GET_URL request is separate from the request for the platform capability descriptor, you can easily generate the descriptor in RAM and fill in whatever URL you wish at runtime.
I saw in one of the thread information about blacklist for WebUSB devices . How can I access WebUSB blacklist in Chrome/Chromium?
There are two different blacklists for Chrome:
The WebUSB Interface Class Filter restricts access to certain classes of USB interfaces: Audio, Video, HID, Mass Storage, Smart Card, Wireless Controller (Bluetooth and Wireless USB).
The USB blocklist restricts access to USB devices based on their vendor ID / product ID pair. This mostly applies to U2F devices.
We have a simple web site for our company, deployed under IIS. it contains 5 html pages with CSS, and some HTML web pages have links to other HTML pages, such as go to home page. now i want to check if my web site generated cookies at users machines or not? so can i do so? and usually does HTML web sites that do not have any login generated cookies?
Edit:
Using chrome development tools (F12) i have found the following:-
Load the development tools in your favourite web browser, then load your website.
In Chrome, the cookies will appear in the 'Application Tab' of the development tools, and under 'Storage' you will see 'Cookies.' Microsoft Edge has them in 'Debugger> Cookies'
Expand that and it will show all the cookies that have been delivered by your website.
It's possible for a 'HTML only' site to be delivering cookies, especially if you have 3rd party content.
Most of the cookies are generated on your Server Side and sent to the client.
You will have to go through your code and see whether it generates cookies.
Usually, if it's a regular HTML page, your server won't create a session for that and most likely that no cookie be sent to the client.
Otherwise, If you use .aspx pages or MVC (for example..) most likely that your server will generate Session Cookie and send it with the response to the client.
Another thing you'll have to check is whether your pages contain references to 3rd-party websites i.e includes of .css / .js files from CDNs like
Cloudflare - these CDNs usually put their own cookie in your client's browser.
And lastly, your pages might contain scripts like Google Analytics which put some cookies in your client's browser.
A HTML Page is not creating any cookies. Maybe you are mixing up Cache with Cookies? For example in PHP you have to define what shall be saved into a cookie. If you don't define any Cookie Variables, there won't be any cookies.
Is the file protocol effectively defunct?
It would be extremely useful to me if an intranet server could generate links such as
<a href="file:///shared/customer_info/customer-name">
<a href="file:///shared/customer_info/customer-name/history.ods">
Since it's an internal intranet app, the server and the users' systems share access to the same filestore, so this is sensible.
Unfortunately, Firefox and Chrome have disabled file:// links. The only thing I can do with them is right-click, copy link location, and then paste it into a file manager location bar or even into the browser's own location bar (in which case they work beautifully!)
Is there a documented way to re-enable them on the browser? Preferably, if there are major security issues, selectively, so that only file:// links coming from a server on the local net are acted upon.
(I'm aware that there's a Firefox plugin "Local filesystem links" that provides some of this functionality, but I'd be hesitant about making my employer dependant on it since Firefox has something of a history of breaking plugins. Also most of the users prefer Chrome. )
No the protocol is not defunct, but it is not a web protocol which is primarily what web browsers were designed for. file:// works in IE and Chrome version 55.0.2883.87 but as you said does not work in Firefox. In a Windows environment, the file protocol, while constructed like a web URL is actually just SMB behind the scenes. Its the same as using a UNC path but allows you to use hyper links and display in a browser.
Its primary use case is for local documentation for product installations (usually help files). It allows accessing the documentation via a web browser and usage of hyperlinks within the documentation. It effectively appears to the end user like a web site, while in fact its just local file access.
For intranet or Internet I recommend setting up http links. Though file:// can work to some degree via intranet I do not recommend it. Especially, as you stated, you already have an http server running.