3 ms·

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 us

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.
- ec109685 10y ago
  Generally your MITM scenario won't work. You won't have access to secure cookies to pass along in the attack. I do agree though if you can spoof arbitrary cookies, I don't see how you are secure from MITM attacks.
- hedora 10y ago
  The proxy would have to spoof the secure cookie flags (and also maybe rewrite JavaScript to request http instead of https) but MITM attacks are already costly, and bitbucket is a big, high value target; this is all within the reach of industrial espionage or state sponsored attack (or bored teens). I just read up on hsts and hpkp. They both seem pretty broken in the face of http MITM attacks (why aren't they part of the secure dns stuff?!?). Also, hpkp is often disabled for self signed and imported (private) CA certs. sigh. https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key... They both look much better than the django referrer hack though. Thanks for the pointer.
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!

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.
ec109685 10y ago
Generally your MITM scenario won't work. You won't have access to secure cookies to pass along in the attack. I do agree though if you can spoof arbitrary cookies, I don't see how you are secure from MITM attacks.
hedora 10y ago
The proxy would have to spoof the secure cookie flags (and also maybe rewrite JavaScript to request http instead of https) but MITM attacks are already costly, and bitbucket is a big, high value target; this is all within the reach of industrial espionage or state sponsored attack (or bored teens). I just read up on hsts and hpkp. They both seem pretty broken in the face of http MITM attacks (why aren't they part of the secure dns stuff?!?). Also, hpkp is often disabled for self signed and imported (private) CA certs. sigh. https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key... They both look much better than the django referrer hack though. Thanks for the pointer.

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!