An IDS can accept a packet that an end-system rejects. An IDS that does this makes the mistake of believing that the end-system has accepted and processed the packet when it actually hasn't. An attacker can exploit this condition by sending packets to an end-system that it will reject, but that the IDS will think are valid. In doing this, the attacker is ''inserting'' data into the IDS --- no other system on the network cares about the bad packets. Secnet IDS Section 3.1
Ma non capisco, se l'IDS riceve tutti i pacchetti e poi li passa al sistema finale, e in qualche modo il sistema finale ne elimina uno (credo con somma di controllo o qualcosa del genere?), quindi se è un La connessione TCP non dovrebbe attendere il sistema finale finché non ha tutti i pacchetti prima di inviarlo al livello dell'applicazione e elaborarlo?
Sto dicendo TCP perché nella parte Insertion di quel sito Web fornisce un esempio HTTP di questo attacco, ma se uno dei pacchetti è corrotto, come può il sistema finale elaborare quella richiesta HTTP prima che arrivino tutti i pacchetti? anche se utilizziamo i flag URG e PSH su TCP , il processo HTTP non dovrebbe attendere fino a quando tutti i pacchetti non arrivano prima di tradurre la richiesta HTTP e di eseguirla? Non capisco come possa funzionare? (Perché se traduce la richiesta prima di aspettare che i pacchetti siano in ordine, allora la richiesta potrebbe essere corrotta e non avere alcun significato)
Nell'esempio del sito web, invia GET /cgi-bin/pleasedontdetecttthisforme?
invece di GET /cgi-bin/phf?
ma non capisco ancora come il sistema finale traduca e elabori questa richiesta quando uno o alcuni pacchetti sono corrotti? (basato su regole TCP dovrebbe sempre aspettare prima che tutti i pacchetti siano OK e presenti prima di elaborarlo)