Aral Balkan

Writing about secure passwords in Buzzword got me thinking about the state of security and user trust in Flash (and Flex)-based Rich Internet Applications in general. After giving it some thought, I concluded that we have a little more work to do if users are to be expected to have the same sort of trust in Flash-based RIAs as they do for JavaScript and HTML-based applications and web sites.

The key security issue I see with Flash applications, especially those that deal with sensitive information, is that the user has no way of knowing whether or not the application is communicating their sensitive data over a secure connection.

In a traditional web application, on the other hand, serving the application over HTTPS makes the security lock icon display in the browser and thus alert the user that their data is being handled securely. If a traditional web application then tries to make an HTTP call, the user is alerted to this.

In the comments to my previous post, for example, I asked whether Buzzword sends my usersame and password over HTTPS and David Colleta replied that it does. Now I trust David, of course, but what mechanism does Joe User have to trust Jane Developer when it comes to how RIAs handle data in general?

The problem I'm describing manifests itself differently based on whether you examine how it affects users or developers:

Users: A false sense of security

A Flash-based RIA is served over HTTPS. The user sees the security lock icon in their browser and thinks that any data they provide will be securely transfered to the server.

Problem: Unfortunately, the security lock only means that the application itself is being securely transmitted. Internally, the application can transfer the user's sensitive data in clear text for the world to see via HTTP and the user would be none the wiser.

Developers: How can I say "this application really is secure?"

A developer creates an application that handles sensitive data and makes sure that every data call in the application is over HTTPS. The application itself, however, is served over HTTP and so the user does not see the security lock icon in her browser and chooses not to trust the application.

Of course, the application can tell the user what it's doing but again, the user would have to trust that the application wasn't lying.

As you can see, the current state of affairs benefits neither the user nor the developer.

From the developer's perspective, there is no way, currently, of communicating to the user that the application transfers data securely short of loading the whole application over HTTPS. And, as far as the user is concerned, an application that is served over HTTPS can still make HTTP calls and compromise the user's data without the user being alerted to this fact.

One possible solution

One possible solution to this is to have Flash applications that are loaded over HTTPS display a dialog box before attempting to do an HTTP call and to give the user the option to cancel the call if they want to.

A similar feature exists in browsers already where a browser will warn you if you are about to leave an HTTPS session using a dialog box that looks like this:

What I'm proposing is a similar dialog to warn users if a SWF that is loaded over HTTPS attempts to make an HTTP call:

This one enhancement should go a long way in giving developers a way of saying "this application handles your data securely" and help build trust in users.

I feel that this will become more of an issue as more RIAs start handling sensitive data like credit card details and I would love to see some proactive steps taken by Adobe to address it in upcoming versions of the Flash player.

Comments

• Hi Nathan, The problem is that _you_ are honest but we have to take your word for it. If only the whole world was full of people like you but unfortunately it's not. Instead we have people who snoop data on open WiFi networks, engage in phishing attempts, and write Trojans. This feature is one that those of us who _are_ honest should be pushing for. As I said in my article, it is meant to educate and build confidence in users. The more I think about it, the more I see it as a glaring security hole. @Brian: Unfortunately, even large companies can handle sensitive data poorly. You need only skim this data loss list to see that the weakest link is again, usually human error (a lost laptop, for example). That could very easily be a missing "s" in the code that sends your credit card information over -- it doesn't even have to be on purpose. And I'm not talking about scam sites here. This feature won't deter against that (but browsers are building in better tools for alerting users to phishing attempts, etc., in any case). This feature is simply to reassure users that they can still trust the "this page is secure" lock icon in their browsers with RIAs. The lock icon and HTTPS become meaningless for RIAs unless users know that the application is not going to make HTTP calls (and if it is, then the user should be alerted to this fact and have the option of canceling it.)

  by Aral on 2007-11-12 09:19:13

• Funny, I thought that HTTPS => HTTP communication was blocked by the Flash Player for this very reason. However, looking at the documentation for the security changes in Flash Player 7 (http://www.adobe.com/devnet/flash/articles/fplayer_security_print.html) I see that it was implemented the other way around - SWFs served over HTTP are not permitted to communicate with HTTPS domains, and even that can be overridden with a crossdomain.xml file. Aral: Did you actually try this out? I've never had need to serve a Flash movie over HTTPS, but I had assumed that the browser's security model would pop up the standard "this page contains insecure items" warning that you get when loading HTTP assets (images, scripts, css, etc) into an HTTPS page. If this isn't the case, then Adobe really should get together with the browser manufacturers and do something about it.

  by Steve Webster on 2007-11-11 19:18:36

• That's not a story for Adobe, it's the browsers that should close this gap.

  by micha17 on 2007-11-11 18:44:43

• It seems to me that the Player security structures are in place, nonetheless the very nature of Flash/Flex development puts the trust factor firmly in the power of the developer as all default structures can be overridden. This has its strengths and weaknesses, security features have a nasty way of becoming a royal PAIN IN THE ARSE. It also creates a dangerous precedent as information can be easily siphoned from apparently secure applications. Such an in-build alert into the Flash player to visibly state the change from HTTP to HTTPS and vice - versa would definitely improve the security of the player

  by aYo on 2007-11-11 19:56:17

• Hi Steve, I haven't had to do this in a while but I remember HTTP calls being allowed from SWFs served from HTTPS when I did have to do it a while back. The security docs also state that HTTP from HTTPS is permitted (the reverse, by default, is not but can be, as aYo states, overridden.)

  by Aral on 2007-11-11 21:02:25

• I think enforcing HTTPS communication when a SWF is loaded via HTTPS is a bad idea, since it would really get in the way of those of us who *are* honest. For instance, the product I work on generates two session tokens (one normal, one secure) for communication with the server. All safe/idempotent HTTP requests are made over HTTP with the normal session token, and all other request are made using the secure session token via HTTPS. The only non-idempotent request we allow over HTTP (using the normal token) is a FileReference.upload(), since we found the overhead of HTTPS for requests with binary payloads was too much for some slower clients. The security sandboxing of the Flash Player has taken up uncountable hours of my time, so adding another level of complexity wouldn't get my tick of approval.

  by Nathan de Vries on 2007-11-12 00:04:07

• I would say the whole "trust" issue (for me anyway) has far less to do with the secure icon than with the company I am dealing with. If I am shopping on a well known store site, Amazon, Gap, whatever, and they have a form that will take my credit card data, I quite blindly assume my data is going to be kept as safe as these companies can. Conversely, if I run across a funky looking site where I am thinking of purchasing from, I usually do a search to see if anyone has complained about that site. Scam sites usually are pretty easy to ferret out with a simple google search. Yet in each case, it is not the https icon I am looking for, I am looking for a company that feels reliable and solid. Because, in the end, even if I see the lock icon, I might feel as though my data got to the other end safer, but if the guys on that end decide to abuse it, well... Seems like it would be nice to be able to assure users. Of course, not if it just ends up scaring them away from Flash. The pop-up warning box should be in terms my grandma would understand.

  by Brian McBride on 2007-11-12 05:21:02

• Last time I saw a study done, the presence or lack of a padlock icon was either totally missed, ignored or satifised by a static .gif to the vast, vast majority of users. Browsers shouldn't punish the users of applications that are built poorly, when most people will click 'OK' to anything they are asked.

  by Tom Chiverton on 2007-11-12 10:49:18

• Just a little anecdotal note about users... I had a customer email me a few weeks ago asking where they could get to a secure order page. I was baffled because the order page was secure. Turns out it was because they were looking for the little lock icon on the page before starting the order process. Now... the page where they enter in the information WAS secure. But the page before that wasn't and they didn't dare click further. This was a great reminder to me that ordinary users don't understand security, when it's appropriate, and when it's safe to click on. It also reminded me that people do actually look for that lock icon. Unfortunately because of this I don't think users would ever understand those dialogs you presented. IMHO the flash player should not allow HTTP requests from a swf loaded over HTTPS. It limits applications but it doesn't impose any additional requirements on what users' understand to be "secure".

  by Marc Hughes on 2007-11-12 14:36:43

• I don't like the pop-ups. I think a nicer alternative would be to right-click on a Flash app and see a security status icon of either "Locked" (https), "Unlocked" (http), or two locks to express mixed communication. Less invasive...

  by Jason The Saj on 2007-11-12 14:40:16

• Hi Jason, The alert message would only display with an application loaded over HTTPS attempted to make an HTTP call. Having the user right-click (a hidden feature) to find out the security status would not solve this problem as most users would not know to do this. And what does mixed communication mean -- does it mean that it's loading a photo over HTTP or sending my credit card information? The alternative is to do what Marc suggested and not allow HTTP calls in SWFs loaded via HTTPS.

  by Aral on 2007-11-12 16:30:54

• Followup: Folks from Adobe have been reading this thread, and it has paralleled some prior internal discussions, but I don't know that they've reached any resolution yet, much less a deliverable. It's on the radar, though. jd/adobe

  by John Dowdell on 2007-11-30 22:55:49

• Cool, John, thanks for the update! :)

  by Aral on 2007-12-01 00:26:57

• Flash works in the form of browser plug-in but unlike the browser itself has no visible system areas such as status bar in the browser. Thus, the plug-in could easily display the security sign (the lock) but has no place for it. Displaying it in the app itself is a deception since the user has to trust the app in this case (and hey, all we see is a bunch of pixels on the screen anyways!). The solution could be Flash plug-in communicating secure connection status to the browser (absence of such or possible warnings). I think this is better option because Flash "knows" about all the browsers but browsers know little about Flash. Hey, Adobe - Make it Possible! (or MS Silverlight will do it first).

  by Micael Pastushkov on 2008-01-25 17:53:45