BaaS: The Cloud Service Every Mobile Developer Should Know About

[ This post was originally written for BlackBerry dev blog and posted on 9/13/13]

There are many different types of cloud services available, and understanding how they differ in order to find the right one for your app business isn’t getting any easier. It seems every month there’s a new provider of services (using a new “_aaS” acronym) making the alphabet soup almost impossible to follow. 

The purpose of this blog is to provide an overview of the cloud services space and to help mobile developers find the right entry point to get involved. I’m also going to highlight the new BaaS (Backend as a Service) segment, because I believe this segment has the most immediate value to mobile developers, especially small entrepreneurial mobile development shops and SMEs looking to move their online presence to mobile.

But first, an overview of the cloud services space. Traditionally, cloud services can be broken into 3 main categories: 

Software as a Service (SaaS)

These services provide you with the whole nine yards. When you sign up with a SaaS provider, you’re getting everything you need from soup to nuts—including the application itself. A good example of this is Salesforce.com. You use their CRM application on their servers, and they handle storage, security, scalability, and everything else. You just use the service.  There isn’t really any significant development on your part. Some other SaaS examples include Adobe Creative Cloud, Dropbox, Evernote, SAP and Workday Inc.

Platform as a Service (PaaS)

These services provide you with everything but the application and the data. Think of it like the Salesforce.com example above, but you have your own CRM application and you just want someone to host it for you in the cloud, manage access and distribution, virtualization, middleware and OS upgrades, scalability, etc. All you have to worry about is your app and its data. So, if your app has or needs an update, you’re on the hook for that. Everything else is handled by the PaaS provider. Some PaaS vendors include CloudBees, redhat OpenShift, AppFog, cloudControl, Heroku, Engine Yard and Google App Engine.

Infrastructure as a Service (IaaS)

These services are the most basic, but don’t confuse basic with low value. According to Gartner, IaaS is expected to be the fastest growing segment by a significant margin for the next five years. When you use an IaaS, you’re providing your own app and data (like in PaaS), but you’re also responsible for managing the app’s runtime, middleware and databases, and virtualized infrastructure. IaaS is a great solution when all you really need is someone to handle scalability and storage on a big scale. Some IaaS vendors include Amazon EC2, HP Cloud IaaS, OpenStack, Rackspace Cloud and Windows Azure.

The diagram at the top of the post illustrates how these services differ with respect to who is responsible for managing which part of your software and hardware stack. I’ve included “Non-Cloud” as well for comparison. In this case, of course, you’re managing everything yourself. 

Now, let’s explore a new type of cloud service: Backend as a Service, or BaaS. In my opinion, this segment has the most immediate value to mobile developers, particularly for small entrepreneurial mobile development shops and SMEs looking to move their online presence to mobile.

What is Backend as a Service (BaaS)?

BaaS, sometimes called MBaaS (Mobile Backend as a Service), is a cloud computing category designed to make it easier for mobile app developers to build and maintain cloud-based apps across multiple platforms. BaaS is a mix between PaaS and SaaS. Kinvey, a leading BaaS provider, offers up a great BaaS Ecosystem Map that illustrates just how complex this cloud services space can be.

Virtually all mobile applications use some backend service (a notable exception might be a single-user/non-social game). BaaS solutions offer developers a single API that gives them access to most of the messy backend services they need without having to hire a backend development team to design, build and maintain it (likely on a PaaS). This frees up time and resources to focus on the core user experience of the mobile app.

So, what do you get when you start using a BaaS? The providers all differ, but typically you get services such as: 

• Data Storage
• Search & Retrieval
• User Management
• Messaging
• Push Notifications
• Social Network Integration
• Location
• Analytics

Developers could leverage each mobile platform’s native APIs for all these services, and many do. The advantage of BaaS solutions, however, is that developers can use a single API for each of these common services across all mobile platforms. This does mean you’re making a commitment to  a single-vendor API, but the advantage of a single, cross-platform, backend code base (without requiring any backend developers!) is very attractive.

BaaS Companies

There are many BaaS companies, but here is a list of the ones with which I am most familiar, ranked alphabetically. I often see these companies at developer conferences and hack-a-thons.  

• Cloudant – Cloudant considers itself more of a “Database as a Service.” Their solution focuses on your data and they are good at managing unstructured, noSQL data as JSON documents. Cloudant offers both dedicated and multi-tenant pricing.  BlackBerry developers access Cloudant’s APIs via standard HTTP requests. Learn more here.  Their entry level multi-tenant pricing is $1.00 per GB per month, plus small fees for hundreds of HTTP requests. The first month is free, and bills under $5.00 are always free.

• Cloudbase.io – Cloudbase.io offers many standard BaaS features, and their database allows for complex queries and data aggregation operations. The enterprise edition of Cloudbase.io can be deployed on-premise and integrates with BES 10, and uses the BES server, if available, for push notifications and authentication. Learn more about their BlackBerry 10 solution here. Cloudbase.io for BlackBerry is available in open source on Github here. Entry level pricing for Cloudbase.io starts at $11.99 per month for 1GB of data transfer and unlimited storage.  Pricing tiers are based on data transferred per month. 

• FatFractal – FatFractal provides a wide range of cloud solutions, including standard BaaS (called “NoServer”), PaaS, and “Cloud in a Box” (an enterprise offering that allows companies to deploy a complete cloud services solution within their own data center). BlackBerry developers can access FatFractal through their HTML5/Javascript APIs here. At the time of this posting, FatFractal is working on a native BlackBerry SDK. Developers can try out FatFracal for free in a small scale Sandbox. Their first tier offering starts at $30 per month with 2.5GB storage. 

• FeedHenry – FeedHenry leverages node.js on the server, which allows for a lot of flexibility when integrating with existing backend systems. FeedHenry also offers end-to-end security, as well as encryption, storage and synchronization. It can be hosted on public or private clouds. BlackBerry developers can get access to FeedHenry’s HTML5/Javascript APIs here.  

• Kinvey – Kinvey offers a wide range of BaaS cloud solutions designed specifically for mobilizing enterprise applications. Kinvey’s Data Link technology allows companies to securely mobilize its on-premise or cloud data store through the Kinvey platform and connect with existing systems to any native, hybrid, or web client. At the time of this posting, a native BlackBerry 10 SDK is in development. BlackBerry developers can access Kinvey via their HTML5 platform offering here.  Kinvey’s pricing tiers are per user. They offer a $0 entry level for 1-100 users, and a $20 per month level for 100-1000 users.

• Parse – Parse, recently acquired by Facebook, offers a wide range of BaaS solutions that appeal to consumer-facing mobile app developers. BlackBerry developers can access Parse via their Javascript SDK here. Parse’s pricing tiers are per API call. They offer a free “Basic” tier up to 1 million pushes and 1 million requests per month. Their next tier, called “Pro,” is $199 per month and is capped at 15M requests per month and 5M pushes per month.

• StackMob – Stackmob offers a complete BaaS solution and provides developers with the ability to integrate custom server-side code into their cloud solution. Stackmob is also fully open sourced on Github here. BlackBerry developers can get access to Stackmob via their Javascript SDK here. Stackmob has a free Developer Edition offering and two paid offerings (Pro and Enterprise). Pricing is dependent on features and integration with StackMob’s Mobile Marketplace composed of third-party partners.

Choosing the BaaS that’s Right for You

There are many factors to consider when choosing a cloud service upon which to build your mobile app business. As you can see from the companies I highlighted above, there are about as many different pricing models as there are BaaS providers, so I recommend spending some time looking at which model makes the most sense for your application. Also, though all solutions provide a Javascript API, only a few offer a native BlackBerry 10 SDK. The architectural differences between the solutions vary widely, and this affects the features and capabilities of the different cloud services. 

Some enterprises decide to take the “Non-Cloud” approach to avoid potential security issues with storing corporate data on external servers. To address this, many cloud services providers are offering “hybrid” cloud solutions that enable enterprises to host the data either on their own servers on-premises (the most secure option) or to host the data on dedicated servers in the cloud not used by any other company. As you compare and contrast services, choose the service with the security provisions that are right for your business.

For further reading on feature-by-feature comparisons between BaaS solutions, check out Cory Wiles’ KitchenSync Github project. In true Github spirit, Cory welcomes contributions, additional tests and additional BaaS solutions added to the project.

Summary

BaaS (Backend as a Service) is a specific cloud services category that helps mobile developers create rich, cross-platform applications very quickly by providing a single consistent API for handling many of the common, heavy-lifting backend tasks most mobile apps require. In a future blog post, I’ll dive deeper to explore a particular BaaS solution and demonstrate how to build a secure BlackBerry 10 application that leverages rich cloud and backend services through a BaaS platform. In the meantime, let us know if you’re using a BaaS solution in the comments below!

GDC 2013: The Beginning of the End of Consoles

With a background and passion for Computer Graphics, I’ve been to a slew of GDC conferences, and over a dozen ACM SIGGRAPHs.  Over the years, it’s interesting to see technologies come and go, and then come back again.    

The things I like to look for at these events are the technologies that have the potential to disrupt the apple cart.  The revolutionary movements that do more than simply evolve last year’s technology.  Rather, they beg the question whether whole companies or industries will radically change and shift to address this new force, and whether or not new players will emerge as drivers in this movement.  At GDC this year, I began to get the feeling that such a shift is starting to take place and I’m excited that BlackBerry is actively engaged in this movement.  I believe we’re starting to see the beginning of the end of consoles.   What’s threatening this industry?  Mobile devices.

Technology Advancement

As with many disruptive forces, a number of normal evolutionary changes take place first that, by themselves, are not disruptive.  However, when brought together, they can change the game considerably and threaten an entire once-stable industry.  The critical technologies all on mobile devices that are beginning to threaten the gaming console industry are the following:

·        Multitasking Operating Systems

·        High Performance GPUs

·        High Definition Video (HDMI)

·        Wireless Mobile Game Controllers

·        Portable Game Software

When all these technology advancement come together in a smartphone, you have something very close to a game console in the palm of your hand.  Each of these plays a vital role.  Let’s explore the contribution of each.

Multitasking Operating Systems

A true multitasking operating system is critical for providing smooth performance and interactivity for today’s most demanding games.  Not only must the OS manage the game itself, but it must also juggle location information, gyro, accelerometer and other sensors, concurrent voice or VOIP for trash-talking your friends during gameplay, and interact with the cloud and social networks for storing and sharing your results.  Neither iOS nor Android has a great multitasking solution here.  In contrast however, BlackBerry 10, powered by QNX Neutrino (a leading world class RTOS), is very well positioned to provide all the power necessary for managing the ever-increasing demand of concurrent functionality in the next generation of mobile games.  

High Performance GPUs

GPUs render the images.  Without them, our game visuals would be slow, blocky, and flat.  There’s no question how important these processors are.  Over the last couple of years, the advancements made by companies like ARM, Imagination, NVidia, and Qualcomm for smartphones have been enormous.  It’s getting harder and harder to tell the difference between a game rendered by a GPU on a laptop vs. a game rendered by a smartphone GPU.  Perhaps the most obvious difference has been the physical screen size.  However, when you add a multitasking OS and a high performance GPU to HD Video (the  next critical technology), things start to get really interesting.

High Definition Video (HDMI)

One of the things we did in the BlackBerry booth this year at GDC was connect a bunch of our BlackBerry Z10 smartphones (using the standard HDMI port) to large HD monitors. We also did this at our interactive pods in the Unity and Marmalade booths.  I can’t tell you how many times people walked up and asked questions like, “Since when did BlackBerry start making game consoles?”  When we told them they were looking at a game being rendered and played on the BlackBerry Z10 smartphone they had that mind blown look on their face. 

 

In the picture above, a young gamer is playing “Shadow Gun” on a BlackBerry Z10.  This is a great First Person Shooter game built on the Unity3D game engine.  You can just see the Z10 on the table in front of him below the monitor.  What you can’t see in this picture is the awesome SteelSeries Free game controller he’s using to play the game.  That piece of critical technology is next on my list.

Wireless Mobile Game Controllers

To an awesome multitasking OS, killer GPU, and HDMI out, you add a wireless game controller and you’ve just about got the whole package.  Using a controller accomplishes two important things:  First, it gets your fingers off the valuable screen real estate freeing up more pixes for game play.  The other benefit of the controller is that it adds that real, immersive game feeling you get with console controllers.  The controllers we used at GDC are the SteelSeries Free Mobile Wireless Controllers (shown below).  The last time I checked, the controller will set you back about $80USD and you can find one here. Other controllers, such as the Wii Remote and the Gametel, are also usable and there’s more to come. 

 

For you game developers out there, you can get more information about how to instrument your code to work with these controllers including samples and tutorials by checking out Sean Paul Taylor’s devblog: “Adding Gamepad Support to Your BlackBerry 10 Game”.  You can also read about Ramprasad Madhavan’s experience at GDC this year and the Unity BlackBerry 10 Open Beta coming soon on his devblog: “Unity and BlackBerry Gaming at GDC 2013”

Portable Game Engines & Frameworks

The final critical technology contributing to the end of the game console industry as we know it is portable game engines and frameworks.  The easier it is to get your game ported from one platform to another, the harder it is for games to be locked to a single console or device.  Companies like Marmalade, ShiVa3D, and Unity3D/Union all contribute here.  As a developer, you want the highest quality game experience you can get with the largest distribution possible. This is exactly what these frameworks offer and each has been tuned to deliver a killer experience on BlackBerry 10.

Summary

I confess I own an Xbox 360, Nintendo Wii, and a PlayStation 3.  However, I more often find myself connecting my Z10 to my 46” flat screen, the audio-out to my surround system, and kick back on the couch with my SteelSeries Free remote to enjoy a great game of Angry Bots or Critical Wave.  There’s no question that smartphones like the BlackBerry Z10 are providing near console game experiences.  Consoles are not becoming mobile communication devices.  They seem to be competing more with cable boxes than anything else.  Where does that leave game consoles in the future then?  Are they becoming extinct?  Will smartphones replace game consoles outright?  Or, will they just become the mobile extension of their stationary counterparts?   As the great Yoda once said, “Always in motion the future is”. 

WebGL: 3D Gaming on the Web Arrives

The Web and 3D have been to the dance many times together before.  They just never really hit it off big.  Sure, there were occasional flings which resulted in beautiful children like VRML born in the mid 1990’s and Second Life born in the early 2000’s.  But numerous other attempts by nameless and countless startups (including some that I worked for) didn’t make it.  The reasons were many, but mostly there just wasn’t a real solid business case for 3D in the browser.  It was complicated to program, expensive to develop models, performance was spotty, and ensuring that all browsers would render the content the same way was certainly not guaranteed.

There was one place, however, where 3D made business sense: gaming (well, native gaming).  3D enjoyed, and still enjoys, a happy existence on PC and Console platforms.  The question I always wondered was, when will 3D in the browser be of high enough performance and quality across all platforms and browsers to support a solid business case for 3D on the web?  I believe the time has finally come.  The confluence of mobile gaming, mobile web app development, and a solid javascript API called WebGL (a biding to the powerful and ubiquitous OpenGL), is fueling its arrival.  I’m proud to say that BlackBerry has been very active in providing one of the first complete mobile WebGL implementations on the BlackBerry PlayBook, and has also brought this capability to BlackBerry 10. 

WebGL provides developers with the ability to write immersive, high-performance, console-quality, 2D and 3D games accessible directly on your BlackBerry 10 smartphone.  This could be done directly though the browser, or even better, directly by a BlackBerry HTML5/WebWorks application.  By building and packaging your HTML5 application into a bar file (a BlackBerry app file container), it enjoys the same rights and privileges as a native application.  These apps look, feel, and behave as native apps.  They don’t run inside a browser context.  They don’t need to be online to work, and they can leverage great BlackBerry services like the Payment Services SDK and the BBM APIs. BlackBerry WebWorks apps can also be certified as Built for BlackBerry affording them additional advantages.

The game shown below is called “Pearl Boy” and is a great example of what a WebGL application can do.  It was developed by Goo Technologies, makers of the Goo Engine for GDC this year.  It’s a 100% web application, written using HTML5, Javascript, and of course, WebGL.  The graphics and performance on the BlackBerry Z10 look great.  Reflections, environment maps, pixel shaders, they’re all there.  WebGL is the real deal. 

If you want to learn more about programming with WebGL on BlackBerry, check out these additional WebGL resources on BlackBerry DevBlog.  I also recommend you check out the O’Reilly book, “WebGL: Up and Running” by Toni Parisi. 

You Just Can’t Port an App to BlackBerry 10 in 36 hours!…or Can You?

[originally posted here for BlackBerry DevBlog on 2/22/13]

I’ve heard this many times. It just can’t be done, they say. Porting an application, a “real” application to a new and unfamiliar platform takes at least 3 to 6 months, numerous developers, designers, lots of QA testing, diligent software engineering practices, et cetera. This makes a lot of sense, right? It’s been the conventional wisdom for as long as I can remember. How, then, have developers been porting their applications to BlackBerry 10 so quickly? Let’s take a look.
It’s true that learning a new platform can take months. Luckily, those standard rules of learning time don’t apply in certain cases – and that often happens to be true for BlackBerry 10. I’ll explain what I mean later.
First, let me share with you some data from our Port-a-thons. In our “Got Game Port-a-thon”, we had over 4,000 gaming apps ported by developers to BlackBerry 10 from other platforms in 36 hours. A few weeks later, we ran another port-a-thon and had 15,000 apps ported. Only a week later, an additional 19,000 apps were ported in the 36 hour window (recap of port-a-thons here). So, you might be thinking, “How could this happen if it takes 3-6 months to learn a new platform?” The reason is simple: Developers don’t have to learn a new set of skills to get their app running on BlackBerry 10. We received games and apps written in all four of the runtimes BlackBerry 10 supports: Native C and C++, HTML5, Adobe AIR, and Android Java. Here’s why it was so easy in each of these cases:

Native C and C++ Apps

Our native platform is Posix-compliant C and C++, and supports a lot of libraries and gaming engines leveraged by game developers including Unity3D, Marmalade, Appcelerator, Shiva3D, NME, OpenGL ES, OpenAL, Cocos2D-X, Box2D, Skia, Lua, and so on. (Learn more about all the native library support options here.) For many developers, the majority of time spent porting their app to BlackBerry 10 was just setting up their tooling and getting their signing keys.
Now, if your app is full of custom, platform-specific APIs or if your app uses a lot of device specific UI, then of course it will take you longer than a day to port your app. But learning Cascades, the UI framework for native development on BlackBerry 10, doesn’t take very long – especially if you’re familiar with Qt and QML. What we’re finding is that most mobile developers today are designing their apps with portability in mind at the outset. They’re separating out platform specific stuff from the common stuff. Or, they’re leveraging a framework like Marmalade that does a lot of this platform abstraction work for them under their APIs. What’s left is pretty easy to port because you have a solid, standards-compliant platform like BlackBerry 10 on which to develop. Things just work.

Android Apps

One misconception I hear a lot is that the BlackBerry Android runtime is an “emulator”. This isn’t the case. Our Android runtime is a pure port of the open source Dalvik VM directly onto QNX. Other mobile vendors ported the same code to Linux, whereas we went straight to QNX – a real-time embedded OS about 1% the size of standard Linux and highly efficient. We don’t touch the byte codes or modify the programs in any way – all we do is re-package them into a different archive format that helps us maintain security for your protection. Either your app runs or it doesn’t. If it doesn’t, our tools will tell you why immediately and you can decide if it’s something you can work around. You can even check out your app using our online tool.
We don’t support apps that use proprietary Google APIs, and we don’t support native extensions. Also, for security reasons, BlackBerry 10 does not allow Android Java apps to run in the Enterprise partition; they may only run in the Personal partition (learn more about BlackBerry Balance). Visit our Android developer site for more info about the limitations of Android apps on BlackBerry. “Porting” Android apps to BlackBerry 10 is trivial. I regularly do this in less than 60 seconds per app – no lie. It literally takes me longer to copy someone’s apk from a USB drive than it does to port it.

HTML5 Apps

BlackBerry 10 has maintained one of the highest HTML5 conformance scores in the industry for many months (see http://html5test.com/). BlackBerry 10 is not only first in the mobile rankings – it outscores all desktop browsers like Chrome, Safari, and Firefox, and it also outscores iPhone, iPad, Android, Firefox Mobile, Opera, etc. So, if you have a web app with all that silly Java or Objective-C wrapper business that Android and iOS make you put in there, you just have to strip that out all that nonsense and re-package for BlackBerry. Web apps on BlackBerry are first-class citizens on our platform; they have sensor APIs, payment capabilities and access to device camera, and they don’t need or require an Internet connection to run.
BlackBerry 10 also supports things like WebGL and WebSockets –functionality not found in many other mobile platforms. Check out all the API support for augmenting HTML5 on BlackBerry here. We also support the leading web frameworks like jQuery, Sencha, dojo, and of course Apache Cordova. For the same reasons that native C and C++ apps “port” very quickly to BlackBerry 10, so do HTML5 apps. The standards support is there. The frameworks are there.

Adobe AIR Apps

AIR is AIR; they just work. You can learn more about how to get your Adobe AIR apps on BlackBerry 10 here.

Summary

Hopefully, the question about whether you can “port” an app in a very short amount of time to BlackBerry 10 should be clear now. Through BlackBerry 10’s adherence to industry standards – and by developers’ common practice of architecting for cross platform deployment – mobile apps are, and have been, easily ported to BlackBerry 10. For more information, check out our new developer site: http://developer.blackberry.com

Application Security Part II: What Should App Developers Do?

[originally posted here for BlackBerry DevBlog on 2/6/13]

 

 

In my previous blog post on this topic, titled “Application Security Part I: Whose Responsibility is it?”, I explored the responsibility of security in the mobile app ecosystem.  In this post, let’s take a little deeper look at the problem of security and code safety from a mobile app developer’s point of view and explore what developers need to think about and how they can avoid potential security problems in their applications.

The majority of security problems in app development are really software quality problems. There’s something wrong with the way the code was written that leaves a door open for someone to exploit.  Fortunately, many of these problems can be easily fixed.  Some of these can be fixed in the design phase of product development and others in the code phase.  We’ll explore a few examples of each type in this post.

The Objective of this Post

Now, before we jump in, I need to confess that this is a broad and deep subject.  My goal here is to present a high-level understanding of code security through discussion and a few examples that will help you understand the kinds of vulnerabilities that can lead to problems.  I will also provide references to further reading for those that really want the “Full Monty” on developing secure apps.

Code Security at Design Time

·        Design with security in mind.  This is perhaps the most important thing you can do. Think about the following questions before you design your code and have answers for all of them:

a)     What Assets does this software need to protect?  Credit Card numbers, user data, contact lists, account info, access to paid services, and privileged access to device.   To protect sensitive assets, you need to plan how you’re going to deal with the data at design time.  If you’re sending sensitive data over a computer network, you should use SSL/TLS protocol to prevent attackers from eavesdropping. Look into OpenSSL for open source libraries and code examples on how to use this protocol.  Also, for server-side storage, consider using a 3^rd party database such as MySQL. These systems have their own built-in security policies that you can leverage.  Also, for secure authentication, leverage trusted services like OAuth and OpenID (See Additional Resources for more info below).

b)     How might an attacker exploit my code?  This is often called “Thread Modeling”.  Attackers might be eavesdropping on the network ports you use, or providing unexpected inputs that overflow memory buffers and inject attacker-supplied code to be executed. You have to ensure, for example, that you never execute code on behalf of an untrusted user.

2.      Follow a Secure Coding Standard - Select a secure coding standard and make sure your code conforms.  A secure coding standard will identify specific issues with a particular programming language that a compiler or analysis tool might fail to diagnose.  Secure coding standards also define requirements for producing code level security in your system.  Several popular secure coding standards are available from CERT® on their website at www.securecoding.cert.org.

3.      Perform Design Reviews.  This is a simple thing teams can do, and it can really pay off in the long run.  A few years ago, I managed a couple of engineering teams at Sun and when a new code module was planned.  The engineering lead would present the design to a team of Senior Architects with different backgrounds (JVM, networking, platform architecture, etc.).  This always uncovered potential problems –and did so early on before they became big problems that were expensive to fix.

4.      Understand Emerging Threats.  Pay attention to the type of exploits that are popular, and make sure you’re not helping the bad guys.   Designate one person on your team to stay up to date on the current security trends and put her/him in the code review. A great place to start is by visiting the CERT website frequently and becoming familiar with all the resources they offer.  In addition, all major platform and OS providers publish security updates from time to time as issues are uncovered.

5.      Use Static Analysis Tools.  Static code analysis can really help locate many kinds of software validation and reliability problems, including many memory problems. Some examples of companies that provide these products include:  Klocworkand Coverity, Parasoft, and Vericode. A more complete list can be found here: http://www.cert.org/secure-coding/tools.html 

If you’re doing all these things, you’re actually doing pretty well.  You’ve got a solid design, you’re following a secure coding standard, you’ve got someone keeping an eye out for potential security exploits, and you’re conducting design reviews and running static analysis tools on a regular basis. You’ve got the design side covered pretty well.  Now let’s look at some specific code issues that can cause problems.  

Code Security at Development Time

Most of the following examples demonstrate some of common problems found in native C and C++ development.  Web developers and Java developers can still benefit as the concepts behind the problems are valid in many languages.  In the Additional Resources section below, I provide links to specific Web and Java resources for code security. 

1)     Application Frameworks 

Use application frameworks whenever possible.  Frameworks hide a lot of the nasty memory management and secure network connection issues from the developer and reduce the possibility of making simple, but costly, mistakes.  Fortunately, the BlackBerry platform supports a lot of great developer frameworks, both from BlackBerry (such as the Invocation and Share Framework, and the UI Framework Cascades) and through BlackBerry’s Platform Partners.  

2)     Memory Management

Aside from the obvious allocation of memory insufficient for the data you’re writing into it, there’s a common issue people new to C and C++ sometimes experience regarding memory management.  The problem occurs when you confuse which action you use to release the memory you’ve allocated.

Using Cascades will reduce the likelihood of memory management problems because it hides all the messy details for you within the framework.  However, if you must allocate memory yourself for your app, keep the following tip in mind.

There are two main C functions for allocating memory: malloc() and calloc().  Use malloc() when you don’t care about initializing the data in memory.  Use calloc() if you want to initialize the memory to 0.  The important thing to remember is when using either malloc() or  calloc(), you must use the function free() to release the memory and give it back to the system. 

In contrast, when using the C++ method new() to create a new object, you must use the corresponding delete() method.  Nothing good can happen when you call free() on memory you’ve created using new().

3)     Function Safety

The QNX platform provides a number of preferred C functions that are safer to use than the more commonly known standard functions.  A subset of these is shown in the table below.  You can find the complete list in the BlackBerry Native SDK online docs (referenced in Additional Resources section below).

As with memory management, using an application framework helps with function safety as well.  For instance, the Cascades classes such as QString and QByteArray protect you from many of these problems as well.

As you’ll see in these examples, most of the serious problems occur when buffers you’re reading into or writing out to are not large enough to take the data.  These functions below help you from over-writing some of the time.  You should always perform bounds checking if you want to be on the safe side.  

Unsafe Function(s)	Preferred Function(s)	Comments
strcpy() and strncpy()   strcat() and strncat()	strlcpy() and strlcat()	The function strlcpy() copies strings and the function strlcat() concatenates strings. They're designed to be safer, more consistent, and less error-prone replacements for strncpy() and strncat(). Unlike those functions, strlcpy() and strlcat() take the full size of the buffer (not just the length) and guarantee to NUL-terminate the result (as long as the size is larger than 0 or, in the case of strlcat(), as long as there's at least one byte free in the destination string). There also exist "wide" versions of these functions that are equally dangerous: wcscpy(), but there is no "l" safe version to use, only wcsncpy() which does not necessarily NUL-terminate the output. Care must be taken to ensure the output buffer is NUL-terminated.
sprintf() and vsprintf()	snprintf() and vsnprintf()	The snprintf() function is similar to fprintf(), except that snprintf() places the generated output (up to the specified maximum number of characters) into the character array pointed to by buf, instead of writing it to a file. The snprintf() function is similar to sprintf(), but with boundary checking. A null character is placed at the end of the generated character string.
gets()	fgets(buf, n, fp)	The fgets() function reads a string of characters from the stream specified by fp, and stores them in the array specified by buf, limited to size n.
getwd()	getcwd(buffer, size)	The getcwd() function returns the name of the current working directory. buffer is a pointer to a buffer of at least size bytes where the NUL-terminated name of the current working directory will be placed. The maximum size that might be required for buffer is PATH_MAX + 1 bytes

 

4)     Structures

Structures in C and C++ are aggregated types that define and contain other data elements within them.  The elements of a structure cannot be re-ordered by the compiler.  Modern compilers do use a variety of methods to minimize the security risk of stack-buffer overflows such as stack canaries, address-space layout randomization, re-ordering the local variables within a function, among other things.  However, since the compiler can’t re-order the elements within your structures, the possibility of a buffer overflow on one of your elements affecting function parameters or local variables remains.  Consider the following example:

        struct _JOB {

            char name[64];
            char title[64];
            DATE startdate;
            DATE enddate;
            WAGE salary;     

        } JOB, *PJOB;

The buffers name and title can both overrun.  Since they’re placed on the stack first, the elements defined after them in the structure and on the stack itself can be affected.  For this reason, care should be given when defining the elements in a structure.  The next example shows a structure that's defensively designed:

        struct _JOB {

            DATE startdate;
            DATE enddate;
            WAGE salary; 
            char name[64];    // Buffers placed at end
            char title[64];   // of struct definition

        } JOB, *PJOB;

 

Recommendations for using structures

When dealing with structures that contain fixed-width buffers or arrays designed to receive data that's controlled or influenced by a user:

·        Buffers and arrays in structures should be grouped at the end of the structure

·        Local variables declared as structures should be declared after local buffers but before any other local variables

·        Global variables declared as structures should be declared before any global buffers and arrays and after any other global variables

·        Pointers to structures do not need any special consideration

·        Where practical, try to minimize the number of local variables cast as structures with buffers and arrays as elements

5)     Macros

Macros are one of my favorite mechanisms in C and C++.  I love using them; however, you have to be very careful as they can get you into trouble.  Macros are defined through the use of the #define preprocessor directive and when processed, literally expand in your source code prior to compilation.  If IDE’s could show you what the processed source code looked like (maybe some do?), then I suspect we’d see fewer problems.  Consider the following example that demonstrates the issue:

#define CUBE (x*x*x)

…

int x = CUBE (5-2)

In this example, you might expect that you’re going to get the cube of 3 which is 27.  However, when the preprocessor expands the macro, normal operator precedence rules apply.  So, here’s how that the value of x will be calculated: 

CUBE(5-2) = (5 – 2*5 – 2*5 – 2)

CUBE(5-2) = (5 – 10 -10 -2)

CUBE(5-2) = -17

Therefore, to protect against this problem, the macro can easily be defined using parentheses as in:

#define CUBE(x)   (x)*(x)*(x)

In this example, we’ve seen how operator precedence rules can get you into trouble with macros.  There are other problems such as the importance of white space when defining macros, using macros in if statements, and self-referencing macros to name a few.  Provided you think about how the macro will expand in your source and you consider how the arguments you pass to macros will be interpreted in that expansion, you should be fine.

6)     Integers (signed, unsigned) and Enumerations

Another common problem that can expose serious threats to your code involves integer overflow or underflow.  This can happen when care is not taken with integers.  The following code fragment demonstrates how serious this problem can be (recall our discussion about buffer sizes above):

int buffLen = 0;

printf(“[buf] %d %u\n”, buffLen, buffLen);

buffLen = -1;

printf(“[buf] %d %u\n”, bufflen, bufflen);

Executing this code gives:

[buf] 0 0

[buf] -1 4294967295

In this example, I forced the value of bufLen to be -1 for demonstration purposes.  But, it’s easy to imagine a simple arithmetic error in a length calculation to be off by one.

Similar problems arise with the use of Enumerations.  Not all compilers use the same kind of “int” for Enumerated types.  So, you need to be careful when using Enumerations.  Make sure you know how your compiler treats them.  If your compiler uses signed integers by default (such as Microsoft Visual C++ and ARMCC), it’s not possible to create an unsigned enumeration as the value will be overflow the signed int (for example, you can’t set the enumerated value to be 0xffffffff).

Summary

Though we’ve just scratched the surface of this topic, we’ve discussed a number of things developers can do to protect their code from security problems.   We’ve explored good practices developers can adopt at design time, such as:

·        Design with security in mind

·        Follow a Secure Coding Standard

·        Perform Design Reviews 

·        Understand Emerging Threats

·        Use Static Analysis Tools. 

We’ve also looked at some common coding mistakes that can lead to security problems and discussed how the code can be fixed to avoid these problems.  We’ve seen how leveraging Application Frameworks (like Cascades) can greatly reduce security problems.  As an app developer, you have a responsibility to protect your user’s identity and sensitive data as best you can from attackers seeking to exploit it.  The content in this blog post should help you get started with some good practices and links to learn more. 
For more information on application security, additional examples, and deeper analysis, please refer to the additional resources below. 

Additional Resources

·        BlackBerry Native SDK Online Docs.  Security Considerations for Native Application Development

·        QNX Online Docs, Neutrino C Library Reference

·        Chad Tetreault, Say It Aint S’OAuth,  in BlackBerry Dev Blogs

·        Software Engineering Institute | Carnegie Mellon  http://www.sei.cmu.edu/ 

·        Seacord, Robert. The CERT C Secure Coding Standard, Addison Wesley, 2008

·        Seacord, Robert. Secure Coding in C and C++, 2^nd Edition, Addison Wesley, 2013.

·        Mark Dowd, John McDonald, Justin Schuh, The Art of Software Security Assessment

Acknowledgements

I’d like to thank Robert Seacord for taking the time to read an early draft of my blog and provide helpful feedback.  Robert is a senior analyst in the CERT® Program at the Software Engineering Institute (SEI) in Pittsburgh, PA where he leads the Secure Coding Initiative and is author of a number of books on Secure Programming.  I’d also like to thank the BlackBerry Security team for their insightful comments and suggestions.