Wywołania zwrotne (RPC)
Często model programowania wymaga wywołania zwrotnego serwera do klienta za pośrednictwem zdalnego wywołania procedury (RPC) lub wywołania klienta do niezaufanego serwera. Wprowadza to wiele potencjalnych pułapek.
Najpierw należy wykonać wywołanie zwrotne do klienta z wystarczająco niskim poziomem personifikacji. Jeśli serwer jest wysoce uprzywilejowaną usługą systemową, wywołanie klienta lokalnego z poziomem personifikacji personifikacji lub wyższym może zapewnić klientowi uprawnienia wystarczające do przejęcia systemu. Wywołanie klienta zdalnego z wyższym poziomem personifikacji niż jest to konieczne może również prowadzić do niepożądanych konsekwencji.
Po drugie, jeśli osoba atakująca wywołuje usługę w celu wykonania wywołania zwrotnego, może uruchomić to, co jest nazywane czarną— odmowa usługi. Takie ataki nie są specyficzne dla RPC; w tych atakach maszyna wywołuje wysyłanie do niego ruchu, ale nie odpowiada na żądania. Toniesz coraz więcej zasobów w wywoływanie czarnej, ale nigdy nie wracają. Jednym z ogólnych przykładów takiego ataku jest atak na poziomie TCP nazywany atakiem powodziowym TCP/IP SYN.
Na poziomie RPC występuje prosty atak czarnej, gdy osoba atakująca wywołuje interfejs i żąda od serwera wywołania interfejsu z powrotem. Interfejs jest zgodny, ale osoba atakująca nigdy nie zwraca wywołania: jeden wątek na serwerze jest powiązany. Osoba atakująca wykonuje to 100 razy, wiążąc 100 wątków na serwerze. W końcu serwer zabraknie pamięci. Debugowanie serwera może potencjalnie ujawnić tożsamość rozmówców czarnej, ale często serwer zostanie uruchomiony ponownie bez podejrzenia faul grać lub może nie mieć wystarczającej wiedzy, aby ustalić osobę atakującą.
Trzecia pułapka jest na kliencie. Często klient wykonuje wywołanie serwera informujące serwer o tym, jak wywołać go z powrotem (zazwyczaj powiązanie ciągów), a następnie czeka na wywołanie z serwera, ślepo akceptując każde wywołanie w tym punkcie końcowym, które twierdzi, że pochodzi z serwera. Protokół wywołania zwrotnego z serwera do klienta powinien zawierać pewien mechanizm weryfikacji, aby upewnić się, że po odebraniu wywołania zwrotnego do klienta faktycznie pochodzi on na serwerze.