It is now Joshbw, CISSP. I don’t think the cert says a great deal specifically about my App Security knowledge, that being a ten mile wide, inch deep sort of certification. The test wasn’t any less a pain because of it though, and at least it says I have the fortitude to make it through the long nights studying the optimal height and candle power of external lighting, how far away backup facilities should be, 8 million different security models, and what the initialization vector length of each encryption algorithm happens to be.

~ Joshbw, CISSP

Ars has their panties in a twist because Kevin Turner dared to suggest that vista is more secure than OS X or Linux. The thing is, from one point of view, Kevin is absolutely right, but from other points of view he is wrong, which just points out the general failing that keeps popping up among security folks: How on earth do you measure security?

When talking about security there isn’t a clean metric.  You have

Vulnerability: Software (for this purpose) weakness that provides a door in
Threat: danger that someone will find the vulnerability
Risk: the likelihood and cost of the vulnerability being exploited
Exposure: time that a vulnerability remains

Companies/orgs love to cherry pick which one they go off of.  Firefox is big on touting their low exposure while being horribly quiet about the number of vulnerabilities.  Microsoft is big about vulnerability (and to some extent exposure, at least on the OS level) count, since they do have a much lower count then competitors that don’t have a decent secure development lifecycle (which would be Apple and most of the OSS projects), but they don’t like mentioning risk because they have more risk than freaking anyone.

The problem is, all of these approaches are at least a little right.  Sure the risk is huge on windows as a whole, but if you install patches quickly your risk is actually pretty low, and with a lower vulnerability count there is less likelihood that someone will release a zero day for a vulnerability that isn’t patched. Mozilla is also right about firefox being more secure, as the fast patch and deployment rate means that zero day isn’t going to remain a concern long (except that they have been a little too quick pushing patches and have regressed things on a number of occassions), but their higher vulnerability count does mean zero days are going to crop up more often.

The only stance that isn’t right is one that throws out vulnerability count as a metric because of “more eyes” (which I have complained about before). Being open source may mean that more good guys have access to code reviews, but it also means more bad guys can get a leg up looking for flaws. The number of known vulnerabilities is ALWAYS a problem regardless of why they are there (incidnetally, again, that more eyes arguement is crap. Code reviews are a horribly inefficient way of finding flaws, and you never know when some poorly trained reviewer will comment out the functionality that actually makes your random function random).

So if all of these are a little right, what is the problem? I think it is really twofold. First, it makes it very hard to make an informed comparison of two platforms in terms of security and best fit for your org. Second, it makes it hard to gauge your own security and communicate that to people in and out of your organization. Both are pretty important, and a common, informative, metric benefits everyone (except those that look bad because of it).

Thinking about it I like:

[Ʃ (CriticalityModifier * Exposure)] / (nTotal * 10)

or, in English, the sum of Criticality of each vulnerability in the past twelve months * the number of days that the vulnerability was unpatched (patches that get rolled back don’t count), then divided by the total number of vulnerabilities times ten, to scale down the number a bit.

The criticality modifier is 0.5 for low, 1 for moderate, 2 for high, 3 for critical. As an example, if a hypothetical product had the following vulnerabilities over the past twelve months:

would give you (3*45 + 3*35 +3*4 +2*20 + 1*45 + 1*50 + 0.5*145 + 0.5*75) / (8 * 10) = 6.15 Security Rating.

This seems like a fair metric, as it measures a level of impact (the criticality, though this isn’t horribly quantitative) of the flaw, the days of exposure to the flaw, and the number of total flaws. What it does not take into account is likelihood, as I can’t come up with a good quasi-quantitive means to measure said likelihood (open to suggestions here).

Thoughts?

~ 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

Blizzard, makers of the extremely popular World of Warcraft game, now offer a token based authentication scheme to help with account hijacking. Two things strike me about this, first, that this is a freaking crazy world when hijacking WoW accounts is serious enough business to warrant this security and second, that we fundamentally need a better way of asserting identity when a FREAKING VIDEO GAME REQUIRES A TOKEN. I wrote a screed about that here, but I think this accentuates all the more a need for a new end to end method of asserting identity and establishing trust.

~ Joshbw

Perhaps I was a bit misleading in the title as this is a flaw in an internet connected coffee machine (why, oh why, do we need this) that allows, among other things, access to a connected PC.

There are a couple lessons in this. First, no matter how trivial your product, you very likely still need to worry about security if it connects to something that does have value. Second, your system is only as secure as all of the systems that connect to it, unless the system is inherently paranoid about connections. In this web 2.0 world of mashups, in the world of connected enterprise applications, our applications are not living in a bubble. They are connected to multiple other systems, and in most cases there isn’t a whole lot of thought that went into security over these connections. A web application may be horribly paranoid about anything it receives from the user, but then blindly accept data from internal systems without a thought. If any of those systems is flawed and you don’t validate input from them, your application is just as susceptible to attack as it would be if it didn’t validate user input.

This just further cements in my head the need to push threat modeling out to more people. I think the real value of threat modeling isn’t the complex threat trees that get built for risk analysis. I actually find those pretty worthless. I think the data flow diagram is the big thing. It is a convenient visual diagram showing where a process or feature is pulling data from and where it is sending the data to. Any source of data is a source of attack, and the DFD is a useful tool for identifying where further scrutiny is necessary. Any output source is a particular asset that might be attacked through your application. I think every dev spec should require a data flow diagram simply because it gets people thinking.

Finally, the last immediate lesson from this is that it is a scary time to be a client. The OS may be pretty solid but there are a million ways to execute code that seem perfectly valid from the OS point of view. Every connected application, any application that pulls data or opens data originally from a remote source, is a potential open door. If a freaking coffee machine can be a source of attack client security is in a lot of trouble.

~ Joshbw

Apple just released an update for quicktime, no surprise there. Doing some digging I found the five security issues patched:

Playing maliciously crafted QuickTime content in QuickTime Player may lead to arbitrary code execution

Viewing maliciously crafted Indeo video media content may lead to an unexpected application termination or arbitrary code execution

Opening a maliciously crafted PICT image file may lead to an unexpected application termination or arbitrary code execution

Opening a maliciously crafted AAC-encoded media content may lead to an unexpected application termination or arbitrary code execution

Opening a maliciously crafted PICT image file may lead to an unexpected application termination or arbitrary code execution

Five exploits, all in how a variety of media (video, audio, and picture) parses code. This tells me two things pretty much immediately- 1) Apple does not do a great deal of Fuzz testing on their formats, but researchers are happy to do so for them and 2) if I do fuzz testing on quicktime myself I will probably find something exploitable as well.

Fuzzing is a horribly brute force method for security testing. It requires a lot of work to wire things to adequately monitor an application (you want to see memory spikes, process spikes, and all of the myriad of crashes) and automate the loading of media. Regardless, it is very effective at breaking parsing and validation code. Microsoft requires 100,000 iteration on all parsed formats. For complex formats (office docs, media files), they basically never stop. Apple would be well served by doing the same (or caring about security at all).

Fuzzing is also applicable to web apps. They process an immense amount of data from end users, and other than specific known attacks done by pen testers, most companies don’t seem to test for various malformed input. The problem is that it is very hard to detect where and why something failed when fuzzing a remote machine. It would be nice to see a good distributed testing harness that can monitor the application state on the server and produce decent debugging logs.

~ 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