Eine erfolgreiche Verbindung beweist laut Mustafayev nur eines: Der Client durfte die Pipe öffnen. Sie belegt nicht, dass es sich um die erwartete Anwendung handelt — ein anderer Prozess desselben Benutzerkontos hat exakt dieselben Rechte. Der Server müsse deshalb die Sicherheitsidentität hinter der Verbindung prüfen, statt sich auf Prozessnamen, Pfad der ausführbaren Datei oder die vermeintliche Geheimhaltung des Pipe-Namens zu verlassen.
Der Zugriff beginnt beim Security-Deskriptor. Die DACL der Pipe steuert den Zugang zu beiden Enden; Windows gleicht beim Verbindungsversuch das Zugriffstoken des Clients mit dieser Liste ab. Der Standard-Deskriptor sei riskant, weil er weiter gefasst sein kann als nötig. Breite Berechtigungen für Jeder, authentifizierte Benutzer oder alle interaktiven Nutzer öffnen die Pipe für unbeteiligte Prozesse.
Authentifizierung und Autorisierung müssen getrennt bleiben: Wer den Dienststatus abfragen darf, darf deshalb noch nicht den Dienst stoppen, geschützte Einstellungen ändern, Prozesse starten oder beliebige Dateien lesen. Jede sensible Operation gehört einzeln autorisiert.
Auch die Gegenrichtung zählt. Ein vorhersagbarer Pipe-Name ist nur eine Kennung und kein Geheimnis — ein Angreifer kann die Pipe unter dem erwarteten Namen anlegen, bevor der legitime Server startet, sodass der Client sich mit einem fremden Prozess verbindet. Die Option für die erste Pipe-Instanz hilft, einen bereits belegten Namen zu erkennen, ersetzt aber weder Zugriffskontrollen noch die Identitätsprüfung des Servers.
Zur zusätzlichen Absicherung lässt sich die Prozesskennung des Gegenübers über Windows-APIs ermitteln und mit QueryFullProcessImageName aus der kernel32.dll der Pfad der ausführbaren Datei bestimmen, geöffnet mit PROCESS_QUERY_INFORMATION oder PROCESS_QUERY_LIMITED_INFORMATION. Die erwartete Datei sollte in einem für Standardbenutzer nicht beschreibbaren Verzeichnis liegen; stärker wirkt eine Prüfung der Authenticode-Signatur, etwa über WinVerifyTrust, oder ein Abgleich mit einem freigegebenen Hash. PID- und Pfadprüfung bleiben jedoch nachrangige Kontrollen: Die Forschung hat gezeigt, dass sich die gemeldete PID eines Pipe-Clients fälschen und ein verbundenes Pipe-Handle an einen anderen Prozess übergeben lässt.
Impersonation kann Operationen im Sicherheitskontext des Clients ausführen — in .NET über NamedPipeServerStream.RunAsClient, nativ über ImpersonateNamedPipeClient. Der Server muss den Erfolg prüfen und RevertToSelf zwingend in einem finally-Block aufrufen. Scheitert die Impersonation, ist die Anfrage abzulehnen, keinesfalls still unter der privilegierten Dienstidentität weiterzuverarbeiten.
Nachrichten selbst gelten als nicht vertrauenswürdige Eingabe. Ohne strenge Prüfung wird der Dienst zum “verwirrten Stellvertreter”: Der Angreifer liefert die Anweisung, der Dienst die Privilegien. Empfohlen werden striktes Message-Framing mit Längenpräfix, begrenzte Nachrichtengrößen, Kommando-Allowlists, Schemavalidierung, Pfadnormalisierung, operationsspezifische Autorisierung und knappe Fehlercodes ohne Stacktraces oder interne Pfade. Vorsicht sei zudem bei symbolischen Links, Junctions, Reparse Points und Time-of-check/Time-of-use-Rennen geboten.
Ein weiteres Thema ist Verfügbarkeit: Wer alle Pipe-Instanzen belegt, Verbindungen offen hält oder unvollständige Nachrichten sendet, sperrt legitime Clients aus. Pipe-Puffer beanspruchen zudem nonpaged Pool im Kernel. Nötig sind Verbindungslimits, Zeitüberschreitungen, Abbruchmöglichkeiten, begrenzte Nebenläufigkeit und Ratenbegrenzung.
Schließlich sind Named Pipes nicht zwangsläufig lokal: Microsoft zufolge können sie aus der Ferne erreichbar sein, wenn der Serverdienst läuft. Für reine lokale IPC empfiehlt Mustafayev PIPE_REJECT_REMOTE_CLIENTS, ein Verweigern der Identität NT AUTHORITY\NETWORK sowie die Freigabe an die passende Anmelde-SID statt an breite Gruppen. Das Leitprinzip: Die Pipe soll die kleinstmögliche Schnittstelle zwischen zwei Vertrauensstufen bieten und Geschäftsoperationen statt Betriebssystem-Primitiven bereitstellen.