3 ms·

Thanks for the explanation. Please excuse my ignorance, but I want to understand something: the 'html injection' phase would be done by some sort of response sp

by r4pha 13y ago

Thanks for the explanation. Please excuse my ignorance, but I want to understand something: the 'html injection' phase would be done by some sort of response spoofing? Also, given that I can write arbitrary javascript to their window, can't I just do something like form.onsubmit(function(){ //send credentials to my private server }); ?

peterwwillis 13y ago
Injection typically involves sniffing their connection and determining the right bits of the connection to be able to spoof your own fake response. It can be done in-between an existing connection or at the start of one. Browsers have developed all kinds of protections to prevent different kinds of attack. In general, if your cookies have been set with the HttpOnly flag, malicious javascript can not submit someone's cookies to any site other than the original domain (as far as the browser can tell). You can't even view the cookies in javascript to be able to submit them somehow else. But HTML forms on plaintext pages can be spoofed or injected to submit them to a fake server using SSL or to the real server without SSL, making it easy to view the form data and the server's response. If the site doesn't set the "secure" token on the cookie, existing session credentials can be viewed as well without needing to observe or force the user to log in. This is how the sslstrip program works, and why many people look to new technologies like HSTS to better protect users against these attacks. The SSL attack in the OP could be used against a site that employed HSTS to capture data from the body of a response if sslstrip failed. If you just want cookie data, the original CRIME attack would be better as it technically works on the headers AND the body, but CRIME depends on TLS compression being enabled, while this attack uses the compression of the body (that every website uses).
- meowface 13y ago
  >Also, given that I can write arbitrary javascript to their window, can't I just do something like form.onsubmit(function(){ //send credentials to my private server }); ? You didn't address this question of his, it seems. I would agree that in the scenario you're explaining, it would make far more sense for an attacker to simply modify the non-HTTPS landing page in such a way that the user hands his credentials in plaintext straight to the attacker. From what I can tell, for BREACH, you don't actually need to inject Javascript into any page belonging to the domain you want to extract secrets from; you simply need to force the user to load a hidden iframe that you control. That iframe will then make repeated GET requests to HTTPS endpoints (which does not violate the same origin policy, so this iframe can be hosted on any arbitrary domain).

by r4pha 13y ago

peterwwillis 13y ago

Injection typically involves sniffing their connection and determining the right bits of the connection to be able to spoof your own fake response. It can be done in-between an existing connection or at the start of one. Browsers have developed all kinds of protections to prevent different kinds of attack. In general, if your cookies have been set with the HttpOnly flag, malicious javascript can not submit someone's cookies to any site other than the original domain (as far as the browser can tell). You can't even view the cookies in javascript to be able to submit them somehow else. But HTML forms on plaintext pages can be spoofed or injected to submit them to a fake server using SSL or to the real server without SSL, making it easy to view the form data and the server's response. If the site doesn't set the "secure" token on the cookie, existing session credentials can be viewed as well without needing to observe or force the user to log in. This is how the sslstrip program works, and why many people look to new technologies like HSTS to better protect users against these attacks. The SSL attack in the OP could be used against a site that employed HSTS to capture data from the body of a response if sslstrip failed. If you just want cookie data, the original CRIME attack would be better as it technically works on the headers AND the body, but CRIME depends on TLS compression being enabled, while this attack uses the compression of the body (that every website uses).

meowface 13y ago
>Also, given that I can write arbitrary javascript to their window, can't I just do something like form.onsubmit(function(){ //send credentials to my private server }); ? You didn't address this question of his, it seems. I would agree that in the scenario you're explaining, it would make far more sense for an attacker to simply modify the non-HTTPS landing page in such a way that the user hands his credentials in plaintext straight to the attacker. From what I can tell, for BREACH, you don't actually need to inject Javascript into any page belonging to the domain you want to extract secrets from; you simply need to force the user to load a hidden iframe that you control. That iframe will then make repeated GET requests to HTTPS endpoints (which does not violate the same origin policy, so this iframe can be hosted on any arbitrary domain).