Мобильная версияКак определить запрос cURL и заблокировать его? Это невозможно? ⇐ Php
-
Гость
Как определить запрос cURL и заблокировать его? Это невозможно?
Один сайт с той же сферой, что и мой сайт, блокирует запросы cURL. Я читал, что сервер не может определить настоящий браузер и cURL. Это невозможно. И я хочу повторить их защиту от ботов и cURL-запросов для своего сайта.
Но это не просто глупая проверка user-agent. Им требуются полные заголовки копий, как в реальных браузерах, иначе вы получите следующее сообщение:
Если вы не бот, скопируйте отчет и отправьте его нам. команда поддержки
И это еще не конец, потому что если вы скопируете полные заголовки запросов браузера для cURL, вы получите пустую страницу с генерацией cookie (насколько я понимаю, это JWT или что-то в этом роде). Я проверил поведение браузеров: в браузерах есть этот файл cookie, но если это ваше первое подключение к их сайту, их сервер вернет заголовки set-cookie с этим JWT и обычной веб-страницей.
Я заметил, что Ethernet говорит - определение cURL-запроса невозможно, но в любом случае они могли бы это сделать, а я не знаю как. Это действительно интересно. Я думаю, как они это делают. Я сравнил заголовки ответов для cURL и реального браузера (для первого контакта):
Ответ заголовка для реального браузера:
HTTP/1.1 200 Сервер: nginx Дата: вторник, 19 сентября 2023 г., 15:42:12 по Гринвичу Тип контента: текст/html;charset=utf-8 Кодирование передачи: фрагментированное Соединение: поддержание активности Поддержание активности: тайм-аут = 15 set-cookie: spid=some_spid_value; Путь=/; Безопасный; SameSite=Нет set-cookie: spsc=some_spsc_value; Путь=/; Безопасный; SameSite=Нет варьироваться: Accept-Encoding кодировка контента: gzip строгая транспортная безопасность: максимальный возраст = 15724800; включить поддомены X-SP-CRID: 1909462187:1 Ответ заголовка для cURL (с копией заголовков запроса, как в реальном браузере):
HTTP/1.1 200 ОК Сервер: nginx Дата: вторник, 19 сентября 2023 г., 15:43:28 по Гринвичу Кодирование передачи: фрагментированное Соединение: поддержание активности Поддержание активности: тайм-аут = 15 контроль доступа-разрешить-происхождение: * контроль кэша: без кэша истекает: вторник, 19 сентября 2023 г., 15:4327 GMT прагма: без кэша тип контента: текст/html X-SP-CRID: 1913083470:1 Если сравнить эти заголовки, вы увидите, что помимо set-cookie сервер отправляет некоторые другие заголовки для cURL и браузера. Дополнительные заголовки для cURL: access-control-allow-origin, expires, cache-control, pragma. Дополнительные заголовки для браузера: vary, content-encoding, strict-transport-security. Это говорит об определении запросов cURL. Я повторил свой эксперимент с Postman и использовал те же заголовки реального браузера. И я получил тот же результат, что и с cURL.
Я не знаю, как они это делают, но думаю, они видят какую-то подпись запроса (может быть SSL или другие метаданные), а затем определяют, является ли это cURL или нет.
Один сайт с той же сферой, что и мой сайт, блокирует запросы cURL. Я читал, что сервер не может определить настоящий браузер и cURL. Это невозможно. И я хочу повторить их защиту от ботов и cURL-запросов для своего сайта.
Но это не просто глупая проверка user-agent. Им требуются полные заголовки копий, как в реальных браузерах, иначе вы получите следующее сообщение:
Если вы не бот, скопируйте отчет и отправьте его нам. команда поддержки
И это еще не конец, потому что если вы скопируете полные заголовки запросов браузера для cURL, вы получите пустую страницу с генерацией cookie (насколько я понимаю, это JWT или что-то в этом роде). Я проверил поведение браузеров: в браузерах есть этот файл cookie, но если это ваше первое подключение к их сайту, их сервер вернет заголовки set-cookie с этим JWT и обычной веб-страницей.
Я заметил, что Ethernet говорит - определение cURL-запроса невозможно, но в любом случае они могли бы это сделать, а я не знаю как. Это действительно интересно. Я думаю, как они это делают. Я сравнил заголовки ответов для cURL и реального браузера (для первого контакта):
Ответ заголовка для реального браузера:
HTTP/1.1 200 Сервер: nginx Дата: вторник, 19 сентября 2023 г., 15:42:12 по Гринвичу Тип контента: текст/html;charset=utf-8 Кодирование передачи: фрагментированное Соединение: поддержание активности Поддержание активности: тайм-аут = 15 set-cookie: spid=some_spid_value; Путь=/; Безопасный; SameSite=Нет set-cookie: spsc=some_spsc_value; Путь=/; Безопасный; SameSite=Нет варьироваться: Accept-Encoding кодировка контента: gzip строгая транспортная безопасность: максимальный возраст = 15724800; включить поддомены X-SP-CRID: 1909462187:1 Ответ заголовка для cURL (с копией заголовков запроса, как в реальном браузере):
HTTP/1.1 200 ОК Сервер: nginx Дата: вторник, 19 сентября 2023 г., 15:43:28 по Гринвичу Кодирование передачи: фрагментированное Соединение: поддержание активности Поддержание активности: тайм-аут = 15 контроль доступа-разрешить-происхождение: * контроль кэша: без кэша истекает: вторник, 19 сентября 2023 г., 15:4327 GMT прагма: без кэша тип контента: текст/html X-SP-CRID: 1913083470:1 Если сравнить эти заголовки, вы увидите, что помимо set-cookie сервер отправляет некоторые другие заголовки для cURL и браузера. Дополнительные заголовки для cURL: access-control-allow-origin, expires, cache-control, pragma. Дополнительные заголовки для браузера: vary, content-encoding, strict-transport-security. Это говорит об определении запросов cURL. Я повторил свой эксперимент с Postman и использовал те же заголовки реального браузера. И я получил тот же результат, что и с cURL.
Я не знаю, как они это делают, но думаю, они видят какую-то подпись запроса (может быть SSL или другие метаданные), а затем определяют, является ли это cURL или нет.
