Hacker Newsnew | comments | show | ask | jobs | submit | jacobian's commentslogin
jacobian 246 days ago | link | parent | on: Django 1.6 released

You may want to check out Invoke (https://github.com/pyinvoke/invoke); it's the successor to Fabric, and it's Python 3 compatible.

-----

twsted 246 days ago | link

For what I can see, Invoke is just a revamped version of Fabric’s task running components. Fabric 2.0 will "leverage Invoke for task running, leaving Fabric itself much more library oriented".

-----

mh- 246 days ago | link

HN appended that link: https://github.com/pyinvoke/invoke

-----


> IaaS providers don't do blog posts proudly declaring that they now support 3 year old technology.

http://aws.typepad.com/aws/2013/07/elastic-load-balancing-ad...

-----

jacobian 289 days ago | link | parent | on: 10x Engineer

How, exactly, is one supposed to cite unpublished research?

-----

btilly 289 days ago | link

The authors of the book were the ones who did the research for their consultancy. But you could easily cite Peopleware itself for the research.

-----

chii 289 days ago | link

tbh, qualitative research like this has no predictive power. It's just a (few) case studies. The variables that are in these case studies cannot be controlled for, nor tested and/or predicted. All it gives is some example anecdotes. Unfortunately, a lot of social science research end up like this, because of the complexity of the problem. Thus, i wouldn't cite peopleware as research, but as anecdotal examples, or case studies.

-----


Again, we believe that sessions and CSRF protection can be orthangonal (and that there are benefits to doing so). If you can prove otherwise, let us know!

There's also https://github.com/mozilla/django-session-csrf, an alternate CSRF implementation by Mozilla that does use session-linked CSRF tokens. So if you insist on "tokens must be session-linked", you can use that instead.

-----

homakov 338 days ago | link

sorry, I think in terms of Rails, in rails a session is a _site_sess cookie... i am not sure how it works in Django but what here is a post about it http://homakov.blogspot.com/2013/06/cookie-forcing-protectio...

https://github.com/mozilla/django-session-csrf seems ok, should be default

-----

JshWright 338 days ago | link

"i am not sure how it works in Django"

Perhaps you should do a little research before proclaiming things insecure?

-----

homakov 338 days ago | link

bitbucket is vulnerable > django has a problem

if it's not enough:

some websites from http://www.djangosites.org/ are vulnerable > django has a problem

-----

homakov 338 days ago | link

and yes, they clearly state it was made as a solution to cookie forcing:

>Your site is on a subdomain with other sites that are not under your control, so cookies could come from anywhere.

it should be default, for sure.

-----


Yes, that's correct, in theory BREACH can be used to target any sort of secret embedded in the body of an HTTP response. CSRF tokens are the most common type of secret in that category, but there are others. However, we can't speak authoritatively to The Web or All Web Frameworks or anything, but we can advise our users on how they can protect themselves.

-----


To your second point, security@djangoproject.com. It's documented in a bunch of places; where'd you look for it? I'll add it there, too :)

To the first point, we believe that Django's CSRF protection is as strong as session-linked CSRF protection, and adds CSRF protection to anonymous users (users without a session as well). In other words, it's a design decision, one that we believe doesn't compromise CSRF protection. If you believe otherwise, please get in touch (see above).

-----

homakov 338 days ago | link

1) session and logged in/out user are two different things. Session is the way you store information about current user, no matter he is anonymouse or logged in.

2) I checked again for instance https://bitbucket.org/ - edit csrftoken cookie to any, 123123 for example. Reload the page and if site keeps working - Cookie Forcing with MITM will do the same thing using http: injector Set-Cookie

not only MITM, subdomains can do precisely same thing. Either bitbucked uses old django or django is vulnerable to it (which is, well, a severe vulnerability imo)

-----

jacobian 338 days ago | link

1) I know the difference between sessions and logging in. I didn't say anything about logging in; I said that our CSRF protection protects users without sessions. Not all sites use sessions (some for performance reasons, others for privacy reasons); must those sites be vulnerable to CSRF?

2) First, you should report this to Bitbucket: https://www.atlassian.com/security. And c'mon, disclosing a possible CSRF vulnerability on a public board is kinda irresponsible. Is responsible disclosure not something you practice?

SecondI don't know what Bitbucket is running, exactly, and exrapolating from Bitbucket to Django is pretty lazy. Frameworks != sites. Once again, we've spent quite of bit of time validating the design and implementation of Django's CSRF protection, and we believe it works. If you find proof otherwise, can you please send it to security@djangoproject.com, and not post it to Hacker News?

-----

homakov 338 days ago | link

1) only to make sure we are on the same page. Now I see - we have different understanding of "session".

>Not all sites use sessions (some for performance reasons, others for privacy reasons);

what kind of site doesn't use sessions? To track a user you need a cookie right?

2) Frameworks != sites. As I used to think, only framework is responsible for CSRF protection, hence I extrapolated. I sent it to security@ as soon as I found this email. I am trying to not proclaim anything but some websites from http://www.djangosites.org/ are vulnerable.

-----

antihero 338 days ago | link

Could you clarify what actually can be done by this? From what I can see, you can't do XSS because it's escaped.

I guess there's the chance that you could do CSRF because you've essentially "set" their CSRF token?

-----

homakov 338 days ago | link

XSS? unrelated here I think.

Exactly, cookie forcing/tossing = "set" their CSRF token

-----

antihero 338 days ago | link

Ok, plausible attack I thought up based on what I could suck up from homakov's and various other posts:

1. User is browsing an HTTPS Django site and a HTTP site on WiFi.

2. Hacker is MITMing a connection (on WiFi), cannot decrypt SSL.

3. Changes user's CSRF token for Django via cookie-forcing.

4. Hacker can now use user's other HTTP session, and inject JS (or whatever) so their browser sends stuff to the HTTPS Django site, fully knowing their CSRF token (because we set it) and thus can forge requests easily.

Does Django mitigate something like that already? I think should be pretty easy to mitigate by using Django's signing to sign the session ID or something into the CSRF token?

-----

donaldstufft 338 days ago | link

An unrelated HTTP session cannot set a cookie for another domain (unless it's a subdomain in which you have the more serious issue of session theft or session fixation). The solution to both of these problems is HSTS with the includeSubDomains option.

-----

homakov 338 days ago | link

1) simulate request to http(NOT SECURE)://site.com 2) simulate response with Set-Cookie: csrf_token=123123;

> unless it's a subdomain in which you have the more serious issue of session theft or session fixation

elaborate plz? From what I know, subdomain can only do same attack (cookie tossing). Are you talking about phishing?

-----

antihero 338 days ago | link

Except we can set the cookie because we're already doing that to HTTPS requests via cookie-forcing.

-----

donaldstufft 338 days ago | link

I've just woken up and I haven't tested it, but off the cuff I believe HSTS will prevent the browser from trusting a plaintext HTTP response at all. So you cannot force a cookie if I understand the blog post correctly. You'd have to create a cookie inside of a verifiable HTTPS connection, which if you can do you've already executed a much worse attack.

-----

homakov 338 days ago | link

> but off the cuff I believe HSTS will prevent the browser from trusting a plaintext HTTP response at all

Cookies are broken (i write about it on my blog like, daily). The essential idea of Forcing is injecting cookies into HTTPS space from HTTP.

-----

antihero 338 days ago | link

I think this is what it hinges on:

http://scarybeastsecurity.blogspot.com.es/2008/11/cookie-for...

Is that possible under HSTS?

-----

donaldstufft 338 days ago | link

@homakov, so you can get a browser to trust a cookie from a HTTP response under a domain protected by HSTS?

-----

antihero 337 days ago | link

Doesn't HSTS just mean that the browser will just always make HTTPS responses?

-----


I have anecdotes about how CoCs have improved communities, but I don't really want to play dueling anecdotes with you. It sucks that you've seen Coc's used as a bludgeon; I haven't.

However, it's sorta irrelevant here: we're not expecting this to really change much of anything, and we don't think the community needs improving. Like the FAQ says, "we know that the Django community is open, friendly, and welcoming. We want to make sure everyone else knows it too." The goal here is to articulate and write down the standards that we already basically follow but have been (until now) unwritten.

In fact, if you're worried about having the book thrown at you, you should be happy about this change. Before today, if I thought you were being a jerk, I could throw you off IRC or the mailing list or whatever and that was that. I was, until a few hours ago, essentially sole arbiter of standards in the Django community, and those standards were ones that basically lived in my head until earlier this year.

Now, those standards are written down, and there's a process and some oversight to make sure I don't unilaterally decide someone's worth hitting with the ban-hammer.

So really, if you're honestly concerned about being people ousted for violated community policies, this sort of documentation and process should make you feel more comfortable, not less. We're replacing a BDFL-ship with open documentation, a committee, and organizational oversight.

-----

skore 343 days ago | link

I appreciate and agree with the points you are making. I really was talking general, it seems like my points were taken a little too much in a python or django related vein.

I do think there are inherent problems with a CoC. You state that the rules probably won't change anything and I agree with that. I think that shows the power of an implicit agreement of conduct. Because even if a CoC tries to inform that, I remain unconvinced that it can.

I suppose mostly what I have a problem with is the concept of expectation itself. A CoC is a lightning rod that is cited when people feel wronged. You sort of turn that around by saying that I might feel safer with explicit rules, but I could just as well argue that the more explicit the rules are, the more suspect they are to being misused or misinterpreted. Because what they do is create the explicit expectation that they will be upheld. What part of them and in what manner is subject to interpretation and those "toxic" people are usually quite inventive when it comes to finding such transgressions. Managing expectations like that can be a very tricky thing.

I might be biased by my experience here, but I've just seen a little too often how making conduct a high ranking concern can create a vacuum that attracts politics.

In the end, I'm quite certain that you are right with the beginning of your second paragraph. Although I would still say - If it's not needed and it won't change anything, then why have it? (And yes, I read your FAQ, so feel free to ignore this question ;-) )

-----


For the record: we reached out to Valerie, not the other way around. We did that because we value her opinion.

It's interesting to me that you seem so angry about a group that's trying to bring more people into tech. What are you worried about, exactly?

-----

sneak 344 days ago | link

Her agenda masquerades as something genuinely good and productive, yet pushes something orthogonal and unrelated. She's on a crusade.

Most of the women I know in tech loathe these sorts of concern-trolls for giving feminists erroneous reputations of being hard to work with.

Also, who's angry? I just think it's stupid to engage with such destructive people, but then again I don't participate in the Django community in any way so it doesn't affect me one way or the other.

Also, giving them credence and strengthening their brand serves to help them undermine actual equality in our industry, but, again, I'm male, so it doesn't directly affect me. It's still stupid, though.

-----

kingkilr 343 days ago | link

Please don't think of diversity as an issue that doesn't affect you, because you are a man. A lack of diversity affects all of us. More diverse groups perform better. If a lack of diversity is a result of artificial barriers being put into place (such as a community not welcoming new members), then that less the effect an individuals right to self-determiniation, and I believe that's an issue that effects all of us.

-----

sneak 343 days ago | link

That's precisely why I qualified it with "doesn't directly affect me".

-----

AdrianRossouw 343 days ago | link

i concur. i know a few female software developers who are completely comfortable amongst an all male group, but are terrified of speaking up when there is a mixed group.

This type of feminist, and the ada group are known for this kind of behaviour specifically, are wont to turn on their own :

http://violetblue.tumblr.com/post/44107008572/what-happened-... http://www.sciencebasedmedicine.org/i-am-not-your-enemy-an-o...

-----


You're completely right: these documents articulate a set of standards that we've essentially been following from day 1. Nothing's really changed except that now we've written down the unspoken rules that nearly everybody followed because, you know, they're good people.

It's an "explicit is better than implicit" kinda of thing!

-----


Can you identify specifically what you find patronizing and CYA-ish? Neither were our intentions; help me understand how we've failed there?

-----

jdc 344 days ago | link

Sorry, I realize I am being harsh, and am grateful for all the work of the Django community organizers. Let me clarify my previous remarks.

The items under the "Be careful in the words that you choose" heading (which make up a significant part of the document), except for maybe the doxing clause, addresses an apparently antisocial audience, which is patronizing.

And what I mean by CYA-ish, is that the intent of the code seems to be to prevent worst-case scenarios. Whereas the HN and Hacker School guidelines aim to boost the level of discourse and friendliness, the Django code offers suggestions on how to avoid getting arrested.

-----

More

Guidelines | FAQ | Lists | Bookmarklet | DMCA | News News | Bugs and Feature Requests | Y Combinator | Apply | Library | Contact

Search: