Ви не можете ефективно відхиляти з'єднання, якщо не надасте кожному клієнту приватний ключ, який ви можете індивідуально відкликати. Але це, мабуть, надмірність. Вам не потрібно бронезахисне рішення, якщо більшість людей не потрудиться стріляти з кулі.
Це питання безпеки, тому опишемо модель загрози та стратегії пом'якшення.
Припустимо, у вас є URL-адреса, яка може спричинити за собою помітну вартість (наприклад, вартість обробки), і ви хочете захистити її як від простої атаки DoS, так і від програм copycat.
Використовуйте SSL, щоб приховати з'єднання від легкого аналізу. Використовуйте номер незахищеного порту, послідовність переспрямування, обмін файлами cookie, щоб трохи ускладнити з'єднання, перш ніж зробити дорогу частину запиту. Використовуйте секретний код, записаний у вашій програмі, щоб сервер знав, що він повинен прийняти з'єднання.
Тепер хтось не може дізнатись дорогої для потрапляння URL просто за допомогою запуску sniffer пакетів або перегляду рядків у коді, схожих на URL. Потенційний зловмисник повинен декомпілювати вашу програму.
Ви дійсно не можете захистити свій код від декомпіляції та / або запуску під налагоджувачем. Зрештою зловмисник дізнається секретний ключ та послідовність з'єднання.
Ви помічаєте, що починаєте отримувати запити на маршрутизацію за вашою дорогою URL-адресою: або у формі атаки, або у формі програми copycat, яка має доступ до вашої служби для запуску, або, можливо, код експлуатації публічно публікується. Ти не можеш сказати, що це неправдивий запит із законного запиту.
Створіть безкоштовне незначне оновлення для вашої програми за допомогою іншого секретного ключа. Він повинен містити іншу дорогу URL-адресу, яка обслуговує ті самі дані, що й URL-адреса, що скомпрометована. Деякий час зробіть обидві URL-адреси доступними.
Перегляньте свій базовий перемикач на оновлену версію Вимкніть скомпрометовану дорогу URL-адресу і врешті-решт її 404. Ви щойно пом'якшили порушення безпеки, сподіваємось, не втрачаючи занадто багато. Назад до квадратного.
Відмова: Я не є експертом з безпеки.