What a load of crap. The chances that github doesn't call reset_session are zero which means this doesn't work.
why should it call reset_session, my little sweet troll?
Hacking Github with Webkit
51–60 of 82 posts
Re: Hacking Github with Webkit
#52Re: Hacking Github with Webkit
#53Re: Hacking Github with Webkit
#54Earlier quoted context omitted.
why should it call reset_session, my little sweet troll?
i say more: this vuln worked fine. wait. github is STILL vulnerable. and i have an exploit
You offered no proof that this actually works and being defeated by a reset_session makes it way more likely it doesn't work.
Re: Hacking Github with Webkit
#55Wouldn't a solution be for the server to set its session cookie for every subdomain, as HTTP-only? For example, set "_gh_sess" for every requesting domain, whether www.github.com, github.com, something.github.com; and ".github.com" as well. If you hit them all, you prevent js from shadowing them.
no, it's already httponly. There is NO WAY to secure your subdomains from such vuln.
Github only sets their cookie for "github.com". What I'm suggesting is that they set multiple http-only cookies: one for "github.com", one for ".github.com", another for every subdomain you access -- "pages.github.com", etc. If there's already an http-only _gh_sess cookie for every subdomain I can put scripts on, I won't be able to shadow it with my own _gh_sess cookie.
Re: Hacking Github with Webkit
#56This is not new[1], but interesting that github didn't think about this when they set-up gh-pages.
It's hard to blame them though. Security is easy to miss. Myself and many other people who use github, and who understand those issues, don't really think about it until someone points this out...
[1] http://security.stackexchange.com/q/12412/7306 - just an example of a discussion about this very same issue from about a year ago (and it wasn't new even then)
EDIT: layout
Re: Hacking Github with Webkit
#57What a load of crap. The chances that github doesn't call reset_session are zero which means this doesn't work.
Given the first vulnerability, which stemmed from poor defaults in Rails and Github using said defaults, I wouldn't be surprised if it were affected by this.
Not using attr_accessible is a lot different than not using reset_session after authenticating a log in. It's very easy to forget or not notice a model missing some whitelisting but to roll your own authentication code with zero security investment is just stupid and I would be extremely surprised if GitHub doesn't do it.
Re: Hacking Github with Webkit
#58Another interesting post from homakov. Thanks so much for posting these as I learn a lot.
A few months back didn't your blog do something devious to people who read it? (Oh, yeah! It was signing people out of their Google accounts, I think?) Anyway, now I'm leery of clicking any links to homakov.blogspot.com.... :-p
I do think I'm safe from you, though. I browse with cookies off, NoScript enabled (except for small whitelist), and RequestPolicy blocking cross-site requests. Homakov, can you think of any sort of exploits I'd be vulnerable to when browsing the web?
Re: Hacking Github with Webkit
#59Another interesting post from homakov. Thanks so much for posting these as I learn a lot. A few months back didn't your blog do something devious to people who read it? (Oh, yeah! It was signing people out of their Google accounts, I think?) Anyway, now I'm leery of clicking any links to homakov.blogspot.com.... :-p I do think I'm safe from you, though. I browse with cookies off, NoScript enabled (except for small wh…
RequestPolicy is OK, cookies off is better.. but how can you use the web !
Re: Hacking Github with Webkit
#60Earlier quoted context omitted.
i say more: this vuln worked fine. wait. github is STILL vulnerable. and i have an exploit
You offered no proof that this actually works and being defeated by a reset_session makes it way more likely it doesn't work.
i tried it on me and on friends, it works
want a personal proof? $3000.