Meteor - How to hide meteor version used - javascript

I wanted to ask that for security reasons - we should be able to remove the meteor version information from the meteor_runtime_config section from the page source section and other headless browser/curl requests like below:
__meteor_runtime_config__ = {"meteorRelease":"METEOR#1.0.3.1"...
Especially so that known vulnerabilities are not exploited. This gives developers the some what time to catch to the new version especially with breaking changes to the code.
Here from a blog post back in 2014, 31 apps were reported to have removed the version number, so it is possible to do so.

A trick is to empty __meteor_runtime_config__.meteorRelease at the startup phase.
Meteor.startup( function() {
__meteor_runtime_config__.meteorRelease = undefined;
});
You can also remove the string assigned to meteorRelease in <application>/bundle/programs/server/config.json before you deploy your application. The information is extracted from that config file, which is generated by Meteor when it builds applications.

Related

Has the ViewingApplication constructor been removed from the AD Viewer API?

After leaving my Autodesk extension alone for a few weeks, my initialization code is failing to create a ViewingApplication.
In my browser's js console, I can see that the Autodesk.Viewing object contains many objects, but it no longer contains any ViewingApplication.
The Viewer API documentation still includes ViewingApplication.
Autodesk.Viewing.Initializer(options, function onInitialized(){
viewerApp = new Autodesk.Viewing.ViewingApplication('MyViewerDiv');
var config3d = {
extensions: ['WharfExtension']
};
viewerApp.registerViewer(viewerApp.k3D, Autodesk.Viewing.Private.GuiViewer3D, config3d);
var model = 'urn:' + defaultModel;
viewerApp.loadDocument(model, onDocumentLoadSuccess, onDocumentLoadFailure);
});
My browser says, "Uncaught TypeError: Autodesk.Viewing.ViewingApplication is not a constructor," and I am inclined to agree?
EDIT: It works as expected from my coworker's machine, so apparently it is not a problem with the API. I am serving the page from a web server on my machine.
EDIT2: Solved. Thanks, Petr. I was including the new, non-backwards-compatible version of the API without realizing it.
Autodesk describes how to create this behavior in the new version in their Migration Guide v6 to v7.
The viewer team has recently released new major version which is not backwards compatible.
Make sure that you're importing the viewer3d.js/viewer3d.min.js file with the expected major version. For example, if you've built your application against version 6 APIs, you should be using the following script tag:
<script src="https://developer.api.autodesk.com/modelderivative/v2/viewers/6.*/viewer3D.min.js"></script>

How do I change the underlying Phantomjs object settings using Chutzpah?

We have some QUnit javascript tests running in Visual Studio using the Chutzpah test adapter. Everything was working fine until we changed our api (the one being tested by the js files) recently, and added some validations over the UserAgent http header. When I tried to update the tests to change/mock the user agent I realized it was not directly possible even by overriding the default browser property.
After a few days of scavenging, I finally found what exactly is happening. Chutzpah is creating a phantomjs page object for the test files to run on. This is being done on a base javascript file (chutzpahRunner.js) located at the Chutzpah adapter installation path. These are the last lines on the file, that effectively start the tests:
...
// Allows local files to make ajax calls to remote urls
page.settings.localToRemoteUrlAccessEnabled = true; //(default false)
// Stops all security (for example you can access content in other domain IFrames)
page.settings.webSecurityEnabled = false; //(default true)
page.open(testFile, pageOpenHandler);
...
Phatomjs supports changing the user agent header by specifying it in the page settings object. If I edit this chutzpahRunner.js file in my machine, and manually set the user agent there, like this:
page.settings.userAgent = "MyCustomUserAgent";
My tests start to work again. The problem is that this is not in the project itself, and thus cannot be shared with the rest of the team.
Is it possible to change the properties of the phantomjs objects created by Chutzpah to run the tests? I'd like to either change them from inside my own tests, or from another script file I could embed on the pipeline.
Without a code change in Chutzpah it is not possible to set those properties on the PhantomJS object. Please file an issue at https://github.com/mmanela/chutzpah asking for this functionality and then fork/patch Chutzpah to add it (or wait for a developer on the project to hopefully get to this).
Update:
I pushed a fix for this issue. Once this is released you can use the following in a Chutzpah.json file:
{
"userAgent": "myUserAgent"
}

Using Node.js to access azure tablestorage

I've been trying to write a typescript application in visual studio using node.js to store and access data in an azure table store.
I've been having some trouble with the tutorials I've found. I've yet to get one to work properly.
I have Node installed on my machine and a tablestore set up in azure.
I'm not exactly sure what needs to be done in visual studio to get all the necessary packages/modules/whatever installed correctly.
Many of the tutorials I've read have used express.js and or have "npm install"ed things and while I have no issue running the commands I don't really understand what I'm installing.
tl;dr I want to make an html page where I can submit and display items to/from azure table store using node.js, typescript, and visual studio
Also: I'd be willing to drop the typescript in favor of javascript if need be.
That tutorial looks like it might be based on the old Node storage package. We have recently posted a new storage library for node - which can be found here: https://www.npmjs.org/package/azure-storage. Also take a look at the following Getting Started to help get you up and running: Store structured data with Table storage.
I will follow up tomorrow to see what we can do to either remove the old tutorial or get it updated. Let me know if anyone wants to volunteer to update the old tutorial!
Jason
I followed this one (I'm assuming you probably tried this as well)
http://azure.microsoft.com/en-us/documentation/articles/storage-nodejs-use-table-storage-web-site/
To boil it down to just what you need in javascript ...
1.Create the table in Azure portal with appropriate data/partition key.
2.NPM necessary packages: azure, async
3.Add the following to app.js (change table_Users to whatever you want to name your table):
var azure = require('azure');
var storageClient = azure.createTableService("<accountname>", "<accountkey>");
storageClient.createTableIfNotExists("table_Users", function tableCreated(error) {
if(error) {
throw error;
}
});
var query = azure.TableQuery
.select()
.from("<tablename>");
//.where('completed eq ?', false); put criteria here.
storageClient.queryEntities(query, function entitiesQueried(error, result) {
// do what you want with result
});

Phonegap 3 contains an alert box in which "OK" crashes browser

I can't come up with a good explanation for this, but when I include
<script type="text/javascript" src="phonegap.js"></script>
In my Phonegap app, which I have not modified, 2 pops will appear on screen.
//The first popup
gap:["PluginManager","startup","PluginManager224542697"]
//the second
gap:["App","show","App224542698"]
I have to cancel both popups and would really love to understand the reasoning.
The two lines in question are on line 21117 and 21118 of phonegap.js
// Tell the native code that a page change has occurred.
require('cordova/exec')(null, null, 'PluginManager', 'startup', []);
require('cordova/channel').onNativeReady.fire();
This of course does not break when its in the app, but it does mean that development is next to impossible.
For me the issue was occurring because phonegap.js was falling back to PROMPT based mode when running outside of phonegap. I believe this mode is intended for phonegap below Android 3.2, where all communication is via alert prompts (which is what you're seeing).
I fixed the problem by setting the following variable before loading phonegap.js:
window._cordovaNative = true;
This tricks phonegap into thinking you're running above phonegap 3.2 hence never enters Prompt mode.
Of course, if you're targeting devices below 3.2 then doing this will probably break all communication with Phonegap on those devices...
I have stumbled upon this error and question while trying the following:
Completed the hello world tutorial with cordova create, etc.
Deployed both on emulator and the connected device w/o a problem.
I got the same error as OP when doing cordova serve and just navigating to //localhost:8000 as instructed.
I agree - seeing those alerts is super annoying. It kills the whole point of speedy non-native js-based development.
What is going wrong?
Communication API with the "device" is falling back to this handler promptbasednativeapi.js (also see cordova-js/src/android/exec.js). On version 3.x.x just saying
window._cordovaNative = true;
was not enough for me. One should implement the whole protocol of communication.
Quick solution
You can use some browser side "emulator", e.g. Ripple emulator extension for chrome ([UPDATE] Consider using https://github.com/apache/incubator-ripple for phonegap 3.x.x as pointed by DuKes0mE). Such an "emulator" can understand and fire respective events, e.g. "device ready". So far it looks promising :-)
What is going on?
An answer by #antscode was of great help. After some digging and reading of cordova/cordova-js code I figured out that
Error comes from the mechanism which is a part of cordova plugin architecture. Plugins are developed as so called cordova commands which can be executed from js - this is exactly how cordova architecture is organized.
Cordova is a JS framework. One is suggested to primary write (non-native) JS code. To talk to all those different native plugins one has to come up with the protocol to communicate with them, sort of RPC with JSON serialization. This is exactly what is going own.
Plugins can be also in pure JS. To quote the manual
Create a new echome plugin with:
window.echo = function(str, callback) {
cordova.exec(callback, function(err) {
callback('Nothing to echo.');
}, "Echo", "echo", [str]);
};
Access it as a cordova command via JS:
window.echo("echome", function(echoValue) {
alert(echoValue == "echome"); // should alert true.
});
No emulator solution
I could imagine a situation when an rather complicated app will break just inside such an web-browser client side "emulator" (and only in it). A better solution would be to figure out a way to convince the app not to fallback to PROMPT method of communication (the one that makes annoying alerts). Well, I do not have such a solution right now :-( Will be happy to learn how to do it though.
Solution is here: https://gist.github.com/ewiger/7d5e0cc8fccf311e9ce2
there is probably no return event for the cancel button. if no instructions are passed to the kernel, this results in an exception(your browser crashing.) try defining an action for the cancel button and see if that helps.
I went into hello/platforms/ios/CordovaLib and copied the cordova.js file into my www root and changed
Or download from here:https://github.com/apache/cordova-ios/blob/master/CordovaLib/cordova.js
<script type="text/javascript" src="phonegap.js"></script>
to
<script type="text/javascript" src="cordova.js"></script>
and no more popups
I was having the same issue with a project created by another developer. The cause in my case was the remains of the Cordova/PhoneGap 2.x configuration. This popup is related to the plugin system. Removing plugin from my config.xml made it better:
<plugin name="InAppBrowser" value="org.apache.cordova.InAppBrowser" />
The end, I decided it would be best to make a new 3.x project and move all of my HTML/CSS/JS to the newly created project. The new project fixed all issues.
I had initially resisted posting an answer on this question. As was mentioned by one of the developers that the phonegap.js should not be included unless it is production code.
This however means you can't tests phonegap features.
To briefly explain my thought process, in all my years developing (php) I have often set global variables that I can easily write code for dev, stage or production.
Please consider this might not be the best way to go, but for me it works and I'm enjoying the rest of my backbone app far more than revisiting this currently ;)
So, I did this:
//Define SD
var SD = {}; //define SD so we can use it globally
/*==================================================
Is Mobile - If true then we are a mobile
================================================== */
SD.isMobile = true;
//This is with the assumtion that your domain contains (for exmaple) http://yourdomain.local
if (document.URL.indexOf("local") > 0 || document.URL.indexOf("sex") > 0) {
SD.isMobile = false;
}
SD = {
isMobile: SD.isMobile,
ENVIROMENT: 'liveApp',
CDN: 'yoururl.com/',
HTTP: 'http://yoururl.com/',
}
// #define the globals depending on where we are -----------------------------------------------------
SD.globals = function () {
switch (window.location.hostname) {
case "sd.local":
SD.ENVIROMENT = 'localApp',
SD.CDN = 'sd.local/',
SD.HTTP = 'http://yoururl.com/',
SD.AJAX = SD.HTTP+'app/';
break;
case "192.168.0.25": //Set to your machines IP address
SD.ENVIROMENT = 'mobilePhone',
SD.AJAX = SD.HTTP+ 'app/';
break;
default:
SD.AJAX = SD.HTTP+'app/';
break;
}
};
And now finally, after all the init work I add the phonegap.js if we need it.
if(SD.isMobile){
$.getScript('phonegap.js', function( data, textStatus, jqxhr){
c( "cordova was loaded." );
});
I was experiencing the exact same two popups you describe but only experienced them when i added iOS to my phonegap project. the first time i did this i copied the www folder from my working Android app. this was the problem because it had artifacts from the Android plugins. After blasting and recreating the iOS app in the phonegap project using the command line tools i more carefully brought over only the needed html, js and css files for my app which resolved the issue.

Why is Cloudfront loading scripts in my web app? (I don't use it)

I manage a secured PHP/MySQL web app with extensive jQuery use. Today, a strange error popped up in our app's logs:
JS Error: Error loading script:
https://d15gt9gwxw5wu0.cloudfront.net/js/_MY_WEB_APP_DOMAIN_/r.js
We are not using Amazon's Cloudfront CDN in our app. When I go to the URL that failed to load, these are the only contents:
if(typeof _GPL.ri=='function'&&!_GPL.isIE6){_GPL.ri('_GPL_r')}_GPL.rl=true;
The user's user agent string is:
Mozilla/5.0 (Windows NT 6.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Please note: I am not the user who triggered this error. It was one of our thousands of users who triggered it. I do not have control over the client machine.
Does anyone know what's going on here? Is this some sort of XSS attack?
** Update **
It appears I'm not the only one who has discovered this anomaly on their website. I found this report of the same exact behavior, which seems to indicate the code is harmless, but still no answers as to where it came from.
In addition, I found this pastebin with similar code, that appears to be some sort of advertising script. Again, not terribly helpful.
** Update 2 **
More context: The webapp uses several third party jQuery plugins but no third party analytics of any kind. All scripts are hosted on our own server, and an audit of all our code provides no matches for "cloudfront".
This app has been in production for about 4 years, and this is the first and only instance of any activity like this. It has not happened before or since, so I doubt I'll be able to reproduce it.
What I'm interested in is if this is some sort of attack. If it is, I want to know how to plug the hole it's trying to exploit if it's not plugged already.
Disclaimer: I'm not a security analyst/expert, your issue simply sparked my interest ;)
Warning: While I share the initial conclusion that the code itself is probably harmless, the underlying technology can most certainly be (ab)used for malicious intents as well, so please take care when investigating this yourself.
Analysis
You already found the relevant evidence yourself - searching further I found another pastebin drop, which is more readable, so I'm using this for the explanation (though at first sight the other one would allow this as well after formatting).
The snippet features JavaScript fragments with the following major functionality:
Line 13 initializes the variable _GPL with all sorts of items for later use, e.g. various constants`, helper functions, browser compatibility stuff and actual payloads, for example:
Line20 defines an empty basdeCDN, line 21 defines a fCDN, which happens to be the one in question (d15gt9gwxw5wu0.cloudfront.net)
line 261 defines a function removeScripts(), which in turn uses findScript()from line 266, further accompanied by insertJS() on line 277 - their respective intend is obvious
line 270 defines function loadDomainRules(), which seems to be the one generating the URL you have found in your logs - see appendix below for the code snippet
Deduction: Even without further evidence gathered below, the naming and functionality strongly hints on r.js being a JavaScript file serving custom JavaScript specifically assembled/generated for the domain at hand
line 100 defines a function loadGeo(), which references some kind of an ad server indeed (ads2srv.com) - see appendix below for the code snippet
line 368 finally defines a function i(), which provides the most definite clues regarding the likely origin of all this, namely the notion of some Yontoo Client and Yontoo API - see appendix below for the code snippet
Corollary
What's it all about?
The extracted clues Yontoo Client and Yontoo API easily lead to Yontoo, an Application Platform that allows you to control the websites you visit everyday, i.e. it sounds like a commercialized version of Userscripts.org, see What is a Yontoo App?:
Yontoo is a browser add-on that customizes and
enhances the underlying website
Where Can I Use It?
Yontoo works on any site on the Web, although the
functionality comes from separate applications called Yontoo Apps
which provide specific functionalities depending on what site you are
on.
[emphasis mine]
Now, looking at the current listings in their App Market easily demonstrates, why this might be used for questionable nontransparent advertizing as well for example, all the trust signs and seals in their footer notwithstanding.
How did it end up in your logs?
Another quote provides more insight into the functionality and how it might have yielded the issue you've encountered:
Yontoo [...] is a
browser add- on that creates virtual layers that can be edited to
create the appearance of having made changes to the underlying
website. [...]
If you see a need for an application or tool over a website, then you
are free to create!
So somebody apparently has visited your site and created some custom domain rules for it by means of the Yontoo client (if it actually allows this for end users) or one of the available apps (the snippet used for analysis references the Drop Down Deals app in line 379 for example), which triggered the creation of d15gt9gwxw5wu0.cloudfront.net/js/_MY_WEB_APP_DOMAIN_/r.js to store these rules for reuse on next site visit in turn.
Due to some security flaw somewhere (see conclusion below) this URL or a respective JavaScript snippet must have been injected into JavaScript code of your application (e.g. by means of Cross-site scripting (XSS) indeed), and triggered the log entry error at some point in turn.
Conclusion
As mentioned upfront already, I share the initial conclusion that the code itself is probably harmless, although the underlying technology can most certainly be (ab)used for malicious intents as well due to its very nature of mocking with client side JavaScript, i.e. a user allows code from a 3rd party service to interact with sites (and especially data) he uses and trusts every day - your case is the apparent evidence for something gone wrong already in this regard.
I haven't investigated the security architecture (if any) of Yontoo, but wasn't able to find any information regarding this important topic immediately on their website either (e.g. in their Support section), which is pretty much unacceptable for a technology like this IMHO, all the trust signs and seals in their footer notwithstanding.
On the other hand, users do install 3rd party scripts from e.g. Userscripts.org all the time of course, not the least for fine tuning the user experience on Stack Exchange as well ;)
Please make your own judgment accordingly!
Appendix
Below you can find the code snippets referenced in the analysis (I've been unable to inline them within the lists without breaking the layout or syntax highlighting):
loadDomainRules()
function () {
if (location.host != "") {
var a = location.host.replace(RegExp(/^www\./i), "");
this.insertJS(this.proto + this.fCDN + "/js/" + a + "/r.js")
}
this.loaded_domain_rules = true
}
loadGeo()
function () {
var cid = this.items.e6a00.get("geo.cid");
var updatetime = this.items.e6a00.get("geo.updatetime");
if (!cid || (cid && updatetime && (Math.floor((new Date()).getTime() / 1000) - parseInt(updatetime)) >= 259200)) {
this.insertJS(((this.proto == 'https://') ? 'https://s.' : 'http://') + 'ads2srv.com/tb/gc.php?json&cb=_GPL.setGeoAndGo')
} else {
this.vars.cid = this.items.e6a00.get("geo.cid");
this.vars.rid = this.items.e6a00.get("geo.rid");
this.vars.ccid = this.items.e6a00.get("geo.ccid");
this.vars.ip = this.items.e6a00.get("geo.ip");
this.loadCC();
this.loadDomainRules()
}
}
i()
function () {
if (typeof YontooClient != 'undefined') YontooClient = {};
if (typeof yontooAPI != 'undefined') yontooAPI = {};
if (typeof DealPlyConfig != 'undefined') {
DealPlyConfig.getBaseUrl = function () {
return "https://d3lvr7yuk4uaui.cloudfront.net/items/blank.js?"
};
DealPlyConfig.getCrownUrl = function () {
return "https://d3lvr7yuk4uaui.cloudfront.net/items/blank.js?"
}
}
this.rm(this.ri, ['dropdowndeals', 'Y2LeftFixedCurtain', 'gbdho', 'bdca', 'dealply-toast-1', 'pricegong_offers_iframe', 'SF_VISUAL_SEARCH', 'batAdRight', 'batAdBottom', 'batAdMiddle_0', 'batAdMiddleExt1_0', 'batAdRight2', 'invisiblehand-iframe', 'scTopOfPageRefinementLinks', 'sf_coupon_obj']);
this.rm(this.rc, ['yontoolayerwidget', 'dealply-toast', 'imb-ad']);
this.rm(this.ric, [
['productbox', 'g'],
['related-searches', 'related-searches-bing']
]);
this.rm(this.rtn, ['MIVA_AdLink', 'itxtrst', 'kLink', 'FAAdLink', 'IL_AD', 'skimwords-link'])
}
I found an iFrame as well in my drupal 7 website. It was loaded into the site by enabling the module of sharaholic.

Categories