My Security Planet » Tags

Feeds

13620 items (0 unread) in 75 feeds

WebSecurity

Security

SEO

Tools

Opensourcetesting.org News

5 items tagged "Mobile"

Related tags: Security [+]

Mozilla Webdev

Approaches to Mobile Web Development Part 4 – A Hybrid Approach

Posted: June 27th, 2011, 1:24pm CDT by Jason Grlicky

Tags: Mobile [edit]
The final post in a series of four. Previously, we talked about what it means to be mobile friendly, the Separate Sites strategy, and Responsive Design.

Silver bullets are hard to find in web development – you’re more likely to come across strategies that make the best use of a variety of techniques given the circumstances. This brings us to our third approach, which aims to avoid some of the shortcomings of the two previously discussed approaches by combining them.

This Hybrid Approach centers around breaking down mobile development into its three goals, and then applying the best techniques available to tackle each goal individually. I’ll present one potential combination of techniques as an example here, but different combinations will be appropriate under different circumstances. The most important concept to remember is that server-side and client-side techniques can be combined to fit your situation.

The Good

Responsive web design is great – right now it is the best technique available for making layouts look as good as possible in a variety of circumstances. If your mobile and desktop use cases are similar enough, this is definitely the preferred option for layout changes. However, it can be a pain to use client-side techniques to alter site content to fit the user’s context.

Luckily, we aren’t technically constrained to using client-side techniques here: another option is to use server-side user-agent detection to show the user the proper content. This keeps the complexity of altering content on the server side, but still allows our layouts to benefit from the flexibility and future-readiness of Responsive Design.

Using user-agent detection specifically for content and not layout also allows you to have a single URL for each piece of content that can adapt its layout to the user’s browser. This is generally thought to be a good thing. Instead of maintaining two completely different sites, we simply redirect users to pages for the content they care about. And since the design is responsive, you know that each page will look as good as possible on the user’s screen.

We can also address some of the performance problems with Responsive Design by incorporating server-side techniques. For example, an often-criticized point about responsive web design is that full-resolution images are sent to all devices, including phones that will show the images scaled down anyways. One such technique for dealing with this issue uses server-side user-agent detection along with the WURFL device capability library to send a properly sized image for the user’s device. A range of products are also emerging which provide this as a service. Of course, this technique suffers from all the downsides associated with user-agent detection, but even if it does not work, it is no worse with respect to performance than only using fluid images.

By combining the techniques listed above, we can get a mobile web development strategy that is both more flexible than pure Separate Sites and has better performance than pure Responsive Design.

The Bad

One downside of mixing approaches is that it can lead to an increase in the number of code paths, both on the client and server side. This can make it more time-consuming to develop than other approaches. With proper planning, though, the code can still be organized in a maintainable way. Another downside is that because this approach relies on Responsive Design, it typically works best on a new project or one that has an existing flexible layout, not as a retrofit. Similarly, because it uses user-agent detection, you will have to update your detection rules as time goes on.

When it is Right to Choose This Option

Combining server-side and client-side techniques is something that is always worth considering; there are so many options that one must just weigh the pros and cons of each individual technique employed.

In many cases, the added complexity of the Hybrid Approach is not even necessary. For example, you may not even need to adjust your content based on what actual device a user is using – just knowing if a feature is present on their browser is often good enough. This is something you might be able to discern on the client-side using Javascript feature detection. It can’t hurt to dig down and ask yourself which axis you are actually looking to adjust your content around.

We’ve talked about incorporating server-side techniques into a Responsive Design, but there are even ways to use the Hybrid Approach if your use cases for mobile and desktop are very different. You could, for example, increase the flexibility of your Separate Sites designs by incorporating media queries and a flexible layout. You may even be able to make your mobile site design adaptable enough to extend comfortably to tablets as well.

Examples

For our Web O’ Wonder demo site, we tried out a basic version of the Hybrid Approach, with positive results. We used some elements of responsive web design to give the site a mobile layout, along with user-agent detection to provide mobile-friendly videos and to re-order the demos if the user is on a phone. Feel free to check out the source code on github.

We could also be doing more development involving this approach very soon! In fact, one potential path for the main Mozilla site is roughly outlined in the “The Good” section above:
- Using user-agent detection, route visitors to a landing page for the Firefox version for their device.
- Every page on the site should look great at a wide variety of resolutions, being built with responsive design in mind.
- Future plans include exploring serving images based on user-agent.
So far there is not much to see for mobile, since things are still in the formative stages of development, but you can always watch the new mozilla.org grow up on github. We’ll be sure to update this blog in the future with our progress.

Summary

No approach is a one-size-fits-all solution. Web apps that want to heavily modify the content or user flow for mobile users should probably go for a separate mobile site. Content-oriented pages that won’t need to modify their content for mobile users will be pleased with responsive design. If you need to slightly alter the site’s message for mobile users, but want to reap the benefits of a responsive design, a hybrid approach may be your best bet. Decisions like these are at the heart of mobile web development: be specific about what you would like to accomplish, and pick a practical approach while being aware of the tradeoffs. Good luck!
Approaches to Mobile Web Development Part 3 – Responsive Design

Posted: May 27th, 2011, 7:07pm CDT by Jason Grlicky

Tags: Mobile [edit]
This is the third in a series of four posts on different approaches to mobile web development. Previously, we covered what it means to be mobile friendly and the Separate Sites strategy.

As a reaction to the problems associated with the Separate Sites approach, a relatively new idea (which is actually quite old) is growing in popularity: ditch user-agent detection, and instead make your page respond on the client-side to the browser’s capabilities. This approach has come to be known as Responsive Web Design.

The Good

Though it wasn’t initially proposed as method for creating mobile sites, Responsive Design has recently gained a lot of attention as a way of taking some first steps towards mobile-friendliness in lieu of a separate mobile site. With this technique, you may address two of the three goals of mobile web development:
- Presentation – Using a flexible site layout paired with CSS media queries, you can make your site look as good as possible no matter what size the user’s screen is.
- Content – By altering the content based on browser features detectable via JavaScript, you can tailor your message to the user.
There are some really nice aspects to this approach. Since it does not rely on user-agent detection, it is more resilient and future-proof than the Separate Sites approach. For simple sites, it can also be significantly easier to implement and maintain than other options.

The Bad

This approach isn’t without its limitations, though. Because content must be altered on the client-side with JavaScript, only minimal content changes are encouraged. In general, things can get very hairy very quickly if you are trying to code two separate sets of JavaScript to work with the same DOM. This is a big reason why web apps do not tend to adopt this approach.

Giving your existing site a responsive design is also going to involve a rewrite of your styles if the you are not sporting a flexible layout already. This could be a blessing in disguise, though; making your site’s layout responsive could be a good opportunity to modernize and clean up your site’s CSS.

Finally, since you are adding code to your scripts and styles, performance may be worse than the Separate Sites approach. There is not really any way around this, though a thoughtful refactoring of your scripts and styles might actually save a few bytes in the long run.

When it is Right to Choose This Option

As mentioned above, since content changes can be difficult, this means that when taking this approach you will not be able to give users a strikingly different experience on mobile without a significant increase in code complexity. That said, if the desktop and mobile versions of your site are going to be very similar, then this approach is a great option. It is well-suited to document-centric sites which have a primary use case that is consistent across devices, like product pages. You may notice that the examples below are all blogs or portfolios!

Examples

Though it is not as popular as the Separate Sites approach, there are more and more websites employing this technique every day. Luckily, since all the code is client-side, if you’d like to see how a site technically implements this approach, it is as simple as visiting the site and clicking “View Page Source.” Here are a few examples:
- [teixido.co] – one of my favorite responsive designs, also pictured above!
- [adactio.com] – also a good article to read, with its own links to examples
- [thinkvitamin.com]
- [stephencaver.com]
- [hicksdesign.co.uk]
Despite being a relatively young approach, there are already some emerging best practices. For example, if you are designing a site from scratch with this option in mind, it is usually worthwhile to create a small-screen design first, so that the constraints of mobile are with you from the beginning. It’s also great to use progressive enhancement for your styles instead of hiding elements of your existing site with media queries. This way, older browsers that might not support media queries will still show the proper layout. An excellent presentation on the merits of this method is available here.

Next Week

There’s got to be a middle ground between completely separate sites and one-site-fits-all, right? Luckily, we can combine server-side and client-side techniques to form a Hybrid Strategy, to be discussed in the next post.
Approaches to Mobile Web Development Part 1 – What is Mobile Friendliness?

Posted: May 4th, 2011, 1:06pm CDT by Jason Grlicky

Tags: Mobile [edit]

In this series of four posts, I’ll provide an introduction to the world of mobile web development by giving a birds-eye view of three different technical strategies. We’ll kick things off this week by examining what exactly it means to be “mobile friendly.” In the following posts, I’ll give a rundown of the different options for accomplishing this.

What is Mobile Friendliness?

Mobile friendliness can mean a multitude of things, depending on who you’re talking to. In my experience, I’ve found it helpful to think of it in terms of three goals for improving your site’s user experience: Presentation, Content, and Performance.

Goal #1 (Presentation)

“Make websites that work well on a variety of screen sizes.”

These days, I can access the web on devices in a wide range of form factors, including phones, tablets, and eReaders. Needless to say, a fixed-width, three-column layout filled with complex JavaScript animations and mouse-over effects is not going to look or feel quite right on a phone with a 2-inch-wide screen and a diminutive processor. A slimmed-down, linearized page layout with elements sized for a touchscreen would be much more appropriate. That’s why this first goal is all about presenting your content in a way that makes life easy for users on mobile device.

Goal #2 (Content)

“Adjust your content for mobile users.”

Think about what your users want to do at your site if they are on a phone. A great example of this is Alaska Air’s website. Their desktop site focuses on getting visitors to book trips. Mobile users, however, are probably more interested in checking-in for a flight or seeing if their flight is delayed. They’ve adjusted their site’s content to reflect this, and it meets the needs of mobile users.

Goal #3 (Performance)

“Give your users a smooth experience, even on a slow connection.”

Though things have been getting better in recent years, browsing the Internet over a wireless data connection can still be pretty painful. This makes it more essential than ever to practice good performance practices, only sending the user the bits they will actually need.

Note: Know Your Audience

While not strictly a part of my definition of being mobile friendly, defining who your target audience is makes these goals much more concrete. For example, it is absolutely critical to keep in mind which browsers and devices you will target when picking a mobile strategy. At Mozilla, we’re keeping our eyes on the future and focusing on tablets and smartphones with standards-friendly browsers as our target audience. On the other hand, if many of your site’s users are on devices with less capable browsers, that may eliminate certain strategies as viable options.

Next Week

As you’ll see in the following posts, different approaches aim to achieve each of these goals by different means. Join me next week to learn about the Separate Sites approach to mobile development.

Justice League

Moving to Mobile – New Threats

Posted: March 29th, 2011, 12:45pm CDT by jOHN

Tags: Mobile Security [edit]
This post written in collaboration w/ Jason Rouse

In the software development circles I travel, the topic of adding a mobile channel onto existing application/system infrastructure has come up a bunch recently. With regards to threat modeling a ‘move to mobile’ represents an ideal opportunity to revisit threat modeling. Remember, I don’t necessarily prescribe threat modeling for well-known system arch-types (such as classic n-tier) and technology stacks as much as when teams attempt new and lesser known architectures.

The natural question: how do my threats change when I bring a mobile channel into my existing application? Consider, for instance, a generic application, as depicted below:

Existing Application w/ New Mobile Channel

This application supported a User and CSR through a browser interface, and had other connections to RESTful services in its middle tier. Now, we’ve added more controller and presentation tier logic, perhaps opting to reuse almost all the former application’s model. In this case, the new functionality aims to provide a more numerous set of users (2-4X as many as the plain browser interface) access to their accounts and services but with considerably lower bandwidth. The intent is that a sub-set of services would be offered (rate comparison and ACH transfer being omitted) and all available services will be provided in a crisp, simple, and responsive format.

Since we’ve discussed this example (and many like it) in threat modeling classes, we’ll leave these users and threats to the original system alone for now.

New portions of the system, being constructed to support mobile, are depicted in blue. In a future post, we’ll discuss how to more clearly identify the change in attack surface due to these additions. For now, let’s just consider the new Threats themselves. Again:

Threat – A class of individuals or software agent executing on behalf of such an individual

When we model threats we describe a threat’s capabilities, level of access, and skills to start. Let’s apply a few of Threat Modeling techniques to identify new threats to consider.

1. Consider the system’s users
When teams add new functionality to a system, or when they start a new development effort entirely, they commonly create user stories or perhaps even detailed use cases and requirements.

The first (and easiest) way to identify new threats to the system is to mine user stories, use cases, and other usage documentation (even marketectures often work) for their users. Then, consider:
- What evil or insidious behaviors could a user engage in?
- What obnoxious or stupid behaviors could a user cause trouble with?
Two users come to mind as we look at proposed new mobile functionality:
1. Mobile device user (in this case, a smart phone)
2. Neighboring network user
Combining the first items from our two lists above, we come to our first threat: a malicious mobile device user.

1. Malicious Mobile Device User – Device users possess the credentials to the device (including any UI, ‘app store’, or other username/password tuples) and likely possess the carrier account/credentials. Access includes physical access to the device and use of both of its applications and browsers. This threat can install applications, sync, and explore device contents with their computer. Of course, this threat has access to device SDK and simulators as any developer would. See this threat depicted in the figure above with label “1″.

When we discuss attack surfaces, we’ll discuss what kinds of access and capabilities these threats possess in a technology-specific fashion. Some conceptual actions include:
- Transfer device contents to computer for debugging, reversing, etc.
- Install purpose-built (malicious) applications on device
- Manipulate application settings, set up a proxy for web interaction, etc.
- Use both browser and application to access the same services/resources
- Jailbreak device
Consider Evil/Insidious User Action
The last behavior piques particular interest. When the user decides, with malicious intention, to jailbreak their device, additional malicious behaviors are available to them. Regardless of whether or not the jailbreak was motivated by malicious intent, the device’s security controls are compromised. In this case, applications can no longer trust that security features such as application signing apply or that a confidential path for their data exists between the application and network. Documenting threats in a traceability matrix allows one to show this escalation of privilege from one threat to another directly:

In summary, this behavior gives rise to another class of threat:

2. Malicious Mobile Device – This threat has all the capabilities and access of a malicious mobile device user, but can also compromise or augment the device OS and its drivers. The figure above depicts this threat labeling it “4″.

A broad range of capabilities results from this opportunity and if a device is compromised prior to the a victim application being loaded, malicious behavior can observe and affect the application installation process itself, or user signup/registration processes–which may include initial credential/key material exchange. This imagined scenario may quickly turn an application’s entire security proposition into a house of cards.

Consider Obnoxious/Stupid User Action
Once you start, it’s hard not to imagine a multitude of stupid things a user could do with their mobile device. Let’s focus on a common and important one: the user could leave the device somewhere, for it to be stolen. This scenario has two effects: first, this dramatically increases the population of Threat #1: malicious device user. Let’s split this threat into 1.A (previously described) and 1.B: malicious device user (same as 1.A but without the user’s credentials). However, Threat 1.B also increases the population of Threat #2–malicious devices because thieves can jailbreak devices even without user credentials.

An important third scenario impacts certain applications, like the generic one we describe above. If our threat traceability matrix (above) was filled out during a previous secure design exercise, it might include “password reset” use described in the mitigation column. Indeed, during many threat modeling courses jOHN teaches his participants indicate “we can remove the malicious CSR threat entirely by doing password reset out-of-band using a mobile phone.”

In the case that a phone is stolen and possesses the bank’s MobileBankingApp, perhaps which caches the user’s name, how effective is this control?

Many password reset implementations jOHN observes (using his accounts) suffer full compromise under the ‘stolen phone’ scenario. In this case, the identification of a new threat causes us to reconsider or augment the design of our system so that it again demonstrates the security properties we desire.

A Brief Diversion into the Mobile Threat Population
Looking superficially at search results, it appears as though ~120,000 phones are stolen in the UK annually; ~200,000 in Australia. Another site indicated 26M phones are stolen annually and resold. Regardless of how accurate these numbers are, this represents a much larger threat population than expected from security researchers and nefarious parties alone.

Not Stolen, “Something Borrowed”

Consider more generally the notion of the device being “out of sight” interaction briefly, perhaps through the following vectors:
- Because stolen (unknown to the device’s user) and returned after being tampered with
- The device is plugged into another individual’s machine (perhaps for charging or for app download)
- Device lent to individual for momentary use (phone call, game demo, contact/weather lookup)
- Grey-market phone, donated phones, recycled/returned phones
Each of these cases exposes the whole of the device’s attack surface to exploitation without visual cues to the phone’s user.

And Who ‘Owns’ These Devices Anyways

This is perhaps a good time to point out that the phone’s user may not be the phone’s owner. Family and corporate phone plans often provide access to the phone, remotely, unbeknownst to the user. In these cases, the phone’s owner must be considered a (yet unpictured in our diagram) threat from the user’s perspective.

From the phone (or account) owner’s perspective, the user represents a similar threat: the user can potentially add/modify/remove software without visual cues or notification. Our ‘single-user’ device actually serves multiple masters:
2. Me
3. The Account Owner
4. Our Benevolent Dictators: Google/Apple… RIM/Microsoft?
5. Carriers: ATT, VeriZon…
6. Device Manufacturer
We know the benevolent dictators retain the right/capability to remove applications from our devices. What other capabilities must an application publisher be concerned about within their Threat Model?

Here in the diagram, you see the inevitable separation of the application store curator and the current set of benevolent dictators listed–Amazon’s new application store is a prime example.

Reconsider Old Model’s Threats
Having conducted a threat model on the classic n-tier system before, a man-in-the-middle (MiM) threat was undoubtedly considered. Reconsider this threat in terms of the new architecture.

A common mistake modelers make in considering mobile MiM is to forget that devices contain not only applications that make Internet connections but that they also possess browsers:

3. MiM – This threat has access to traffic sent over the Internet (OR carrier network) sent either from the app to server or
vice versa. When a device contains a browser, this threat can see both app to server traffic and browser to server traffic from the same account/device. This threat may be able to see traffic through (active or passive) interposition, or through landing code (script) w/in the device’s browser using classic web attacks (Depicted as Threat #4 in the figure above).

Whether or not one needs to consider both Internet and carrier-based sniffing depends on other factors within the threat model. Cigital has always considered carrier-level compromise part of its mobile threat model, at a low barrier to entry. However, it bears mentioning that as recently as 2004 it was challenge to convince organizations that individuals could “be the mobile network”. It’s somewhat vindicating to see this as a consumer-grade scenario now.

This isn’t the half of it though (and we’re getting ahead of ourselves a little bit in talking about attack surface here, but). Consider the following ‘radio-based’ surfaces on the phone:
2. GSM Stack
3. CDMA Stack
4. 802.11
5. Bluetooth
6. NFC (coming soon to a device near you!!!)
Remember, vulnerability in any of these implementations may cause our user to suffer a “drive-by owning“, leaving him/her with Threat #2: Malicious Device.

Other Old Threat
Taking another cue from former efforts, modelers must consider the possibility that malicious applications will run alongside their applications within a mobile device. This scenario is no different than that of a browser, or any application running on the almost forgotten host computer.

4. Malicious Application – Threat represents either a compromised victim application on the device, a Trojan, or other malware (depicted in the figure above as #3). The causal vector may have been data interpreted and executed by a vulnerable app, a malicious application placed in an app store (or otherwise available for download), or different entirely. Such applications (malicious or corrupted) can attempt to poke and prod at your victim app directly, exploit the underlying device OS, or focus on server resources directly. The malicious app may possess a valid signature (or not, as advantageous) and has access to the device’s services (as per what the user has granted it).

Summary
Hopefully, this thought exercise has shown its reader threats they hadn’t considered. Hopefully it shows the reader the advantages of reconsidering a threat model as the architecture changes through normal means:
1. Start with the users/user-stories
2. Think maliciously
3. Think ‘stupid’
4. Re-consider old threats in the new architecture
5. Understand, you’re not the only device ‘user’, ‘owner’
It continues to surprise me that these techniques pay off even when only threats (the ‘who’) themselves are considered.

Next, we’ll write up how consideration of the attack surface differs as we ‘move to mobile’ and begin to see how this expanded surface can have dramatic implications on the security posture of existing functionality.
With apologies to Peter Deutsche…

Posted: April 29th, 2010, 2:38pm CDT by jason

Tags: Mobile Security [edit]
A long time ago, when distributed computing was in its infancy, and the promise of new technology made early adopters of us all, a fellow named Peter Deutsche found himself pulling out his hair. There was, he reasoned, an unimaginable amount of positivity about this new “distributed” technology. Accordingly, Deutsche decided to record the “Fallacies of distributed computing” for posterity. Almost twenty years later, I think there’s still a lot of learning to be done.

At Cigital, I lead the mobile and wireless practice, and I often find myself in the same position as Mr. Deutsche. As I’ve watched the mobile industry grow over the years, I’ve seen a huge amount of optimism placed on the hardware and software that we’ve all come to find indispensable in our modern lives — the cell phone.

While I still remain optimistic, I’ve decided to pen my own “Fallacies of Mobile & Wireless” list, to spark some discussion and to get the industry rolling on some positive (and sometimes painful) changes.

The list goes something like this:
1. The (network|handset) is reliable
2. The (network|handset) is secure
3. Bandwidth is infinite
4. Users will accept buggy software
5. Handsets are homogeneous
6. CPU is unlimited
7. Users understand the risks to their privacy and data
8. Everyone has the latest hardware
Before you judge me curmudgeonly, let me say this: I have nothing but the greatest optimism for mobile and wireless technology; the benefits I’ve seen far outweigh the costs. However, I feel that it’s time to really set the record straight on some of the awful compromises that have been made. This is the beginning of an 8-part blog where we’ll explore each one of these fallacies, and tease out some of the group think that’s led us to the situation we’re in today, as well as some of the concrete actions we can take to improve the lot of mobile and wireless from the security, privacy, and, dare I say, reliability perspectives.

Let’s dissect the first idea briefly.

“The network or device is reliable”

The idea that we can make phone calls, browse the web, read our email, or watch YouTube has become a cornerstone of our mobile lives. Most of the time, things work pretty well. The nasty thing is, we predicate all of these things on a mish-mash of software and hardware over which we have little control. Application developers all over the world have been counting on the fact that network connections can be made, SMS messages will arrive safely, and that, in general, there will be few or no errors to deal with in the field. While this approach works well for media consumption (a la YouTube), we’re moving into dangerous territory as we begin to have ubiquitous banking, social networking, and other privacy-laden applications show up.

My hat is off to the wireless providers the world over, as they have generally been doing a great job of connecting us to each other for more than a decade. The biggest trick is that our general use of mobile devices has been undergoing a gradual but ever-accelerating change. We’ve gone from simple voice calls to short messages, and from short messages to multimedia messages, and from there… Well, we’re very close to having a highly-converged IP-based backbone with mixed traffic and an even larger universe of devices which can access it.

Does this worry anyone else? I don’t normally find myself sleepless over technology-related issues, but I do wonder how well both wireless carriers and mobile phones will cope with this eventual evolution. From network issues in large urban environments (Apple iPhone in Manhattan, anyone?) to guaranteed connectivity in rural areas , we have a lot of work to do to catch up to the needs of subscribers and the businesses who publish mobile applications.

The idea that mobile and wireless applications can simply abdicate their responsibility for error handling is quickly coming to an end. I hope that we’re ready for the tidal shift that will require us to learn our lessons all over again.

TOP RSS Gregarius 0.5.4 Tentatively valid XHTML1.0, CSS2.0 Last update: Thu May 24 12:14:11 2012

My Security Planet » Tags » Mobile

Feeds

5 items tagged "Mobile"

Mozilla Webdev

Approaches to Mobile Web Development Part 4 – A Hybrid Approach

Posted: June 27th, 2011, 1:24pm CDT by Jason Grlicky

Tags: Mobile [edit]

Approaches to Mobile Web Development Part 3 – Responsive Design

Posted: May 27th, 2011, 7:07pm CDT by Jason Grlicky

Tags: Mobile [edit]

Approaches to Mobile Web Development Part 1 – What is Mobile Friendliness?

Posted: May 4th, 2011, 1:06pm CDT by Jason Grlicky

Tags: Mobile [edit]

Justice League

Moving to Mobile – New Threats

Posted: March 29th, 2011, 12:45pm CDT by jOHN

Tags: Mobile Security [edit]

With apologies to Peter Deutsche…

Posted: April 29th, 2010, 2:38pm CDT by jason

Tags: Mobile Security [edit]