Enterprise 2.0 App Stores: When Good Web 2.0 Apps Go Bad

Share your find
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Custom Dashboards in the Enterprise & Web 2.0 Apps

There’s an app for that!

The success of Apple’s iPhone App Store, Mac apps, and Google’s Marketplace all play a part in driving the trend of Enterprise 2.0 App Stores in business organizations of all sizes.  The idea of providing a solution with “There’s an app for that!” will be common place in the near future.  The App Store market will get very interesting when organizations and Government Agencies harness the true power of Service Oriented Architecture (SOA) & Cloud Computing.  This trend will help fuel the Federated System.  More information about Enterprise 2.0 App Store Architecture can be found here The 80-20 Rule for Web 2.0 Architecture in the Enterprise.

Where Do Apps Come From?

Custom Enterprise 2.0 Dashboards can include apps, widgets, and gadgets that include resources that are internal, external, and a combination of both.

  1. Internal Resources: Apps and their data that are hosted and maintained within the organization. The risk level is low.
  2. Internal and External Resources: There are usually internally created apps that use external data. The risk level is medium.
  3. External Resources: Apps that are hosted by third parties.  The trust relationship is complex and the risk level usually remains high.

How Are Apps Delivered?

Apps are added to devices and dashboards in multiple ways. App code and private data should reside in the client, but this is rarely the case.  Web 2.0 Apps are usually added to Enterprise 2.0 Dashboards by using the following technologies and methods.

What Are Application Security Risks?

Attackers can potentially use many different paths through your application to do harm to your business or organization. Each of these paths represents a risk that may, or may not, be serious enough to warrant attention.  The top 10 application security risks of 2010 can be reviewed on the Open Web Application Security Project (OWASP) web site here.  Additional Web Security information is available from the Open Ajax alliance at Ajax and Mashup Security.  The main rule of thumb is, “Never trust external data”.  Using a Proxy Server to fetch external data can help support the additional security requirements.  A proxy server is also helpful in capturing metrics of external resource usage.  The proxy server can integrated like an Enterprise Service Bus (ESB) to support the complex structure of Enterprise 2.0 App Stores.

What Happens When Good Web 2.0 Apps Go Bad?

How to Detect a Key Logger on Your System

Most people in the Web 2.0 World are familiar with the acronym WYSIWYG, “What You See is What You Get”.  This new acronym WYRIWYR, “What You Requested is What You Received” will be covered here.  The consumer and the producer should be focused on WYRIWYR.  Producers need to trust the consumer’s identity and consumers need to feel secure.

Data can be tampered with on either end and while in transit.

The Open Source Software Community frequently uses checksum to protect software integrity. This same strategy can be used to protect consumers from malicious apps and widgets.  This simplified example will use MD5 in PHP to check the integerity of the app, but MD5 should not be used for sensitive data like passwords in a production environment.  US-CERT of the U. S. Department of Homeland Security said MD5 “should be considered cryptographically broken and unsuitable for further use,” and most U.S. government applications will be required to move to the SHA-2 family of hash functions after 2010.

Simple App

Here is a very simple app that could be part of a custom Enterprise 2.0 Dashboard. The App is reviewed and approved. The reviewer signs the app (creates app MD5 Hash: c15a7308d89afe9218a1b0f60a37f8ad) so changes can be detected when it comes back through the proxy server.

Simple App in Proxy Server before Dashboard Display
Deliver app if new hash and signature match. Disable app and notify Admin if something does not look right.

The Simple App with Key Logger Script Injected

Happy Fav Five Friday!

Fav 5 Places

  1. Google Gadgets For Your Webpage
  2. ‘App store’ makes service orientation real for the business
  3. Global CIO: The Case For Copying Apple’s App Store
  4. Nexuo Enterprise Platform
  5. Enterprise Irregulars: Designing User Experience

The people from Open Social provides a great Introduction To Signed Requests

OpenSocial API provides a method to communicate OpenSocial ID numbers back to your server in a secure way, allowing for the construction of robust web service backed OpenSocial applications, using a portion of the OAuth authorization protocol.  This article will explain the method to make such secure requests from your OpenSocial applications, as well as the server-side process that you need to follow in order to verify that the data passed has not been tampered with.   Learn more here.