3 ms·

Yes, this was precisely my question. I agree with you that the post does a great job of explaining the how request smuggling works, and how they used it to tric

Yes, this was precisely my question. I agree with you that the post does a great job of explaining the how request smuggling works, and how they used it to trick Slack's server into responding to the user's client with a 301 redirect to the hacker's server. But then, when they got to the part where the cookies are sent, they just said, "and the cookies are sent" with no further explanation. That's the part I'm stuck on. Is there some browser behavior I'm not remembering where it sends sensitive cookies across domains just because one redirected the browser to the other?

Matt3o12_ 7y ago
I think this rather applies to API clients which can handle that differently. A quick test for python's shows that all headers are redirect regardless: requests.request("GET", "http://localhost/redirect-to?url=http%3A%2F%2Fhttpbin.org%2Fget", headers={"x-foo": "bar", "Cookies": "abc=dcv;"}).json() { "args": {}, "headers": { "Accept": "*/*", "Accept-Encoding": "gzip, deflate", "Cookies": "abc=dcv;", "Host": "httpbin.org", "User-Agent": "python-requests/2.22.0", "X-Amzn-Trace-Id": "Root=1-5e6bebe1-cd6e71729a818015a06aa7cb", "X-Foo": "bar" }, "origin": "91.58.8.128", "url": "http://httpbin.org/get" } I'm running a local copy of httpbin on localhost, so python's request should not send sensitive headers for redirects but it does. Golang is a bit more explicit about it's http client behavior: > • when forwarding sensitive headers like "Authorization", "WWW-Authenticate", and "Cookie" to untrusted targets. These headers will be ignored when following a redirect to a domain that is not a subdomain match or exact match of the initial domain. For example, a redirect from "foo.com" to either "foo.com" or "sub.foo.com" will forward the sensitive headers, but a redirect to "bar.com" will not. https://golang.org/pkg/net/http/#Client https://golang.org/pkg/net/http/#Client Though this might also cause problems if you are using sensitive non standard headers such as X-Token for token authentication, etc. So while you could probably mitigate this vulnerability on some clients, you are trusting the server to only redirect you to trusted URLs which is not the case here.
- bawolff 7y ago
  Hmm that would make sense. The user-agent header does have "slack" in it so probably not a web browser, and its not far fetched that most libraries dont implement the same origin policy when it comes to headers and redirects.
- kevin_thibedeau 7y ago
  "Cookies" is not a sensitive header in a request. "Cookie" is.

Matt3o12_ 7y ago

I think this rather applies to API clients which can handle that differently. A quick test for python's shows that all headers are redirect regardless: requests.request("GET", "http://localhost/redirect-to?url=http%3A%2F%2Fhttpbin.org%2Fget", headers={"x-foo": "bar", "Cookies": "abc=dcv;"}).json() { "args": {}, "headers": { "Accept": "*/*", "Accept-Encoding": "gzip, deflate", "Cookies": "abc=dcv;", "Host": "httpbin.org", "User-Agent": "python-requests/2.22.0", "X-Amzn-Trace-Id": "Root=1-5e6bebe1-cd6e71729a818015a06aa7cb", "X-Foo": "bar" }, "origin": "91.58.8.128", "url": "http://httpbin.org/get" } I'm running a local copy of httpbin on localhost, so python's request should not send sensitive headers for redirects but it does. Golang is a bit more explicit about it's http client behavior: > • when forwarding sensitive headers like "Authorization", "WWW-Authenticate", and "Cookie" to untrusted targets. These headers will be ignored when following a redirect to a domain that is not a subdomain match or exact match of the initial domain. For example, a redirect from "foo.com" to either "foo.com" or "sub.foo.com" will forward the sensitive headers, but a redirect to "bar.com" will not. https://golang.org/pkg/net/http/#Client https://golang.org/pkg/net/http/#Client Though this might also cause problems if you are using sensitive non standard headers such as X-Token for token authentication, etc. So while you could probably mitigate this vulnerability on some clients, you are trusting the server to only redirect you to trusted URLs which is not the case here.

bawolff 7y ago
Hmm that would make sense. The user-agent header does have "slack" in it so probably not a web browser, and its not far fetched that most libraries dont implement the same origin policy when it comes to headers and redirects.
kevin_thibedeau 7y ago
"Cookies" is not a sensitive header in a request. "Cookie" is.