Ivan Ristić has an excellent blog post about fixing session hijacking. He is absolutely right that the current hack to add state in web applications absolutely sucks. Storing session information in cookies means it will be stolen from some users, either because HTTPOnly wasn’t used and an XSS flaw allowed for a simple query of the cookie, or it was used and an XSS flaw allowed an attacker to query the response from XHR to get the cookie, or because it was tacked on some place it shouldn’t, or a million other web based attacks. Just as likely, a great deal of malware these days actually scans infected machines and harvests cookie data (since both IE and Firefox keep all of it in the clear in predictable locations). Cookies simply are not secure, so it is silly to store secure information there.

I like the idea of adding it to the encrypted transport layer, as it already manages state anyway. I do think there are some challenges there, particularly when it isn’t the web/application server managing SSL but instead a third party appliance, but it would be a much more secure way of tracking state. The DOM has no access to that, malware on the client system would have a much more difficult time getting that data (it could conceivably configure itself as an SSL proxy, but that is a non-trivial task), and whenever session information is being transmitted the connection should be encrypted anyway.

More worrying to me than sessions is the fact that the vast majority of authentication on the internet is a lie. It does not authenticate an individual, as most think, but rather it authenticates two pieces of trivia associated with a particular account. There is absolutely no assurance that a person using a particular userid/password happens to be the account owner, especially when the userid might as well be public data on most websites (it is either visible, or an email address that can be obtained many ways).

For the average, non-paranoid net citizen, there are hundreds of ways that those two pieces of trivia can be disclosed. Most disclose the same two pieces of trivia whenever they register or sign on to a different site. Some sites, like LinkedIn, actually prompt for the trivia to access other sites (yes, give LinkedIn your login to hotmail, gmail, facebook, etc). Phishers, SMSishers, etc all try to trick people into disclosing the trivia. Every company that hosts the trivia can be a source of breech for it. Dozens of applications exist to guess the trivia. It is inherently a weak and fragile mechanism that is ineffective at assuring identity.

Some companies, like PayPal, are concerned enough about this that they hand out rotating tokens. This is good security, for a handful of sites, but between paypal, my bank, and my VPN token for work I think I have reached my limit of tokens I am willing to keep track of. I know RSA is thrilled about the idea of all big websites giving users tokens, but I sure am not.

Microsoft recognizes this. Craig Mundie gave a good talk at RSA this year about enabling end to end trust- how the client can authenticate who the server is and the server can authenticate who the client is. Most people who misunderstood this thought it would be a return of Palladium (which they focus on protecting DRM, rather than in general the protection of system integrity which was actually the point. Yes, it could protect DRM, but it could also make sure something like Windows Update wasn’t compromised. The problem with security is that it can be used to secure things people don’t agree with) and flipped out, or thought it was some nefarious evil Microsoft plot for world domination (seriously, it is a business, not the villain in an bond movie). That’s a shame, because abstracted from Microsoft this is specifically the type of discussion and innovation that needs to be realized. We need a system that isn’t easily compromised that can identify ourselves to other parties, and vice-a-versa. An example of such a system is two way SSL, but that is not something that would be adequate for the usage scenarios of a human end user.

As an industry I think it is important that we shift to a new paradigm of authentication. I think we need to start talking about various models that can actually realize end to end trust. And unlike sessions and roll your own authentication, I think we need to stop using weak hacks and design it right this time.

~ Joshbw

So Microsoft and Apple are sparing over a flaw in Safari. The flaw allows drive by downloads of files onto a user’s desktop from a malicious website. Apple is calling it a feature request for a convenience functionality or some such BS, because apparently they don’t think a third party being able to force files onto a user’s computer is a big deal. Microsoft very much disagrees, seeing it as a great way to deliver malware. It happens to be just that, but that would require a two stage attack (you do need to get it to execute) which is why Apple doesn’t care (in general I think it obvious that Apple doesn’t care about security).

Ah, that is an unimaginative attack though. If one is interested in harm to individuals it can be used by itself to cause trouble. Say some attacker happen to hate the smugness of safari users and want to get them in some legal hotwater. They control an offshore webserver and dump a bunch of kiddyporn.rar files in a publically accessible directory. They name will get it flagged by Google immediately, who will turn it over to the FBI (both google and MS routinely do so) for monitoring. The FBI can’t do anything about it being overseas but they can watch all US traffic that hits it so they can track down pedophiles domestically. The use of a .rar file was to make sure it was something that typically doesn’t have a mime handler associated with it, but is commonly used to distribute archives of data among warez sites and the such, so that safari would automatically download it. The attacker also posts a small web page with exploit code on it to trigger downloads in safari. They then go to a bunch of apple specific sites that allow community feedback and exploiting one of the myriad of XSS vulnerabilities likely to be on the site they inject a CSRF attack that sends a fraction of the visitors (so as to not send an abnormally high amount that would trigger the FBI’s scrutiny) invisibly to the exploit site.

Now the FBI has a whole host of people to start investigating, and even if the person is ultimately exonerated, it is going to cause them some headache. Granted this whole scheme is pretty convoluted and far fetched, and would need to be executed exceptionally well, but I use it to show that the execution of malware is not the sole concern here. Simply receiving data you did not request can be dangerous, and that makes this a vulnerability.

Also, any decent SDL would have caught this vulnerability quite a while ago, as it appears that it is by design. Hey Apple, maybe you might want to start embracing the message you put across in those ridiculous commercials.

~ Joshbw

GNUCITIZEN has an article on Live Mesh up, a product I have been thinking about as well.  Some folks like Joel Spolsky seem to think it is a failed idea to begin with, but from a user standpoint I have been hoping for a seamless means of synchronizing data easily across many devices, which is exactly what Live Mesh ultimately hopes to do.  I have used several solutions in the past, everything from the SyncXP/SyncVista power tools, to custom scripts that first synchronized to xdrive and then skydrive.  All of the solutions sucked for various reasons, and from my experience with Live Mesh, many of the things I have hated in previous solutions have been mitigated.

There are multitudes of security concerns with the product though, but I think GNUCITIZEN misses many of these:

1) It is based on Microsoft Live ID. This means that if someone hacks into your WebMail they essentially hack into your network as well. Cross-site Scripting attacks does not look that harmless now, do they? That messages is intended for all haters.

2) It works form the browser using SilverLight. This means that everything is accessible via the reach GUI environment of .NET. Sweet! Files, documents, etc.

3)It uses HTTP enhanced RDP to provide remote desktop connectivity. As the video on Channel 10 suggest, It bypasses the firewall! Now this is interesting. I wonder how my RDP shell injection attack will work here.

I think these three things are blown WAY out of proportion.  Point 1) seems to not understand how Live ID works.  It is really a glorified token granting service similar to kerberos.  It does not grant a unified sessionID that would allow the whole federation to be compromised by stealing the session out of the cookie (the cross domain restrictions on cookies would be an issue that would prevent a third party session ID from working to begin with).  Compromising one website to steal the LiveID token would not translate into compromising all LiveID websites.  In terms of XSS, Live Mesh has a very limited attack surface, so it is probably going to be quite difficult to get its specific LiveID token for a user.  

Now I think single sign-on is a really bad idea in general anyway, but not because to the fear of stealing sessions.  It puts all eggs in one basket- if the credentials are ever compromised then the user is screwed.   Phishing is my great fear with SSO attempts, though CSRF is also quite worrisome (as the chance that the user is logged in increases).  Having played around with Office Live quite a bit, MS seems to be expiring sessions fairly often to mitigate CSRF though.

I don’t understand point 2).  Yeah, the experience is much richer, but it is also sandboxed a great deal more than something all ajax-ified.  By this I don’t mean sandboxed from the system, but rather from the browser.  It puts a logical boundary between the application and the browser.  From a user experience standpoint this isn’t always great, since it presents the experience of another application that just happens to be open in the browser tab, rather than an application integrated with the browser functionality (which is why I HATE 90% of flash sites).  From a security standpoint, assuming no vulnerabilities in this boundary, the application is more protected from typical DOM focused attacks. 

Point 3) isn’t a new issue.  RDP already has firewall exceptions in its current state, it doesn’t really matter that it is going over port 80 rather than 3389, other than the traffic may not be as heavily scrutinized as it would otherwise be.

So those issues aren’t what bothers me a great deal.  They could be vulnerable, but I think that is less likely than with traditional web apps rather than more.  What bothers me is that the attack surface for this thing is HUGE for a consumer.  Every synchronized client, as well the website, are potential attack points.  The threat model must be crazy.  Moreover, the setup is a great way to propagate viruses (infect one file, have it auto-synchronize) to all of a user’s machines (and potentially smart devices), and while MS likely scans files for malware it necessarily has to be signature based (Skydrive and Office Live both do I believe, so that neither service can be used to distribute malware).  Signature based scans, like all blacklists, sucks.  So I think there are a lot of concerns with the product, things researchers should look into, but traditional web application attacks aren’t the most glaring worries in my mind.

~ Joshbw

My coworkers and I were just BSing about CAPTCHAs and how to make them harder to crack while still usable.  Tangentially the conversation just previously was about the bastards that injected a highly animated flash file on an epilepsy forum (which is messed up), and my mind drew a random connection between the two.

I wonder how hard it would be for automation to break an animated CAPTCHA, for example a small flash file that loads the text dynamically from the server (so there isn’t even the overhead of generated a dynamic CAPTCHA image) and slowly scrolls the text across, never showing all of the CAPTCHA text at once (though immediately a concern is the text could be intercepted in transit; it might be better to dynamically create animated GIFs on the server).  The implementation for this obviously needs to be much more complicated than that simple description; it has to cover attempts to compromise the CAPTCHA system without needing to do image processing.  However, if the attacker was forced to do image processing, how much of a speed bump would the animation create?

Any image processing gurus happen to know?

~ Joshbw

Two posts in a day, I’m on a roll (well not really; most posts I complete the night before and read over again during the day, before publishing, when I am lucid and not splitting attention between what I am writing, an attention hungry five year old, my wife, and an affection demanding but otherwise clueless cat. This is one of the few posts I am actually composing while at work before I forget about it). Anyway, having just finished complaining to my coworkers about yet one more site that seems to be using stupid security questions for their forgot password functionality (not one of our company sites, we have pretty strict security standards regarding when questions are even acceptable and how they are implemented, generally stricter than this post pleads for) I feel the need to share some advice with the random folks that occasionally stumble in here.

There are several things to keep in mind when creating security questions, but mostly they should be easy for the customer to remember the answer to (and please use a tolower call on both the provided and stored answer before comparing people, I don’t want to remember which case I used) and very hard for an attacker to figure out.  The number of websites that don’t get this right are staggering.

To start with the last criteria first, security questions should be hard for most attackers (I say most because if a close friend/family member is the attacker there aren’t very many questions that would meet the first criteria that the attacker either wouldn’t know or couldn’t find out).  This means the question shouldn’t have a very limited possible answer set.  “What is your favorite color?”- well lets try blue (apparently the color most likely to be a favorite in America.  Good branding job democrats), red, black, pink, green, purple, grey and orange.  We could go further in depth, but those are the most prefered colors in the US (I have no idea if it is a cultural thing, or if by extension the rest of the world shares a similar ordering) and cover the majority of the population.  That can be brute forced very easily.  Likewise questions along the lines of “How old were you when…”, “What grade were you in when…”, “What is your favorite movie genre” and so forth all easily brute forced because most people’s answers fall into a predictable and small set.  Questions like these lend themselves very well to automated attacks hunting for credentials.

Questions that are easily publicly discoverable are also a bad idea even if they otherwise have a much larger brute force dictionary.  Questions about a person’s family (father’s middle name, mother’s middle name, etc) can easily be discerned through the various family tree websites.  Questions that could easily be gleaned off of a person’s myspace/facebook/whatever page are also a bad idea since most users of these sites use their real names and are easily found doing a google (or yahoo or live if you swing that way) search.  Most profiles on social sites list favorite band, book, tv show, etc, but also things like high schools and colleges.  Using questions that are easily publicly accessible makes it easy for attackers to compromise the system with nothing more than google searching for details about a known user (they don’t work great for blind attacks though).

As for the other criteria, that the answer should be easy for the user to remember, this acts more as a constraint for how esoteric a question can get (if they have to think about the answer when filling out the field initially, they probably won’t recall what they said when prompted) than as a genuine security concern.  If the user can’t consistently answer their own security questions the feature is pretty pointless.  One of the things to keep in mind is that even general easy to come up with answers can eventually become hard to remember.  Current “favorite whatever” questions are susceptible to the user changing their mind.  For example, a person’s favorite television show tends to change over time, and they shouldn’t be forced to recall what their favorite whatever at the time they signed up for an account.

So what are good security questions?  Here are a couple I have seen and liked:

• Who was your best friend in kindergarten?
• Who was your first significant other (though not so great for people who married their first SO)?
• Where did you and your current SO go on your first date?
• What was the name of your first pet (I actually like when this is more specific to cat or dog, since many people had both simultaneously; it is easier to recall the answer)?
• What did your mom/dad do for a living when you were born?

Not all of these questions apply to everyone but they have the benefit of being fairly hard for a stranger to discover without being overly hard for the person to remember.  As mentioned though, they will not apply to everyone, which is why the user should be presented with a list of secret questions and are allowed to pick a subset for their own security questions.  The list should be broad enough that everyone should be able to find a couple applicable questions.

Venturing further there are other ways to improve the forgot password functionality, such as requiring a user to answer multiple secret questions to further mitigate against data mined attacks.  Ultimately such questions will still likely be susceptible to attacks by close acquaintances and disgruntled family so developers need to weigh the risks and business requirements when deciding how strict to be with the functionality.

So please various web developers, stop using weak questions, and please for the love of whatever you hold dear, don’t display the password to the screen or allow a new password to immediately be set after the questions were answered.  Emailing existing passwords is also not a great idea.  Setting a new random temporary password (by temporary I mean with a timeout as short as possibly can be acceptable by your application sensitivity and business cases) that gets emailed and requires the user to change on first login is probably a good practice.  For very sensitive applications the widespread “forgot password->secret question” paradigm might not even be strong enough, nor am I advocating this paradigm over another.  I am simply asking that if it is what a web developer chooses that they can take some steps to make it less vulnerable than I typically see.

~ Joshbw

It is common practice for security professionals to recommend that a website disable browser autocomple (credential caching) on authentication screens.  For example, OWASP says the following about authentication:

Browser Caching – Authentication and session data should never be submitted as part of a GET, POST should always be used instead. Authentication pages should be marked with all varieties of the no cache tag to prevent someone from using the back button in a user’s browser to backup to the login page and resubmit the previously typed in credentials. Many browsers now support the autocomplete=false flag to prevent storing of credentials in autocomplete caches.

This seems like perfectly valid advice since doing otherwise puts a substantial number of users on shared or public machines at risk.  If I use the same machine account as Chuck and Chuck compulsively clicks “yes” to IE nagging him about caching credentials (btw browser makers, the default answer that a user would compulsively click on should probably err on the side of security), when I use IE and visit a Chuck’s bank website IE will kindly fill in the credentials for me.  This would be bad.  Likewise, if a laptop were ever stolen and the user account on it was easily compromised (for example, the machine was in hibernate and the user didn’t configure Windows to require a password when being restored from hibernate), if autocomplete was used the user’s web credentials would also be compromised.

However some unrelated train of thought has lead me to feel that caching credentials on a private machine may not be such a bad idea, or more precisely that there are positive tradeoffs.  Most people only use at best a couple different credentials, as it is a pain for them to remember the variants and the associated websites (for example, my compulsive differentiation of credentials always comes back to bite me on rarely visited websites, especially since I don’t provide consistent BS answers to what my favorite color is in the forgot password functionality.  I know I didn’t write down a color, but I don’t remember what I did write down).  The problem with only using a limited credential set (and incidentally the problem with single sign on and federated websites) is that if any credential is compromised that will likely allow the threat agent access into many unrelated accounts.  For example, if I only used one or two usernames and a paypal phishing scam bit me, the attacker could very likely log in to my bank, into amazon, and so on with the same credentials (well to be clear, as previously mentioned, I use many passwords, often to my dismay, so on a personal note, the attacker would get very little).

By enabling autocomplete it makes it easier for users to use different credentials on different websites.  The browser can be in charge of remembering all of the variations rather than the user, and if any one credential set was compromised then only one account with one website is affected (unless it happens to be the credentials to your gmail account, where the attacker could just do a search of your email for all of the helpful companies that disclose your password in email).  An idea I have been kicking around is having an “This is a private computer, Enable browser caching of credentials” checkbox (with a corresponding “what’s this” link to explain the risk to users) that when checked sets the form to allow autocomplete.  That way, by default the credentials are not cached but if the user is confident that they can protect their machine they can choose to enable the functionality and thus successfully manage a larger collection of credentials with ease.

Thoughts?

~Joshbw

In the past post I ended up having a discussion with the Opera developer I linked to.  Obviously Opera has some bad blood with MS, but if his complaints are true (namely that MS has been mum about deviations it was planning, despite chairing the HTML 5 WG) I do think he is justified.  I don’t think standards bodies are great at considering security; ultimately most of them tend towards a democratic discussion process, is a nice way of saying the majority get their way.  Security tends to be the minority voice in the tech industry in general, and it seems this holds true among voting members of standards bodies as well, so it follows that as the minority voice it will often be overlooked.

That said, MS has a great deal of influence being the predominant browser manufacturer as well as the chair of that particular WG.  I feel they have the responsibility to disclose when they are going to deviate from the spec for security reasons and clearly articulate their rationale, as they could have huge influence either changing the standard, or getting the other browser manufacturers to follow suite despite the standard.

As an aside, when I get a spare moment this week I’m hoping to get involved in a couple discussions with the WG about concerns I have.  I can’t really complain about security concerns when the WG has an open discussion list for the public to voice issues.

~ Joshbw

Hey MS, back in the day I used to be able turn javascript off, but IE 7 certainly doesn’t have that feature and I didn’t see it in my look through IE 8.  It would be great if there was a “Paranoid” mode in IE 8, similar to the great NoScript plugin for firefox, that allows me to selectively enable javascript for sites that make heavy use of it (“Paranoid mode” might not be an overly marketable name, so feel free to change the terminology).  You could expand the functionality to granularly block other potentially dangerous functionality, like images and other requests made for offsite resources (in blog comments and forum posts I have seen plenty of XSS attacks based on this), as well as disabling ActiveX controls and other <object> tags on certain websites (considering the number of quicktime/PDF remote exploits I don’t really like the idea of autoloading media in third party players for example).  It would be even better if I could enable this functionality with either a whitelist or blacklist of sites.

In other news, kudos on finally having a decent DOM inspector and javascript debugger!

~ Joshbw

 Update: Yeah, security zones can allow me to do this sort of thing, but it is a pain in the ass.  If I want to lock down my default internet zone to disallow javascript, and then find a website that I want to enable javascript support for, I have to go through tools->internet options->security->sites and add the site to a trusted zone, which isn’t anywhere near as easy as NoScript enabling script for a certain website in FireFox.  It also changes my definition of “trusted site” from one that I trust implicitly with just about any action, including running ActiveX objects unsafe for scripting, to sites I trust to have basic JavaScript support.  I’m not saying Security Zones can’t be modified into something that fulfills this functionality and makes such use practical, but they were not designed for it originally, and would need to be heavily modified with such use in mind.

I’ve only spent an hour or two now with the IE 8 beta, not really enough time to get a real impression of it (there seems to be some nice GUI functionality changes, not much to say on the “standards” compliance yet).  I was happy to see that the new cross domain version of XMLHttpRequest (XDomainRequest) doesn’t send cookies.  When MS first hinted at this feature I was pretty wary.  There is already an XSS method to steal cookies even when HttpOnly is set on the cookie, you essentially make an XMLHttpRequest to the site and read the response headers, but the limitation of this is that you really need to embed this on a web page hosted on the same domain as the source you are making the XMLHttpRequest to (since XMLHttpRequest doesn’t really function all that well across domains).

My concern with cross domain requests was that it would be possible for random attacker Bob (in my world Bob is the generic nefarious individual, much to the consternation of Melinda Gates) to use this same sort of attack, but embedded on completely unrelated webpages.  Cursory examination seems to suggest it won’t be that easy.  There actually seems to be some sort of negotiation necessary just to receive any content.  I’m waiting to see the official MS documentation so I have a better idea what I am doing with the API (more specifically, so I know enough to then try and break the safeguards, because I would rather report a break now and get MS to fix it before they exit beta).  It seems someone else has the same idea, which is good.  I could see a lot of room for abuse if a flaw is found in this scheme so hopefully the security community will do a good job pounding on this functionality before release.

~ Joshbw

UPDATE: for those who want to play around with IE 8 but don’t want to overwrite IE 7 (or 6… please upgrade if you are on 6), MS has free virtual PC images available that already include IE 8. Virtual PC 2007 is needed to run them, but it is also available as a free download and completely rocks as a workstation VM.