콜백(RPC)

프로그래밍 모델은 RPC(원격 프로시저 호출) 또는 신뢰할 수 없는 서버에 대한 클라이언트 호출을 통해 클라이언트에 대한 서버 콜백이 필요한 경우가 많습니다. 이로 인해 많은 잠재적인 문제가 발생합니다.

첫째, 클라이언트에 대한 콜백은 충분히 낮은 가장 수준으로 이루어져야 합니다. 서버가 권한이 높은 시스템 서비스인 경우 가장 수준 이상의 가장을 사용하여 로컬 클라이언트를 다시 호출하면 클라이언트에 시스템을 인수하기에 충분한 권한을 제공할 수 있습니다. 필요 이상으로 가장 수준이 높은 원격 클라이언트를 다시 호출하면 바람직하지 않은 결과가 발생할 수도 있습니다.

둘째, 공격자가 서비스에 콜백을 수행하도록 유도하는 경우 블랙홀(서비스 거부) 공격을 시작할 수 있습니다. 이러한 공격은 RPC에만 해당되지 않습니다. 이러한 공격에서 컴퓨터는 트래픽을 보내도록 유도하지만 요청에 응답하지는 않습니다. 당신은 블랙홀을 호출에 점점 더 많은 자원을 싱크, 하지만 그들은 다시 오지 않는다. 이러한 공격의 일반적인 예 중 하나는 TCP/IP SYN 홍수 공격이라는 TCP 수준 공격입니다.

RPC 수준에서 공격자가 인터페이스를 호출하고 서버에 인터페이스를 다시 호출하도록 요청할 때 간단한 블랙홀 공격이 발생합니다. 인터페이스는 규정을 준수하지만 공격자는 호출을 반환하지 않습니다. 서버의 한 스레드가 연결됩니다. 공격자는 이 작업을 100번 수행하여 서버에 100개의 스레드를 연결합니다. 결국 서버의 메모리가 부족합니다. 서버를 디버깅하면 잠재적으로 블랙홀 호출자의 ID가 드러낼 수 있지만, 파울 플레이를 의심하지 않고 서버를 다시 시작하거나 공격자를 결정하기에 충분한 전문 지식이 없을 수 있습니다.

세 번째 문제는 클라이언트에 있습니다. 종종 클라이언트는 서버에 다시 호출하는 방법(일반적으로 문자열 바인딩)을 알리는 서버를 호출한 다음 서버의 호출이 도착할 때까지 기다렸다가 서버에서 온 것으로 주장하는 해당 엔드포인트에 대한 호출을 맹목적으로 수락합니다. 서버에서 클라이언트로의 콜백 프로토콜에는 콜백이 클라이언트에 올 때 실제로 서버에서 시작되었는지 확인하는 몇 가지 확인 메커니즘이 포함되어야 합니다.