8 ms·

Issue: Bitbucket relies on the Referer HTTP header

71 points by whyagaindavid 10y ago

Analemma_ 10y ago
Seems fairly clear that this is a Django issue, not a Bitbucket issue. Maybe change this link to point to the equivalent Django bug: https://code.djangoproject.com/ticket/16870 https://code.djangoproject.com/ticket/16870.
- chinathrow 10y ago
  Of course it's a 100% Bitbucket issue as seen as a user. I ran into the same issues while having some debug headers set. As a user I simply don't care what platform they use.
- 1_2__3 10y ago
  So when my car breaks down I should expect Toyota to say "sorry that's a Takata issue take it up with them"?
  - innoying 10y ago
    But that's not what happened here at all. Bitbucket has responded explaining why this (self-inflicted) bug exists (a security decision in an underlying framework) and deferred to the framework maintainers for further discussion because they have the best context on why that decision was initially made and under what scenarios it might be changed.
    - nickpsecurity 10y ago
      They chose to use a framework without understanding the implications of its security issues. When one comes up, they tell their users it's someone else's problem. Maybe they're an impoverished company that can't afford to pay to solve the problem. Or they dont care much.
    - cortesoft 10y ago
      It is an open source framework. They are free to patch the code.
  - geofft 10y ago
    A better analogy is you pump 100% ethanol into your gas tank, a sensor shuts it down, and you tell Toyota "This is actually perfectly safe for the engine for these reasons, here's why the engine manufacturer's safety document is wrong." I'd hope Toyota understands engines enough to have the ability to argue with you if they choose, but "The interlock is from the engine manufacturer and we're not going to overrule their judgment, please convince the engine manufacturer to remove the interlock" is a fine answer. After all, you could just pump normal fuel into your car, which does have harmful side effects but it's also what everyone does. It's not like the current situation makes your car inoperable or unsafe.
- marcosdumay 10y ago
  Bitbucket should not POST from HTTP to HTTPS. It's their issue to fix.
marcosdumay 10y ago
Well, you should not post from HTTP to HTTPS anyway. I highly doubt there is any good reason to do it anywhere, and on the one case you think you got a good reason (I still doubt it), don't try to anonymize the hell out of a logged-on request.
- ubercore 10y ago
  From memory when this came up, I think the concern is someone spoofing a non-HTTPS version of your site to trick a browser into posting to the HTTPS version? Someone that understands this stuff properly will need to chime in.
  - r1ch 10y ago
    It looks like Django relies on client-side tokens embedded in cookies for CSRF protection, there is no server-side state that the attacker has to guess. A MITM can trick someone to visit http://example.com/ http://example.com/, set their own token in a HTTP cookie for example.com, use the same token in the POST request to https://example.com https://example.com and it will pass validation, as cookies set over HTTP are still sent to HTTPS. Should be easy to mitigate this by using server-side CSRF state, or signing the tokens.
    - berdario 10y ago
      I'm a bit confused... I thought that Django always signed the CSRF tokens with the app's SECRET_KEY But upon looking at the code, it seems that the SECRET_KEY is only used to reseed the PRNG O_o https://github.com/django/django/blob/stable/1.10.x/django/utils/crypto.py#L54-L77 https://github.com/django/django/blob/stable/1.10.x/django/u...
      - ubercore 10y ago
        Secret key is used for signing. https://github.com/django/django/blob/master/django/core/signing.py#L156 https://github.com/django/django/blob/master/django/core/sig...
hedora 10y ago
Does anyone know of a good alternative to the atlassian suite? Given their price structure and popularity, I'd expect them to fix stuff like this in a timely fashion, and fix some basic UI issues. Bitbucket server (aka "stash") examples: - Create a pull request (the most common workflow in bitbucket) takes far too many page loads, and is buried in "hamburger"/"more options" - For teams with per-developer repos, it does not remember which repos the currently logged in user frequently uses, so you scroll through everone on the team's name for most operations. (And the new version "improved" this in some places with a JavaScript-heavy list that renders like molasses on no-gpu xeon vms). - Each product (bitbucket, jira, confluence) uses a different markup language. And so on. I could complain about other workflows or other products, but this is pretty typical for their stuff.
- circular_logic 10y ago
  I would be interested to know as well. To add to your list. If you need to scale up to huge intsances it hurts. Repo Clones take huge amount of resources for some reason, and updates require hours of downtime to spin the cluster up again. Aparrently there development team haven't even had a very large instance for test until late 2016 so fixing there issues is likely to take time.
  - rbbitbucket 10y ago
    Bitbucket product manager here. Sorry to hear you've been having trouble. What you describe is most definitely unusual so I'd suggest contacting us (or having your admin contact us) at support.atlassian.com so we can look into it. The team has spent a great deal of effort over the entire life of the product to ensure it performs at scale for broad range of load profiles. The notion that we only recently had a very large instance for test is untrue. Perhaps someone got the wrong idea from our most recent series on how we build Bitbucket Data Center to _already_ support massive scale: https://developer.atlassian.com/blog/2016/12/how-we-built-bitbucket-data-center-to-scale/ https://developer.atlassian.com/blog/2016/12/how-we-built-bi...
  - blibble 10y ago
    sounds exactly like jira and bamboo an empty jira instance on hardware meeting their recommended spec used to take 3+ minutes to start up
MrBuddyCasino 10y ago
Relying on the referrer header for CSRF protection is dubious at best. Just use a token like everybody else, protect against session fixation, call it a day.
- berdario 10y ago
  They are using a token, just like everyone else... this is just some added protection on top Let's not spread FUD :)
  - quantumtremor 10y ago
    It's not really any additional protection...how are you going to break a token? I've encountered this a few times on other sites, have to waste a few seconds messing around in my about:config.
  - hedora 10y ago
    But this isn't added protection. Here is the textbook list of security goals: - availability - integrity - confidentiality It breaks availability and confidentiality to protect against an attack that is already prevented by https. This is like installing an open ip cam and welding my padlock shut, then claiming you've improved my storage unit.
    - berdario 10y ago
      Have you read the discussion on security.stackexchange.com ? there's no decrease in availability by an attacker (there's only a self inflicted denial by the user) there's also no decrease in confidentiality for the service itself (and if the user uses an appropriate extension[0], or the browsers implement an appropriate whitelist mechanism, there's no confidentiality decrease for the user in general either) This is simply defense in depth If you leaked the SECRET_KEY/misconfigured the CSRF creation (which should be impossible, but it's the whole point of adding layers) AND the victim is being MITM AND you don't implement HSTS AND You correctly set cookies as Secure You would have a potential vulnerability, exploitable (only?) via CSRF, which this check prevents [0] like https://addons.mozilla.org/en-US/firefox/addon/smart-referer/ https://addons.mozilla.org/en-US/firefox/addon/smart-referer... but I'm not advocating for the use of this extension
unknownsavage 10y ago
I really don't think this is a big deal. I run a medium size website with well over 2000 uniques users per day and also require the referer header to use the website. So far, I've yet to receive a single complaint or find a browser that doesn't send it. It might be optional as per the spec, but it's completely ubiquitous at this point, and provides an easy way to add an extra layer of safety for web developers.
deleted 10y ago
[deleted]
bsusuabw 10y ago
Twitter does this. If you filter all referrers, all Ajax requests fail (even posting something).
i386 10y ago
How dare Bitbucket have a bug in their code while the rest of us live and breath standards compliant perfection?

71 points by whyagaindavid 10y ago

Seems fairly clear that this is a Django issue, not a Bitbucket issue. Maybe change this link to point to the equivalent Django bug: https://code.djangoproject.com/ticket/16870 https://code.djangoproject.com/ticket/16870.

chinathrow 10y ago
Of course it's a 100% Bitbucket issue as seen as a user. I ran into the same issues while having some debug headers set. As a user I simply don't care what platform they use.
1_2__3 10y ago
So when my car breaks down I should expect Toyota to say "sorry that's a Takata issue take it up with them"?
- innoying 10y ago
  But that's not what happened here at all. Bitbucket has responded explaining why this (self-inflicted) bug exists (a security decision in an underlying framework) and deferred to the framework maintainers for further discussion because they have the best context on why that decision was initially made and under what scenarios it might be changed.
  - nickpsecurity 10y ago
    They chose to use a framework without understanding the implications of its security issues. When one comes up, they tell their users it's someone else's problem. Maybe they're an impoverished company that can't afford to pay to solve the problem. Or they dont care much.
  - cortesoft 10y ago
    It is an open source framework. They are free to patch the code.
- geofft 10y ago
  A better analogy is you pump 100% ethanol into your gas tank, a sensor shuts it down, and you tell Toyota "This is actually perfectly safe for the engine for these reasons, here's why the engine manufacturer's safety document is wrong." I'd hope Toyota understands engines enough to have the ability to argue with you if they choose, but "The interlock is from the engine manufacturer and we're not going to overrule their judgment, please convince the engine manufacturer to remove the interlock" is a fine answer. After all, you could just pump normal fuel into your car, which does have harmful side effects but it's also what everyone does. It's not like the current situation makes your car inoperable or unsafe.
marcosdumay 10y ago
Bitbucket should not POST from HTTP to HTTPS. It's their issue to fix.

marcosdumay 10y ago

Well, you should not post from HTTP to HTTPS anyway. I highly doubt there is any good reason to do it anywhere, and on the one case you think you got a good reason (I still doubt it), don't try to anonymize the hell out of a logged-on request.

ubercore 10y ago
From memory when this came up, I think the concern is someone spoofing a non-HTTPS version of your site to trick a browser into posting to the HTTPS version? Someone that understands this stuff properly will need to chime in.
- r1ch 10y ago
  It looks like Django relies on client-side tokens embedded in cookies for CSRF protection, there is no server-side state that the attacker has to guess. A MITM can trick someone to visit http://example.com/ http://example.com/, set their own token in a HTTP cookie for example.com, use the same token in the POST request to https://example.com https://example.com and it will pass validation, as cookies set over HTTP are still sent to HTTPS. Should be easy to mitigate this by using server-side CSRF state, or signing the tokens.
  - berdario 10y ago
    I'm a bit confused... I thought that Django always signed the CSRF tokens with the app's SECRET_KEY But upon looking at the code, it seems that the SECRET_KEY is only used to reseed the PRNG O_o https://github.com/django/django/blob/stable/1.10.x/django/utils/crypto.py#L54-L77 https://github.com/django/django/blob/stable/1.10.x/django/u...
    - ubercore 10y ago
      Secret key is used for signing. https://github.com/django/django/blob/master/django/core/signing.py#L156 https://github.com/django/django/blob/master/django/core/sig...

hedora 10y ago

Does anyone know of a good alternative to the atlassian suite? Given their price structure and popularity, I'd expect them to fix stuff like this in a timely fashion, and fix some basic UI issues. Bitbucket server (aka "stash") examples: - Create a pull request (the most common workflow in bitbucket) takes far too many page loads, and is buried in "hamburger"/"more options" - For teams with per-developer repos, it does not remember which repos the currently logged in user frequently uses, so you scroll through everone on the team's name for most operations. (And the new version "improved" this in some places with a JavaScript-heavy list that renders like molasses on no-gpu xeon vms). - Each product (bitbucket, jira, confluence) uses a different markup language. And so on. I could complain about other workflows or other products, but this is pretty typical for their stuff.

circular_logic 10y ago
I would be interested to know as well. To add to your list. If you need to scale up to huge intsances it hurts. Repo Clones take huge amount of resources for some reason, and updates require hours of downtime to spin the cluster up again. Aparrently there development team haven't even had a very large instance for test until late 2016 so fixing there issues is likely to take time.
- rbbitbucket 10y ago
  Bitbucket product manager here. Sorry to hear you've been having trouble. What you describe is most definitely unusual so I'd suggest contacting us (or having your admin contact us) at support.atlassian.com so we can look into it. The team has spent a great deal of effort over the entire life of the product to ensure it performs at scale for broad range of load profiles. The notion that we only recently had a very large instance for test is untrue. Perhaps someone got the wrong idea from our most recent series on how we build Bitbucket Data Center to _already_ support massive scale: https://developer.atlassian.com/blog/2016/12/how-we-built-bitbucket-data-center-to-scale/ https://developer.atlassian.com/blog/2016/12/how-we-built-bi...
- blibble 10y ago
  sounds exactly like jira and bamboo an empty jira instance on hardware meeting their recommended spec used to take 3+ minutes to start up

MrBuddyCasino 10y ago

Relying on the referrer header for CSRF protection is dubious at best. Just use a token like everybody else, protect against session fixation, call it a day.

berdario 10y ago
They are using a token, just like everyone else... this is just some added protection on top Let's not spread FUD :)
- quantumtremor 10y ago
  It's not really any additional protection...how are you going to break a token? I've encountered this a few times on other sites, have to waste a few seconds messing around in my about:config.
- hedora 10y ago
  But this isn't added protection. Here is the textbook list of security goals: - availability - integrity - confidentiality It breaks availability and confidentiality to protect against an attack that is already prevented by https. This is like installing an open ip cam and welding my padlock shut, then claiming you've improved my storage unit.
  - berdario 10y ago
    Have you read the discussion on security.stackexchange.com ? there's no decrease in availability by an attacker (there's only a self inflicted denial by the user) there's also no decrease in confidentiality for the service itself (and if the user uses an appropriate extension[0], or the browsers implement an appropriate whitelist mechanism, there's no confidentiality decrease for the user in general either) This is simply defense in depth If you leaked the SECRET_KEY/misconfigured the CSRF creation (which should be impossible, but it's the whole point of adding layers) AND the victim is being MITM AND you don't implement HSTS AND You correctly set cookies as Secure You would have a potential vulnerability, exploitable (only?) via CSRF, which this check prevents [0] like https://addons.mozilla.org/en-US/firefox/addon/smart-referer/ https://addons.mozilla.org/en-US/firefox/addon/smart-referer... but I'm not advocating for the use of this extension

unknownsavage 10y ago

I really don't think this is a big deal. I run a medium size website with well over 2000 uniques users per day and also require the referer header to use the website. So far, I've yet to receive a single complaint or find a browser that doesn't send it. It might be optional as per the spec, but it's completely ubiquitous at this point, and provides an easy way to add an extra layer of safety for web developers.

deleted 10y ago

[deleted]

bsusuabw 10y ago

Twitter does this. If you filter all referrers, all Ajax requests fail (even posting something).

i386 10y ago

How dare Bitbucket have a bug in their code while the rest of us live and breath standards compliant perfection?