If I write a chrome extension, it normally consist of multiple parts:
One is the devtools page which is a normal HTML page with origin set to
"chrome-extension://<guid>/filename". On that page I can use
the Dropbox API to get user confirmation via HTML popup and then use
the saved auth info and do all work via the Dropbox javascript library.
Another part of extension is the content script which is executed
in the context of specified third-party web pages ("injected") and have
origin cookies and web storage shared with them.
Is it possible to also use the Dropbox JavaScript library in that content script?
I can't call authenticate in interactive mode since it will re-ask for confirmation for each different webpage I'm injected into. And calling authenticate without interactive will fail since the content script doesn't share the origin, cookies and web storage with the devtools extension page :(. Maybe there's some way to "pass" the Dropbox auth info from the part of the extension that offers GUI and where user successfully confirms dropbox usage to the parts of the extension that are GUI-less, like content script or background page?
I have managed to get Facebook working from code injected into a web app via a content script. I suspect there are multiple ways, but what I did was take advantage of the chrome.identity API to do the OAuth work for me, specifically the launchWebAuthFlow().
This can only be done in the background page (in my case an event page), but I send messages to the event page which replies with the access_token, which can then be used in URLs in the same was as the 'web' technique - i.e. in HTTP requests with XHR.
You can send/receive messages via the content script (using events on document), but I decided to do it directly using "external" messages with the chrome.runtime.sendMessage() API in the web app context, and chrome.runtime.onMessageExternal() in the background script. This requires adding "matches" for the URLs you're injecting code into in an "externally_connectable" section of the manifest.json.
I believe this can be adapted to make it work with Dropbox.
Related
Consider this scenario:
A content script wants to upload a file. I would prefer this operation to be done from my service/background script, but passing a File to that side via messages seems to be somewhat impossible without weird workarounds.
This is a good reference for the workarounds available: Passing FormData/File Object from content script to background script in chrome extension with Manifest V3
Workaround 1 seems bad, since it will require to break up the request which is not compatible with the backend API. Workaround 2 seems insecure, since the host web page will definitely be able to send rogue messages to an embedded iframe as it will share context.
I'm considering having the content script perform the upload directly like this:
The content script loads the authentication secret from extension storage (chrome.storage.sync or chrome.storage.local depending on login persistence mode).
It calls fetch directly to upload the form data.
Is that safe?
One hazard I had in mind was that a host page could hook window.fetch to intercept the credentials. That doesn't seem possible after my testing (the content script has a separate fetch defined in its own isolated environment). Is there anything else to watch out for?
I am using Microsoft Graph login in my chrome extension and I am facing a disturbing issue, seems that the user login info is not cleared even if I fully clear browser data, its only forgotten after I restart the browser.
Is this a security vulnerability ?
How is this even possible as my extension is closed and all data is cleared , where is this info saved ?
( I am aware of the logout api, the reason I am asking is because this seems like a security issue to me )
Thanks Jacob. Could you please verify the known issue for the Microsoft Graph and here is the URL:- https://learn.microsoft.com/en-us/graph/known-issues
you can also verify the Content Security Policy (CSP) for the chrome extensions. Please verify the content scripts of the Chrome extension and make sure you know the chrome limitations.
Content scripts are JavaScript files that run in the context of web pages. By using the standardDocument Object Model (DOM), they can read details of the web pages the browser visits, or make changes to them.
Here are some examples of what content scripts can do:
Find unlinked URLs in web pages and convert them into hyperlinks
Increase the font size to make text more legible
Find and process microformat data in the DOM
However, content scripts have some limitations. They cannot:
Use chrome. APIs, with the exception of:
extension ( getURL , inIncognitoContext , lastError , onRequest ,sendRequest )
i18n
runtime ( connect , getManifest , getURL , id , onConnect , onMessage , sendMessage )
storage*
Use variables or functions defined by their extension’s pages
Use variables or functions defined by web pages or by other content scripts
These limitations are for Content scripts can indirectly use the chrome.* APIs, get access to extension data, and request extension actions by exchangingmessages with their parent extension. Content scripts can also make cross-site XMLHttpRequests to the same sites as their parent extensions, and they cancommunicate with web pages using the shared DOM. For more insight into what content scripts can and can’t do, learn about the execution environment.
Please share the log file for further investigations.
I created a question a few minutes ago here: How to modify Chrome Extension, which authenticates every user through Google's OAuth 2?
However, it seems like the CRX files are signed, which means I cannot modify the extension. However, I know exactly how the extension works. Basically I need to do call a function, while parsing it a string. Is that possible to do through my website? The function from the background.js could look like this:
function sendAlert(message) {
alert(message);
}
Is it possible to call sendAlert() from my website?
It's not possible to directly access an extension from a web page.
A web page can communicate with an extension in two cases:
the extension expects external connections via, for example, runtime.onMessageExternal.
the extension listens to DOM events of the page in its content script AND there's an event that triggers the behavior you need
I have an extension which provides a number of services to any web app that requires them. I had been assuming that a web app could use chrome.runtime.sendMessage(ext-id,message), but when I try, there is no sendMessage function on chrome.runtime.
Have I misunderstood where sendMessage can be used, and is there another technique that I can use to communicate from an arbitrary web app to my extension?
There are a few options.
First, http://developer.chrome.com/extensions/manifest/externally_connectable.html is the closest to how you're thinking about it right now. You're expecting to be able to add proprietary, Chrome-specific functionality to arbitrary web pages. externally_connectable will give you a limited version of (see http://developer.chrome.com/extensions/messaging.html#external-webpage for an example), but only for specific web pages (e.g., *.yourdomain.com but not *.com).
Second, you can postMessage from your web page to a content script (see http://developer.chrome.com/extensions/content_scripts.html#host-page-communication), which can do anything a content script can. If you need chrome.* APIs at that point, you can message from the content script to your extension's page, which has access to any chrome.* APIs that it's asked for.
Finally, depending on what your "number of services" actually is, you can always executeScript another script directly into a target webpage, which is similar to forcing the webpage to include it as if it were another <script> tag. (Only similar to, not identical to, because the injection typically happens after the page has loaded.)
The new Facebook Javascript SDK can let any website login as a Facebook user and fetch data of a user...
So it will be, www.example.com including some Javascript from Facebook, but as I recall, that script is considered to be of the origin of www.example.com and cannot fetch data from facebook.com, because it is a violation of the "same origin policy". Isn't that correct? If so, how does the script fetch data?
From here: https://developer.mozilla.org/en/Same_origin_policy_for_JavaScript
The same origin policy prevents a
document or script loaded from one
origin from getting or setting
properties of a document from another
origin. This policy dates all the way
back to Netscape Navigator 2.0.
and explained slightly differently here: http://docs.sun.com/source/816-6409-10/sec.htm
The same origin policy works as
follows: when loading a document from
one origin, a script loaded from a
different origin cannot get or set
specific properties of specific
browser and HTML objects in a window
or frame (see Table 14.2).
The Facebook script is not attempting to interact with script from your domain or reading DOM objects. It's just going to do its own post to Facebook. It gets yous site name, not by interacting with your page, or script from your site, but because the script itself that is generated when you fill out the form to get the "like" button. I registered a site named "http://www.bogussite.com" and got the code to put on my website. The first think in this code was
iframe src="http://www.facebook.com/plugins/like.php?href=http%3A%2F%2Fwww.bogussite.com&
so the script is clearly getting your site info by hard-coded URL parameters in the link to the iFrame.
Facebook's website is by far not alone in having you use scripts hosted on their servers. There are plenty of other scripts that work this way.. All of the Google APIs, for example, including Google Gears, Google Analytics, etc require you to use a script hosted on their server. Just last week, while I was trying to figure out how to do geolocation for our store finder for a mobile-friendly web app, I found a whole slew of geolocation services that had you use scripts hosted on their servers, rather than copying the script to your server.
I think, but am not sure, that they use the iframe method. At least the cross domain receiver and xfbml stuff for canvas apps uses that. Basically the javascript on your page creates an iframe within the facebook.com domain. That iframe then has permission to do whatever it needs with facebook. Communication back with the parent can be done with one of several methods, for example the url hash. But I'm not sure which if any method they use for that part.
If I recall, they use script tag insertion. So when a JS SDK call needs to call out to Facebook, it inserts a <script src="http://graph.facebook.com/whatever?params...&callback=some_function script tag into the current document. Then Facebook returns the data in JSON format as some_function({...}) where the actual data is inside the ... . This results in the function some_function being called in the origin of example.com using data from graph.facebook.com.