4 ms·
Correct me if I'm wrong, but it appears as though Django isn't the only framework/technology that is vulnerable to such an attack, they're just one of the first
by brokentone 13y ago
Correct me if I'm wrong, but it appears as though Django isn't the only framework/technology that is vulnerable to such an attack, they're just one of the first to provide a mitigation strategy (resulting in this post).
- steveklabnik 13y agoAny website that * Be served from a server that uses HTTP-level compression * Reflect user-input in HTTP response bodies * Reflect a secret (such as a CSRF token) in HTTP response bodies is vulnerable, regardless of technology. The mitigation strategies were given in the original paper[1], this announcement is just repeat of what's in there. That said, it's exactly the right thing to do, that's not a knock on Django. 1: http://breachattack.com/#mitigations http://breachattack.com/#mitigations
- homakov 13y ago> * Be served from a server that uses HTTP-level compression this is the only must-have. Last 2 exist almost in every website (everyone needs a CSRF token, everyone reflects something somewhere)
- steveklabnik 13y agoMy blog does not have CSRF tokens, and does not reflect user input. Many web _apps_ have these things, but many web sites do not.
- homakov 13y agosince it's attack on secrets then we don't even consider blogs and read only media as targets :)
- steveklabnik 13y agoAbsolutely, I'm just saying that your statement that it's the only must have is factually incorrect. I could include some sort of secret on every page, but since my blog doesn't reflect user input, it would be fine. I could also have a 'search' function that would reflect input, but without the secret in the body, the secret would be fine. All three parts are a must-have, even if they are incredibly common. Saying otherwise is misleading.
- jamoes 13y agoFrom my understanding (which may be wrong...), the requirement of "Reflect user-input in HTTP response bodies" is actually pretty important. If the application only does this on POST requests, then it should probably be fine. Since an attacker cannot formulate a valid POST without the CSRF token (assuming the app is using CSRF tokens correctly), then there is no way for an attacker to get this attack bootstrapped. If the application reflects GET request input in the response (eg `https://domain.tld?q=ASDF` https://domain.tld?q=ASDF` results in some `value="ASDF"` being included somewhere in the response), then it is indeed likely vulnerable. This allows the attacker to simply continually change the value of `ASDF` as they guess and check for some secret on the page. Of course, if your application is allowing untrusted POSTs to be made, then you will still have to worry about POST requests...
- homakov 13y agoyou're right, also, to make compression work, ASDF is not enough, attacker needs https://domain.tld?q=value="ASDF https://domain.tld?q=value="ASDF
- marshray 13y agoDon't forget the requirement that the site must use SSL/TLS in the first place! On the other hand, if you're saying that we just take this for granted these days, you have made me very happy. :-)
- artificialidiot 13y agoYou are right. The thing is, django doesn't have an image problem so it is fine to announce the attack that way.
- thatthatis 13y agoI'd argue that Django doesn't have an image problem BECAUSE they announce security vulnerabilities this way.
- jacobian 13y agoYes, 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.
- qznc 13y agoThere was an article on Rails, but no official announcement. https://news.ycombinator.com/item?id=6150535 https://news.ycombinator.com/item?id=6150535