securecookies with malicious values over HTTP - with disastrous consequences for most of the contemporary web apps.
- Plugin SOP problems: similarly to cookies, the variants of same-origin access rules implemented by plugins such as Java, Flash, or Silverlight, are often peculiar - and do not necessarily respect the isolation between encrypted and non-encrypted content (but share the cookie jar and document cache with the rest of the browser).
- Cache poisoning: browser cache persists across network visits. On insecure wireless networks, malicious active content can be persistently cached in any non-encrypted origin - even if that origin is not intentionally visited - and will be carried onto trusted networks accessed later on (e.g., home or corporate environments); in other words, your browser may be essentially permanently backdoored after a single visit to a public hotspot. Curiously, there is some renewed interest in this area of recent. HTML5 features such as cache manifests and local storage promise to make the problem even more pronounced.
- Cache retrieval: for the same reason, content injected over insecure wireless networks can comprehensively enumerate and read back all previously stored objects in browser cache, in arbitrarily selected non-encrypted origins - a huge privacy problem for as long as any remotely sensitive data is still exchanged over HTTP - even when this exchange itself happens only over private, secure networks.
- Address bar autocompletion poisoning: even with mechanisms such as Strict Transport Security in place, content injected over insecure networks may attempt to silently poison address bar autocompletion mechanisms - ensuring that future attempts to navigate to a particular website will be completed in a subtly incorrect way, and will take the victim to a malicious domain name instead.
PS. As of today, encrypted 802.11 is not much better for this use: the fiasco of WEP aside, on WPA2-PSK networks with publicly advertised key, insiders may simply decode and modify traffic to other clients by watching the handshake; while other authentication systems may be vulnerable to "Hole 196". On top of that, attackers may opt to impersonate "trusted" access points as seen fit. These shortcomings are incredibly frustrating - but can be addressed; in fact, some proprietary workarounds seem to be available already.