Evothings secured, now serving over HTTPS!

There is a major security trend on the Internet today, including search engines floating secure websites over insecure ones, websites turning from regular HTTP to HTTPS in every market segment imaginable. It involves acquiring a certificate to put on each domain or site, ensuring visitors that the organizations behind the site is legitimate, or at least matches with the one advertised. And now services are popping up which issue HTTPS certificates without cost, like Let’s Encrypt which is another driver.

For us as an industrial tools provider, it’s imperative to abide to the leading standards in accessibility and security, in order to maintain an unbroken chain of secure data. Many applications are mission critical for our customers and their end-users. Many service contracts and legal agreements disallow regular, less secure transports like HTTP, RTSP or FTP access, regardless of the nature of the payload. So we are happy to announce that Evothings uses HTTPS for all communication between your development environment, servers and connected mobile end-points.

In practice, it means that any web page served from a secure server can only acquire resources from other sites if they in turn also are served over HTTPS with their respective certificates in place. Resources served from sites which have HTTPS enabled, while using so-called “self signed” certificates won’t be served either. Anyone can generate a self-signed certificate without contacting anyone, and they simply won’t do since the certificates are not issued by a certificate authority.

From Evothings’ point-of-view as an industrial mobile tools provider, this means an improved working environment for all involved and a less complex task for the developer to ensure end-to-end security from sensor devices to server, and for each mobile device serving in one of several roles in the system; as gateway for local sensor data, as dashboard for viewing data in a comprehensive manner, as remote control, data visualizations device for analytics, and in many contexts also as off-line storage and usage, to name some of the most common uses of mobile IoT apps today.

It also means that special care has to be taken when mixing secure and unsecure resources, as it wrongly used can circumvent the sandbox security set up for preventing attempted man-in-the-middle attacks, port sniffing et cetera. See it as the Web’s best effort to control every API and access point in the systems involved. Here’s a classic JSON call using jQuery and HTTPS:

var flickerAPI = "https://api.flickr.com/services/feeds/photos_public.gne?jsoncallback=?";    
$.getJSON(flickerAPI, {
    tags: "mount rainier",
    tagmode: "any",
    format: "json"
  })
  .done(function(data) {
    $.each(data.items, function(i, item) {
      $("").attr("src", item.media.m).appendTo("#images");
      if (i === 3) {return false;} //only the first three items
    });
  });

Given that you know what you’re doing as a developer, there are alternative paths to take: An obvious one, which always has been open to native developers, is to acquire the external resource from outside of the web container and then – after finding it well-formed and free of potentially malicious contents – serving it up as local contents into the web container over the Cordova bridge. There are also specific services who offer a controlled gateway, to pull unsecure resources in from specific domains, check them and release like Amazon’s AWS API Gateway. Setting up your own way of collecting plaintext resources requires you as a developer to programmatically cleanse any potential occurrences of malicious code yourself, identical to the case where a native developer fetches resources natively when working out of xCode or the Android SDK.

Here’s the Cordova way of picking up a JSON resource outside of the web container. Note that these calls are made differently than the regular calls made normally from inside. Note further that the more extravagant features, such as uploading from a mobile device using HTTP PUT, are not enabled in this restricted version of the HTTP plugin. See our page on Github for more information on our willful disabling of less desired features.

In the code below (which requires the cordovaHTTP plugin in order to work, and will fail in your desktop browser), the function hyper.log is a global function which writes back to the Workbench “Tools” section, very useful for many things. Try the “eval selection” button for instance.

Ok, back to the code. Find below a typical HTTP GET which is called from either a HTTP or HTTPS page:

cordovaHTTP.get(
	'http://evothings.com/demo',  
    function(response) // on success
    {
        hyper.log('HTTP success: ' + response.status);
        hyper.log(response.data);
    }, 
    function(error) // on error
    {
        hyper.log('error: ' + JSON.stringify(error));
    });

There are two things you need have in place in your code, to make this run properly. (1) One is a link to the cordova javascript library in the index.html file:

<script src="cordova.js"></script>

.
Evothings apps in general already have this in place. Note; you don’t need to add the library as such as it’s already on-board in the Viewer app.
(2) You need to allow the scripts to load before running the app’s main function. There are several ways to do this naturally, while I like adding an event listener on deviceready:

document.addEventListener(
    'deviceready',
    function() { main() },
    false);

As always it’s a good idea to have an extra look at what came in the door in terms of data, and that it is well formed. Depending on the nature of the resource, additional sanity checks could be necessary, while outside of the scope of this article. When JSON was first introduced, it was common to use eval() to evaluate the json-string, while modern day javascripters per default shun such practice as it potentially opens up a security exception big enough for Ben Hur’s chariot race to ride right through.

A basic approach to check up on the contents of an incoming text stream, would be to use try/catch as a preamble to any mission critical operation, in our case of the fetched JSON. And no, this won’t save the world from malicious code, yet it’s good to start thinking about end-to-end security and how to get there.

var json; 
try 
	{  // is the resource well-formed?
	json = JSON.parse(client.responseText); 
	}
catch (ex) 
	{   
	// Invalid JSON, notify of the failure...
	alert(‘Could not parse json, aborting..’);
	} 
if (json) 
	{ 
	// Ok, it seems to be valid JSON, proceed here with the code
	}

p.s Only version 1.2 and onwards of Evothings Viewer can carry out outside-the-web-sandbox CordovaHTTP() requests. if you really need to pick up external resources over HTTP you’ll need to upgrade your mobile clients at the public app stores or roll your own from our Github account.

Download Evothings Studio now to secure your app development, also when involving testers over public networks!