I have the following problem: my Google Chrome extension has been submitted before the packaging mechanism (i.e. ship your own pem file to the webstore) was introduced.
Now I'd like to update the extension but since I don't have a pem file the webstore will automatically generate a new one, hence, my extension will have a new ID which causes the update mechanism to fail and I'd loose my existing user base.
Is it possible to get a pem file for the old extension or can I provide my own pem file w/o breaking the update mechansim.
Thanks,
Peter
If your extension is already in the Chrome Web Store, then you don't need to have a .pem file to submit an update. If your extension is not in the Web Store, but you'd like to move it there and keep the same ID, then you can upload your old .pem file with the name key.pem (see the documentation for details).
This isn't really an ideal solution but you can call it Plan B. The updated extension (with a new id) can automatically disable the old one, by looking for the old one's id.
chrome.management.getAll(function(ext){
if(ext.length===1) return;
for(var i=0; i<ext.length; i++){
if(ext[i].id!=="ENTER_OLD_EXTENSION_ID_HERE") continue;
chrome.management.setEnabled(ext[i].id,false);
}
});
Related
I have a Chrome Extension in development, locally which is a React application.
I have set up a CI/CD pipeline so that the React app is built with yarn build to produce the dist directory containing the app files and the manifest.json. The pipeline then uses this npm package to create the .crx file and upload it to a public storage location along with the update.xml file which has been updated with a new version number and URL to the new .crx file.
I created a private key (key.pem) locally and stored in a key vault so that the "packing" job in CI pipeline uses the same private key each time. The public key has been added to the manifest.json so that the app ID stays the same each time.
Update2.xml
<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
<app appid='blahblahooaejaldnohkhmaedknkfogn'>
<updatecheck codebase='https://mypubliccrxstorage.blob.core.windows.net/crx/myapp-1.0.20210702.22.crx' version='1.0.20210702.22' />
</app>
</gupdate>
manifest.json
{
...
"manifest_version": 2,
"version": "1.0.20210702.22",
"key": "<my-public-key",
...
"update_url": "https://mypubliccrxstorage.blob.core.windows.net/crx/update2.xml"
}
Steps to install and update:
Go to chrome://extensions/ > developer mode > load unpacked > select local dist directory.
The unpacked extension appears in the list of extensions with app id: blahblahooaejaldnohkhmaedknkfogn
Select the extension and click "Update"
Expected result:
Chrome queries the remote update.xml file, sees a version later than the initially installed version, downloads and installs the new crx file from the specified location.
Actual result:
The extension is not updated.
Note: I downloaded the crt generated by the CI/CD from the storage location and uploaded it here. The public key shown by that online tool matches the value of key in the manifest.json and the calculated app id matches the one in update.xml.
To dig a little deeper I opened Fiddler4 and sniffed the calls made by Chrome. Although I don't understand everything, part of one of the responses was:
<?xml version="1.0" encoding="UTF-8"?><gupdate xmlns="http://www.google.com/update2/response" protocol="2.0" server="prod"><daystart elapsed_days="5296" elapsed_seconds="28389"/><app appid="mgndgikekgjfcpckkfioiadnlibdjbkf" status="error-unknownApplication"/><app appid="apbllhlpimnkljppmmdbiipfbjjimjgj" cohort="1::" cohortname="" status="ok"><updatecheck _esbAllowlist="false" status="noupdate"/></app></gupdate>
That "app id" is not mine (or is that the Chrome app id?), but the status of "error-unknownApplication" perhaps gives some hint as to what is going on.
No protection setting in Chrome allows an extension to update. This setting also allows to drag and drop .crx into chromium extensions.
Installing the chrome extension by "Load unpacked" button at chrome://extensions "ties" the install to the file system and doesn't allow for updates.
The extension needs to be installed via the .crt file for updating to work.
The ability to do this has been removed in Chrome for security reasons.
However you can use Chrome's developer version, Chromium to install the .crt file by dragging and dropping. Installing in this way allows the extension to be updated using the method in the original question (if everything is configured correctly).
This workaround was acceptable in my case.
We had to implement an image uploader for a node.js project. As framework we are using express.js We did it like described here: http://howtonode.org/really-simple-file-uploads
But we are not sure how to secure this image uploader. What we did so far is:
checking the file size
checking extension and header
rename the file
file is only accessible over a special route and is not in the root folder
Is this enough? We don't feel very comfortable with the following line:
// CHECKING FOR FILESIZE, EXTENSION, HEADERS
fs.readFile(req.files.displayImage.path, function (err, data) {
...
...
...
// RENAMING FILE
// SAVE FILE
...
...
...
}
Is it save to read the image this way? We are afraid, there could be malicious code in req.files.displayImage.path. Do we need to add more checks or are our checks sufficient? What attack vectors do we offer an attacker if we use the code as described?
Thank you for your advices
Tschoartschi
If you are concerned for opening malicious images on client side as posted in your comments. Try opening third party scripts and untrusted files inside a sandboxed iframe this will protect your users.
Is there a way to detect whether I'm running an extension that was installed from my .crx file or the extension was loaded as via 'Load unpacked extension...' button?
I'm aware about ID differences in that case, but I don't want to rely on hardcoded strings in the code.
If by "installed from my .crx file" you mean installed from Chrome Web Store you can simply check extension manifest.json for value of update_url attribute. CWS adds it when you upload your extension.
If you have a self-hosted .crx file, get your extension information using chrome.management.getSelf() and check installType of returned ExtensionInfo object. If it says "development" that means that extension was loaded unpacked in developer mode. "normal" means that it was installed from .crx file.
Here is a code sample how to do this:
function isDevMode() {
return !('update_url' in chrome.runtime.getManifest());
}
or
const isProdMode = 'update_url' in chrome.runtime.getManifest()
An extension is running in developer mode (i.e. unpacked), when it does not contain the update_url field in its manifest.
This works because an unpacked extension's JSON manifest file should not contain the update_url field. This field is automatically added when publishing via the Chrome Developer Dashboard.
For example, debug logs that only appear during development.
const IS_DEV_MODE = !('update_url' in chrome.runtime.getManifest());
function debugLog(str) {
if (IS_DEV_MODE) console.log(str);
}
debugLog('This only appears in developer mode');
A web game I play on that allows user uploaded content has been having a lot of issues with people using the navigateToURL function to send players to random websites. I was curious if there was a way to disable this function using Actionscript 2 or 3. I have seen a way to do it using the HTML embed but I do not have administrative access to the website.
After doing some more research, I have come up with a solid answer:
You should use a combination of PHP and an executable called swfdump on the server side to validate the user uploaded content.
swfdump is an exe file located in the bin folder of the Flex SDK. You can run it from PHP using exec.
It will read the bytecode of the swf and produce a report. From that you can easily locate which files contain navigateToURL() and reject the files.
I tested a file of my own using swfdump -abc -out myfilereport.swfx myfile.swf
and in that output I found this:
findpropstrict flash.net:navigateToURL
findpropstrict flash.net:URLRequest
pushstring "http://www.plasticsturgeon.com"
constructprop flash.net:URLRequest (1)
callproperty flash.net:navigateToURL (1)
The url I was using was "http://www.plasticsturgeon.com". But it would be far easuer to just eliminate any swf that includes flash.net.navigateToURL. Once you identify tha is present you can generate an error notice to your end user.
So using this method you can find and reject any swf that is using navigate to URL. You could even create a batch to run and invalidate any existing assert with this problem.
More information about using bytecode:
http://code.google.com/p/redtamarin/wiki/ABC
And about decompiling ASbytecode:
http://dougmccune.com/flex/FOTB_Decompiling_Doug_McCune.pdf
I am trying to create an extension ('XML Uploader') with a backend module and a frontend plugin also.
The backend module will be used for managing xml files (upload, validate against a DTD), and the frontend plugin should be used for displaying the uploaded xmls.
The problem is with the frontend part:
I followed
the basic extension tutorial - added a new page, created a content element of type 'Insert plugin' - but when trying to add a new record, the type 'XML Uploader' does not appear in the list of new record types. Moreover, the changes made to class.tx_xmluploader_pi1.php have no effect.
So how should I work with the frontend plugin? Or would it be better to create a separate extension instead?
Any help would be very much appreciated.. Thank you.
When creating your table with the extension kickstarter you must check the "Allowed on pages:" checkbox to allow records from this table to be created on regular pages.
If your changes have no effect, it could be that the page is cached by typo3. In that case you can clear or disable the cache with the admin panel or in the page configuration menu.
You have to include the static template of your extension (I presume you used the kickstarter or extension_builder):
go to the your template, in the object browser you should see something like:
plugin.tx_xmluploader_pi1 = USER
if you can't find it, edit your template (edit/modify => edit whole template record) and add your extension template in the tab 'Includes'
Additionally, check your ext_localconf.php for the line
t3lib_extMgm::addPItoST43($_EXTKEY, 'pi1/class.tx_xmluploader_pi1.php', '_pi1', 'list_type', 0);
This is where your FE plugin is being registered.