Live data from Hacker News

Hacking Github with Webkit

homakov.blogspot.com

61–70 of 82 posts

Re: Hacking Github with Webkit

#61

This 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…

did I say cookie tossing is something new?

If I would consider it as a new attack I would call it Homakov Cookie Tossing Attack. Now it's just cookie tossing.

Re: Hacking Github with Webkit

#62
post #50

Earlier quoted context omitted.

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.

> different than not using reset_session after authenticating a log in

if it's obvious for you — you are good at security. But it is NOT a common sense to use reset session

Re: Hacking Github with Webkit

#63
post #48

Earlier quoted context omitted.

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.

You can shadow other httponly cookies too. Any cookies.

Re: Hacking Github with Webkit

#64
post #39
post #38

Earlier quoted context omitted.

JS CSS HTML are very mixed in each other. It is very hard to allow only CSS/HTML.

May I recommend https://js-quasis-libraries-and-repl.googlecode.com/svn/trun... as a good read. It examines a system that can safely escape content based on its context, and forms the basis of one of the template packages of Go.

Thanks for the rec, this looks really good! Reminds me a lot of XHP.

Re: Hacking Github with Webkit

#66
post #38
post #36

Earlier quoted context omitted.

What about only letting users customise CSS and HTML? Can that be secure?

JS CSS HTML are very mixed in each other. It is very hard to allow only CSS/HTML.

Alright... what if they could only change the CSS, and not the HTML and JS? (Obviously not a solution for Github pages, but workable in some scenarios)

Re: Hacking Github with Webkit

#67
post #60

Earlier quoted context omitted.

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.

ты охуенен.

your posts are so entertaining, keep it up

Re: Hacking Github with Webkit

#68
post #65

Earlier quoted context omitted.

I believe that * .heroku.com points to * .herokuapp.com

https://www.google.com/search?q=site%3Aheroku.com&aq=f&#... About 598,000 results (0.23 seconds)

Some do redirect to * .herokuapp.com, though. For instance: http://blacklistapp.heroku.com redirects to http://blacklistapp.herokuapp.com. I wonder if they switched it over for newer instances?

Re: Hacking Github with Webkit

#70
post #59

Another 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 !

Ha, well in some ways the web is better: I generally don't get ads or annoying pop-ups or social sharing widgets, etc. CSS is often on a separate domain so most pages are unstyled and ugly, but pretty easy to read (usually just black text on white background).

But the downside is I had to open this page in a different browser to reply to you just now. And things like Gmail, GitHub, etc, I use in my other browser, but I try to keep the sites I use "unprotected" to a minimum.

On the whole, a fair trade-off I think.

Post reply on HN