Posts

Posted on

Would WebSockets Security Vulnerabilities Be A Showstopper?

When you’re developing interactive applications with simultaneous editing ability (for example, a virtual collaborative whiteboard, chat, online game or real-time reporting system over the web), using the traditional loosely coupled HTTP request/response web model is obviously not an efficient way to go. That approach is simply not designed for a real-time model. We need a more lightweight protocol that can provide a full-duplex communication channel between endpoints of the system to achieve as near a real-time experience as possible.

This need is becoming critical as such applications are deployed and run in the mobile world, where the resources for staying connected are sometimes very limited: limited bandwidth, limited memory, lots of potential latency.

A number of creative approaches—work-arounds—aiming to create a real-time feeling for users have been implemented (for example, Ajax, Comet). So far these have served the connected world well by bringing together good user experience with the ability to shorten the time in which data is being sent between client and server. But these approaches still have several limitations from a resource-consumption perspective: a huge redundancy of network traffic, server demands and the complication of maintaining two HTTP connections between endpoints (one for the upstream and another for the downstream).

Using WebSockets is a big step forward in the effort to create an engaging, interactive user experience. It could provide capabilities such as real bidirectional communication, low latency, significant reduction of overhead and dramatically reduced complexity of implementation.

From a security standpoint, though, some people are afraid of using WebSockets due to some risks that would create vulnerabilities. WebSockets’ application programming interface (API) allows establishing WebSockets connections across domains without the user’s acknowledgement, and requests are sent without notifying the user. This makes it possible for the attacker to inject malicious JavaScript code into the victim’s client application (the user agent; for example, browser, mobile app and so forth) to establish a WebSockets connection to an arbitrary target. The connection can then be utilized by the attacker for malicious purposes, such as:

  • Remote shell, web-based botnet, port scanning

Cross-site scripting (XSS) vulnerability has been common in web technology, but utilizing WebSockets introduces some threats that would give an attacker more power to control the victims—assuming that the user somehow visits a malicious service, or a website that has XSS vulnerability exploited, from the user agent. Once loaded in the user agent, malicious JavaScript code can be executed and the attacker can easily establish a WebSockets connection to a malicious server and create a remote shell to utilize the victims for malicious purposes: a Distributed Denial of Service (DDoS) attack (with lots of victims), access to the company’s intranet services for information, port scanning or using the victim’s user agent as a proxy, a springboard for other attacks.

  • Friendship between WebSockets and proxies, firewalls

In November 2010, a serious security issue involving WebSockets was reported. WebSockets was still not adopted widely enough, so some transparent proxies didn’t correctly understand the HTTP upgrade mechanism being used for the handshaking of WebSockets and thus can potentially allow a cache poisoning attack. Frame-masking was added to avoid that vulnerability, but in turn the frame-masking and other natural lightweight features of the protocol (lack of metadata like HTTP header, content length) challenge the virus and malware scanning tools in analyzing the data patterns to detect malicious content in a malicious usage of WebSockets channel.

The vulnerabilities are mostly not specific to WebSockets API or the protocol, but the freedom of the new data exchange model opens up more threats and more attention is needed to secure the communication. Best practices for traditional web programming should still be applied for WebSockets.

  • Maximize the validation on both client and server side against the received input. Client and server basically should not trust each other by default.
  • Maximize the use of Transport Layer Security (TLS) encryption to achieve integrity.
  • Carefully implement authentication and session management between endpoints.

When you are struggling with the trade-off between security and performance while deciding whether or not to use WebSockets, it might be a good choice to utilize a well-known solution for your particular need. One of the proposals to deploy your application that uses WebSockets is to not make it a mobile web application that runs on web browsers of the users’ mobile devices, but instead to use an alternative way—to build a hybrid mobile application and stick your client application with a proven server-side solution, for example, Node.JS (and Socket.IO, or Worlize). IBM Worklight offers you a way to easily build a hybrid mobile application (and much more). You can basically build your app in a web-based code such as JavaScript, CSS or HTML just like a web application, but the code will eventually run on top of a thin native container that utilizes the device’s webkit engine, instead of using the mobile browser itself (you need some work-around for dealing with Android though, because unfortunately WebSockets has not been widely supported in its embedded webkit engine yet).

Be well aware of the security vulnerabilities of using WebSockets. Dealing with them properly will help you to build a secure, interactive mobile application and enjoy the near real-time experience on your mobile devices in a collaborative world where time is precious and conserving resources is critical

Posted on

What could go wrong with your enterprise mobile application?

Developing and releasing mobile applications can be a difficult business, especially in the enterprise context, with a lot of expectations and constraints. In this post we’ll talk about some common challenges you may have with enterprise mobile applications.

You cannot smoothly deploy and distribute your app

When an app is ready for release, you might be stuck at how to move forward with deploying it because you did not take into account some critical dependencies on a platform-specific deployment process. For example, if you want to host your app in a public app store, you need to mindfully consider the approvals process of the app store owner, the audits your app needs and the app’s capabilities once it’s deployed there due to the deployment constraints. If the app is going to be deployed in an enterprise app store, in many cases you need to know how to get enrolled into the proper developer programs as well as how to provision and profile your app accordingly. You need to be aware of the dependencies of the app on the mobile device management (MDM) platform that your organization is using.

Also, you need to consider the download size of your app, what part of the app should be bundled into the installation package, what part should be distributed later as the user uses the app and so forth. You might also be struggling with how to inform your users about a new version of your app and how to have it conveniently updated on their devices. All of these can obviously create problems that may impact your deployment plan.

Your app crashes, freezes or behaves weirdly

A poor testing plan that did not sufficiently cover all the aspects of your app when it goes live usually causes the quality issues. With the wide adoption of bring your own device (BYOD) in the enterprise, testing becomes a huge, challenging task in mobile app development due to the diversity of mobile devices and operating systems in the market.

Even though simulators are your friends they can’t substitute for real devices. Manual testing, or interactive testing, which involves real human beings trying the app on real devices, is still a crucial testing method even though it is expensive and requires a lot of effort. You should incrementally involve users from different departments in the testing cycle to make sure your app is frequently tested before rolling it out at the corporate level. Manual interactive testing works best in many scenarios, especially nonfunctional testing like performance and user experience evaluation. You may also want to consider testing in the wild with poor connection or battery draining; device-specific testing on resolution and orientation; or even testing with different carriers, which could cause strange behavior in your app.

Your app is too complex

One of the common pitfalls is putting too many features that involve resource-consuming functions into a single mobile app, which complicates navigation within the app, challenges the user or drains the battery quickly. Due to the natural small screen of the mobile device and its limited computing resources I recommend that you make your mobile app as simple and lightweight as possible in terms of functionality and resource consumption so that the battery won’t be drained even before the user gets used to the app. User satisfaction is usually higher when an app has fewer but better-defined functions, rather than a broad range of complicated features. The user’s expectation usually includes the ability to conveniently complete complex tasks in the simplest way possible.

Your app’s usability is poor

Enterprise apps usually do not get enough focus on user experience design and are not typically as polished as consumer apps. Meanwhile, employees still expect to have an equivalent level of usability. Even though enterprise mobile apps often have a different mission and have more going on than consumer apps, they share the same challenges when used on mobile devices.

The usability expectation is that apps be intuitive and easy to use. It’s reasonable if the users ignore your app because of its lack of user-friendly design, poor navigation experience and so forth. The mobile application also should not be data intensive and should help your employees to easily browse its functionalities and get results instantly.

You lack support and maintenance or a way to track results

Perhaps your users do not know how and where to get help when they have trouble using the app. Or the users have the app, but no one is following up to see if it’s being used, how often it’s being used and if people are happy about the app.

It’s crucial to plan for app usage statistics and a feedback recorder up front and to spend effort on analyzing and managing them to continuously address users’ concerns and feedback. App analytic is critical to keep your mobile app essential to its users and drive your users’ satisfaction to meet the business needs.

The last stage of your mobile app is not deployment. It’s ongoing support, a learning effort to know what works and doesn’t work for your users, in context, to better ensure the business value of your app.

To avoid most of these headaches, you need a comprehensive mobile application life-cycle management approach that is sufficient for your needs and can offer agility to your enterprise. And that’s where IBM MobileFirst can help with its mobile application development life-cycle offering.