Tag: security

Posted on

Is Your Organization Mobile Ready?

Mobile nowadays has become more front and center in the enterprise landscape. It is both directly and indirectly creating new revenue or strengthening the existing revenue streams. Companies that listen and respond properly to mobile trends can win competitive advantages. Is your organization mobile ready

Here are five key questions to ask as you prepare for your company to go mobile.

1. Is your business model mobile ready?

It’s apparent that mobile is now everywhere and significantly changing the way businesses operate. It is considered to postdate the days of personal computers and is becoming the main tool of the business workforce. All stakeholders who are influencing your business, including customers, business partners and employees, are also profoundly being influenced by mobile technologies. They are going mobile. New work flows and connection patterns are being created among your business influencers. Customer demands are getting more sophisticated with all the mobile options, which may force your company to reexamine a lot of things, including its business model, to reposition where it is in the value chain. Revenue streams are shifting to where the mobile involvement is, and you have to refine your business model accordingly to keep your customer happy as well as catch new opportunities. Mobile is where the customers are, so that’s where you need to be.

2. Is your infrastructure mobile ready?

A research study from IBM states that 91 percent of mobile users always keep their mobile devices within a reachable distance. It implies that users want the ability to access applications and services everywhere, whenever they are needed and of course as quickly as possible. This challenges your infrastructure in terms of availability, performance and responsiveness to the explosive number of requests.

The wide adoption of mobile devices also challenges your current system’s architecture. Technically, services that have been exposed outside of the enterprise might not be suitable for mobile requests because in responding to the requests from a mobile environment, which is typically limited in computing resources, the data being transferred back should be lightweight enough that it can be effectively consumed by mobile applications to provide the expected user experience.

Additionally, the diversity of mobile platforms that involve platform owners in operating some useful services (for example C2DM or APNS, the users’ service providers and so forth) would require your enterprise system to be adapted to interact with those external systems effectively and securely.

3. Have you considered security?

Security has always been a big concern when enabling an enterprise to go mobile. Controlling security for mobile is getting more and more challenging due to the natural portability of the mobile environment as well as the constantly growing diversity of mobile platforms and mobile applications. It consequently requires an efficient approach from the strategic level with clearly defined mobile use cases in the business context. This in turn helps the enterprise to build up a comprehensive mobile security policy to more detailed levels, like how to use technologies for implementing the policy and how to make mobile users aware of security threats and regularly educate them to follow security practices to protect themselves and the corporation. That circle from strategy to policy to technology and education should incrementally, iteratively evolve to keep your security strategy up to date and ensure that it reflects your business needs.

4. Is your design approach and concept mobile adequate?

Mobile devices are typically made with smaller screens and are several times less powerful than desktop computers in terms of computing resources, yet the activities performed on mobile require a sense of immediacy. They tend to be tactical in nature. As a result, the interaction flow between the user and the mobile application requires a completely new user experience design mindset. Data presented on mobile needs to be somehow contextualized and condensed to convey as much information as possible and to best utilize less network bandwidth and hardware resources. There is no room for redundancy. Information and an application’s features need to be progressively, selectively displayed.

Design approaches applied for desktop are consequently inadequate for the mobile environment, not only from the user interface perspective but also from code design since the same code would not run on mobile as effectively as on desktop. It needs to be leaner.

Mobile is becoming mainstream in the workforce, and a mobile application is no longer simply a smaller, zoomed-in version of your desktop application. Applying an appropriate design mindset will make your mobile application, the heart of your mobile business model, more attractive to help you meet user expectations and gain a competitive advantage.

5. Is your application development process mobile suitable?

Mobile devices and platforms evolve rapidly, and your app consequently needs to adapt quickly to those changes in order to continuously gain user satisfaction. In other words, mobile apps are written, used and replaced at a much higher rate than traditional enterprise apps. That requires your development process to be refined so that your app will be iteratively delivered more quickly without sacrificing quality.

Additionally, mobile user expectations are very high, yet loyalty is low. They will easily forget your app if they cannot find what they need on the very first try on their tiny mobile devices. In order to continuously make sure your app satisfies its users and keeps them using the apps, you need to get them involved in the development of the apps earlier, interact with them more frequently to get feedback and then meet their expectations promptly—period.

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