Nathan has nearly 7 years of experience in systems integration focused on core enterprise systems (ERP), and both consumer and enterprise mobility. Nathan's ERP experience includes a number of SAP-ECC6 implementations and an integration project between ECC6 and SAP's SRM7.0 with Procurement for Public Sector. Nathan's mobility experience includes both consumer and enterprise mobile applications. Nathan has been involved with multiple applications deployed via the Apple AppStore as well as utilizing the Apple Enterprise Developer Program. In his free time Nathan enjoys spending time with his family, golf, college football and staying on the bleeding edge of tech.
HTML5 for the Mobile Enterprise - Security and Compatibility
May 11 2010
Last week, I discussed some of the new, exciting functionality that will be available in HTML5. While this new functionality presents endless opportunities to change how your company delivers content to employees and end users, there are security and compatibility concerns that must be understood prior to embarking on a great HTML5 journey.
Today, we'll discuss some of the more common security concerns raised as part of the HTML5 specification as well as compatibility issues you may face if implementing an HTML5 solution. In some cases, I'll even include notes on how certain issues can be avoided.
Security
The new benefits of HTML5 aren't without their security concerns and potential for abuse. Some of the concerns below may not be applicable for mobile apps deployed at the enterprise level but worth reviewing nonetheless.
Web Storage: There are obvious security concerns with client-side storage. There is a large potential for abuse if not implemented properly. Here are some security concerns that should be reviewed as part of planning and design. Keep this in mind while reading (credit to Opera for the verbiage), origin is the tuple of scheme/host/port. Thus, http://captechventures.com, http://blogs.captechventures.com, https://captechventures.com and http://captechventures.com:80 are all different origins.
Storage is assigned on a per origin basis so DNS spoofing is possible which would allow intruders access to a users data. SSL can be used to prevent this.
This probably will not be an issue in the enterprise (since Geocities has left us - moment of silence), but, Web Storage should not be used where more than one user is using different pathnames on one domain. For example, if I implemented Web Storage at captechventures.com/nathan/ it would be accessible by a Web Storage implementation at captechventures.com/jones/ (note: not valid URLs).
Databases would be stored locally on the client which allows would-be attackers to download a copy of that database and create very precise attacks by issuing plain SQL statements, no need for injection when you have the database. While this may not immediately impact mobile devices, proper security should be put in place - phone locks, data retention periods (e.g. if the new lead has been sent to the CRM system, wipe it), etc.
The fact that the database resides on the client also opens up the potential for attacks on your backend enterprise systems. Your schema is now widely known, very targeted, malicious queries can now be created. If your app is designed properly (hint, hint, nudge, nudge), client-side storage should only need to store a small subset of information. Therefore, you can design a database specifically for that subset of information without giving away secrets about your entire backend.
Cross-Domain Capabilities: The new capabilities in HTML5 such as canvas, audio and video make it easy to access content across domains and continue to 'mashup' information. However, this could introduce information leakage. There are safe-guards being put in place to help prevent information leakage. For example, the canvas element contains a flag called origin-clean which indicates whether the content originates from a different origin (see Opera's explanation of origin above) or not. If the origin-clean flag is set to false, calling the toDataURL() or getImageData() methods of the element would raise a SECURITY_ERR exception.
Geolocation: Geolocation presents a host of privacy concerns considering that you're pinpointing the location of the device and therefore the user. While not always 100% accurate, geolocation should be used sparingly, requesting location information only when necessary for user experience. Proper warnings and terms must be included to make the user aware that you are storing location information and potential consequences - i.e. broadcasting that you're home (with GPS coordinates included) once a day for 5 months and then telling the world you're in Maui for the week has potential to be abused.
Forms: This should be common practice, but I want to reiterate, Javascript is client-side code and, as such, you lose a lot of control. While client-side validation, especially on a mobile device, can be powerful you should always validate form submissions on the server after each form is submitted. Yes, this may require an extra round-trip, on occasion, but if someone is trying to be malicious do you really care if they eat another 120KB of their data plan? That's what I thought...
KeyGen: This is a post for another day, but HTML5 also includes the 'keygen' element which facilitates the creation of private and public keys for identity verification - think enterprise security, banks, etc. You should note that adoption is not standardized, documentation is sparse, and Microsoft has even asked that it be removed from the HTML5 specification all-together. Here is one link I found useful if you're itching to dig deeper.
Compatibility
It goes without saying that a web-based version of a mobile application is quicker and typically more cost effective to deploy than platform native applications. Firstly, you don't need an in-house Objective-C developer and iPhone OS (iPad/iPod included) API guru, Java developer and someone versed in the cumbersome Blackberry APIs. HTML5 web applications simply require a web developer and web designer. Secondly, you don't have a platform specific approval process to battle. Consider the source, but even Google's VP of Engineering points out that not many companies are rich enough to build native apps in support of each mobile platform.
That being said, there are compatibility issues to consider when looking at HTML5 for your mobile application. HTML5 is still in draft status and is not supported by all mobile browsers. Mobile Safari (iPhone), the Android browser support quite a few, but not all, changes in the HTML5 specification. Opera Mini supports some (around 10%) but is constantly evolving and was recently approved for use on the iPhone. IE Mobile 6.0 still doesn't appear to have much support for HTML5...surprise, surprise. I'm still trying to dig up information on whatever version of IE will be bundled with Windows Mobile 7, but I'm not holding my breath.
Blackberry is beginning to implement some of the specification (e.g. the datalist element) in some of it's browsers but it's still not ready for the big leagues. With multiple versions of their browser running on multiple versions of the OS, building for the Blackberry will be challenge. This has been heralded as one of the biggest obstacles for HTML5 to overcome in order for it to go mainstream. In my humble opinion, as Android phones and the iPhone continue to rip away market share, Blackberry will pick up the pace of innovation.
In the mean time, creating a lighter version for Windows Mobile and Blackberry, while frustrating, is an option. Another potential option in the future would be to deploy Opera Mini to Windows and Blackberry devices. It runs on each platform and, while it only supports about 10% of the specification now, it is evolving. Remember, Opera was a core contributor to Web Applications 1.0.
If you're interested in discussing how CapTech can help mobilize your enterprise, contact Jack Cox, the Mobile Service Offering lead.
Last week, I discussed some of the new, exciting functionality that is available as part of HTML5 and how it applies to the enterprise. While this new functionality presents several new opportunities to change how content and functionality is delivered to employees and customers, there are security and compatibility concerns that must be understood prior to embarking on a great HTML5 journey.
Today, we'll discuss some of the more common security concerns raised as part of the HTML5 specification as well as compatibility issues you may face while implementing some of the new HTML5 components. In some cases, I'll include notes on how certain issues can be avoided.
Security
The new benefits of HTML5 aren't without their security concerns and potential for abuse. Some of the concerns below may not be applicable for mobile apps deployed at the enterprise level, but worth reviewing nonetheless.
- Web Storage: To the point, there are security concerns with client-side storage. There is a large potential for abuse if not implemented properly. Here are some security concerns that should be reviewed as part of planning and design. Keep this in mind while reading (credit to Opera for the verbiage), origin is the tuple of scheme/host/port. Thus, http://captechventures.com, http://blogs.captechventures.com, https://captechventures.com and http://captechventures.com:80 are all different origins.
- Storage is assigned on a per origin basis so DNS spoofing is possible which would allow intruders access to a users data. SSL can be used to prevent this.
- While this will probably not be an issue in the enterprise (since Geocities has left us - moment of silence), Web Storage should not be used where more than one user is using different pathnames on one domain. For example, if I implemented Web Storage at captechventures.com/nathan/ it would be accessible by captechventures.com/jones/ (note: not valid URLs).
- Databases are stored locally, on the client, which allows would-be attackers to download a copy of your database and create very precise attacks by issuing plain SQL statements. There's no need to employ injection techniques when you have the database. While this may not immediately impact mobile devices (retrieving content from them is not straight-forward), proper security should be put in place - phone locks, data retention periods (e.g. if the new lead has been sent to the CRM system, wipe it from the local database), etc.
- The fact that the database resides on the client also opens up the potential for attacks on your backend enterprise systems. Your schema is now widely known; very targeted, malicious queries can be created. Proper consideration should be given to your mobile storage design - client-side storage should only store a small subset of what may be available at an enterprise level. Therefore, design a new schema specific to that subset rather than deploying your enterprise design.
- Cross-Domain Capabilities: The new capabilities in HTML5 such as canvas, audio and video make it easy to access content across domains and continue to 'mashup' information. However, this could introduce information leakage. There are safe-guards being put in place to help prevent information leakage. For example, the canvas element contains an attribute called origin-clean which indicates whether the content originates from a different origin (see Opera's explanation of origin above) or not. If the origin-clean flag is set to false, calling the toDataURL() or getImageData() methods of the element would raise a SECURITY_ERR exception.
- Geolocation: Geolocation presents a host of privacy concerns - you're pinpointing the location of the device and therefore the user. While not always 100% accurate, geolocation should be used sparingly, requesting location information only when absolutely necessary to improve the user experience. Proper warnings and terms must be included to make the user aware that you are storing location information and potential consequences. Broadcasting that you're home (GPS coordinates included) once a day for months and then telling the world you're in Maui on vacation may have unfortunate consequences.
- Forms: Javascript is client-side code and, as such, you lose a lot of control. While client-side validation, especially on a mobile device, can be powerful you should always validate form submissions server-side to ensure integrity. Yes, this may require an extra round-trip, on occasion, but if someone has malicious intent, I wouldn't worry if they eat another 120KB of their data plan.
- KeyGen: This is a post for another day, but HTML5 also includes the keygen element which facilitates the creation of private and public keys for identity verification - think enterprise security, banking, etc. You should note that adoption is not standardized, documentation is sparse, and Microsoft has even asked that it be removed from the HTML5 specification all-together. Here is one link I found useful if you're itching to dig deeper.
Compatibility
Creating a web-based version of a mobile application is quicker and typically more cost effective to deploy than platform native applications. Firstly, you don't need an in-house Objective-C developer and iPhone OS (iPad/iPod included) API guru, Java developer, and someone versed in the cumbersome Blackberry API's. HTML5 web-applications, simplistically speaking, require a web developer and web designer. Secondly, you don't have a platform specific approval process to battle. Consider the source, but even Google's VP of Engineering points out that not many companies are rich enough to build native apps in support of each mobile platform.
That being said, there are compatibility issues to consider when looking at HTML5 for your mobile application. HTML5 is still in draft status and is not supported by all mobile browsers. Mobile Safari (iPhone), the Android browser support quite a few, but not all, changes in the HTML5 specification. Opera Mini supports some (currently, around 10%) but is constantly evolving and was recently approved for use on the iPhone. IE Mobile 6.0 still doesn't appear to have much support for HTML5. I'm still researching what will be available as part of the new Windows Mobile version 7.0, but am not holding my breath.
Blackberry is beginning to implement some of the specification (e.g. the datalist element), in some of it's browsers but it's still not ready for prime time. With multiple versions of their browser running on multiple versions of the OS, building for the Blackberry will be challenge. This has been heralded as one of the biggest obstacles for HTML5 to overcome in order to go mainstream. In my humble opinion, as Android and the iPhone continue to gain market share, Blackberry will pick up the pace of innovation.
In the mean time, creating a lighter version for Windows Mobile and Blackberry, while frustrating, is an option. Another potential option would be to deploy Opera Mini to your Windows and Blackberry devices. It runs on each platform and, while it only supports about 10% of the specification now, it is evolving. Remember, Opera was a core contributor to Web Applications 1.0.
If you're interested in discussing how CapTech can help mobilize your enterprise, contact Jack Cox, the Mobile Service Offering lead.
© 2011 CapTech Ventures, Inc. All Rights Reserved. Legal Notices.