This answer is mostly about Chris Dixon's statement more than answering "How many attacks are coming from MiTM".
If we assert the different way one could possibly become MiTM and the given consequences I think we can make up some conclusions of whether or not we care how prevalent MiTM attacks is.
If we look at some risks for the different situations we could have something like:
- Someone stealing the database via exploiting the web application itself?
- Someone attacking user/admin via MiTM attack
I would say the first has a much bigger impact (generally) and should in many ways be mitigated the most and treated the first.
So for point 2 to prevail over point 1 I think that MiTM would really have to be crazy wild for us to value it as high as a security obstacle as point 1 (As Chris denotes in the quote)!
Now if we see at the different attack vectors. First for MiTM. To become MiTM one could for example:
- Own a rogue wireless access point. This is trivial, but for a targeted attack you would have to be in the same physical location of the victim using your webapp.
- Sniff unencrypted wireless data or data coming through a HUB (they even exist anymore?)
- Use ARP Poisoning to attack the users. Not trivial unless you are on the same network as the targeted users using your webapp.
- DNS Cache Poisoning. For this to work you need to poison the DNS being used by the targeted users. If the DNS is not properly set-up this attack becomes somewhat trivial to perform, however there is a lot to rely on for this to work.
- Phishing attacks. These still fool the unsuspecting and naive users, however a lot of the responsibility lies on the user.
All this for just attack one or a small subset of users. Even then, attacking these users will give them a warning in their browsers (there is ways to attack this as well, but I am not taking that up here). Only by compromising a root CA or by finding a flaw in the algorithm used to generate the certificates would you be allowed to pose as a trusted certificate issuer.
If we on the other hand look at all the potential nasty stuff that we can see if we don't invest in enough security of the webapp itself we see attack vectors like:
- SQL Injection - trivial and easy to both exploit and discover. Very high damage impact.
- XSS (Cross Site Scripting) - easy to discover, harder to exploit. I think we will see higher and higher user impact from this in the future. I foresee this is becoming the "new SQL Injection" trend that we have been seeing back in the days.
- CSRF (Cross Site Request Forgery) - Moderate to discover, moderate to exploit. This would require users navigating to an already owned site, triggering a request to your webapp which would do a transaction on the behalf of the user.
So by just mentioning these few, but popular methods for both attacking webapp and becoming MiTM I would leave it up to a specific risk/consequence analysis of the specific given organization you are trying to secure, whether or not you should defend your users directly by implementing SSL or by defending the webapp as a whole (which also include intellectual property, user data, sensitive data, potential data that could breach other applications, and so on).
So in my humble opinion I very much agree with Chris Dixon's statement. Prioritize securing the webapp as much as you can before you start thinking of securing the transport layer.
On a side note: Pages like Facebook, Gmail and others were under heavy MiTM attacks during the wake of Firesheep. This could only be mitigated through SSL and awareness.
However if you think about it, sniffing wireless traffic with Firesheep and hijacking the sessions would require the wireless LAN you are connected to to not have any encryption.
When I go war-driving today it has dramatically decreased the number of open wireless AP's and also in the number of WEP enabled AP's. We keep seeing more and more WPA2 encrypted AP's which in most cases provide us with enough security.
Now what is the risk of someone creating a easy and convenient tool for sniffing and hijacking your users sessions? What is the impact for those users? It also could be mitigated in different ways (re-authenticating the user when coming from different footprints at the same time, notifying the user when something looks wrong (gmail is a good example of this)).