4 ms·
> the servers are chopping those careful requests up and sending them to random places. I understand that the backend is parsing different requests than the fr
by jorams 7y ago
> the servers are chopping those careful requests up and sending them to random places.
I understand that the backend is parsing different requests than the frontend, but I don't see how the cookies ever get sent to the attacker's domain.
I understand three requests as moving like this:
1. attacker -> frontend -> backend (partially) -> frontend -> attacker
2. victim -> frontend -> backend (including a bit of 1) -> frontend -> victim
3. (after 301) victim -> malicious server
The second request results in a 301, causing the victim's client to make a new request to the target of the 301. This new request does not include cookies, because it is to a different domain.
What am I misunderstanding? When do the cookies get sent to the malicious server?
- tptacek 7y agoAlongside a legitimate request with cookies, there is queued an evil request that uses mismatched Content-Length and chunked encoding headers to graft the body of the evil request to the envelope of the legitimate request. The evil body becomes the envelope for the entire legitimate request, and the evil envelope generates the redirect. Skip down to the "Explanation of malicious request" section.
- jorams 7y agoI get that the evil body essentially gets prefixed to the legitimate request, making the server generate the redirect, but this redirect is returned to the victim. The victim then makes a request to the malicious server, and this request should not contain cookies because the origin is different. How do the cookies get to the attacker?
- JangoSteve 7y agoAll of your explanation (which is appreciated) just further describes the request smuggling, not how that ends up sending the slack cookies to the hackers server. If you take all of this together, it's all leading to Slack's back-end server returning to the user's client a 301 response that tells the user's browser to send a new request to the hacker's domain. However, when the browser does this, it's to a different domain, so typically the slack cookies would not get sent with that request, unless I'm missing something. The "Explanation of malicious request" section doesn't explain this, either. All it explains is that all this effort was to get Slack's server to send a 301 response to the user's browser pointing to the hacker's server, but then it glosses over any information about how the cookies are getting sent with a single sentence, "and all cookies (including 'd') get redirected there too.... :(" My question is, how? Is something going on where Slack's back-end servers are explicitly setting response headers that allow their cookies to be sent to the hacker's domain? Is there some additional vulnerability that's allowing the browser to send the cookie across domains on a 301 redirect?
- justicz 7y agoIf you zoom in on the last image in the report, you see that the victim's client is not a web browser, but Slack's Electron-based client. Perhaps that client is willing to send Slack cookies cross-domain after a redirect for an auth'd request? Edit: looks like terom above me had the same idea before I did