A couple months ago I had a bit of an argument with an Opera developer. He was critical of MS with IE 8, because IE 8 will not pass cookies when doing a cross domain XHR. Like everything from Opera the argument is that it deviates from the standard, and as they like to toot their own standards compliance horn as their marketing message this is pretty much their primary form of criticism against any browser. I had a problem with this, because the concept is inherently flawed and I do not believe that standards (and lets be clear, when they say standards, what they mean is specifications, and not even very well written specifications) should be blindly followed when in contrast to security considerations. This could diverge into a general rant that I have about the W3C not being an effective body to begin with, producing neither horribly useful documentation, nor having an appropriate method to settle on specification to begin with, but I will save that for a later date.

Anyway, Cross domain XHR that passes cookies allows for private data to be retrieved off of remote sites, which is problematic because it only provides a mechanism to authenticate the user (and not a particularly strong one) but no means to truly authenticate the original site who served up a web page with the XHR (oh sure, you could check referrer headers and other such details, but the integrity of those are always suspect; it also increases the impact of XSS). It enables client proxies to 3rd party websites by design; website A asks client to retrieve data from website B for it. There is already a mechanism for two trusted domains to share information; federation and webservices. That way both endpoints as well as the client using the browser can all be authenticated. Yes, this requires more work. Doing it correctly always requires more work than doing it wrong.

Some websites will implement this all correctly- they will be very careful what data they let slip, what actions are exposed to cross domain XHR- but most will not (come on, they can’t even get input validation on their own forms right). It is like justifying the continued use of strcpy in place of strncpy because it is possible to use it correctly and it is just a pain to force developers to specify the buffer size. We as an industry know that we should ban strcpy, because even though it *can* be used safely, it is very common for developers to make mistakes with its use. The same can be said with cross domain XHR- it can be used safely but there are better methods available that inherently enable the developer to be more safe.

Anyway, I bring this all up because Window Snyder of Mozilla fame announced at Blackhat that, while it was pulled from Firefox 3 for security reason, Cross Domain XHR will be added back to Firefox 3.1 and pass cookies. I was very much hoping that both IE and Firefox would implement a safer XHR that did not pass cookies when going cross domain, but it appears that only IE 8 is willing to err on the side of security. That’s too bad. Fortunately NoScript will probably come to the rescue but I am really tired of having to rely on third parties to provide security for something that should be there from the start.

And Opera, sorry, I never was confident you were secure, especially since you don’t freaking star out password fields on your blackberry client, and the Cross Domain XHR only exacerbates things.

~ Joshbw

There are some interesting posts coming out of the IE 8 team on security and I think it is heartening that the two major browser manufacturers are viewing security as a competitive feature (now if only Safari would…). The big news seems to be the default XSS filter to protect against reflective XSS. You are still screwed with persistant XSS but at least we are making ground. There has been some noise that MS is just aping features from NoScript, for which I say, GREAT! One browser shouldn’t be bared from a great security feature just because someone else thought of the protection earlier, and this has the benefit of being installed by default (if what happened in one browser was blocked from other browsers the whole XHR wouldn’t exist; that was an MS innovation after all, even if it wasn’t native).

The blog posting has several folks that are worried about false positives, but I think they either don’t understand how reflective XSS works, or they are concerned that their insecure webpage will be broken. The filter seems pretty simple; if content in a request is echoed unsafely in the response it is flagged. Just because some webpages echo intended content that way does not mean that they shouldn’t be flagged. I think the “false positives” might actually be a selling point as it will point out to web developers where they have been remiss.

Just as interesting is the smörgåsbord of security controls discussed in the follow up post. I’m sure MS will probably catch flack for deviating from the standard, but my hope is that the functionality becomes the standard. Good client side input validation functions (toStaticHTML) are a great idea, as are many of the other features (I wonder how secure anyone can make mashups though; they are a fundamentally horrid idea from a security perspective).

Anyway, let the race to a more secure browser commence. Competition is good for everyone.
~ Joshbw

Ars Technica has an article on four things that need to be fixed to secure the future of the web and I find it a horribly depressing list. The only marginal nod for security is security considerations in integrating JSON fully into the gecko rendering engine.

I think this points out a fundamental issue with security on the web; web developers just don’t think about security. It isn’t on their radar. The list is four things that web developer want to do “cool things” with, but black hats are going to be equally happy to do “cool things” with the technology and no thought has been given to that.

Instead of the list provided, I offer more generic fixes I would love to see to ensure a bright future for the web:

1) A truly stateful protocol replacing the stateless HTTP and the cookie session ID hack that we are using now. The current system is fragile and easily compromised; it is the definition of kludge but everyone goes along with it.

2) End to End trust, not based on trivia. Forget usernames and passwords; let’s develop a means for the server to verify the identity of the client and vice-a-versa, to kill phishing sites and role your own retarded authentication/forgot password scheme. What we really need is the equivalent of two way SSL, but in a more portable scheme for end users.

3) simplification of the tiers. Complexity is the enemy of security (I have a lot of enemy/bane/unfriend of security criteria, but complexity is definitely one) and the tiers have seriously made things complex. I have an HTML event trigger a javascript function that makes an XML request to a JSP that communicates to an EJB which performs an RPC to a mainframe to ultimately execute SQL, and then backtrack. There are so many points of failure in this scheme that I feel like weeping.

4) Make people care about security. I really want to go off on the dynamic languages, since they are all about speed to market at the expense of good, secure, code, but the real issue isn’t the languages but the mentality that speed to market can’t afford secure practices. We need to make executives and developers and marketing and customers really care.

so what are your top 4 for things to save the web?
~Joshbw

We all encounter websites that accept user generated comments and this is often a a source of cross site scripting. In the past couple of weeks I have contacted two larger websites about this. In many cases there is a simple solution- whitelist input validation (which becomes slightly more complex if supporting internationalization) and output HTML entity encoding.

In ASP.Net a simple call to System.Web.HttpUtility.HtmlEncode will handle the output encoding for you. I actually like PHP’s htmlentities function a bit more, as you have control over how quotes are encoded and can additionally choose a character set (I very rarely can praise PHP over ASP.net, but they deserve credit for that). Java apparently doesn’t have a native method for entity encoding, which is dumb, but the nice folks at OWASP have provided a method. One caveat, like much of the OWASP material it is very UTF-8 centric, so it is less than optimal for international support and alternate character sets.

The problem is that many websites like customers to be able to supply some HTML that does render. Social networking sites love all the nice HTML based output that a billion online quizzes generate, and users like to be able to have some formatting other than plaintext (wiki does this right with their custom markup). That shoots whitelist validation of characters right down, and prevents entity encoding. Instead it requires custom parsing to validate which tags are used, and further parsing to make sure they aren’t used in a dangerous way. For example <a href=”something” onmouseover=”alert(’Give me a cookie’);”>this is pertinent </a> needs to be parsed to make sure that nothing malicious was in the legitimate attack. It isn’t as simple as just blacklisting any use of on* to stop events, since many of these sites want style tags to be used as well (I can’t imagine why, someone can do serious defacement this way), and good ol’ IE has this nice Expression value that can execute javascript inside of the style (the problem with this microsoft, is that the only people who use it anymore are people misusing it).

When one includes all of the myriad of ways to use encoding to obfuscate attacks, accepting selective HTML, especially if you accept more than just UTF-8 input, results in a seriously complex validation engine. Complexity is the enemy of security. Both of the websites I contacted (having used an isolated test area impacting only me- remember kids, it isn’t ok to do web vulnerability testing where you can ever impact another user) accepted some HTML tags and had flaws in how they validated them.

~Joshbw

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