TCP Hijacking and conflicting data handling on the OS level

Question

Assuming I perform a TCP hijacking attack, by having access to the wire on which packets are being transmitted. In practice, the party to which I'm sending the hijack packet is going to receive the data of the specific sequence number twice - once from my hijack packet and another from the other party.

What does the TCP specification say would be the right way to handle the conflicting data? Is the Operating System supposed to take the first copy of the data, the last copy, or is it unspecified? If unspecified, what's the common implementation in practice for most Operating Systems?

I know that when loosing the race to inject my packet into the session, my data arrives second but it's ignored by the application. However, this doesn't give me any indication on whether this is because the application already read the data from the buffer of the operating system, or whether it's just ignored by the operating system and so it doesn't matter when does the application read the data.

Currently, if I'm trying to hijack a non-secure HTTP session and redirect it to a different site, I send an HTTP redirection and make sure to close the connection - to avoid relying on this sort of implementation detail on the side of the TCP stack. However, I wonder if this is really needed.

Answer 1

The premise of TCP is that it handles connectivity-layer things and limits the application's exposure to a reliable data stream. Therefore, these things are taken care of at the OS level for TCP (but not, say, UDP).

The TCP stack should discard duplicate packets and data (e.g., overlapping packets) before the application sees them. TCP relies upon sequence numbers to determine if data is duplicated, in part or in whole, and will discard any duplicated data. To quote RFC 793:

At the receiver, the sequence numbers are used to correctly order segments that may be received out of order and to eliminate duplicates.

and

Initial tests on arrival are used to discard old duplicates, but further processing is done in SEG.SEQ order. If a segment's contents straddle the boundary between old and new, only the new parts should be processed.