4 ms·

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
  - hedora 10y ago
    So redirecting all port 80 requests to https://<domain>/ https://<domain>/ (or otherwise kill port 80 on the server). Then, make sure each page view overwrites / clears any side-effecting session state. Put another way, why should unexpected cookies change the side effects of post requests? Anyway, if the browser is connecting via port 80, the MITM can just use a transparent http->https proxy to rewrite the referrer, and forward the request to the https server, so you've already lost.
    - innoying 10y ago
      I think you're misunderstanding the attack scenario here: > Anyway, if the browser is connecting via port 80, the MITM can just use a transparent http->https proxy to rewrite the referrer, and forward the request to the https server, so you've already lost. That wouldn't actually work since the user's active session cookie has the "Secure" flag set (i.e. isn't sent over HTTP). Sure if the user logged-in again on the HTTP page you could exploit this with a transparent proxy but there's very little outside of implementing HPKP that BitBucket could do to prevent that attack.
      - berdario 10y ago
        Exactly But even shutting down access to port 80 on the server wouldn't be enough: the attacker only needs the victim to send the request, it doesn't need for the plaintext request to actually reach the server (did you mean HSTS instead of HPKP, btw? The scenario I described didn't involve MITM of a HTTPS connection, and thus HPKP wouldn't be strictly needed ) also, I agree that the condition under which this check might be useful are quite convoluted... since Security is often in tension with Usability there is a case to be made for less defense-in-depth, and removing (potentially?) redundant checks... but I think we should be wary of making simplistic arguments for it, due to how delicate web app security is
        hedora 10y ago
        Agreed; killing port 80 just decreases the chances the browser makes subsequent port 80 requests. I still think the referrer is only helping paper over a deeper design flaw (using cookies to carry post state) at the expense of getting some users to trade privacy for availability, and decreasing performance/opening up attacks for people that install extensions as a workaround.
  - hedora 10y ago
    Ugh. HSTS / HPKP make my head hurt. Best practice on the client side is rapidly converging to 'make the web browser stateless', with things like tails, or just leaving private browsing mode on 100% of the time. Both those protocols are significantly weakened by stateless clients!
MrBuddyCasino 10y ago
Wasn't implying this, I meant it as "token sufficient, referrer of low value".

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
- hedora 10y ago
  So redirecting all port 80 requests to https://<domain>/ https://<domain>/ (or otherwise kill port 80 on the server). Then, make sure each page view overwrites / clears any side-effecting session state. Put another way, why should unexpected cookies change the side effects of post requests? Anyway, if the browser is connecting via port 80, the MITM can just use a transparent http->https proxy to rewrite the referrer, and forward the request to the https server, so you've already lost.
  - innoying 10y ago
    I think you're misunderstanding the attack scenario here: > Anyway, if the browser is connecting via port 80, the MITM can just use a transparent http->https proxy to rewrite the referrer, and forward the request to the https server, so you've already lost. That wouldn't actually work since the user's active session cookie has the "Secure" flag set (i.e. isn't sent over HTTP). Sure if the user logged-in again on the HTTP page you could exploit this with a transparent proxy but there's very little outside of implementing HPKP that BitBucket could do to prevent that attack.
    - berdario 10y ago
      Exactly But even shutting down access to port 80 on the server wouldn't be enough: the attacker only needs the victim to send the request, it doesn't need for the plaintext request to actually reach the server (did you mean HSTS instead of HPKP, btw? The scenario I described didn't involve MITM of a HTTPS connection, and thus HPKP wouldn't be strictly needed ) also, I agree that the condition under which this check might be useful are quite convoluted... since Security is often in tension with Usability there is a case to be made for less defense-in-depth, and removing (potentially?) redundant checks... but I think we should be wary of making simplistic arguments for it, due to how delicate web app security is
      - hedora 10y ago
        Agreed; killing port 80 just decreases the chances the browser makes subsequent port 80 requests. I still think the referrer is only helping paper over a deeper design flaw (using cookies to carry post state) at the expense of getting some users to trade privacy for availability, and decreasing performance/opening up attacks for people that install extensions as a workaround.
- hedora 10y ago
  Ugh. HSTS / HPKP make my head hurt. Best practice on the client side is rapidly converging to 'make the web browser stateless', with things like tails, or just leaving private browsing mode on 100% of the time. Both those protocols are significantly weakened by stateless clients!

MrBuddyCasino 10y ago

Wasn't implying this, I meant it as "token sufficient, referrer of low value".