Security Dependencies

There's been an interesting little tempest in a teapot going on WRT IE and Firefox. I in general don't pay a whole lot of attention to the browser vuln du jour, but this one caught my eye - https://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9027718&intsrc=news_ts_head. A fun link within the article is to Jesper's blog - https://msinfluentials.com/blogs/jesper/archive/2007/07/20/hey-mozilla-quotes-are-not-legal-in-a-url.aspx.

You can go read the gory details for yourselves, but the gist of things is that IE isn't pre-validating input passed off to a URL handler, and neither is Firefox. What I think is somewhat interesting about the whole thing (aside from the amusement value) is taking a threat modeling approach. Frank Swiderski and Window Snyder wrote a rather dry book entitled "Threat Modeling" which we've used as the core reference for a lot of the threat modeling work that goes on at Microsoft. Michael Howard and Steve Lipner's SDL book is a bit more recent and I think more useful – I also have some ideas about improving on TM's that I should blog about later. At any rate, it's the same Window Snyder (how many could there be?) as now works for Mozilla and claimed IE ought to be pre-validating inputs for Firefox's URL handler. A bit of ad-hoc threat modeling seems in order, since this is an interesting exercise.

One of the bits of background information needed to conduct a threat model is the external dependencies – in here, we list what we depend on, and what we expect them to do. An extremely critical part of a threat model is to ensure that the item we're depending on actually agreed to do what we expected. When we're looking for problems here, trying to find mismatches between what someone expects in their external dependencies and what the external dependency actually guarantees is often a productive source of things to go tidy up.

Thus if we're following along with how Frank and Window say to do threat modeling, and were going to threat model some generic URL handler, we might have an external dependency on the browser that's invoking us. The problem is that it could be any browser. We might notice that some browsers might present the user with scary warnings, and so on, but what we should build on is what's guaranteed. If IE or Firefox have some behavior, that's interesting to note, but you could be hosted by DavidsDodgyBrowser that doesn't check anything. Or worse yet, you could be hosted by TomsVulnFinder browser that's just really rude and gives you obnoxious inputs. It's pretty clear that a URL handler would be making mistakes if it assumed anything about how well formed its inputs were, given that there's no telling what sort of browser it might be interacting with. I'm surprised at Window, since her recent statements are clearly in conflict with her own book. (If you find I'm in conflict with my books, I'll either fess up or blame it on Michael <g>)

Something else that's worth pointing out since I do have to ship code here and there is that we can never consider security in a vacuum. We also have to worry about app compat, usability and performance. If a browser started munging things passed off to a URL handler, what happens when someone built the CriticalBusinessApp URL handler? What if that app happened to _need_ quotes coming in? If we look at things from the browser's point of view, there's no telling what a custom URL handler may or may not be doing, and if we go changing any of the inputs, who knows what could break? Murphy's Law says it would cripple a large financial customer who spends a lot of money with us and cause millions of dollars of losses per hour. You really don't want to be the support person to handle that one.

I apologize for not blogging much recently, but most of my spare time has been spent on my horse, and this doesn't seem like the right blog to discuss how my endurance riding season is going.