Well, you announce that you are going to post a whole bunch of information, including technical details, in a whitepaper through I Hack Charities so that a whole slew of AppSec folks and web hackers go register. Then you notice that the registration is page is in the clear.

Now granted, the whole payment solution is through paypal, so other than your credentials there isn’t much to steal, but seriously Johnny, couldn’t you get Verisign to donate SSL certs for charity?

~ Joshbw

A blacklist file was found by an iPhone hacker and the internet is all abuzz over the possibility that Apple has a kill switch for applications. Well of course they do- Apple clearly shows by their insistance on the App store that they will control what gets run on the device- but I don’t think the blacklist file mentioned is that mechanism. Showing up in the location cache is a really sketchy area to put a file that blacklists applications, unless it is an exceptionally stupid instance of security through obscurity, so I think people misunderstand what it is for.

Now if I were Apple and I wanted complete control over what ran on the device I would only allow the device to run signed applications so that both the identity of the app author can be checked and the integrity of the binary can be scrutinized. I would insist on being the only CA, which I could do because all apps have to go through my store *anyway*, so why not include issueing certificates in the whole deal. I would then publish a certificate revocation list via SMS at regular intervals so that the user has no control of when an app gets blacklisted and I can count on it being pushed to the device.

This isn’t a foolproof design but it does provide pretty decent control over the platform. In essence it isn’t really any different from what console manufacturers do. People seem willing to accept that they don’t actually have control over the device the bought, and have certainly been willing to deal with the draconian oversight of cell carriers for years, so they would very likely accept this from Apple. So what if they suddenly lost they ability to use an application that they ultimately purchased from Apple?

Is this what Apple is doing? I don’t know. But given their aims it seems the best way to do it. I hate touch screen interfaces no matter how slick they are done, so I won’t be investigating myself.

~ Joshbw

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

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

Yes, its true, web applications scare the hell out of me.  Back in the grand old days of remotely exploiting rich client apps the attack of choice was buffer overflow (ignoring retarded macro attacks, for which the design was just ineptly flawed).  Sure, there were others, but at the time you could pretty much count on any given app having some unchecked buffer copy.  Today that is largely a solved problem, with static analysis tools being pretty damn good at finding such flaws.  Coupled with decent banned API rules, buffer overflows should be a solved problem, like small pox (don’t tell Apple or Adobe that though, they might actually get around to catch up with the rest of the world).  I find it laughable when a buffer overflow is found in modern software.

The thing is though, exploiting buffer overflows wasn’t trivial (well, pre-metasploit).  It actually required that a person have a decent understanding of how memory worked (so your average scripter or java developer was out in the cold) in order to craft an attack.

With web applications, the two vulnerabilities of choice are XSS and SQL Injection.  SQL Injection is pathetically simple to protect against and yet is horribly prevelent.  On a US UTF-8 only website that doesn’t need to accept HTML, XSS is also very easy to protect against (unfortunately it quickly gets complex when you internationalize, or decide to accept HTML).  These attacks are often disgustingly simple, but work well.

That concerns me a great deal, but a well designed website can put up a decent defense.  That isn’t what really scares me.  It is the fact that many of these web applications store very sensitive data, anything ranging from PII, to one’s entire collection of documents.  It isn’t just that the attacks are so simple, but that the payoff (or cost depending on which side of the coin you are on) is so large.

So enter something like Google, which wants to store your emails, health records, personal documents and files, payment information, and everything else you might value.  It takes one tiny little flaw and all of that is exposed.  It takes one well put together phishing site, and it is all exposed.

What keeps me awake at night is knowing how much there is to lose from one tiny little mistake.  What scares the hell out of me is how much data is stored, how sensitive it is, and how easy it is to find vulnerabilities and exploit.  For crying out loud, bots are doing SQL Injection attacks as we speak.

(what also scares me is that many people actually think HTML and Javascript in a browser creates a compelling competitor to rich client apps.  It will be a cold day in hell when a web app can provide even a marginally compelling experience versus the likes of Office.  Even flash and silverlight are poor replacements.  Adobe is high as a bloody kite if they think that an AIR version of Photoshop is a remotely good idea)

~ Joshbw

Reading a lot of Bruce Schneier recently, and his excellent take on the security mindset, as well as working on a full security development lifecycle at work that is focused on getting security into each stage of the application, I have security mindset on the, er, mind.  Bruce phrases it much better than me, but I think the security mindset is being able to see a scenario or situation and enumerate the potential mischief that could be enabled there.

So I see that Northwest is planning to try out paperless e-tickets using PDAs and similar smart devices.  Essentially the screen displays a version of the ticket to the screen and that gets scanned.  I already think that the current print your own ticket is ripe for abuse (for example, it wouldn’t be hard for me to make a fake ticket that got me through the ticket-required TSA checkpoint), but my mischievous little mind is already at work when going over scenarios that a dynamic screen that I control could present.  As an exercise for the reader, to flex that security mindset, what can go wrong here?

~ Joshbw

Jeff Atwood of Coding Horror posted a flawed article on why session expiration is bad.  The gist of his article is that it presents poor user experience which should trump the security concerns.  I will not deny that the user experience with session expiration is less than ideal, the whole idea of sessions to begin with is an ugly hack to get around the fact that HTTP is stateless and that the best end user authentication scheme that we have come up with is a login screen with easily stolen personal credentials.  Until a better scheme is brought up, which will be no small thing, it is something that we just have to live with.

That is not to say that the user experience can’t be improved.  Saving a session state, so that when the user is forced to authenticate again they don’t lose progress, is imminently doable and would improve the experience when sessions expire.  Getting rid of session expiration entirely is a horrible idea though.  Jeff seems to think that the risk of persistent sessions is someone sniffing the sessionID over the wire and that SSL/TLS completely mitigates that.  To me that is a low concern (sensitive data should always go over an encrypted channel, but network sniffing is rarely efficient anywhere outside of an intranet), relative to the threat of CSRF, cross site script attacks against the cookie storing the sessionID, and if the HTML 5 working group gets their way, XMLHttpRequest going across domains and passing cookies (fortunately it seems both FireFox 3 and IE 8 are inclined not to do so- take that Opera).  Regardless of how long the session is valid there is some risk from these attacks, but having persistent cookies extends the length of exposure after the sessionID has been compromised.

With the widespread presence of cross site scripting and the relative lack of protection against CSRF these are very really security concerns that are highly likely to be present on most websites.  If neither were present it would be safer to have longer sessions, but I think it would be naive to assume their absence.  Defense in Depth is a mantra for a reason.  Yeah, it sucks for the user somewhat, but erring on the side of usability is a Windows 98 style mistake.

What bothers me about Jeff’s post isn’t that a developer feels that way, sadly that is pretty common, but that a fairly competent developer with a large readership is evangelizing an unsafe practice.  It is, in effect, the same thing as Joel Spolsky of JoelOnSoftware fame advocating the avoidance of Exception Handling.  It is a bad practice and it concerns me that someone with such high visibility would actively be promoting it.  I think it also illustrates how security ignorant developers really are, when even such senior individuals don’t understand how bad a suggestion really is.  I could be wrong though, Jeff may understand- many of his past points stress usability and he could be of the mindset that usability trumps all other concerns (it is important, but it is one of many considerations that must be weighed).

~ Joshbw

So I upgraded WP to 2.5 and forgot that I tweaked how some of the Widgets outputted their HTML (it bugs me that I can’t just override the widget functions in my own PHP file, but sadly PHP doesn’t support such functionality).  Thus there is some formatting wonkiness in the standards compliant browsers (looks fine in IE 7 though; render what I mean not what I type) when I upgraded and overwrote my changes.  Fixes will be forthcoming when I have free time, but I am in the process of signing paperwork for a new place to live AND working on several projects at work AND working on several projects outside of work (like modifying phpBB to use prepared statements when the mysqli interface is available and when connecting to mysql > 3.0, since a friend of mine got burned by a retarded MOD that changed input without sanitizing it that in turn allowed for a SQL injection).  Thus free time is an undefined variable at the moment.

~ Joshbw